G32 not acting as expected



  • I am setting up the G32 auto level for my Hypercube build and it works pretty good but weirdly it does not level the bed correctly. The back corners are higher up than the front 2 corners and it always repeats that way. I am using 4 separate Z motors and probing 4 points. Another curious thing, whenever I finish a print or do the G32 command it says deviation is about 1.100mm or something like that and "corrects" itself, but from there if I run a print and do it again it is off by about that same amount, anyone have any ideas on that?



  • Can you post your bed.g macro so we can see what G32 is doing? Are your probe points in the same order your stepper drivers are listed?



  • Here they are, also here is my config section dealing with that

    M584 X0 Y1 Z6:7:5:2 ; Z Motor Mapping
    M671 X-22.0:670.0:-22.75:670.0 Y127.0:127.0:500.0:500.0 S5.

    ; Z-Probe
    M574 Z1 S2 ; Set endstops controlled by probe
    M307 H7 A-1 C-1 D-1 ; Disable heater on PWM channel for BLTouch
    M558 P5 H5 F500 T4000 X0 Y0 Z1 ; Set Z probe type/mode 5. H=Dive Height. F=Speed the bed moves
    G31 P500 X-27.0 Y0.0 Z2.3117 ; Set Z probe trigger value, offset and trigger height
    M557 X30:550 Y30:550 S25 ; Define mesh grid

    bed.g
    ; called to perform automatic bed compensation via G32
    ;
    ; generated by RepRapFirmware Configuration Tool v2 on Mon Feb 11 2019 12:17:42 GMT-0500 (Eastern Standard Time)

    M561 ; clear any bed transform
    G29 S2; Clear bed height map
    ; Probe 3-point
    M401 ; Deploy probe - deployprobe.g
    G30 P0 X45.0 Y45.0 Z-9999 ; Front Right
    G30 P1 X550.0 Y45.0 Z-9999 ; Front Left
    G30 P2 X45.0 Y550.0 Z-9999 ; Front Left
    G30 P3 X550.0 Y550.0 Z-9999 S4 ; Center Rear
    M402 ; Retract Probe - retractprobe.g



  • @phaedrux Also ignore the comments on the bed file I never bothered to label them correctly oops that's embarrassing haha



  • Your probe point order looks like it makes a backwards Z pattern.

    Review the documentation perhaps: https://duet3d.dozuki.com/Wiki/Bed_levelling_using_multiple_independent_Z_motors



  • @Phaedrux Yes it does that, is that not okay? I read this and it did not imply that I needed to do it in any sort or order besides the order that the motors were defined. So how should I change this to make it better?



  • I think it just needs to be in the same order the lead screws are defined. I would think that would usually be in a circular clockwise pattern, but I suppose it need not be? Not sure.

    Using 4 lead screws isn't recommended due to the added potential for binding, which seems possible in this case. What happens if you even them up manually and then run G32? Does it stay level or get worse? What happens if you run G32 a few times in a row, does it improve?



  • @phaedrux said in G32 not acting as expected:

    Using 4 lead screws isn't recommended due to the added potential for binding, which seems possible in this case. What happens if you even them up manually and then run G32? Does it stay level or get worse? What happens if you run G32 a few times in a row, does it improve?

    If I run it a few times in a row the deviation number gets lower and lower but it still looks uneven , when I print the side that looks like it is sticking up slightly has a more crushed layer line. I have not tried manually fixing it and running it again but I will try that once this print finishes and report back. If I have to go to three I will but I really liked the idea of 4 points of control



  • 4 points is possible but there needs to be enough flex in the bed frame to allow for it to go out of true during leveling without causing binding.

    I assume you're using a BLtouch as your probe. How consistent are the probe results? If the probe isn't consistent that could explain poor leveling results. I notice you're using the older P5 probe type. Consider switching to the dedicated BLTouch probe type P9. You can then also reduce the trigger threshold value in G31 P500 to G31 P25, both of which may help make the BLTouch trigger more responsive.

    Also, what firmware version are you running? Upgrade to 2.02 if you aren't already running it.



  • @phaedrux said in G32 not acting as expected:

    I assume you're using a BLtouch as your probe. How consistent are the probe results? If the probe isn't consistent that could explain poor leveling results. I notice you're using the older P5 probe type. Consider switching to the dedicated BLTouch probe type P9. You can then also reduce the trigger threshold value in G31 P500 to G31 P25, both of which may help make the BLTouch trigger more responsive.

    Great tips I will try all that and report back!



  • @deanethiro I forgot to mention also that your probe speed is rather high for the BLTouch. Try M558 F120 instead.



  • @phaedrux Ok so I changed everything and made the probe points closer to the lead screws and it seems to be doing a better job. I am going to run the tests you suggested and report back with those results.


  • administrators

    The order of the probe points in bed.g doesn't matter, except when using bed.g to perform old-style 3, 4 or 5 point bed compensation (which is not the same as bed levelling using independent leadscrews).

    The model used by the leadscrew adjustment calculation assumes that the bed is free to tilt about each leadscrew as if it is attached to the leadscrews by gimbals. When using 4 leadscrews, it also assumes that the bed is free to twist. In practice, the bed and leadscrew nuts do not behave exactly like this. Often this means that after applying the corrections, if you probe again you find that smaller corrections in the same direction are still required. If this is the case then you can use the F parameter of the M671 command to deliberately over-correct.

    If the corrections needed increase each time instead of decreasing, this usually means that the order of the leadscrews coordinates in the M671 command is not the same as the order of the corresponding motor drivers in M584.

    Bed levelling using independent Z motors does not work in firmware 2.03beta1. It does work in 2.02 stable and in 2.03beta2. There are also some older firmware releases in which the calculation for 4 leadscrews was incorrect.



  • @dc42

    Ok good to know, the number has ALWAYS decreased when I did multiple G32 commands. I will give that F parameter a try and see what that does.

    I am using firmware 2.02(RTOS) so It sounds like I am safe from math errors?


  • administrators

    @deanethiro said in G32 not acting as expected:

    I am using firmware 2.02(RTOS) so It sounds like I am safe from math errors?

    Yes, the bug in 4-leadscrew levelling was fixed almost a year ago in firmware version 1.20.



  • @dc42 said in G32 not acting as expected:

    Yes, the bug in 4-leadscrew levelling was fixed almost a year ago in firmware version 1.20.

    I noticed reading about the M671 command that "For printers that print directly onto a desktop and have levelling feet, this command can be used to define the coordinates of the levelling feet, so that bed probing can be used to calculate and display the adjustments needed to the feet. In this case the displayed corrections must be reversed. For example, "0.2 turn down" means the bed needs to be lowered or the printer raised by 0.2 turn lower at that screw position."

    My printer is a Hypercube that has the bed move down in +Z movement do I need to change anything due to that? The height map generated by a g29 seems to be upside down when I tried that so maybe that is the source of my issue?


  • administrators

    @deanethiro said in G32 not acting as expected:

    @dc42 said in G32 not acting as expected:

    Yes, the bug in 4-leadscrew levelling was fixed almost a year ago in firmware version 1.20.

    I noticed reading about the M671 command that "For printers that print directly onto a desktop and have levelling feet, this command can be used to define the coordinates of the levelling feet, so that bed probing can be used to calculate and display the adjustments needed to the feet. In this case the displayed corrections must be reversed. For example, "0.2 turn down" means the bed needs to be lowered or the printer raised by 0.2 turn lower at that screw position."

    My printer is a Hypercube that has the bed move down in +Z movement do I need to change anything due to that? The height map generated by a g29 seems to be upside down when I tried that so maybe that is the source of my issue?

    No, you don't. As I understand it, your issue is that when you run g32 it makes corrections in the correct direction, but it under-corrects. That is very common for the reasons I explained, and is why I added the F parameter.



  • @dc42

    My Main issue is that the G32 seems to level it backwards I guess, the front side of the bed is always too low and the back side of the bed is always too high, it is close enough to print stuff but say when I print a benchy, the skirt on the front is almost not wanting to stick and the skirt towards tho back of the printer is almost transpartent because its being squished so much.

    I just tried to use G29 height map and it seems to be doing the same thing. I will draw a diagram to explain what I think it happening



  • @dc42 alt text

    Here is what I am talking about

    EDIT: forgot to mention on the picture X0 Y0 Z0 is the back left corner but it shows on the back right corner fro the bed mesh


  • administrators

    Some observations:

    1. You have set up your printer to use a left hand coordinate system. That means you will get mirror image prints. Also the height map displayed by DWC is the mirror image of the actual height map being used. You should change ot to use a right hand coordinate system. If +X is to the right, then +Y must be to the rear and X=0 Y=0 must be at the front left.

    2. We can't see the rear left corner of the displayed height map, but if it is as blue as the rear right corner that we can see, then you have either a lot of sag in the Y axis, or a bed that is far from flat.


Log in to reply