Welcome! Log In Create A New Profile

Advanced

Wrong Z height after long print, Z-shifting

Posted by Legion 2.3 
Wrong Z height after long print, Z-shifting
August 17, 2024 07:16AM
Hello, dear plastic-melting community

I few months ago, I replaced the old electronics of my printer with a BIGTREETECH Manta M8P with Raspberry Pi 4.
Firmware: Marlin 2.1.2.1 / Marling 2.1.x (bugfix from 09. Aug 2024), config: Configuration.zip

No Input shaping, S-curve, junction deviation or anything else fancy activated, just as basic as possible.
Host: Repetier Server
Hardware:
  • X-Axis: Closed loop Servo Leadshine iSV2
  • Y-Axis: Closed loop servo Clearpath-SD
  • Z-Axis: Closed Loop Stepper JMC iHSS57-36-10-21-38

Everything worked fine so far, or so I thought. From time to time i discovered that the printed parts were a few 1/10mm smaller than the should have been. These were mostly simple large parts with few "islands", so only a few retracts. It wasn´t critical and minor enough that I thought it was just regular shrinking or warping due to the size.
Last time, I printed a build plate filled with multiple small, complex parts, many islands, many retracts, long print time (24h) for only 15mm of build height.
When I measured the parts, I´ve discovered that they were only 12,5mm tall, 2,5mm were missing.
Then I manually moved the Z-Axis down, the nozzle touched the printbed at a displayed Z-height of 2,5mm. So the Z-height apparently has been shifted by 2,5mm during the print.

After I discovered this, I checked the mechanics of the machine: Everything sits properly, there is nothing loose, all belts are tensioned, pulleys are fixed. There is no measurable backlash on the z-axis.
When I move the Z-axis manually, even 10 times several 100mm +-, the shift doesn´t appear.
It only seems to appear at a high number of Z - movements.

Then, I wrote a test gcode file which rapidly performs a small Z-movement followed by a small XY-movement which mimics a complex print with many small islands with Z-hops 7500 times in total with an additional Z+0,2 every 500 cycles. It´s attached: Test.Z+-0.2.total.+3Z.+XY.rel.x7500.zip
It looks like this:

G91 ;set relative positioning
15x
(
(500x)
(
G1 Z0.2
G1 X0.2 Y0.2
G1 Z-0.2
G1 X-0.2 Y-0.2
)
followed by 1x
G1 Z0.2
)
G90 ;set absolute positioning

I´ve run this test G-Code with 3 different Marlin firmware versions:

Version 2.1.2.1: Z+0,25mm
Version 2.1.x (bugfix) from 11. Jun. 2024: Z-0,32mm
Version 2.1.x (bugfix) from 09. Aug. 2024 (latest version): Z-0,32mm

Z+ means the axis is higher than it is supposed to be (gap between nozzle and printbed at Z=0),
Z- means the axis is lower than it is supposed to be (nozzle crashes into printbed at Z=0).
The results are repeatable, always with identical values.

My Z-axis runs with 1280 steps/mm, 300mm/s² acceleration and 0 jerk. X-Axis is 160,22 steps/mm, Y-Axis 128,28 steps/mm, both 5000 mm/s² acceleration and 10mm/s jerk.

What I´ve tried so far:

  • Decreased acceleration XY 4000 -> 1000, Z 300 -> 100, XY Jerk 10 -> 5: Same result (Z-0,28)
  • Changed steps/mm on Z 1280 -> 1000 on Marlin only, motor settings weren´t changed: Same result (displayed Z-0,35mm, real: Z-0,28)
  • Increased MINIMUM_STEPPER_PULSE_NS 3000 ->10000, MINIMUM_STEPPER_PRE_DIR_DELAY + POST_DIR_DELAY 5000 -> 10000: Same result (Z-0,28)
  • Doubled step resolution on Motor and Marlin (Z Steps/mm 1280 -> 2560): Different Result (Z-0,14)
  • Increased move distance for test program Z+-0,2mm -> +-0,4mm: Same result (Z-0,28)
  • Added an "M400" - command (Wait for current moves to finish) before and after any Z movement: Different Result (Z+-0, no error). However, the M400 increases the execution time by 4, so that the test progranm, which usually takes ~18 min, now took 70 min to finish. It looks like M400 doesn´t only empty the move buffer, but also adds a delay before the next move is started.
  • Decreased acceleration Z 300 -> 30: Same result (Z-0,28) (printtime of testfile almost doubled)
  • Increased acceleration Z300 -> 1200: Same result (Z-0,28)
  • disabled "classic Jerk", enabled "Junction deviation": Same result (Z-0,28)
  • Enabled "S_Curve_Acceleration": Same result (Z-0,28)

So far I assume the following:

  1. The acceleration has no impact on the problem. Thus it seems like it´s no mechanical or power related issue since quadrupling the acceleration should definitely have an impact if this would be the case.
  2. The print time has no impact on the problem. I printed the test file with a much lower acceleration and with longer distances, without any change.
  3. There seems to be a constant amount of Z-shift / Z-move (or Z directional change), According to my math, its Z-0.0000186666mm / Z-move. This must be caused by a constant stream of additional steps on the Z-Axis, because doubling the steps/mm halves the Z-shift.
  4. The move buffer or path planner seem to be involved because the problem disappears when I interupt the Z-move with M400
  5. Changing the Marlin version does change the problem: Version 2.1.2.1: Z+0,25mm, Version 2.1.x (bugfix): Z-0,32mm, so it is quite clear that this issue is firmware related.

Any ideas what causes this problem?
So far I´m running out of ideas.
I still could revert to my old electronics (RADDS, Arduino Due and Repetier Server), but I want to use the modern features of Marlin in the future.

I think that it´s firmware related. Maybe it wasn´t discovered yet because the effect is only visible at large complex prints.
If someone has a similar hardware and firmware config, it would be great if you could run the test g-code to verify if this is a general Marlin problem or isolated to my system.
rq3
Re: Wrong Z height after long print, Z-shifting
August 17, 2024 11:43AM
Interesting. I've recently noticed that the latest bugfix prints all of the axes on a 1 inch test cube 0.008 inches (0.200mm) too big.
Reverting to a bugfix from April 2023 makes the problem go away.
Re: Wrong Z height after long print, Z-shifting
August 18, 2024 02:57PM
My machine was a very well used kit that I bought second hand to get into 3d printing.

Have you had random missing extrusions?

I chased this problem once. thinking slicer issues?, firmware?, my lack of experience?

It turned out to be very well used steppers, (the end play of the motors was going out)
They would act up randomly, usually from printing differently shaped objects and during different run times.

I disconnected all of the steppers from the machine. {Mechanically and electrically] When I turned the Z steppers gently by hand,
they seemed to be just the tiniest bit more coarse in the clicks, and take the tiniest bit more torque
to turn than my X & Y stepper motors. They weren't getting hot or making noise. AMP's were set the same in the firmware.
They would just randomly miss extrusions. No errors were reported in pronterface.

I replaced the steppers, and the problem immediately went away.

I am not saying this is the problem that you are having, or even how to properly test it.

Just food for thought in your diagnostics. - shane
Re: Wrong Z height after long print, Z-shifting
August 19, 2024 02:28PM
Success!!
I finally was able to fix this problem.
The problem was caused by the stepper timing settings
The following settings are working without Z-shift:

MINIMUM_STEPPER_PULSE_NS 3000
MINIMUM_STEPPER_PRE_DIR_DELAY + POST_DIR_DELAY 30000

The DIR_DELAY is now 6 times longer than it usually has to be with this motor, I have no idea why. According to the manual, it only needs 5000 ns.
However, this fix works for me, finally !!!
Since the MINIMUM_STEPPER_PULSE time is the same as before, I can still print with full speed. The additional DIR_DELAY only costs a few extra seconds for every print hour, depending on the geometry.
While this is not great, it´s at least usable. Maybe the developers can find out what´s the reason for this strange behavior sooner or later.
I still think that there is something messed up with the motion or path planner in Marlin: The problem only appeared when the Z-move was followed by an XY-move, while a pure Z-move without XY didn´t trigger the Z-shift. This means it can´t be related to the motor.

I´m currently printing the failed 24h-print again to check if the problem also disappears under real conditions, but I am very confident.

Edited 1 time(s). Last edit at 08/19/2024 02:28PM by Legion 2.3.
Sorry, only registered users may post in this forum.

Click here to login