[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%

[thinkyhead]

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

The reason I inquired is that UBL works a bit differently, so that when you alter the current position in any way you have to "ping" UBL to let it know it needs to update its internal variables. It has been under consideration for a while to integrate UBL into planner.apply_leveling and remove its custom motion routines, which apply optimizations for certain types of moves, but which probably incur extra overhead that negates the gains in the usual case.

Anyway, my guess is that there is some alteration of the current position being applied, but UBL is not getting "pinged" with a null move to update its internal variables. If you test AUTO_BED_LEVELING_BILINEAR and see the same problem, then we will know that UBL is not the source of the issue.

[thinkyhead]

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

No. Only mesh-based leveling is suitable for deltas, and in fact it was originally programmed specifically for the Kossel delta by Johann Rocholl.

[Bob-the-Kuhn]

Should we change the Marlin DOCs page to say that only UBL is compatible with delta printers or should we fix the bilinear leveling?

I did some playing with bilinear G29 and the M48 commands. There's as much as 25mm difference between the reported Z trigger points between the two! The M48 results are believable. The G29 are not.

Both use the same routine to get the trigger point. That routine's comments say the trigger point is based on converting the stepper counts. Time to investigate why they're different.

[thisiskeithb]

Should we change the Marlin DOCs page to say that only UBL is compatible with delta printers or should we fix the bilinear leveling?

3 point and Bilinear used to work (recently). We also have delta configs with those options enabled, so something broke those features.

@sjasonsmith: Which leveling system(s) were you testing on your delta?

[sjasonsmith]

Which leveling system(s) were you testing on your delta?

That was along time ago. I tested with UBL and BILINEAR (maybe others, but I don’t remember). I was more focused on whether the probe was physically crashing into towers than the actual results. I never really needed any bed leveling when I was printing, so I’m not sure how well it worked at the time.

[Bob-the-Kuhn]

I think G29 bilinear leveling needs to modify it's first probe movements in order to be compatible with my printer.

I'm pretty sure all my bilinear leveling issues are because my printer looses steps when doing X/Y movement with the head very near the top.

On my system the G29 command results in two small Z moves, a move to the X/Y of the probe point and then a long Z only descent to do the first probe. All reasonable things to do.

If I manually do the X/Y move without first doing the small Z drop then I can hear binding and see jerky movement. If I first drop down 10mm and then do the X/Y move then the binding noise/jerk is gone. A 5 mm Z drop still has the binding.

I think what is happening is the large X/Y move requires a large drop in one axis/stepper and small increases in the other two axis. The small increases are causing the carriages to bump into the physical Z stops which is the binding noise I hear. I can see the small increases and watch the Z endstop light go from on (not triggered) to off (triggered).

Rather than just increase the first G29 Z movement a little, it would be better to just move directly to the Z_CLEARANCE_xxx point and then do the X/Y movement. Just modifying the first G29 Z movement enough to make my printer happy runs the risk of someone else running into this issue.

Thoughts?

[Bob-the-Kuhn]

So many ways to skin a cat ...

I ran across the variable delta_clip_start_height which is intended to represent the max printable height on a delta printer and is also assumed to be where the max X/Y movement can start. If my configuration.h file isn't too messed up, this is usually set to the height reported by the G33 command.

In my case I need it to be a few mm shorter. On my printer the max printable area is a cylinder whose top edge droops a bit so max printable height is a little more than the height where we can use the full xy-area.

I'm assuming I'm not the only one that's run into this so how best to update Marlin?

• Add a constant offset?
• Add yet another configuration item? Maybe DELTA_FULL_XY_HEIGHT or DELTA_FULL_XY_HEIGHT_OFFSET

height where we can use the full xy-area is mentioned in G28, G33 and used in several other routines. I think it's best to modify the delta_clip_start_height variable where it is defined in delta.cpp.

---

I'm having a hard time adhering to the KISS principle. So easy to make it complicated.

The code change option I'd recommend is:

• From: float delta_clip_start_height = Z_MAX_POS;
• To: float delta_clip_start_height = Z_MAX_POS - 20;

If it makes sense to modify the configuration.h file then I'm thinking that a code change isn't needed and the file changes would look like:
FROM:

#define Z_MAX_POS MANUAL_Z_HOME_POS
#define MANUAL_Z_HOME_POS DELTA_HEIGHT // Distance between the nozzle to printbed after homing
#define DELTA_HEIGHT 485.75               // (mm) Get this value from G33 auto calibrate

TO:

#define Z_MAX_POS MANUAL_Z_HOME_POS - DELTA_FULL_XY_HEIGHT_OFFSET
#define DELTA_FULL_XY_HEIGHT_OFFSET 2  // always 0 or positive - Distance from home position to where
                                       // full XY motion can start.  On some delta printers the head
                                       // can not extend to the full X/Y reach when at the home position
                                       // because that would force a carriage into the physical Z stop.
#define MANUAL_Z_HOME_POS DELTA_HEIGHT // Distance between the nozzle to printbed after homing
#define DELTA_HEIGHT 485.75               // (mm) Get this value from G33 auto calibrate

[Bob-the-Kuhn]

Tested the G29 bilevel code change and there was no binding so all worked as expected.

I also tested to see if the UBL filament jam code change made a difference. G29 bilevel behaved properly with and without the UBL change.

[thinkyhead]

Thanks for taking the simpler route. The one delta I have had access to was never very reliable, and is currently out of commission.

I'm surprised that the default value of delta_clip_start_height makes a difference, since it is calculated based on the delta_safe_distance_from_top() in update_software_endstops(Z_AXIS) called by recalc_delta_settings() during settings.postprocess() at boot time, so the default value should never be used. Still, if there is any possibility of it being used, then subtracting 20 will be slightly better.

So, back to one of the original questions…

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

Is this seen with both UBL and with Bilinear?

Sorry to draw out the conversation about the proposed change. My worry is that disabling/re-enabling bed leveling too often –like with every unscaled E move– will cause some corruption of the Z position, since the resolution is limited to a single step, and we are converting float to integer steps and then integer steps back to float every time. It would be better to figure out the underlying reason why moving only the E axis should have any effect on Z at all.

[Bob-the-Kuhn]

The unwanted head movement during filament out only happens with UBL. It does not happen with bilinear. I was not able to test with any other leveling systems.

Sounds like I need to look for a better location for a fix and/or a better fix. I'll see what I can find.

not getting "pinged" with a null move

Can you point me to an example of this being done? Not sure what a null move looks like.

[thinkyhead]

Can you point me to an example of this being done? Not sure what a null move looks like.

I'll have to look through the code and see if I can find some…. First hint I can find is in line_to_destination_cartesian…

inline bool line_to_destination_cartesian() {
  const float scaled_fr_mm_s = MMS_SCALED(feedrate_mm_s);
  #if HAS_MESH
    if (planner.leveling_active && planner.leveling_active_at_z(destination.z)) {
      #if ENABLED(AUTO_BED_LEVELING_UBL)
        ubl.line_to_destination_cartesian(scaled_fr_mm_s, active_extruder); // UBL's motion routine needs to know about
        return true;                                                        // all moves, including Z-only moves.
      #elif ENABLED(SEGMENT_LEVELED_MOVES)
        . . .

It hints that it may be better sometimes to call line_to_destination_cartesian where we now call planner.buffer_line if UBL is in effect, even if the move is to the current position. So then the question is where in the process up to the E move is Z getting lost, and can calling line_to_destination_cartesian make a difference … where it can be used?

[thisiskeithb]

Was this fixed in #23622?

[thisiskeithb]

Was this fixed in #23622?

I’ll assume this was fixed in that PR. We can always reopen this or open a new issue.

[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.