Sensorless Homing with Third-Party Motors doesn't work reliably  

Re: Sensorless Homing with Third-Party Motors doesn't work reliably

I just experienced the same issue. On my mk3 from prusa i had an x axis motor fail. Prusa has agreed to send me a replacement but still haven't shipped it. I asked customer support if there is a supplier that i can get motors from sooner. They told me that e3d are the motors they use. I ordered one from e3d and when it showed up i realized that it was .9 degree and not 1.8 which prusa still uses. E3d does not sell 1.8 anymore. I ordered a couple from Amazon with good reviews but could not find anyone who has used them on an mk3. Found out that not all NEMA 17 motors are not the same even though all the specs look real close. Homing and collision detect do not work work these motors. They are real quiet and real tight but i cannot use them. If anyone can provide a link to a motor that will work with the mk3 that would be great.

Re: Sensorless Homing with Third-Party Motors doesn't work reliably

Not sure where you got those specs from but they are wrong for stock Prusa motors!

XYE motors are 6.5v 1.0a P/N LDO-42STH38-1004A

Z motors are 8v 1.0a P/N LDO-42STH34-1004L321E

Re: Sensorless Homing with Third-Party Motors doesn't work reliably

There are a few settings taht define homing sensitivity, here
https://github.com/prusa3d/Prusa-Firmware/commit/f916e0f8797107e447d2814691bcd06871575f8b

https://github.com/prusa3d/Prusa-Firmware/blob/f916e0f8797107e447d2814691bcd06871575f8b/Firmware/Configuration_prusa.h#L199

But the parameters for auto homing are already at 1 (highest sensitivity), and higher or lower values for holding/running currents have no effect on the success of the sensorless homing.

Watch out! TMC2130_SG_HOMING is just a flag, so the specific value has no meaning except being different from 0. The homing thresholds seem to be hard-coded (and there is no G-Code command for changing them - shame!):
https://github.com/prusa3d/Prusa-Firmware/blob/MK3/Firmware/tmc2130.cpp#L51 :
uint8_t tmc2130_sg_thr[4] = {TMC2130_SG_THRS_X, TMC2130_SG_THRS_Y, TMC2130_SG_THRS_Z, TMC2130_SG_THRS_E};
uint8_t tmc2130_sg_thr_home[4] = {3, 3, TMC2130_SG_THRS_Z, TMC2130_SG_THRS_E};


Same holds for the homing currents, https://github.com/prusa3d/Prusa-Firmware/blob/MK3/Firmware/tmc2130.cpp#L36 :
uint8_t tmc2130_current_r_home[4] = {8, 10, 20, 18};

Regarding the threshold values (tmc2130_sg_thr_home[]), these are specified as unsigned values but, at the TMC register level, are interpreted as signed values between -64 and 63. Normal encoding for negatives assumed, for -1 you would write 127, for -2 126, and so on. But you probably don't need to go "lower" than 0 anyway.

Re: Sensorless Homing with Third-Party Motors doesn't work reliably

Not sure where you got those specs from but they are wrong for stock Prusa motors!

XYE motors are 6.5v 1.0a P/N LDO-42STH38-1004A

Z motors are 8v 1.0a P/N LDO-42STH34-1004L321E

Thanks for the heads up.
I took the (false) info from LDO's site, in which they list all their generic motors. I cannot find the Prusa motors there for sale or specs on them either.

I wonder why Prusa went with Motors that have such a high rated DC voltage.
Most of the generic motors i can find online for reprap machines have 1-2 volt , with high amperage.

This also makes me wonder how the current logic works in the source files.

From what i've seen, i need to up the current a lot more for my motors to avoid problems for running and auto homing.

There are a few settings taht define homing sensitivity, here
https://github.com/prusa3d/Prusa-Firmware/commit/f916e0f8797107e447d2814691bcd06871575f8b

https://github.com/prusa3d/Prusa-Firmware/blob/f916e0f8797107e447d2814691bcd06871575f8b/Firmware/Configuration_prusa.h#L199

But the parameters for auto homing are already at 1 (highest sensitivity), and higher or lower values for holding/running currents have no effect on the success of the sensorless homing.

Watch out! TMC2130_SG_HOMING is just a flag, so the specific value has no meaning except being different from 0. The homing thresholds seem to be hard-coded (and there is no G-Code command for changing them - shame!):
https://github.com/prusa3d/Prusa-Firmware/blob/MK3/Firmware/tmc2130.cpp#L51 :
uint8_t tmc2130_sg_thr[4] = {TMC2130_SG_THRS_X, TMC2130_SG_THRS_Y, TMC2130_SG_THRS_Z, TMC2130_SG_THRS_E};
uint8_t tmc2130_sg_thr_home[4] = {3, 3, TMC2130_SG_THRS_Z, TMC2130_SG_THRS_E};


Same holds for the homing currents, https://github.com/prusa3d/Prusa-Firmware/blob/MK3/Firmware/tmc2130.cpp#L36 :
uint8_t tmc2130_current_r_home[4] = {8, 10, 20, 18};

Regarding the threshold values (tmc2130_sg_thr_home[]), these are specified as unsigned values but, at the TMC register level, are interpreted as signed values between -64 and 63. Normal encoding for negatives assumed, for -1 you would write 127, for -2 126, and so on. But you probably don't need to go "lower" than 0 anyway.

> Same holds for the homing currents, https://github.com/prusa3d/Prusa-Firmware/blob/MK3/Firmware/tmc2130.cpp#L36 :
uint8_t tmc2130_current_r_home[4] = {8, 10, 20, 18};

Thanks!
This should help me tweak the bugs i currently have in auto homing.
Currently, sometimes it has not enough current to move the motors during auto homing, and that coupled with randy.h info about the original LDO motors tells me i should up the current during auto homing a bit.

I do wonder what the [4] value is and how i should change the threshold vualues for the third party motors.

Re: Sensorless Homing with Third-Party Motors doesn't work reliably

I wonder why Prusa went with Motors that have such a high rated DC voltage.
Most of the generic motors i can find online for reprap machines have 1-2 volt , with high amperage.

It is always a trade-off between several goals - and some Voodoo might be involved too.
The torque basically goes with the current and the number of windings in the motor coils. High number of windings needs less current but comes with higher R (the wires are thinner and longer) and higher L. All of it affects the torque-over-speed curve, e.g., having high torque at low speeds which breaks down for medium speeds already, versus having medium torque but over a wider range of speeds. See the torque curves for https://en.nanotec.com/products/358-st4118m1206-b/ , for example. Torque is required for acceleration/deceleration and constant load. The maximum acceleration defines the required peak torque. For 3D-printing, acceleration can occur at all speeds, which is why we normally go for medium torque over a wider speed range.
Obviously, also the supply voltage plays an important role, which might be one reason why Prusa picked motors with higher R - simply because they can afford to do so with 24V. Not sure, but I would guess that most implementations so far (and with "dumb" drivers) use 12V, along with it the low-R = high-current motors. Another reason might be that a higher L makes it easier for the motor driver, in general and for measuring back EMF in particular. Last but not least, lower currents usually come with less power loss - not necessarily in the motor itself but, for example , in the motor driver and the current sense resistors on the PCB.
To cut the long story short: it is complicated!

This also makes me wonder how the current logic works in the source files.

From what i've seen, i need to up the current a lot more for my motors to avoid problems for running and auto homing.

That is to be expected but not necessarily alarming. You might also want to lower jerk and acceleration a bit, if you get the feeling that you need too high currents otherwise. Make sure that the drivers are not getting too hot on the long run.

I do wonder what the [4] value is and how i should change the threshold vualues for the third party motors.

The [4] is just the maximum number of the elements in the array variable (this is C programming language).
For finding the right values, I would suggest making heavy use of G-Codes for setting motor currents and stallguard sensitivities and see what happens while moving against the end stop with normal move commands (G1). This way you don't have to re-program the firmware over and over again.

Re: Sensorless Homing with Third-Party Motors doesn't work reliably

Alright, an update on this.

I've got the sensorless homing working on X and Y with the third party motors.
All that was really needed was upping the current about 50-60% on the homing currents in the file tmc2130.cpp to this
uint8_t tmc2130_current_r_home[4] = {12, 16, 20, 18};
This is for (X,Y,Z,E), an increase over the stock {8, 10, 20, 18};

That's it.

Sensorless homing is still out on the Z axis, can't get this currently to work regardless how much or how less power i give them.
Both Z motors dock on for a while at the top with a long 'brrrrrrrrrrrrrrrr-brrrrrr', instead of the quick 'br-br' that X and Y now do.

I suspect this is in relation with the max Z height somehow, if the max Z height isn't exactly measured, then the homing on the Z axis does something weird.
Will investigate further when i have time, but so far you only need to home the Z axis once during XYZ/Z calibration, then never again.
Messing with the X carriage only requires you to dock it to the top of the 3D printed supports, then the X carriage is level again.

Anyway, XYZ calibration will pass with flying colors now.

Re: Sensorless Homing with Third-Party Motors doesn't work reliably

Sensorless homing is still out on the Z axis, can't get this currently to work regardless how much or how less power i give them.
Both Z motors dock on for a while at the top with a long 'brrrrrrrrrrrrrrrr-brrrrrr', instead of the quick 'br-br' that X and Y now do.

If I interpret the code in Marlin_Main.cpp/calibrate_z_auto() correctly, the firmware assumes stall guard to trip as soon as the first motor hits the top. Then the firmware drives Z another 10mm up (at half of the homing speed actually), which means that the procedure can handle the Z motors being misaligned by up to 10mm. So a 'brrrrrrrrr' for as long as it takes the Z axis to move 10mm at half of the homing speed is completely normal. Only 'brrrr's longer than that would indicate a too high stall guard threshold.

Re: Sensorless Homing with Third-Party Motors doesn't work reliably

So a 'brrrrrrrrr' for as long as it takes the Z axis to move 10mm at half of the homing speed is completely normal. Only 'brrrr's longer than that would indicate a too high stall guard threshold.

So the second 'brrrrrr' is normal, while the first longer one shouldn't happen, correct?

Re: Sensorless Homing with Third-Party Motors doesn't work reliably

So the second 'brrrrrr' is normal, while the first longer one shouldn't happen, correct?

Yes, I guess so. Normally, the procedure is started right after normal homing, i.e. head is shortly above Z=0. Thereafter, the firmware moves up to maximal Zmax (210mm?) plus 10% extra (+21mm). So if stall guard does not work, the first 'brrrr' (longer) would be for the extra 21mm (±), the second one would be for the 10mm. Actually, do the 'brrrr's have different frequencies? The final move is half as fast, so I would expect the final 'brrr' having an accordingly lower frequency.

Re: Sensorless Homing with Third-Party Motors doesn't work reliably

Actually, do the 'brrrr's have different frequencies? The final move is half as fast, so I would expect the final 'brrr' having an accordingly lower frequency.

Yeah, first brrr sounds like the printer is full on pissed at me, second brrr sounds like the printer is only slightly mad.

Re: Sensorless Homing with Third-Party Motors doesn't work reliably

Yeah, first brrr sounds like the printer is full on pissed at me, second brrr sounds like the printer is only slightly mad.

LOL. Guess that proves that it is not really erratic behavior of the firmware but just a too high stall guard threshold.

Re: Sensorless Homing with Third-Party Motors doesn't work reliably

Yeah, first brrr sounds like the printer is full on pissed at me, second brrr sounds like the printer is only slightly mad.

LOL. Guess that proves that it is not really erratic behavior of the firmware but just a too high stall guard threshold.

Tried to find the correct setting for the stallguard threshold on the z axis, but it's like a needle in the github haystack

Here maybe?
https://github.com/prusa3d/Prusa-Firmware/blob/MK3/Firmware/tmc2130.cpp#L52

Or here?
https://github.com/prusa3d/Prusa-Firmware/blob/MK3/Firmware/variants/1_75mm_MK3-EINSy10a-E3Dv6full.h#L248
(wonder how the homing threshold relates to the axis thresholds)

Re: Sensorless Homing with Third-Party Motors doesn't work reliably

Tried to find the correct setting for the stallguard threshold on the z axis, but it's like a needle in the github haystack

Here maybe?
https://github.com/prusa3d/Prusa-Firmware/blob/MK3/Firmware/tmc2130.cpp#L52

Or here?
https://github.com/prusa3d/Prusa-Firmware/blob/MK3/Firmware/variants/1_75mm_MK3-EINSy10a-E3Dv6full.h#L248
(wonder how the homing threshold relates to the axis thresholds)

The relevant line would be

#define TMC2130_SG_THRS_Z 4 // stallguard sensitivity for Z axis

And the value range is -64...+63.
I am not sure what the printer is supposed to do when Z stallguard trips during a normal move and I cannot try because I am not on Prusa-Marlin anymore. But you can try setting the stallguard threshold value temporarily with M916 Z<value>, e.g. M916 Z0 ( https://github.com/prusa3d/Prusa-Firmware/blob/MK3/Firmware/Marlin_main.cpp#L6489 ). This value, however, is then only used for normal moves (or the 2nd short move when doing Zmax calibration), so you would just activate stallguard detection via LCD menu, send the M916 command, initiate a normal Z move, and then see what happens when you block one of the Z axes with your fingers. Once you have found a good value, you can put it in the config file and re-program the firmware. Use a rather high stallguard threshold though because you don't want to get false positives during normal printing (assuming you ave stallguard activated during normal printing).