Layer shifting

[classbproject]

Running the 1.1.8 version of the Marlin firmware. For some reason my prints move after a few layers (see the image). This is really frustrating and a colossal waste of my material. This part was being printed at 75% infill and the layers shifted towards the very end of the print. Is this a bug?

[sidbyron]

Did you check the steps of each axis?

[Spawn32]

I have only seen layer shifting like this when there is a problem with the belt's or pulley's.
Belt's can be to tight or to loos...

Could also be stepper driver adjustment.

[classbproject]

No issues with the mechanical setup at all. Just printed another part and that printed fine. This happens very randomly.

[mcmatrix]

Most of us are using 1.1.8 without layer shift issue. Usually the problem is not in firmware. Have you checked your driver and/or stepper temperatures when printing.
Maybe they are overheating (this will cause skipping steps). Visually it means layer shifting.
I have had layer shift when i didnt had active cooling (fan) for drivers.
After adding proper cooling layer shift went away.
Have you measured drivers Vrefs. Maybe you are driving your steppers with too strong current.

[saikek]

What application are you using to generate Gcode ? Are you printing over USB or SD ?
I had this issue few times with Cura & Octoprint after switching to Merlin.

[classbproject]

@mcmatrix Stepper temps are normal. They are warm while running but not hot really. The drivers are also actively cooled using a 80mm fan. Vrefs are set to draw about 1A of current per motor.

@saikek Simplify3D. Printing using SD card. I did face this issue while printing over USB a couple of times.

[thinkyhead]

Check:

• Motor current:
  • Is it too high or too low on the problem axis? Can you throw off the axis by hand?
  • Cooling fan on the stepper drivers? Overheating can cause shutdown.
• Acceleration, Max Feedrate, and Jerk: Too high can lead to lost steps.
• Extrusion in Slicer / E-steps in Firmware: Too much causes the nozzle to hit the print, which may throw off an axis.

[thinkyhead]

And, be sure to test with bugfix-1.1.x as this is our current testbed.

[jsschlat]

I'm having the same/similar problem. For some reason, I'm only experiencing this problem in the Y axis. It has happen while I'm watching it. No reason to believe the stepper motor/belt is skipping. I've had this happen on new prints and just had it happen when using a .gcode for a calibration print that has worked perfectly before.

[saikek]

@jsschlat Also - it can be acceleration speeds. Are you using TMC2208 ? Try decreasing MAX value to 1300 at most.

[PiteousHonking]

Hi, I have just upgraded to 1.1.8 and experiencing the same - Layer shifts in the Y axis. Always the Y axis and always positive movement. Shifting was not an issue on 1.1.0-RC8 and no other changes have been made other than firmware. I have swapped stepper drivers on X and Y and shifting remains on Y only. Drivers are tuned to .6v which is as it should be.
Rhumba Board, A4988 steppers. SDCard printing. Is there anything I can do with enabling logging and serial monitor to try and debug?

[PiteousHonking]

Current Settings

> Receive V47 stored settings retrieved (642 bytes; crc 64087)
> G21; Units in mm
> M149 C ; Units in Celsius
> Filament settings: Disabled
> M200 D1.75
> M200 D0
> Steps per unit:
> M92 X160.00 Y180.00 Z1600.00 E677.77
> Maximum feedrates (units/s):
> M203 X150.00 Y150.00 Z6.00 E50.00
> Maximum Acceleration (units/s2):
> M201 X1000 Y1000 Z100 E10000
> Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
> M204 P1000.00 R5000.00 T1000.00
> Advanced: S<min_feedrate>T<min_travel_feedrate> B<min_segment_time_us> X<max_xy_jerk> Z<max_z_jerk> E<max_e_jerk>
> M205 S0.00 T0.00 B20000 X8.00 Y8.00 Z0.40 E5.00
> Home offset:
> M206 X0.00 Y0.00 Z0.00
> Mesh Bed Leveling:
> M420 S0
> PID settings:
> M301 P33.74 I2.71 D105.02
> M304 P195.69 I37.32 D256.50
> Z-Probe Offset (mm):
> M851 Z-1.42
> ok

[thinkyhead]

@PiteousHonking — Please try 1.1.9.

[PiteousHonking]

Tried 1.1.9 - Couldn't test print because the Auto-homing at the end of the mesh bed levelling process would consistently fail requiring a reset.
Read around the issue and the suggested fix was enabling endstop noise filtering (I have mechanical switch endstops). Once this was enabled it prevented the BLTouch from triggering so Z homing didn't complete.
Reverted to 1.0.0RC8 and Y layer shifting issue has gone so I do still suspect its not a mechanical issue.
Happy to keep trying.

[thinkyhead]

Sorry about that @PiteousHonking. There was a recent overhaul of the endstops and probe handling by @ejtagle and myself, and we've been getting piles of reports about problems ever since. We hope to get it back to being as reliable as 1.1.8 soon, when we have a chance to re-examine and debug more thoroughly.

1.1.0-RC8 is pretty old! You might find that 1.1.8 is a better choice, as it works just fine for most.

[AnHardt]

Read around the issue and the suggested fix was enabling endstop noise filtering (I have mechanical switch endstops). Once this was enabled it prevented the BLTouch from triggering so Z homing didn't complete.

Maybe this report is claer enough now.
It's impossible to find 7 consecutive tests 1ms apart when the pulse is only 5ms long! The current code can't work.

[ejtagle]

With BLTouch you need to disable noise filtering (why would you want it, when BTtouch has a hw filter in place ? )

[AnHardt]

For sure you need to enable filtering if only one of the other endstops is noisy.

[thinkyhead]

Should we split up endstop filtering so it can be separate from probes?

I'm collecting troubleshooting tips! I've got troubleshooting tips for a few different topics like Linear Advance, Trinamic Drivers, etc.. What kinds of troubleshooting tips do we have for endstops, probes, and particularly the BLTouch?

[ejtagle]

Possibly, being able to configure endstop filtering per endstop/probe...

[PiteousHonking]

@thinkyhead I'd love to remain on 1.1.8 if I could resolve the shifting. I know others with (almost) the same hardware as me are using it without issues - that's partly why I posted all my settings in case there was some obvious cause there I'm missing.

[classbproject]

Since I started this thread, I thought I'd weigh in and update the status of my problem. I finally pinned down the issue to one of the wheels on my mechanical setup which would bind randomly. Probably due to a failed bearing. It would get dragged and just once in a while, it would mechanically bind the whole axis just for a fraction of a second which would end up shifting the layer. I have recently moved to 1.1.9 and everything works as it should.

[richfelker]

I'm seeing almost these exact symptoms on Marlin 1.1.9 on my Ender 3. Was the cause ever determined?

[Roxy-3D]

One thing you can do is start your print... and then turn the dial of your LCD Panel to slow the F/R down to 70%. Usually that is enough to insure the print will finish without a layer shift.

Turning down the feed rate does two things. First, it gives the processor more time between GCode commands. And it gives more time for the interrupt routines to feed pulses to the stepper motors.

The other thing it does is cover up any 'stickiness' or places where the belts and pulleys bind. By moving slower, if there is a sticky spot, the motors may be able to compensate and continue without losing steps.

Most layer shift problems are mechanical. Slowing things down will cover up the problem. But I'm not ruling out a problem in the code base. If it is a firmware problem, we have a lot of people looking for it, and we haven't found it yet.

[richfelker]

Thank you for the quick reply, but I don't think it's helpful. The problem is almost surely not mechanical, as it started from replacing the stock firmware with Marlin 1.1.9. I will re-test with stock firmware just to be sure. Slowing down print to work around whatever bug is behind this really is not helpful either; the point of upgrading is to get better functionality (particularly, in my case, linear advance for ability to print at high speed and varying extrusion rate without warping or dimensional inaccuracy), not to reduce the printer's functionality and have to tiptoe around bugs that could waste hours of print time and corresponding amounts of material.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.