Marlin: Layer shift at random heights on 1.1.3 Bugfix

[Kaibob2]

Since i upgraded from RCBugFix to 1.1.3 bugFix i experience random layer shifts on every print.

The GCODE produced by S3D is okay. I printed the same cube a dozen times before with BCbugFix from before RC8.

I tested 115200baud and 250000baud via serial and also printing the same file from SD.
Like you can see the shift happens at different heights, so the behaviour is random.
The printer is well calibrated, the driver have enough current, Acc. and vel. is pretty conservative.

Any ideas?

[Kaibob2]

I caught the serial output when it happened.
Layershift.txt
This is what it printed

The last good layer is M117 Layer 60, H=9
The inner perimeter of layer 61 is okay, the outer one is shifted to the left.

This is what S3D sends for the both perimeters
1.txt

It's always the outer perimeter which fails and it shifts about the same distance several times

[epatel]

If you slow it down a little?

I am thinking that maybe your travel speed is too close to what the current version can handle in speed (sending pulses to the stepper drivers).

[Kaibob2]

Was there a decrease in the maximum speed since RCBugFix? I have travel speed set to 200mm/s which was fine before.

[epatel]

I wouldn't be surprised.

[Kaibob2]

Setting maximum velocity to M203 X500.00 Y500.00 Z9.00 E150.00 and performing a manual movement with
G91
G1 X-100.000 F30000
G90
works flawless.
So this doesn't seem to be the cause. To be honest: I would have been surprised :)

[Kaibob2]

Different object, same problem

The gecko is 72mm, the layer is shifted by 36 mm. Exactly the half.

[Bob-the-Kuhn]

After the shift and the print is completed/stopped, does M114 report the correct information or is that also shifted?

When you look at the X/Y values in the log from the good layer vs. the bad layer, are they the same or shifted?

[Kaibob2]

Only the X-axis seems to be affected. I never had a shift in the Y-axis.
Maybe you can take a look at
Layershift2.txt
This is the log from layer 59-61 of a cube which was fine until the outer perimeter of layer 61 shifted.
I don't get the Count: output. The coordinates seem okay.

[Kaibob2]

Below is the last part of the log when another cube failed right now.
I was watching the whole time and this is what happened in the moment of failure:

This is the topview.
Printing direction is counterclockwise. Startpoint for every layer is fixed at the top left of the drawing.

Green: 30 layers ok
Red: first line of layer 31
orange: slowly creeping back to startpoint of red line
blue: left turn and printing into the air at normal speed
violet: continue to print the cube...shifted

SENT: M117 Layer 31, H=4.65
READ: X:118.90 Y:108.73 Z:4.50 E:0.00 Count X:7315 Y:7293 Z:7196
READ: ok
READ: ok
SENT: G1 X90.600 Y114.400 F12000
READ: ok
SENT: G1 Z4.650 F540
SENT: G1 E0.0000 F2400
READ: ok
SENT: G92 E0
READ: ok
SENT: M105
SENT: G1 X90.600 Y85.600 E0.6825 F2730
READ: ok
READ: X:90.60 Y:114.40 Z:4.65 E:0.00 Count X:7315 Y:7901 Z:7196
READ: ok
READ: ok T:189.71 /190 B:60.16 /60 T0:189.71 /190 T1:30.49 /0 @:60 B@:0 @0:60 @1:0
SENT: G1 X119.400 Y85.600 E1.3650
READ: ok
SENT: G1 X119.400 Y114.400 E2.0475
READ: ok
SENT: G1 X91.000 Y114.400 E2.7205
READ: ok
SENT: G1 X90.600 Y114.400 F2730
Print stopped here.

M114 returns:
SENT: M114
READ: X:90.60 Y:114.40 Z:14.65 E:2.72 Count X:7275 Y:9141 Z:23428

This is the Gcode file:
Cube 30x30x15.txt

[epatel]

I would expect "Count" to be the stepper counters, and when looking at the logs this looks very fishy...will check the code a little.

(i.e. X_STEPS_MM → count value)

[Kaibob2]

At the last log I had to lift Z 10mm to prevent the nozzle from melting the object.
That's why Z:14.65 but H=4.65

[epatel]

I imagine the "Count:" log can be a little misleading as the count numbers are a snapshot of the absolut position in travel so to speak, but the XYZ are probably the position the steppers are working to get to. First it looked strange I thought, but I can imagine it be correct and maybe not too helpful. Unless the position is reported when the head is not moving...

[Kaibob2]

Yap. That's the problem when sending M114 after the print is stopped or still shifted. I don't know exactly where the nozzle physically was when the position is reported.
I managed to take a video of the shift. Funny, but true.
The shift happens not only once but again and again...
It happens at around 1:15
https://youtu.be/LUHp9UVuhOg

Pretty close to my great artistic drawing, right :)

[Kaibob2]

And for completeness:

Configuration.zip

[epatel]

Have you tried to set MINIMUM_STEPPER_PULSE to something > 0? (Configuration_adv.h)

Again, still thinking its a problem with the stepper driver. Maybe it gets more picky on the pulse width with heat? well, guessing...

[fiveangle]

video is sad. poor thing ! https://www.youtube.com/watch?v=NeFkrwagYfc

[Kaibob2]

OH! MY! GOD!
This is so akward, i missed to uncomment #define USE_CONTROLLER_FAN
Shame on me. The TMC drivers become quite hot without cooling
@epatel You were right from the begining!! Great job!!!
I'm an electrical engineer and i missed this little thing. Damn, sorry for that!!!
Sometimes you are so focused on the error that you won't see the forest because of all the trees.

[Kaibob2]

@fiveangle ...at least it tried...

[Kaibob2]

Thanks all for the patience and good will...

[andergrin]

I have the same problem with 1.1.3 and 1.1.4 versions - shifted layer on the Y axis on the random hight. GCODE generated by Simplify 3D. Previosly i use'd RC7 and it's work fine without any problems, and settings in 1.1.3 and 1.1.4 was identical with RC7. So now i have to return to RC7.

[Kaibob2]

Like I commented above, in my case, it was not Marlins fault but mine. Without active cooling the stepper drivers overheat and cause random shutdowns of themselves which results in step losses.

[nealpalmer]

I'm having the same problem on 1.1.1. But I usually see the problem on the Z-axis showing extra thick layers that aren't bonded well to the layer below and are like spaghetti (about 10% of prints do this once or twice). I heard it happen once: it was in the middle of a layer doing infill, and the x/y stopped moving, and Z did a large move (about 1mm) which was very audible, then the print separated after that. I think I have also seen the Y-axis shift, but much more seldom than the z-axis. My problem is definitely not the stepper driver overheating.