G29 dips down while moving from point to point on a large delta bot

[jakehenak]

I recently downloaded the latest RC 1.1.0-RC6 and attempted to take another stab at getting be(d) leveling working. I looked at the other defects and did not find a close enough match to my issue, although it may be related to other auto level issues.

Everything works well on a smaller scale, ie 30-50mm radius, however when I increase the bed leveling routine to 120+ I can see the end effector dip down in a convex motion and scrape the aluminum bed.

The routine consistently detects the surface and G29 completes when I set the Z_RAISE_BETWEEN_PROBINGS value to something high like 30 but this doesn't seem practical. If I run it at ten like below it will tear up my kapton tape.

It is consistently reproducible by creating a set of points that are more than 30-40mm apart and it dips deeper as that distance increases.

Here are a few thoughts as to what this could be.
a) could it be that it assumes 0 delta_radius when planning probe moves.
b) The behavior appears to be the same as when DELTA_SEGMENTS_PER_SECOND equals 0 and I do a long move (found out that doesn't work too well)

Another odditiy is that some times after auto level completes, I can click up or down and the probe charges down about 10-15 mm, however mine does not hit the surface.

Copy of autolevel configs

Note software enstops are set to false.

define AUTO_BED_LEVELING_FEATURE // Delete the comment to enable (remove // at the start of the line)

define Z_MIN_PROBE_REPEATABILITY_TEST // If not commented out, Z Probe Repeatability test will be included if Auto Bed Leveling is Enabled.

if ENABLED(AUTO_BED_LEVELING_FEATURE)

#define AUTO_BED_LEVELING_GRID

#if ENABLED(AUTO_BED_LEVELING_GRID)

#define LEFT_PROBE_BED_POSITION -120
#define FRONT_PROBE_BED_POSITION -120
#define RIGHT_PROBE_BED_POSITION 120
#define BACK_PROBE_BED_POSITION 120

#define MIN_PROBE_EDGE 10 // The Z probe minimum square sides can be no smaller than this.
#define AUTO_BED_LEVELING_GRID_POINTS 3

#endif // AUTO_BED_LEVELING_GRID

#define X_PROBE_OFFSET_FROM_EXTRUDER 0 // X offset: -left [of the nozzle] +right
#define Y_PROBE_OFFSET_FROM_EXTRUDER 28 // Y offset: -front [of the nozzle] +behind
#define Z_PROBE_OFFSET_FROM_EXTRUDER -1.5 // Z offset: -below [the nozzle](always negative!)

#define XY_TRAVEL_SPEED 8000 // X and Y axis travel speed between probes, in mm/min.

#define Z_RAISE_BEFORE_PROBING 15 // How much the Z axis will be raised before traveling to the first probing point.
#define Z_RAISE_BETWEEN_PROBINGS 10 // How much the Z axis will be raised when traveling from between next probing points.
#define Z_RAISE_AFTER_PROBING 15 // How much the Z axis will be raised after the last probing point.

#define MECHANICAL_PROBE

Background:
I'm able to dial in the configuration and get pretty good prints using paper and probing at around 160mm in either direction. However I use a heated bed and each print subsequently has minor shifts in the height (usually drops about .1-.2mm per every 5 hours. I'd love a simple auto level procedure to re-adjust.

My printer is a custom deltabot with a large radius, 400mm rods and a large end effector.
Z height is roughly 360mm
build plate is 190mm radius
my delta_radius is 235.7mm.
Using a sn04 inductive probe measuring -1.5mm from the nozzel.

[tkurbad]

I'm seeing something similar on my Deltaprintr, though Z_RAISE_BETWEEN_PROBINGS set to 10 seems adequate here. The printer is much smaller, though (DELTA_RADIUS ~135mm(

What I observe in particular is that while the effector travels to the first probe point, the movement shows a downward bulge.

[clefranc]

@jhenak Your observations are correct. Instead of breaking the travel in small segment (like during prints), G29 use a straight line between probing points, that are natively U shaped for a delta. The solution to solve this is so simple that I was able to eliminate it:

clefranc/Marlin4Delta@c3bfd3c

I'm not an expert coder, and my fork is from the dreaded MarlinDev, but I think @thinkyhead or other collaborators can look at it and provide a quick fix.

[thinkyhead]

When this issue first cropped up, I was really unfamiliar with the planner code and how it all worked, so I was afraid to touch it. But as you point out, it's pretty trivial after all! This will be patched up ASAP.

[jakehenak]

Thanks for confirming this issue, after clefranc pointed out it was a trival fix I started digging into the code to see where the move commands are being executed and I think I found the cause of the problem.

The method do_blocking_move_to has a condition for Delta that calls prepare_move_raw(); however I think this move should actually use the prepare_move_delta() method which calculates segments per second and moves to the position.

Below is the 1 line change to the Marlin_main.cpp file that I am proposing.

 static void do_blocking_move_to(float x, float y, float z) {
 ...
    #if ENABLED(DELTA)
    ...
-      prepare_move_raw(); // this will also set_current_to_destination
+     prepare_move_delta(destination); // this will also set_current_to_destination
    ...
    #else

I'll test it out and if it works I'll check it in.

[Roxy-3D]

our observations are correct. Instead of breaking the travel in small segment (like during prints), G29 use a straight line between probing points, that are natively U shaped for a delta. The solution to solve this is so simple that I was able to eliminate it:

I ran into the same problem and my solution was different. This solution by @clefranc is better than what I did. I made do_blocking_move() break the move up into smaller sections by calling itself recursively. That worked very well, but you could hear the stepper motors speed up and slow down for each section that got broken off of the bigger move. Still... That didn't hurt anything but like I say, this is a better solution. (I didn't dare go mess around inside the prepare_move_raw() and prepare_move_delta() routines. So I did it some where I felt safe.)

This has been labeled as a verified bug. We are scrapping the nozzle some times because of it. Is everybody comfortable putting this fix into RC-6 ? I think I am.

[clefranc]

@jhenak @Roxy-3DPrintBoard This is a 2 part fix, first use prepare_move() in run_z_probe() to remove the U shape, then take care of adjust_delta() so the corrections are not applied while doing a G29. The last part needed a flag that I named bed_leveling_in_progress.

[jbrazio]

Closed by #3707, you may reopen this issue if required.

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