› ›

Facing Puzzling Print Layer Shifts

stevediazstevediaz
in General
Hello

While printing a complex model, I've been encountering an issue where the layers seem to shift unexpectedly, resulting in misaligned parts. I've checked my belts, tightened screws, and ensured proper slicer settings, yet the problem persists. Has anyone else experienced similar layer shift issues? What troubleshooting steps did you take to resolve them? Any insights or suggestions would be greatly appreciated.

Comments

  • allardjdallardjd
    edited October 2023
    Yes, I'm having the same issue.  It's been ongoing for a couple of months.  I'm at wit's end over what could be causing the problem.

    The printer is a RepRapGuru I3 clone, from a kit, purchased, built and put in service in Summer 2018.

    The Marlin firmware on the 2560 main board has never been updated or modified in any way.  I don't know the version but it's whatever RepRapGuru shipped with their kits in mid-2018.  The shield board is a RAMPS; I'm almost sure I remember "Version 1.4" on the box it came in within the kit.

    I've never attempted to modify acceleration or jerk settings.  They're as they've always been.

    I use Repetier Host V2.3.2 software.  I use the embedded "CuraEngine" slicer.   I have not tried other slicers.

    The layer shifts are always in the +Y direction.

    It those cases where I've witnessed the shift, there seems to always be a very rapid "jitterbug" motion going on, as in inter-wall infill or while laying down a long narrow section of the model or while building overhang.  

    I typically run with retraction (2.5 mm; 40 mm/s) and Z-hop (0.5 mm) turned on.

    SPEEDS Slow/Fast Settings:  

    Print: 40/60 mm/s
    Travel: 65/80 mm/s
    First Layer: 30/30 mm/s
    Outer Perimeter: 40/40 mm/s
    Inner Perimeter: 40/40 mm/s
    Infill: 40/40 mm/s
    Skin Infill: 40/49 mm/s  (don't know where "49" came from, probably a typo)

    The machine is controlled directly from a PC which is running Win10; there is no SD card slot, digital display or rotary encoder control on the printer.  Gcode comes directly from the Repetier Host software on the PC to the printer via the USB connection.

    Things I've tried:

    - I've used the "Cut off Bottom" feature of the slicer to print test versions of some of the problem models at partial height, beginning a few layers before the common failure points.  The failures still occur mostly at the same point in the model, indicating height above the bed is not the determining factor.

    - Where I can identify a common failure point in a model, I've examined the gcode in the vicinity of the failure point and can't see anything anomalous.  I should point out I'm not a gcode expert.

    - I sent the gcode output from my slicer for an object that is consistently failing with layer shifts, to a friend.  He printed it on his machine without problems (different machine, but still Marlin/RAMPS).  This seemed to absolve the slicer/gcode as culprit.

    - I swapped the X and Y stepper motors.  The layer shifts continued, still always in the +Y direction.  Motor shafts were straight and undamaged, mounting screws were tight as found, bearings seemed OK, pulley set screws were tight.  This seemed to absolve the Y stepper motor.

    - I swapped the Y stepper driver board with the unused E1 stepper board. The layer shifts continued, still always in the +Y direction.  This seemed to absolve the stepper driver. (The motor and driver swaps were performed independently, with a failed test after each.  Motors and driver boards are the originals.)

    - I rechecked the stepper current limit settings on the driver boards and all were found OK.  The largest discrepancy from the target setting (0.50 V) was 0.03 V.

    - I had installed "smoothers", i.e. Schottky diode boards, between the drivers and stepper motors on X and Y a few years ago and never had problems but also didn't note any improvement from them at the time.  I removed them during these problems without affecting the layer shift issue.  They remain out.

    - I put an 80 mm muffin fan on the bench, directed toward the stepper drivers during printing. There was no effect on the layer shifts.

    - After match marking the Y motor pulley and belt, I ran another test print.  I killed the print after a series of Y layer shifts totaling approximately 8 mm in the +Y direction.  The belt/pulley match marks were still aligned.  This indicates belt slippage is not occurring; pole slip seems to be the problem.

    - I was monitoring the 2560  5 V Vcc during the last test and saw nothing unusual.  

    The slips I observed on the last test were occurring where the printer was beginning to build a small section of overhang, where a brief but rapid series of short moves were made.  There was a definite, dull clunk each time the motor slipped.


  • RepetierRepetier
    > The layer shifts are always in the +Y direction.
    If the endstop is at y min this is in 99% crosstalk to y endstop preventing a move to y min when endstop is high from crosstalk of parallel lying cables. With moves toward y endstop prevented by firmware you shift away from the endstop.

    Possible solutions:
    - twist y endstop cable or shield it or move it away from motor/heater cables.
    - disable endstop testing during moves, but this requires recompilation of firmware.

  • allardjdallardjd
    Yes, endstop is at the Y minimum end.

    I've braided the three conductors to the Y endstop and encased the Y motor cable in braided copper sheathing which is connected to ground at one end only.  There's no change in the behavior of the printer.  With the test piece I'm using it layer shifts in the + Y direction when executing small, rapid moves while building overhang.
  • RepetierRepetier
    If it is more special to this model with small rapid moves, try reducing jerk and acceleration. Sounds like you could have many hard direction changes and that could cause step loss as well if you exceed the limits, so try stressing the motors/printer less and see if it improves.
  • allardjdallardjd
    It's not just one model.  It occurs on any model with one or more of the following situations... a) narrow infill between the inner and outer shells of vertical walls, b) building overhang, c) laying down a narrow section of a horizontal surface.  All three of those situations involve rapid moves of X and Y.  These operations are no more severe than with hundreds of earlier prints over five years that did not experience layer shifts.  This is a new problem, beginning in about July of this year.

    The most puzzling thing is that nothing has changed on the printer from the time I built the kit.  I've never changed anything in the firmware.  The M503 data reports a firmware date in 2017.  I can't understand why acceleration and jerk settings that worked without problems for five years suddenly are problematic.  

    I put an o'scope on the sense line of the Y endstop, setting it to trigger at 2V on a falling edge.  The sense line is high (5V) unless the endstop switch is actuated.  I had several layer shifts but the scope never triggered, meaning that the sense line of the end stop remained above 2V even when layer shifts occurred.  

    In a different mode, the scope trace for the Y endstop at 5V during printing shows some low level "grass" in both the + and - direction, however the largest deviation I saw from 5V was about 300 mV.  The 2560 should not interpret that as a low indication.  Watching the scope in that mode while layer shifts occurred indicated nothing any different than during steady state printing.  I understand that a layer shift transient may have been too fast for me to have seen it but the other mode using event triggering should have caught even a quick transient.

    I also tried rolling Repetier back to the next earlier version and that did not resolve the problem.  It's back at version 2.3.2 now.

    Continuing to grasp at straws here.
    - - - - - - - - - - - - - - - - - - - 
    Printer Reset and M503 output:

    RESET
    14:40:13.293 : Printer reset detected - initializing
    14:40:13.294 : start
    14:40:13.294 : echo:Marlin 1.1.6
    14:40:13.298 : echo: Last Updated: 2017-10-10 12:00 | Author: (RepRapGuru Prusa i3 V4,11/27/17)
    14:40:13.298 : echo:Compiled: Aug  6 2018
    14:40:13.301 : echo: Free Memory: 4023  PlannerBufferBytes: 1232
    14:40:13.306 : echo:Hardcoded Default Settings Loaded
    14:40:13.306 : echo:  G21    ; Units in mm
    14:40:13.306 : echo:  M149 C ; Units in Celsius
    14:40:13.306 : echo:Filament settings: Disabled
    14:40:13.310 : echo:  M200 D3.00
    14:40:13.310 : echo:  M200 D0
    14:40:13.310 : echo:Steps per unit:
    14:40:13.313 : echo:  M92 X80.00 Y80.00 Z4000.00 E90.00
    14:40:13.314 : echo:Maximum feedrates (units/s):
    14:40:13.314 : echo:  M203 X250.00 Y250.00 Z2.00 E22.00
    14:40:13.314 : echo:Maximum Acceleration (units/s2):
    14:40:13.318 : echo:  M201 X1000 Y1000 Z5 E1000
    14:40:13.322 : echo:Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
    14:40:13.322 : echo:  M204 P500.00 R500.00 T750.00
    14:40:13.326 : echo:Advanced: S<min_feedrate> T<min_travel_feedrate> B<min_segment_time_ms> X<max_xy_jerk> Z<max_z_jerk> E<max_e_jerk>
    14:40:13.330 : echo:  M205 S0.00 T0.00 B20000 X20.00 Y20.00 Z0.40 E5.00
    14:40:13.330 : echo:Home offset:
    14:40:13.330 : echo:  M206 X0.00 Y0.00 Z0.00
    14:40:13.333 : echo:Material heatup parameters:
    14:40:13.333 : echo:  M145 S0 H180 B70 F255
    14:40:13.333 : M145 S1 H225 B100 F255
    14:40:13.333 : echo:PID settings:
    14:40:13.333 : echo:  M301 P22.20 I1.08 D114.00
    14:40:15.882 : FIRMWARE_NAME:Marlin 1.1.6 (Github) SOURCE_CODE_URL:https://github.com/MarlinFirmware/Marlin PROTOCOL_VERSION:1.0 MACHINE_TYPE:REPRAPGURU PRUSA i3 EXTRUDER_COUNT:1 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff
    14:40:15.882 : Cap:EEPROM:0
    14:40:15.882 : Cap:AUTOREPORT_TEMP:1
    14:40:15.882 : Cap:PROGRESS:0
    14:40:15.882 : Cap:PRINT_JOB:1
    14:40:15.882 : Cap:AUTOLEVEL:0
    14:40:15.882 : Cap:Z_PROBE:0
    14:40:15.882 : Cap:LEVELING_DATA:0
    14:40:15.882 : Cap:SOFTWARE_POWER:1
    14:40:15.886 : Cap:TOGGLE_LIGHTS:0
    14:40:15.886 : Cap:CASE_LIGHT_BRIGHTNESS:0
    14:40:15.886 : Cap:EMERGENCY_PARSER:0
    14:40:15.891 : X:0.00 Y:0.00 Z:0.00 E:0.00 Count X:0 Y:0 Z:0
    14:40:15.894 : echo:DEBUG:INFO,ERRORS
    14:40:15.894 : echo:Active Extruder: 0
    14:40:15.898 : echo:DEBUG:INFO,ERRORS
    14:40:15.902 : echo:Active Extruder: 0
    14:40:20.392 : echo:SD init fail

    M503
    16:24:56.537 : echo:  G21    ; Units in mm
    16:24:56.537 : echo:  M149 C ; Units in Celsius
    16:24:56.537 : echo:Filament settings: Disabled
    16:24:56.537 : echo:  M200 D3.00
    16:24:56.541 : echo:  M200 D0
    16:24:56.541 : echo:Steps per unit:
    16:24:56.541 : echo:  M92 X80.00 Y80.00 Z4000.00 E90.00
    16:24:56.546 : echo:Maximum feedrates (units/s):
    16:24:56.546 : echo:  M203 X250.00 Y250.00 Z2.00 E22.00
    16:24:56.550 : echo:Maximum Acceleration (units/s2):
    16:24:56.550 : echo:  M201 X1000 Y1000 Z5 E1000
    16:24:56.554 : echo:Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
    16:24:56.554 : echo:  M204 P500.00 R500.00 T750.00
    16:24:56.558 : echo:Advanced: S<min_feedrate> T<min_travel_feedrate> B<min_segment_time_ms> X<max_xy_jerk> Z<max_z_jerk> E<max_e_jerk>
    16:24:56.562 : echo:  M205 S0.00 T0.00 B20000 X20.00 Y20.00 Z0.40 E5.00
    16:24:56.562 : echo:Home offset:
    16:24:56.562 : echo:  M206 X0.00 Y0.00 Z0.00
    16:24:56.566 : echo:Material heatup parameters:
    16:24:56.566 : echo:  M145 S0 H180 B70 F255
    16:24:56.566 : M145 S1 H225 B100 F255
    16:24:56.566 : echo:PID settings:
    16:24:56.570 : echo:  M301 P22.20 I1.08 D114.00 
  • RepetierRepetier
    Host only sends the gcode and the coordinates stay - firmware does handle the moves and limits speeds so it is firmware/printer issue not host.

    What is newer is the thin infill pattern at steep curves with many tiny moves. Several newer slicers generate this now to better support perimeters for better quality. So if printer is configured near edge it can be that these new situation push him over it. Acceleration of 1000 is normally no issue. Jerk 20 is for most printer no isse, you can try reducing to 10 to see if it helps. And if possible check if endstop check is disabled during print to prevent cross talk issues just to be sure. Also check slicer settings - especially prusa slicer I know can add own accelerations so check what it sets these to or if that is disabled in slicing.
  • allardjdallardjd
    MAY have it fixed, mainly by rerouting the X motor cable.  For some reason I was focused on the Y cable and should have given more thought to the X cable as a source of the problem.  Not certain the problem is solved but did print one test piece with no layer shift.

    Does the endstop checking only apply to the Y stop, or are the other endstops checked during printing as well?
  • RepetierRepetier
    Don't know marlin enough but normally all endstops are checked or none I'd guess. And if one triggers that move stops at least causing a shift.
  • allardjdallardjd
    Pretty convinced now that crosstalk is not the issue.  After one successful test piece the problem continues.  All five motor cables are now braided and are not routed anywhere near the three endstop cables. 

    Have a new RAMPS board coming.  There are capacitors on the board near the endstop connections.  Not sure of their function but if they're for filtering and one is bad, I guess that could be the problem.  Still grasping at straws. 

     Have exchanged motors between X and Y and have exchanged stepper driver boards between Y and the unused E1 location earlier with no improvement.  
  • allardjdallardjd
    Reduced acceleration to an agonizingly slow setting of 50 with an M203 statement in the startup gcode.  No layer shifts.

    Increased acceleration to 250, half original settings.  Layer shift.

    Decreased acceleration to 200.  Layer Shift.
  • allardjdallardjd
    My mistake in the post above, that was an M201 statement.

  • RepetierRepetier
    That is in deed very slow. Acceleration of 1000 are normally possible with most printers if the print head/moving mass is not too big and motor has good current. Have you checked if the move is friction free over complete range. If there is additional force needed that can lead to lost steps. Also higher speeds are more likely to have issues, so what speed are travel moves in slicer? Motors loose force on higher speeds. But still it bothers me that shift are only in Y+ direction. Acceleration is symmetric so would expect it to shift in both directions depending on gcode.
  • allardjdallardjd
    Printer always worked OK with acceleration at 500 before rebuild.  

    Rebuild did increase mass of Y carriage; original acrylic Y support plate was replaced with 3 mm aluminum plate, incorporating an extra linear bearing (now 4 aluminum pillow blocks vs. 3 plastic pillow blocks formerly); heated bed replaced with a 3 mm aluminum backed heated bed; glass build plate replaced with a magnetic build plate.  

    Rebuild was done in stages and the Y shift problems began early in the process, before anything was done that would increase Y carriage mass.

    Seems OK now at 150 but wouldn't work at 200 in last test.  I just replaced the X and Y stepper drivers with new ones yesterday but haven't bumped acceleration up to test them yet.

    Set the current limits on the new stepper drivers somewhat higher than recommended by printer manufacturer.  X at about 0.67; Y at about 0.71 (0.50 recommended).

    Both X and Y carriage movement is very free.  Layer shifts occurred anywhere on bed, not necessarily near ends of travel.

    Travel speed 65/80 mm/s.

    Printer operation is good at an acceleration setting of 150, but don't understand what's changed from five years of acceptable performance at 500.

    Will bump acceleration up to 200 for another test soon.

  • allardjdallardjd
    Considering putting a 1 ohm resistor in each of the motor coil circuits for the Y motor and trying to capture the actual peak current values with an oscilloscope reading the voltage across the 1 ohm resistors.  May even be able to capture the current profile when a shift occurs, with luck.

    Need to build a harness to do that safely.  Won't happen for a while.

    Motors are original; all five motors are the same.  Swapped X and Y motors while troubleshooting this.  Layer shift remained on the Y axis after swapping the motors.

  • RepetierRepetier
    Sounds like more mass so reduction of acceleration seems a correct solution. Not sure what 0.71 means for driver - is this voltage or resulting amp? Good nema 17 motors can handle 1.68A so if you have a smaller one it might help to replace it with a motor with more Nm torque and use the possible amp if driver can handle it. Also note that if drivers get too hot they stop to cool down and can cause shifts as well, so ensure cooling of drivers as well.
  • allardjdallardjd
    "... is this voltage or resulting amp?"

    Setting is a voltage but a knowledgeable friend informs me that for these particular drivers the resistor is sized so that there's a 1:1 correlation between voltage and current, thus 0.71 volts equates to 0.71 amps.  

    Motors are NEMA 17.  Motor tag says KS42STH40 - 1024A.  Don't know what most of that signifies, other than that the "42" means 42 mm, thus a NEMA 17.

    Printer is operating OK now with acceleration at 150 and new X and Y stepper drivers.  Haven't tried bumping the acceleration up yet but plan to after a few badly needed prints are done.

    I really appreciate you sticking with me through all this.

Sign In or Register to comment.