Hi. I made some tests, and my LR3 was completely out of scale. For example, moving the Y axis by 100mm results in a 220mm movement. A 100mm drawing using ESTLCAM resulted in 220mm (both drawing and the software are in mm). I made several checks:
M92 command returned 200, 200, 800 (in the firmware was 100, 100, 400 - why did that happen?)
I compared the expected and actual results and made a rule of three to found to the correct steps per minute.
I changed the firmware with that value, and everything seems “ok” now. However…
My question is, why did I have to change the DEFAULT_AXIS_STEPS_PER_UNIT? I mean, is this issue normal? what causes it?
You may want to detail your build here so others can see and recommend help. Maybe a pic of your build as well. I know that when I built my mpcnc there was no issues, I Know that is no help to you, sorry, but I am not really sure.
The 220 value is the most puzzling aspect of your question. I would have expected 200. If it is 200, then please detail your electronics and what version of the V1 firmware you are using. I suspect that the microsteps of your stepper drivers is different than the firmware is expecting. For example, if you used A4988 stepper drivers instead of DRV8825 drivers, you would have this problem, since the maximum number of microsteps is different between the two boards.
As an aside, you can change the steps per mm without recompiling the firmware using either the display or using a M92 g-code, but once you’ve made that change, any changes made using DEFAULT_AXIS_STEPS_PER_UNIT will be ignored unless you do a factory reset (M502). Further changes need to be made using the display or g-code.
Someone who knows more about the TMC2209 drivers (like @jeffeb3) is going to have to answer that question since I’ve never played with them. If you set up your TMC drivers like V1 specifies, then I suspect the microstep settings are pulled from the firmware using UART communication, and the jumpers are ignored.
Rereading your question, I’m unclear of the exact scenario, but I have a guess. If the board you are using has had the steps per mm set either from the display or by g-code, then the values in the firmware for DEFAULT_AXIS_STEPS_PER_UNIT will be ignored. If the board was tested or a return, setting them to (200,200,800) could have happened before you even got your board. Looking at the V1 files, it appears that microstepping is set at 16X, and the values of (100,100,400) are the correct ones.
If the 220 vs 200 is true, even if you get the microsteps sorted, the extra 20 steps point to an additional problem of some sort.
Not smarter, I’ve just spent a lot more time plaguing this forum. After a while, I began to see various forms of the same questions and answers. For movements being consistently off (no lost steps), 98% of the questions/answers fall into the following:
If X and Y and Z are off by 2X, 4X, 8X, etc., then the issue is usually a mismatch of some sort between the steps per mm and the micro-step setting.
If only Z is off by 4X, then it is likely that a 1-start lead screw instead of the specified 4-start lead screw was used. This will increase Z torque but requires a significantly lower max Z feedrate to avoid lost steps.
If the X and Y are off (larger) by around 25%, then it is likely 16T rather than a 20T pulleys were used. This will reduce the torque for X and Y somewhat, which may slightly lower the max feedrate, but many usable machines are built using 16T pulleys.
If movements are tiny, like 25x too small, or possibly imperceptible, then it is likely that the g-code is being output in inches. V1 versions of firmware do not enable inch support, but it can be enabled in the firmware. Also, in every situation I’ve seen, changing a setting in the CAD or post-processor will result in outputting g-code in millimeters rather than inches, even if the original CAD is in inches.
If the movements are consistently inconsistent (i.e. move different distances depending on location but always precisely return to the same (0,0) home position), then it is likely steel reinforced belts were used, and the steel has broken resulting in stretching between some teeth.
And that’s it, and all pulled from reading answers to questions on the forum. Note all of these assume no lost steps. Lost step issues are a completely different list.
The TMC drivers (if they are configured in uart mode and not standalone) don’t care about the microstepping pins. There are two settings for microsteps. One determines how many external rising edges from Marlin makes one whole step (we set this to 16). One determines how much internal resolution the TMC uses. We set that to 256, IIRC.
The one you posted is the external one. Since it is set to 16, I expect it to be 100,100,400.
You probably had different firmware on before your latest build. The previous firmware had 200,200,800. To force Marlin to use the defaults you compiled into the browser, you need to send M502 to load the defaults and M500 to save them.
What numbers did you end up with? Something like 90 seems too far off.
Just one note on that. I believe that they do care about the MS pins. In this situation (UART mode) they set the address of the driver. This is used to program multiple drivers from a single UART port. If you have the jumpers in place the UART will try to talk to driver at address 0 but the driver will ignore because they have a different address defined by the shunts.
In other words all shunts need to be removed for the UART mode to work (if an UART per driver is being used)
