Issue converting bed.g to use Conditional gcode

tekkydave

Hi. I have been modifying my bed.g to use condition gcode as per the example here. I have a corexy with 3 independent z motors so only 3 points are probed.

My M671 in config.g is

M671 X-35:335:150 Y63:63:365 S1.0            ; leadscrews at front-left, front-right and rear-centre

so G30 can only adjust up to 1mm maximum in any individual screw.

bed.g

; If the printer hasn't been homed, home it
if !move.axes[0].homed || !move.axes[1].homed || !move.axes[2].homed
  G28

while true
  if iterations = 5
    abort "Too many auto calibration attempts"

  G30 P0 X10 Y63  Z-99999         ; probe near a leadscrew
  if result != 0
    continue

  G30 P1 X290 Y63  Z-99999        ; probe near a leadscrew
  if result != 0
    continue

  G30 P2 X150 Y290 Z-99999 S3     ; probe near a leadscrew and calibrate 3 motors
  echo result
  if result != 0
    continue

  if move.calibrationDeviation.deviation <= 0.03
    break

  echo "Repeating calibration, Deviation is " ^ move.calibrationDeviation.deviation ^ "mm"

echo "Auto calibration successful. Deviation = " ^ move.calibrationDeviation.deviation ^ "mm"

G28 Z   ; re-home z axis in case it has shifted

The problem is with the final probe
G30 P2 X150 Y290 Z-99999 S3
If one of the screws is more than 1mm out then G30 generates an error (result = 2) and doesn't proceed with adjusting the screws.

G32
Error: Some computed corrections exceed configured limit of 1.00mm: 0.737 -1.316 0.712
2
Auto calibration successful. Deviation = 0.000mm

which is expected as I have deliberately moved one to test the script.

The loop is exited immediately since move.calibrationDeviation.deviation is already 0.0 from the previous (good) calibration.

I can't see how this code could work unless either:

G30 can be forced to adjust by 1mm regardless of the error, or
move.calibrationDeviation.deviation can be set to an arbitrarily large value.

Any ideas most welcome

EDIT:
Board: Duet WiFi 1.02 or later + DueX2
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.01-beta2 (2020-01-23b1)
Duet WiFi Server Version: 1.23

droftarts

@tekkydave Isn't it doing what you told it to do with the M671 ... S1.0 command, which limits movement to 1mm? If you do this without using conditional code you get the same error message, though without the misleading message that calibration was successful. What behaviour are you expecting/wanting when the deviation is greater than the limit you set? I'd say this was a good place for automation to cease, because if it's moved more than 1mm (or whatever value you set), you'd want to know, as there may be some other issue.

Ian

tekkydave

That's a good point. I was assuming the M671 limit was just that; it would only move 1mm and report the fact so further calibrations could be carried out.
Maybe I have got the use case of the example wrong too. In the dozuki it says:

"if calibration yields a standard deviation that is above a limit, it repeats the calibration process"

maybe it needs an extra comment about it only working within the limit set by M671.

I'll have to come up with a slightly different script to achieve what I need

dc42

@tekkydave said in Issue converting bed.g to use Conditional gcode:

G30 P2 X150 Y290 Z-99999 S3 ; probe near a leadscrew and calibrate 3 motors
echo result
if result != 0
continue

What it should be doing with that code is starting the loop again if the movement required is too high. Does it? Then after probing those points 5 times it will exit the loop.

What I think you need to do instead is to abort if that final G30 command fails.

tekkydave

It aborts anyway if G30 errors. It returns result=2 so control drops out of the loop prematurely. I think I assumed it would progressively 'home in' to correct a large levelling discrepancy by correcting say 1mm each iteration at a time. If you have the S parameter of your M671 set large enough it corrects it first iteration anyway.

gtj0

@tekkydave said in Issue converting bed.g to use Conditional gcode:

It aborts anyway if G30 errors. It returns result=2 so control drops out of the loop prematurely. I think I assumed it would progressively 'home in' to correct a large levelling discrepancy by correcting say 1mm each iteration at a time. If you have the S parameter of your M671 set large enough it corrects it first iteration anyway.

I would have thought that as well. I'd have expected the G30 ... S3 to terminate the current probe "session" and in the next iteration it would start over again, just as if you had no loop and ran bed.g multiple times manually.

OwenD

@tekkydave I would have thought the max adjustment limit of 1mm was relative to the point probed in homeall.g
In order for the adjustment to be cumulative you would have to home Z after each iteration to reset that point.

gtj0

@dc42 will have to confirm or deny (because that code makes my head hurt) but I think it's correction, per screw from where the screw was at the time the probe was done.

gtj0

A quick experiment revealed that if the M671 S limit is reached, no correction is done at all so it can't possibly converge by running multiple times. The only way out would be to manually move the screws until the correction would be inside the limit.

fcwilt

@gtj0 said in Issue converting bed.g to use Conditional gcode:

A quick experiment revealed that if the M671 S limit is reached, no correction is done at all so it can't possibly converge by running multiple times. The only way out would be to manually move the screws until the correction would be inside the limit.

It seems that something may have changed since I last used auto-leveling. Back then it made the max adjustment it could and multiple runs kept improving things.

Frederick

gtj0

I thought it did as well which is why i tested it. I set my limit to 1mm and manually moved 1 screw so it would need at least 3mm then ran G32 S3. It probled the 3 points but returned Some computed corrections exceed configured limit of 1.00mm: -0.219 3.092 -1.290 with no movement.

Bear in mind, I'm using RRF3 via the DSF/SBC. It may be different in standalone mode. I can check that in a bit.

gtj0

Nope, no change in standalone mode...

M671 X-23:238:498 Y13:485:13 S1
ok
G28
ok
G32 S3
Error: Some computed corrections exceed configured limit of 1.00mm: 0.935 -3.386 -2.561
G32 S3
Error: Some computed corrections exceed configured limit of 1.00mm: 0.939 -3.385 -2.561

gtj0

@dc42 : Bug?

A Former User

@gtj0 it can be a bug or a feature depends on how the G32 was designed by author
to me it looks like it's intentional to do not do any correction if discrepancy is larger by limit set by M671Sxxx. I'd too probbly do it exactly like that but would be cool to have a separate parameter for M671 to "do max x mm of adjustment" in order to be able to do what you want (adjust only 1mm then measure again, adjust 1mm max, measure etc etc.. ) ... but I'd keep Sxxx limit as a "hard one" as if "too badly missaligned" or "damaged probe" or "$h1t on the print bed you are probing over" trying to fix it could be damaging to the printer itself

Danal

@gtj0 said in Issue converting bed.g to use Conditional gcode:

The only way out would be to manually move the screws until the correction would be inside the limit.

Or chose to configure a larger limit. M671 S10.

Only you can know what limit represents "this is about to damage the printer" vs. "OK to adjust this large amount".

tekkydave

@gtj0 said in Issue converting bed.g to use Conditional gcode:

A quick experiment revealed that if the M671 S limit is reached, no correction is done at all so it can't possibly converge by running multiple times. The only way out would be to manually move the screws until the correction would be inside the limit.

That's what I've found.

tekkydave

@fcwilt said in Issue converting bed.g to use Conditional gcode:

@gtj0 said in Issue converting bed.g to use Conditional gcode:

A quick experiment revealed that if the M671 S limit is reached, no correction is done at all so it can't possibly converge by running multiple times. The only way out would be to manually move the screws until the correction would be inside the limit.

It seems that something may have changed since I last used auto-leveling. Back then it made the max adjustment it could and multiple runs kept improving things.

Frederick

Yes, I thought it worked that way but obviously not.

tekkydave

Thanks for all the helpful comments. Just to say I have no issue with the way G30 works although the option to move by a limited amount per session would be a nice to have.
My issue is about the example code which seems to suggest it can iteratively home in when it can't.

I usually have my limit at 3mm which works fine and to be fair G30 usually achieves a deviation of 0.0 on my D-Bot first time it runs.

droftarts

@tekkydave said in Issue converting bed.g to use Conditional gcode:

My issue is about the example code which seems to suggest it can iteratively home in when it can't.

"if calibration yields a standard deviation that is above a limit, it repeats the calibration process"

From https://duet3d.dozuki.com/Wiki/GCode_Meta_Commands#Section_Using_conditional_GCode_commands_in_bed_g_to_calibrate_a_delta_printer

I think you have misinterpreted what the 'limit' is; it's not the hard limit imposed by M671, it's the limit set in these lines:

if move.calibrationDeviation.deviation <= 0.03
break
echo "Repeating calibration because deviation is too high (" ^ move.calibrationDeviation.deviation ^ "mm)"

ie 0.03mm. If the calibration is more than 0.03mm out, it repeats it for up to 5 times.

Ian

tekkydave

@droftarts said in Issue converting bed.g to use Conditional gcode:

@tekkydave said in Issue converting bed.g to use Conditional gcode:

My issue is about the example code which seems to suggest it can iteratively home in when it can't.

"if calibration yields a standard deviation that is above a limit, it repeats the calibration process"

From https://duet3d.dozuki.com/Wiki/GCode_Meta_Commands#Section_Using_conditional_GCode_commands_in_bed_g_to_calibrate_a_delta_printer

I think you have misinterpreted what the 'limit' is; it's not the hard limit imposed by M671, it's the limit set in these lines:

if move.calibrationDeviation.deviation <= 0.03
break
echo "Repeating calibration because deviation is too high (" ^ move.calibrationDeviation.deviation ^ "mm)"

ie 0.03mm. If the calibration is more than 0.03mm out, it repeats it for up to 5 times.

Ian

Not what I found. G30 exits if the limit in M671 is exceeded without getting to the test.