Setting M425 to non-zero values causes Layer Shift

[schmttc]

When two M425 commands are placed in Cura > Machine > Start G-Code, prints have a consistent layer shift. The layer shift occurs at different points depending on the version and configuration of Marlin 2.x firmware installed.

Example: G28 ;Home G1 Z15.0 F600 ;Move the platform down 15mm ;Prime the extruder M425 X0.39 Y0.39 Z0.2 M425 F1 S0 G92 E0 G1 F200 E3 G92 E0

This required more diagnosis to resolve. Suggest setting backlash offsets outside of printing, and save to EEPROM.

[schmttc]

M425 is enabled at 0,0,0 F0 S0 in firmware

Test 1, Left in image First line of Cura start block: M425 X0.39 Y0.39 Z0.2 F1 S0

Test 2, Right in image Save settings to EEPROM, confirm over reboot Remove M425 from Cura start block

Layer shift exists in both, but presents differently. I'm beginning to suspect this is an issue with the backlash compensation module in Marlin. IIRC I didn't have these issues when I compiled the backlash configuration into the firmware. This requires further testing.

[schmttc]

For comparison, here is a print using the same firmware, with M425 set to X0 Y0 Z0 F0 S0

[schmttc]

Confirmed that compiling the firmware with backlash offsets does not cause layer shift Test prints using this tower: https://www.thingiverse.com/thing:2371069 Lines mark the 'zero' point, which should align to the middle thick layer when backlash is zero.

Pink: 0 backlash compensation Orange: 0.39mm compensation XYZ Blue: 0.24 compenstaion XYZ I'm assuming the shift in the orange tower is a mechanical coincidence

Cura Profile and (untested) 0.2mm backlash binary attached for those wanting a quick fix, this should be 'close enough'. Remane the files and remove the ".txt" K7.temptower.curaprofile.txt mksLite.backlash0.20.bin.txt

[schmttc]

It turns out the layer shift in the orange tower was no coincidence. Another user is having layer shift issues even when hard coding the backlash values. Longer prints, or more layers, or more segments seems to trigger the layer shift, which leads me to believe it is some sort of overflow error.

0.3 layers, 0.5 0.36 backlash, smoothing 0, correction 1. No layer shift apparent

0.2 layers, 0.5 0.36 backlash, smoothing 0, correction 1. Layer shift begins at top of tower

Testing is required with the latest mainline bugfix version before reporting the issue.

[schmttc]

Latest Marlin bugfix-2.0.x (2.0.9.3) Compiled backlash 0.5x0.5,0; correction 1, smoothing 0 Layer shift still present

[crazy-hair]

Interestingly enough, when I try to print with backlash compensation on, it seems to layer shift every layer, not just sporadically. The shifts still aren't consistent, which means I can't use a post-processing script to fix it,though.

[real-artswan]

I've managed to compile vanila bugfix-2.1.x* with your fixes for our printer (can do a PR if you want). backlash compensation doesn't hurt anymore and I can print (almost) perfect circles. I've always had a pattern "squared circle" because of a huge backlash on the weak mechanics

now with a M425 F1.00 S0.00 X0.6 Y0.9 Z0.20 I've got perfect rounds

now I've got another problem, after a several layers of a bigger object it makes sound like "beep" (don't know, it has no buzzer, so pwm may be... it seems it happens on a layer change) and stops and reboot without any messages about a reason in a serial console. Could it be a buffer overflow issue? O rather a PWM issue, can you advice how to fix/tune?

may be I just should try some more stable branch...

[schmttc]

I wonder if the crash is related back to the original issue; I found I had to print a large enough item (I suspected at the time there was a minimum number of segments or moves or gcode steps) before the layer shifts started. As you noted the 'beep' could be the stepper motor trying to do a large/fast move that it's physically incapable of; pure speculation but maybe it draws too much current and browns out the board? Could try setting lower current limits in the configuration files and retest.

I started a 2.1.2 branch here https://github.com/schmttc/EasyThreeD-K7-STM32/tree/2.1.2 which incorporates the maple compile bugfix https://github.com/MarlinFirmware/Marlin/issues/25346 It compiles and flashes but caveat I haven't tested it yet as the K7 isn't my main printer any more. Maybe see if that fixes the large print issue. Otherwise I'd suggest raising a ticket in mainline.

Sidenotes

• I'm very interested to see how Linear Advance works on the little printer
• I have a to-do item to roll the updates in this repo back into mainline Marlin

[real-artswan]

Can say that the backlash issue is irrelevant to my problem and it works well, at least me can't reproduce with the latest bugfix-2.1.x branch, I can make a PR, to merge it, should I? It seems my problem is different, it's definitely about the extruder's stepper, it hangs and PWM is audible, at that time the printer still sends status to serial, but doesn't respond neither accepts commands anymore. My thoughts are:

1. when it gets too LOW current (or too low PWM freq, don't know)
2. when it's asked for a too high aсceleration from the very rest
3. Enabling "Linear Advance" just calls for the hanging problem sooner, the bigger K value the sooner it hangs (I think because it shapes speed/acceleration, does it make it slower in the corners?)

so it might be a power source issue, or might be some steppers physical limit, it also could be an issue in the Marlin code (or my config). I tried to set DEFAULT_MINIMUMFEEDRATE to 20, but it didn't affect at all. At the end of the day, I want more or less precise circles but printers mechanic is weak so I need backlash compensation and I need to lower all accelerations and speeds (and expectations;)). And finally, I've also disabled linear advance (btw, on the photo above it was 0.6) and added retraction 1mm and seems got balance between speed and stability and precision and quality. Wondering to try it with more power, but max current on a stepper could also be a driver limit, (need to look at the board, which extruder stepper driver it has)

[schmttc]

Happy for a PR, but it would be best to solve the large print hanging issue first.

• Does the issue occur with the 2.9.1 firmware?
• Does the issue occur when backlash compensation is disabled in firmware?

[real-artswan]

to me, backlash compensation works well and helps a lot

[schmttc]

It looks like the crash and noise might be due to a bug in linear advance https://github.com/MarlinFirmware/Marlin/issues/25553 @real-artswan please do a PR and we can get a few people using it

[schmttc]

The backlash problem still exists in Marlin 2.1.2, but it seems to be less of an issue.

The backlash tower printed fully

But printing the two ducts from https://www.thingiverse.com/thing:4931953 shifted half way

[thinkyhead]

Thanks for all the images. I'm convinced the issue is real.

may be I just should try some more stable branch.

Yes, actually there is a straightforward procedure that can help to isolate the exact cause of the issue, if you would like to help us track it down, but it's a little meticulous.

The strategy is to first find a commit from some point in the "distant" past where the feature works perfectly. Then, using the bugfix-2.1.x branch you would test a commit from halfway between that date and today…. And then you keep going to the commit half-way in between your "known to work" commit and your "known to be broken" commit until you find the exact commit that broke the feature.

Even if you started from a point 5000 commits in the past, it would take no more than 12 or 13 tests to find the exact commit that broke it.

This can be done with git bisect but we don't expect the average user to use that method, plus it doesn't account for configuration changes between versions. So, it is best just done manually. It is best for someone who is experiencing the issue to do this procedure, since it may not be straightforward for someone else to reproduce the issue.

The first trick is to find some older version that doesn't exhibit the issue, and then you can start testing from that point in time.

[thinkyhead]

@tombrazier — Can you take a peek at some changes to backlash compensation, starting from 87c4cd20e5 (#23814) and particularly at the Backlash::applied_steps method? I note that there is a bool called reversing (now called reverse) that simply tests Backlash::last_direction_bits to see if an axis was moving "backward" at an earlier point. I haven't looked very closely at the complete backlash logic, but I wonder if that should instead be looking for some change in the direction bits, rather than just checking whether the last direction was set to 1, indicating that the axis was moving in a particular direction. We can go over Backlash::applied_steps together in Discord soon so that I understand it, and backlash compensation in-general, and make sure all changes since last year are sound.

[schmttc]

Thanks for all the images. I'm convinced the issue is real.

may be I just should try some more stable branch.

Yes, actually there is a straightforward procedure that can help to isolate the exact cause of the issue, if you would like to help us track it down, but it's a little meticulous.

The strategy is to first find a commit from some point in the "distant" past where the feature works perfectly. Then, using the bugfix-2.1.x branch you would test a commit from halfway between that date and today…. And then you keep going to the commit half-way in between your "known to work" commit and your "known to be broken" commit until you find the exact commit that broke the feature.

Even if you started from a point 5000 commits in the past, it would take no more than 12 or 13 tests to find the exact commit that broke it.

This can be done with git bisect but we don't expect the average user to use that method, plus it doesn't account for configuration changes between versions. So, it is best just done manually. It is best for someone who is experiencing the issue to do this procedure, since it may not be straightforward for someone else to reproduce the issue.

The first trick is to find some older version that doesn't exhibit the issue, and then you can start testing from that point in time.

You read my mind, I was just planning to do this, ellensp ran me through the process previously for a different issue. Based on my research this firmware (https://www.thingiverse.com/thing:4499386) at 2.0.5 supported backlash compensation and there were no issue reports, so I'll start there when I get some spare time.

[tombrazier]

Can you take a peek at some changes to backlash compensation, starting from https://github.com/schmttc/EasyThreeD-K7-STM32/commit/87c4cd20e514b9fc94450e9503e268cc014490e8 (#23814) and particularly at the Backlash::applied_steps method?

I can but not immediately. It is so long since I worked on that code I can't even remember what I fixed!

You read my mind, I was just planning to do this, ellensp ran me through the process previously for a different issue. Based on my research this firmware (https://www.thingiverse.com/thing:4499386) at 2.0.5 supported backlash compensation and there were no issue reports, so I'll start there when I get some spare time.

Excellent.

[tombrazier]

After some reflection...

I wonder whether the bug is due to the backlash value being wrong or just because backlash compensation itself causes movement that is more likely to result in a layer shift. This could be tested by checking whether layer shifts still occur with lower speed/acceleration or with input shaping enabled.

My guess is that it is more likely to be the second reason because if it was built in to the backlash calculations then I'd expect the same layer shift in the same place every time something was printed with the same parameters.

One place to look will be calculations in planner.cpp that depend on steps_per_mm. This variable can end up with a rather odd value if a backlash is loaded onto a really short segment.

[thinkyhead]

backlash compensation itself causes movement that is more likely to result in a layer shift

My assumption is that it just adds more length to any axis move that is changing direction, but of course when more than one axis is moving, it can't just lengthen the whole move; it has to do the extra correction steps only on the affected axis, and then continue the move with the combined axes. So it could certainly lead to the other (non-compensated) axis having a sudden stop for a small period — enough to induce a layer shift.

Other things to consider in relation to layer shift include the motor current settings (for TMC and some other stepper drivers) and how those may have been adjusted between versions, and general acceleration settings. So it may help to experiment with some of those to see if the problem can be mitigated.

And finally, in the course of testing be sure to disable various optional features including things like Junction Deviation (enable Classic Jerk to disable JD), Linear Advance, Firmware Retraction, S-Curve Acceleration, and anything else in the realm of motion. This can help determine that the problem is specific to Backlash or whether it is caused by weird interactions with other features.

I look forward to finding out where the root cause lies! Backlash Compensation isn't the most popular feature, but it's a pretty important one, especially for machines beyond 3D printers that have more play in their mechanical components.

[schmttc]

Well I havn't got to the bottom of the issue, but here's what I've done so far.

TLDR; The workaround is to try 'unreasonably low' acceleration values when layer shift occurs. But the failure mode looks like a combination of higher acceleration and backlash compensation being enabled, that I don't understand yet.

A: 2.0.5 firmware, backlash correction enabled 0.2/0.36/0/1, 2.0 ejerk, 100mm/s acceleration, print speed 20, travel speed 40 - fail B: 2.0.5 firmware, backlash correction enabled 0.2/0.36/0/1, 2.0 ejerk, , 20mm/s acceleration, print speed 20, travel speed 40 - success C: 2.0.5 firmware, backlash correction enabled 0.2/0.36/0/1, 0.1 ejerk, 100mm/s acceleration, print speed 20, travel speed 40 - fail F: 2.0.5 firmware, backlash correction enabled 0.2/0.36/0/1, 2.0 ejerk, 100mm/s acceleration, print speed 20, travel speed 20 - fail

I need to rerun these tests, as 2.0.5 doesn't seem to be re-building reliably when I change configuration parameters, the old ones stick D: 2.0.5 firmware, backlash correction enabled 0.2/0.36/0/1, 0.1 classic jerk, 100mm/s acceleration, print speed 20, travel speed 40 - fail E: 2.0.5 firmware, backlash correction enabled 0/0/0/0, 2.0 jerk, 100mm/s acceleration - fail G: 2.0.5 firmware, backlash correction disabled, 2.0 jerk, 100mm/s acceleration, print speed 20, travel speed 20 - TBA

I don't know exactly how backlash correction and acceleration works, but my first suspicion went something like

• Backlash correction adds 'microsegments' to correct for backlash

• Due to the small segment size, acceleration for the segment quickly approaches the maximum allowed by the firmware

• With backlash disabled, a regular length segment reaches max acceleration almost never, or the change in acceleration is slower

• When a printer is allowed 'to much' acceleration, it can overrun, causing layer shift

• So acceleration is the key limiter to the layer shift, but it is brought forward by enabling backlash correction.

• Different firmware versions have slight variations in the motion engine, which is why the layer shift is not consistent across firmware

• Different variables for compensation also give varying layer shift as they change the acceleration curve.

• Watching the printer, I also feel like the shift is occurring on the diagonal travel at the end of the layer, which is why the shift is always in the same direction.

  • Travel speed is double the wall speed, so more chance of getting out of control. Maybe need to target travel speed/acceleration

Most people are trying to ring speed out of their printers, and most printers ship with bad default values So when my little printer has a max accel of 300, I set 'slow' as 100, and thought I'd covered off the acceleration side of the problem So I would recommend for troubleshooting that people set an 'unreasonably low' acceleration of say 20mms, and see if the problem persists.

• But the outlier question is why I could previously get layer shift when backlash comp was enabled, but set to zero. But on the same settings with backlash disabled, no layer shift. Maybe the extra calculation time allows overrun? Need to re-run this test to confirm.
• If this is the case, can layer shift be caused on a different printer by enabling compensation and setting zero values?

[tombrazier]

2.0.5 is really old firmware and backlash has been worked on since then. What do you get with the latest bugfix?

[schmttc]

2.0.5 is really old firmware and backlash has been worked on since then. What do you get with the latest bugfix?

I was exploring 2.0.5 as a potential non-buggy version in the 'distant past'. 2.0.9.1-2.1.2 are all impacted. I suggest that everything in between would be too. I'll try the latest bugfix when I do some more testing, but expect it to be impacted as well.

I wonder whether the bug is due to the backlash value being wrong or just because backlash compensation itself causes movement that is more likely to result in a layer shift. This could be tested by checking whether layer shifts still occur with lower speed/acceleration or with input shaping enabled.

My current thinking is that this is correct - lowering acceleration to 20 removed the issue in 2.0.5. My next questions are 'why', and 'can it be remediated'.

[schmttc]

The issue is consistent in 2.1.2 bugfix.

1. 2.1.2 bugfix firmware, backlash correction enabled .2/.36/0/1, classic jerk, disable linear advance, 2.0 jerk, 100mm/s acceleration, print speed 40, travel speed 40 - fail
2. Same compile as 2, set M425 to 0/0/0/0 - OK
3. 2.1.2 bugfix firmware, backlash correction enabled .2/.36/0/1, ejerk, linear advance, 2.0 jerk, 100mm/s acceleration, print speed 40, travel speed 40 - fail, sounds like the printhead movement is pulsing along a straight line
4. Same as 4, print and travel acceleration set to 20 - OK

[thinkyhead]

I'm still keen to understand what is going on here, but don't have any idea about a solution yet. There is definitely a problem there, so to get to the bottom of it we'll need to observe the code in situ and see what's going on under the hood. We have a Simulator which should make it easier to debug, so the best next step is to test out backlash compensation in the simulator within LLDB, log all the low level motion events, and look for oddities there.

[tombrazier]

I still wonder whether it is caused by adding backlash to small segments. @schmttc what happens if you define BACKLASH_SMOOTHING_MM?

[tombrazier]

Incidentally, 0.36mm seems like a pretty large backlash to me. After doing what I can to tighten up my belts, etc. I have 0.05mm for both my X and Y axes.

[schmttc]

Thanks for your patence.

• I have tested backlash smoothing (I used examples of S3 and S1), which fixes the layer shift; but introduces stuttering and odd speed changes in various segments throughout the whole print
• Based on the limited other mentions of backlash layer shift that I could find online plus these results, I concur with @tombrazier in the belief that the layer shift is caused by high acceleration being performed on very small segments.
• As the acceleration limits are being respected, the issue is not in the firmware itself, but rather caused by acceleration being set too high relative to the capabilities of the hardware.
• Hardware is the reason for the large backlash; 24BYJ48 is an 11.25 degree stepper with a 64:1 reduction to increase resolution. This gear train provides the backlash
• I'm thinking it's something to do with the gear train that causes the layer shift - maybe the short sharp acceleration causes an over step, not enough time to decelerate?

My apologies for the accusations against backlash compensation, it has been an odd combination of symptoms.

[tombrazier]

As the acceleration limits are being respected, the issue is not in the firmware itself...

The problem actually is that the acceleration limits are not being respected and the issue is in the firmware. What happens is Marlin adds steps to the axis movement but leaves the distance in mm unchanged. It then limits acceleration using the distance in mm. For a short segment and a comparatively large backlash (which I think does not happen for most printers but obviously does in this case) the steps to mm ratio is effectively much higher for this one segment and so the acceleration limit in steps is exceeded even if the acceleration limit in mm is not.

Backlash smoothing should resolve this without causing the odd speed issues described. So there may be another bug there. I don't really have the capacity at present to look into this but I wonder whether a simple (but slightly expensive) solution would be to recalculate block->millimeters in Backlash::add_correction_steps().

@schmttc do you have the skill to experiment with this?

[schmttc]

Ah I misunderstood, thanks for the explanation. I'm happy to see if I can follow the code and have a tinker, no promises.

[schmttc]

Hi @tombrazier , I've had a few tries at recalculating block->millimeters at various points and in various ways, but all I've been able to do is cause the print head to freeze. This will need to go into the backlog for someone more skilled to look at.