Bed autolevel isn't working on delta-printers.

[roboprint]

Hello, I'm using latest firmware (commit f47fc87) with delta-printer and trying to setup auto bed level feature, but this feature isn't working at all.

Array of bed level points bed_level[][] is filled in G29 in Marlin_main.cpp. Bed level must be adjusted in function prepare_move(), but adjust_delta() is not called from prepare_move(), so Z-position of hotend is not adjusted at all.

See line 4268 here for reference: https://github.com/jcrocholl/Marlin/blob/deltabot/Marlin/Marlin_main.cpp#L4268

Also, then hotend moving from one row of bed calibration points to another in G29 (i.e. then changing Y position) it moves not straight line like '---', but touching bed in the middle of move moving like 'U' letter.

[Natealus]

I have been having "true" level issues too but I've also been recoding and testing and such. On most recent commits my test array is in the front-right origin although it does still seem to do as many probings. For a bit I had it probing just about the whole bed but I still have more testing and modification to do.

[thinkyhead]

I've just fixed this in #1740 and will merge that soon.

[roboprint]

adjust_delta() is fixed, but effector U-movements during changing row of bed testpoints is still exists :(
I can upload video. Or can try to explain: then you issue G29 command, effector moves from home position down to bed and probes points in row (Y is constant, internal X for() loop in G29 function), for example, (X-20 Y-20), (X-10 Y-20), (X0 Y-20), (X10 Y-20) (X20 Y-20), then printer moves effector to next row: X-20 Y-10. And this movement isn't parallel to bed, effector moves using U trajectory, touching bed in the middle of movement.

This is not mechanics or general delta calibration issue. General movement (G1 X-70 Y0 Z15 => G1 X70 Y0 Z15) is done parallel to the bed.

I'm not understand Marlin code very well, looks like probe_pt() must call another function to move effector in delta printers. It calls do_blocking_move_to(), which calls prepare_move_raw().

[thinkyhead]

@roboprint That is unusual, because for delta, if the moves are linear during regular moves, they should also be linear during probing moves. I'm examining the code closely, but so far nothing obvious stands out. I will be messing with homing and leveling code generally, so keep checking the latest code, especially once #1764 is committed.

[roboprint]

I have uploaded latest firmware (commit 443468d which including #1764), nothing changed.

[Natealus]

I have as well experienced this...I just added more in between probing Z height for now. But a curiosity @roboprint...is your bed leveling probing the whole bed or just a quarter of it?

[roboprint]

I have found problem. It is because of movement isn't split into segments in G29 for deltas. As I said before, probe_pt() is calling do_blocking_move_to(), which calling prepare_move_raw(), which calling plan_buffer_line() one time with ONE segment.

Generally, the G1 command moves the effector, splitting the path into small segments, calculating delta using calculate_delta() in function prepare_move().

So difference is prepare_move() vs prepare_move_raw().

If you have delta printer you can test this, splitting path in prepare_move() by 1 segment using command M665 S1 - you will see U-movement for simple move G1 X-70 Y0 Z15 => G1 X70 Y0 Z15.

[Natealus]

Ah that is definitely sound research there. If it were only processing 1 kinematic segment for the whole move I could see how it could bow in a U pattern like that.

[roboprint]

prepare_move_raw() is called in many places for deltas. I also want to note that the sound of motors using one segment in movement is simply amazing, smooth, crystal clear. Sound of segmented movement is dirty, with clicks, twitches and so on.

[Natealus]

Oh yeah cause every segment is coordinating a new movement. Where else is the raw movement used?

[roboprint]

engage_z_probe(), retract_z_probe(), run_z_probe() for example. Also it used in do_blocking_move_to(), which is called from different places.

[thinkyhead]

@roboprint Thank you for your excellent insight into the issue. I've still been studying the code, thinking all is well and good with the longstanding methodology, but apparently there's some flawed thinking going on. So, what is the comprehensive solution here? Do we just have to call different movement functions for delta during probing, or is this going to be more involved?

[Natealus]

If my...less that excellent understanding of code has a penny for thought...it sounds pretty reasonable. If it's going through prepare_move rather than prepare_move_raw it would be going through the same channel that all print movements go through and get the kinematics calculations for the given type of printer. Or is that a false assumption?

[roboprint]

I think prepare_move_raw() calls must be replaced by prepare_move(), but I can't test this now. The only difference I found in this functions is path splitting.

If anyone with delta printer can reproduce this U-movements using G29 or M665 S1, he can check G29 with path splitting into segments with this quick (and dirty) hack:

Just replace original function:

void prepare_move_raw()
{
  previous_millis_cmd = millis();
  calculate_delta(destination);
  plan_buffer_line(delta[X_AXIS], delta[Y_AXIS], delta[Z_AXIS],
                   destination[E_AXIS], feedrate*feedmultiply/60/100.0,
                   active_extruder);
  for(int8_t i=0; i < NUM_AXIS; i++) {
    current_position[i] = destination[i];
  }
}

with this one:

void prepare_move_raw()
{
  prepare_move();
}

[Natealus]

Well I could already tell you mathematically your theory was sound. But I did just do an actual test using old skool 3 tower adjustment macros 30mm Z up and yup there's a total bowl curve at 1 segment per second...glad I made it 30mm up lol. If just moving 100 mm straight X or Y...you only notice the effect slightly. But if moving both X and Y (like when the probings move to the next row) it is Very apparent.

[Natealus]

Even at 20 segments per second its visually unnoticable to the naked eye without print layers...let alone 150-200 segments.

[Natealus]

And I just tested the hack...its definitely not doing the 1 segment per second bowl...but it is moving z in an odd fashion like a straight diagonal line...that could be partially due to the Z_RAISE_AFTER_PROBING adding additional height between probings bug that was talked about in another issue.

But yeah it does seem the Raw movement code unaltered is not using more than 1 delta segment which over an X and Y consecutive movement is largely noticeable as a bowl or U curve.

[thinkyhead]

Arg, I just want to go back to the old code sometimes and start over. Moving in a "U" and only probing a corner of the bed on deltas. I wish I had a completed delta to test this on, but right now mine is only half-built, needing a new stronger base to make it rigid. I was comparing this to the "official" delta branch by @jcrocholl and I might have missed something. It looks to be doing the same thing. I will have a closer look. Maybe the way to do this is to still use the more expensive movement, but just reduce the number of segments so it doesn't eat too much processor. Or does it matter? Delta is expensive computationally anyway.

[Natealus]

In terms of probing its only moving in straight lines, it by far uses more processing to do circles because so much gcode and changing is happening per second. Shouldn't be of any issue to use the normal movement call using the segments per sec we use for printing.

[thinkyhead]

Anyone down to test @roboprint's solution?

[Natealus]

@thinkyhead I did test it the posts above were my results. I've just gotten through testing the current merges and it seems Z_RAISE_AFTER_PROBING is still adding 50mm Z to the MANUAL_HOME_Z so I had to reduce 50 off my manual. But then the grid calculations that came out were a couple Thousand mm...lol something went funny there. It no longer raises the Between movements but it also isn't raising it after the G29 calibration is complete.

Taking that off everything seems to work pretty good except for that little curve that happens from it only using 1 segment to make the diagonal movement as it probes the next row. And it's still only probing the same quarter pie of the bed.

On the + side the Z_BEFORE_PROBING is working fine again and BETWEEN is working fine too. I've been trying it on Z_PROBE feature putting the pins into the Azteeg X3 Pro pins as an #ifdef Z_PROBE_ENDSTOP.

[thinkyhead]

@Natealus Let's add your printer specs to #1209 too.

[Natealus]

Hey this is trippy @thinkyhead ...G29 remains to do the quarter pie on my printer...if I do G29 E...it now does the whole bed! Thats like...the most complete calibration I've seen so far.

[thinkyhead]

@Natealus Interesting. So the option intended to just make the probe raise between probes… also makes the bed probing do the correct area? Gotta love code.

[Natealus]

Yes it seems if I had anything after the command too like //comment type thing it screws with it too. The kicker is that G29 by itself now does not extend the servo probe and just drove the nozzle down to the bed. Luckily I was watching for something odd to happen. Any other additional stuff after it sends it to do the quarter pie with servo up down for each probing.

Probe goes up and down with the G29 E thats working right now. Probably a good thing too cause it swings the nozzle pretty damn close to the surface when switching to the next row cause of only using 1 delta segment. I increased BETWEEN_PROBINGS to 10mm to make sure it doesn't contact.

[thinkyhead]

@Natealus I hope your GCode comments are actually starting with ;…

Yeah, must deal with that U-shaped move very soon!

[Natealus]

Guess that would help I tend to not do it anyways but I saw some like that in the program before. Perhaps they were mistaken in the first place lol.

Yeah no its correct now in the places they commented things in default settings. Probably was a typo I saw once.

[Natealus]

I'm heating up for a test print to see how this bed leveling is actually doing now. :)

[Natealus]

From the print it looks like the bed leveling is correctly applying to the delta radius/grid. +1 I have to redo my Kapton tape from all the...unfortunate testing incidents...lol but after that then I can fine tune the probe z offset and switch to a 0.25 mm nozzle and get really detailed tests and results. :)

[thinkyhead]

@Natealus Does that include G29 without E or only working well with G29 E?

[Natealus]

Still working well with G29 E...still doing the bowl curve when moving Y to the next row of X probings. All the straight X probings seem to be very smooth and straight like they are using the set delta segments per second.

G29 by its lonesome still does not activate the servo before it starts moving to probe down.

[Natealus]

And Z_RAISE_AFTER_PROBING is still adding its 50 to the total Z height which I compensated for and coming out with some odd measurements like:

<--251.65 -201.41 0.00 -101.31 -52.59 0.00 
<--52.36 -1.90 48.56 98.37 147.76 0.00 
<-0.00 197.61 247.85 298.06 348.11 0.00 
<-347.24 397.49 447.74 497.70 548.01 597.69 
<-598.29 648.56 698.84 749.09 798.80 0.00 
<-0.00 0.00 0.00 850.43 0.00 0.00 
<-ok
<-echo:endstops hit:  Z:1132.95 Z_PROBE:1132.95
<-X:19.00 Y:138.00 Z:914.73 E:0.00 Count X: 981.64 Y:1013.90 Z:1132.96

This is what a normal one looks (with it commented out)

<--3.45 -1.73 0.00 -2.36 -2.40 0.00 
<--1.84 -1.78 -1.71 -1.96 -1.69 0.00 
<-0.00 -1.83 -1.53 -1.56 -1.73 0.00 
<--2.11 -2.00 -1.89 -1.49 -1.74 -2.15 
<--2.48 -0.60 -0.41 -0.64 -0.99 0.00 
<-0.00 0.00 0.00 0.37 0.00 0.00 
<-ok
<-X:19.00 Y:138.00 Z:14.67 E:0.00 Count X: 131.58 Y:163.84 Z:282.90

[thinkyhead]

Doing some tweaking at #1811…

[Natealus]

I will do more testing after a...4-6 hour nap. ;)

[lcfm1]

i have similar. when tuning between the rows of dots head moves in a parabola
PS on delta printer

[Natealus]

Yeah I detailed some of my testing in another article on this issue too. I think thinkyhead might look at it when he has time.

[thinkyhead]

Lots of probing and homing logs to read through on #1769 and elsewhere…

[thinkyhead]

Getting closer, I have a rolled-back branch ready for testing. Please move to #2040 to help narrow down the most likely culprit.

[thinkyhead]

With the serious leveling issues patched up, we can next ensure that moves aren't U-shaped any more. I probably asked this before, but does the problem exist with the @jcrocholl branch?

[a4jp-com]

How is this bug fix going?

[thinkyhead]

@a4jp-com Generally bed auto-leveling is working well, with some lingering issues. Moves between probes on deltas may still be u-shaped, but it's easier to tune the height between moves to compensate for any lowering of the nozzle. We might just close this issue and work on the more specific issues in each of their own topics....

[a4jp-com]

Okay. Cool.

[a4jp-com]

Bug Fixing Round 2 is done ^^

[schirrel]

Is anyone having U shape problem?
I had it without the autolevel but i put an pullup and this problem was solved.
Now that i'm trying to implement autolevel it has came back.

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