Issue converting bed.g to use Conditional gcode



  • 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


  • Moderator

    @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



  • 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 🙂


  • administrators

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



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



  • @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.



  • @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.



  • @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.



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



  • @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



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



  • 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
    


  • @dc42 : Bug?



  • @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



  • @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".



  • @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.



  • @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.



  • 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. 🙂


  • Moderator

    @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



  • @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.


  • Moderator

    @tekkydave ANY G30 bed levelling exits if it exceeds the deviation limit set by M671, whether it's called in conditional gcode or a manual bed levelling. If you'd rather M671 issued a warning and attempted to level, rather than exiting, you'd best ask @dc42 for that functionality.

    Ian



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

    @tekkydave ANY G30 bed levelling exits if it exceeds the deviation limit set by M671, whether it's called in conditional gcode or a manual bed levelling. If you'd rather M671 issued a warning and attempted to level, rather than exiting, you'd best ask @dc42 for that functionality.

    Ian

    I'm ok with how G30 works and I understand what you mean about the "real" test being the 0.03. I just wanted to point out that the example needs a line explaining that it will only work within the limit you have set in your M671 command. Most users would have left this at the default of 1mm. If you have disturbed one of your leadscrews by more than 1mm you will need to manually level the bed before running the macro.


  • administrators

    Currently, if calibration fails then move.initialCalibrationDeviation and move.finalCalibrationDeviation are not changed. I'll change this in beta4 so that they are both set to the measured initial deviation. Also I'm thinking of moving them to a separate move.calibration section.


  • Moderator

    @tekkydave I've just realised the example code is for a delta printer, which doesn't use M671 (no leadscrews) to limit correction, so hasn't been considered in the description or writing of the code. I've updated the page to reflect this.

    NOTE: If you use this method to iterate the levelling of a bed/gantry mounted on leadscrews (eg Cartesian, CoreXY etc), the maximum deviation corrected is still limited by the S parameter of M671 (default 1mm). If the maximum deviation exceeds this limit, the script will exit with "Error: Some computed corrections exceed configured limit of 1.00mm", as it would if G30 bed levelling was called manually.

    https://duet3d.dozuki.com/Wiki/GCode_Meta_Commands?revisionid=HEAD#Section_Using_conditional_GCode_commands_in_bed_g_to_calibrate_a_delta_printer

    Ian



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

    @tekkydave I've just realised the example code is for a delta printer, which doesn't use M671 (no leadscrews) to limit correction, so hasn't been considered in the description or writing of the code. I've updated the page to reflect this.

    NOTE: If you use this method to iterate the levelling of a bed/gantry mounted on leadscrews (eg Cartesian, CoreXY etc), the maximum deviation corrected is still limited by the S parameter of M671 (default 1mm). If the maximum deviation exceeds this limit, the script will exit with "Error: Some computed corrections exceed configured limit of 1.00mm", as it would if G30 bed levelling was called manually.

    https://duet3d.dozuki.com/Wiki/GCode_Meta_Commands?revisionid=HEAD#Section_Using_conditional_GCode_commands_in_bed_g_to_calibrate_a_delta_printer

    Ian

    Thanks 🙂 I realised the code was for a delta but adapted it to the commands I normally used in bed.g. I didn't know delta's don't use M671 so 😝 to me for using it in the wrong context. I was keen to have a play with conditional g-code.
    Dave


Log in to reply