Prusa I3mk3 Z Calibration Axis Failure, Bearing OK, Moves Smoothly, PINDA OK, Cables OK, Still fails.

[Solved] Prusa I3mk3 Z Calibration Axis Failure, Bearing OK, Moves Smoothly, PINDA OK, Cables OK, Still fails.  

Active Member

Hello All!

We have a Prusa I3mk3 we have used for almost a year now without any serious issues, It started getting noisier with time, we noted the bearings were dry and starting to scratch the rods, so we took them out, cleaned them greased them and rotated the rods, we assembled again and printed for about two weeks without any issues.

Then gradually we started getting seeing some issues with the Z movement, it would home midway,  Z would go up normally then stop randomly while going down, at the beginning we restarted the printer and then it was fine, however now it is always doing it and doesn´t come down at all. 

"Calibration failed check the axes and run again"

Tested on Firmware 3.6 and 3.7
PINDA probe has been tested according to Prusa instructions and seems to be working well
We checked PINDA and motor cables all OK, same with connectors.
We also took out the Einsy Board and cleaned it but no luck.
There is no mechanical interference anywhere on the Z-axis movement, It is smooth to move by hand while the printer is off.
Also smooth to move Z with the Settings-Move Axis
Cleaned and lubricated the linear bearings

Sorry for the long post just wanted to be thorough,  Any help is appreciated, we are out of ideas of what else to do.



This topic was modified 1 year ago by juan.osorio
Posted : 06/05/2019 5:38 pm
Active Member

Hello Again, 

We tested the PINDA probe using this procedure, , (the first test, not the one using PronterFace).

We just tried exchanging the Einsy board with that of a Mk3S that is working fine, and the issue still happened on the MK3, the MK3S got the other board and had no issues.

We will try to exchange the PINDA next, perhaps there is some other failure mode that would not show up using the procedure linked above?

Thanks to anyone that has seen this kind of issues before.



Posted : 06/05/2019 11:56 pm
Honorable Member

I'd say broken PINDA cable that only disconnects when the Z axis is high, but otherwise has contact. When a cable breaks, it typically only disconnects in a certain X/Z location.

Posted : 07/05/2019 1:52 am
Illustrious Member

Things to check ...

Is the red LED on the PINDA lit when the carriage is at the top of travel?  If yes, odds are the PINDA is not the problem.

Is the printer set in STEALTH mode or NORMAL?  Set it to normal, and rerun the calibration.  Check for any crashes during the test to rule out motor stalls.  If you do see a crash detection, check the two dust caps on the Z screws are well above the motors and not binding; and also, check that the X carriage is not jamming at the top: the X plastic might wedge against the screws holding the upper Z rod supports in place. I modified my upper supports and used countersunk flat head screws to avoid the issue.

How do you get the X-axis lower when it stalls like this?


It is always wise to get more than one opinion......
Posted : 07/05/2019 2:14 am
Active Member

Hello Vojtech and Tim

All tests have been done on NORMAL mode, and we have not been able to find any mechanical binding in X or Z wires or screws, we also have removed the spool holder, etc.

Yes it seems to be a PINDA error, we exchanged the probes with that of a working printer and the issue is gone, however we have not been able to reproduce outside the calibrating procedure even if the Z-axis is high, the Red LED is ON and when we approach it with something metal it goes OFF, and also in Support->Sensor Info we can see the 1 and 0 changing as expected even while moving the axis and shaking the cable.

Besides the wiring (which we will check thoroughly), are there other known PINDA failure modes which could look out for?

When it stalls we get the Z axis lower by using the move-Z in settings, the Z is physically at maximum but the FW thinks it is at 0, so we tell it to go up to say 50, and it loses steps crashing into the top until the FW thinks its at 50, although physically it has not moved; then we just tell it to go back to 0, and then it physically moves down.      I get the feeling this is not a good thing to do to the drivers/motors/screws/bearings, so we only did it for the video and a couple more tests.

Thank you for the help and ideas!

Posted : 07/05/2019 2:59 pm
Honorable Member

If replacing the PINDA helped, it means the move down was as expected prevented by the signal from the PINDA.

The printer, when doing Z calibration will first move up until it hits a physical barrier, to level the X gantry. It makes sure the bed is in a position where PINDA will trigger going down and starts going down until PINDA triggers. Then it checks the number of steps and if it is out of range (including too low), it fails the calibration.

Your PINDA thus must have been firing prematurely, near the top. This would typically be a cable or some other signal integrity problem. An oscilloscope would be a great tool to diagnose any possible glitches, they may not be visible to the naked eye. Any four of the PINDA wires could be having a problem.

Also, make sure that your Temperature Calibration is disabled during the tests.

Posted : 07/05/2019 3:36 pm
Active Member


Thank you for your help, noted regarding turning off Temperature Calibration.

It definitively was a signal integrity issue caused by the black (ground?) cable of the PINDA, we didn´t have a chance to scope it, but once the cable was out we could see the resistance changing in the multimeter while bending the cable, not a completely open circuit but enough I guess to cause a false reading.

We cut the cable about 1 inch away from the sensor and soldered in a new one, and it is working fine again.   I imagine that the Firmware in the selftest could detect this if the signal is changing too quickly without moving the motors?

Thank you for the help!




Posted : 07/05/2019 9:31 pm
Honorable Member
Posted by: juan.osorio

I imagine that the Firmware in the selftest could detect this if the signal is changing too quickly without moving the motors?

Yes, it could. It's currently rather limited by the size of the Flash memory on the CPU, so non-essential features tend not to be added.

Posted : 07/05/2019 10:05 pm

Please Login or Register