[BUG] Z moves down on both filament out and resume

[Bob-the-Kuhn]

Did you test the latest bugfix-2.0.x code?

Yes, and the problem still exists.

Bug Description

Just got a BTT Smart Filament Sensor and ran into unexpected head movement when the filament out triggers and when the print resumes.

I'm running the bugfix 2.0.x from 13 Jan 2022 (plus or minus a day).

This is a Tevo Little Monster delta printer with a Duet Smart Effector. This means the nozzle is the Z probe.

UBL is enabled. Same behavior with a 5x5 matrix and a 11x11 matrix.

Bug Timeline

I don't know if it;s new. My memory is that I ripped out my old DIY filament sensor a year or two ago because of this.

Expected behavior

The head rises monotonically to the park position when the filament out event happens and then falls monotonically to the original print level when the print is resumed.

Actual behavior

The head is going below the print level both on the filament out event and when resuming the print.

When filament out triggers the following happens:

1. LCD shows event
2. Head drops by 5-10 mm below the level it was printing at
3. Head goes to park position (Zmax -10mm)

When I resume the print:

1. Head descends rapidly to about the print level
2. Head slowly goes lower than the print level
3. Head rapidly goes up to the print level
4. Normal printing resumes

Steps to Reproduce

1. Enable UBL and do a G28
2. Use Octoprint to print the attached gcode file. This file prints starting at Z = 20mm so that the head dip is visible.
3. Force a filament fault. Both letting the filament run out and keeping the filament from moving give the same result.

Version of Marlin Firmware

Send: M115 Recv: FIRMWARE_NAME:Marlin bugfix-2.0.x (Jan 16 2022 16:23:23) SOURCE_CODE_URL:github.com/MarlinFirmware/Marlin PROTOCOL_VERSION:1.0 MACHINE_TYPE:TEVO Little Monster EXTRUDER_COUNT:1 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff

Printer model

Tevo Little Monster (delta printer)

Electronics

stock electronics

Add-ons

Duet Smart Effector

Bed Leveling

UBL Bilinear mesh

Your Slicer

Cura

Host Software

OctoPrint

Additional information & file uploads

Config files, pin file and Gcode file: temp.zip

Video showing the behavior: https://user-images.githubusercontent.com/20692583/149685464-1e928c82-7c83-4d5e-b1e4-dcc276c148ce.mp4

---

Don't know if my "fun" with G33 auto calibrate and the nozzle offset contribute to this but ...

I have NOT been able to get a G33 result where the nozzle just touches the plate when Z equals zero and bed leveling is off. I've played with the nozzle offset and G33 but was never able to get to the ideal. Didn't seem to make a difference after playing with UBL so I left it as is.

With UBL disabled the nozzle touches the bed at about Z equals positive 8 mm. After doing G29 P1 and P3 and several iterations of P6, I can get UBL to give me the nozzle touching the plate at Z equal zero. The UBL matrix values are mostly around 8mm.

The nozzle offset was determined by:

1. Disabling bed leveling
2. Using the paper method to put the nozzle close to the plate.
3. Using G92 to set Z to zero
4. Using M48 to get the trigger point

[thinkyhead]

Would you be able to test some bugfix-2.0.x commits to narrow this down?

The strategy is to find a commit from some point in the "distant" past where the feature works. Then, 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 day where it broke.

If you started from a point 256 commits in the past, it should take no more than 8 tests to find the exact commit that broke it.

[Bob-the-Kuhn]

The problem is NOT present in bugfix 2.0.9.

Will start narrowing it down.

[Bob-the-Kuhn]

2.0.9 and 2.0.9.3 both have the bug.

UBL must be active In order to see it. G29 D results in the correct operation.

---

FYI - I did try changing my nozzle offset from negative to positive. That had no effect.

[Bob-the-Kuhn]

This may sound crazy but ... I need some help theorizing what's going on.

If I put 15 second pauses immediately before and after an E retract statement, I see the following:

1. run out message on console
2. head pauses for 15 seconds - debug print says Z is 20.2 (agrees with LCD)
3. head drops by about 10 mm (Z movement only, no X, Y movement) - only should see E movement here
4. head pauses for 15 seconds - debug print says Z is 20.2
5. head goes to park position (as expected) and normal operation resumes

The statement is line 443 unscaled_e_move(retract, PAUSE_PARK_RETRACT_FEEDRATE); in file pause.cpp in routine pause_print

Commenting this line out results in normal operation.

My next step is to modify the debug prints to show the counts for each axis and apply liberally.

[Bob-the-Kuhn]

It's definitely a leveling issue.

The "extra" Z movement follows the leveling matrix.

If I set leveling active (G29 A) and set the matrix to a known value (G29 P0 then G29 P6 Cxxx) then I get the following:

• xxx (matrix values = positive number - "extra" Z movement is down by that number
• xxx (matrix values = negative number - "extra" Z movement is up by that number
• xxx (matrix values = 0 - no "extra" Z movement

Now I know why no one else is reporting an issue. Almost all Z probes trigger before the nozzle touches the bed so the leveling matrix values are almost always negative. An "extra" movement in the same direction as the park position doesn't affect anything.

Since my probe triggers after the nozzle touches the bed then I get positive numbers in my leveling matrix and "extra" head movement in a bad direction.

[thinkyhead]

@Bob-the-Kuhn — Does this affect all three mesh leveling systems, or just one or two?

[Bob-the-Kuhn]

I was not able to properly test any leveling systems other than UBL.

The Marlin docs page says that only bilinear and UBL support delta printers.

I tried bilinear and never got a believable mesh. It gave 20 to 40 mm tilt acros the bed. When I printed in the air the head was definitiely following the tilt. I was never able to get positive values in the mesh so never saw the unwanted head movement.

Just for grins & giggles I tried 3 point leveling. Manual probe points didn't work and the first automatically generated probe point was offf the board.

As best I can tell only UBL is compatible with delta printers.

[thisiskeithb]

Leveling on deltas has been broken for a while.

[Bob-the-Kuhn]

Is there a reason to invest the time to get one of the other systems working with delta printers?

The only reasons I see are:

• Marlin DOCs page says UBL and BILINEAR are supported on delta printers
• Trying to squeeze an image into a 2560 8 bit machine. To that end I did some comparison compiles:

               STM32          2560      
           RAM     FLASH    RAM (max 8,192)   FLASH (max 253,952) 
3 Point   14,324  190,828   5,233 64%         186,486 73%
LINEAR    14,324  192,844   5,233 64%         189,808 75%
MESH      14,368  195,928   5,271 64%         194,056 76%
BILINEAR  14,412  197,716   5,327 65%         197,336 78%
UBL       14,872  225,568   6,642 81%         240,020 95%