G32 vs G29 and dual Z axis (slight confusion)
-
Hello,
It’s my first post here so I’d like to say how happy I am to be joining the Duet userbase. It’s enirely new world and printing experience. Comming from Repetier/Marlin environment, the G-Code jungle can be sometimes confusing.
My build has two z drives and I welcomed the ability to level the bed using G32. On the other hand, in the https://duet3d.com/wiki/Setting_up_automatic_probing_of_the_print_bed it’s said that the G32 should not be used with cartesian printers but G29 (mesh compensations) which I have to use due to large bed area. Once upgraded to 1.19 I reenabled the bed.g and it does two point probing near the leadscrews.
My question is if the order of operation I’ve set up is the right way to do it.
Initial (one time):
1. Delete the heightmap.csv file
2. Run the G32 to compensate tilt (two measures close the screws)
3. Calibrate the IR sensor height (and update the config.g)
4. Run the G29 to create the heightmap.csvThe bed.g file contains now:
M561 ;clear and bed transform
G28. ;home all axis
G30 P0 X73 Y220 Z-99999
G30 P1 X260 Y220 Z-99999 S2
G29 S1 ;load and activate compensationEvery print I send has G32 at the beginning.
-
Yes, that looks good. I've updated the page you linked to because it wasn't very clear.
-
Thank you!
-
Evening Guys.
Sorry to jump in, but this topic has given me a question.
I've reverted to using G29 only with my CoreXY setup which is working well I will add.
However I do have two Z motors situated on the left and right side of the bed and so reading the above, could I rebuild a bed.g file to use G32 to level the bed for me between the two Z motors by reading just one point on either side of the bed?Thinking this could be used to check and then maybe fix any loss of steps after so many prints if yes, or should I just leave the idea alone.
Thanks.
Ian
-
The reason I was so happy about introducing support for separate Z motors was the fact, that my bed is quite heavy. After switching off the motors or the printer, I never knew if when the bed was sliding down (by its own weight and gravity) one of the sides would go further than the other - resulting in tilted bed. To overcome that, before each print I would have to slide the bed down to the point where both sides would bang on the axis ends. Only then I would home Z to min and start printing (knowing that both screws were at the matching level).
Now, I don’t know how it relates lost steps. What I do know is that using the G32 (as described in the documentation) gives the assurance that both sides of the Z drives are at the same level (after every time you run G32). The feature works by measuring the bed distance to the Z probe close to the mounting points of the multiple Z axis drives (leadscrews). If there are differences (tilt), the firmware compensates them by driving one of the motors so the distances are matching - to null out the differences.
So as I described above, having two Z drives (connected to separate drivers on Duet) I’m using the G32 before each print. After the G32 is executed and both sides of the bed leveled, the height map is loaded to compensate any bumps on the bed during print.
-
Evening Guys.
Sorry to jump in, but this topic has given me a question.
I've reverted to using G29 only with my CoreXY setup which is working well I will add.
However I do have two Z motors situated on the left and right side of the bed and so reading the above, could I rebuild a bed.g file to use G32 to level the bed for me between the two Z motors by reading just one point on either side of the bed?Thinking this could be used to check and then maybe fix any loss of steps after so many prints if yes, or should I just leave the idea alone.
Thanks.
Ian
Yes, if your two Z motors are connected to separate drivers.
-
The reason I was so happy about introducing support for separate Z motors was the fact, that my bed is quite heavy. After switching off the motors or the printer, I never knew if when the bed was sliding down (by its own weight and gravity) one of the sides would go further than the other - resulting in tilted bed. To overcome that, before each print I would have to slide the bed down to the point where both sides would bang on the axis ends. Only then I would home Z to min and start printing (knowing that both screws were at the matching level).
Now, I don’t know how it relates lost steps. What I do know is that using the G32 (as described in the documentation) gives the assurance that both sides of the Z drives are at the same level (after every time you run G32). The feature works by measuring the bed distance to the Z probe close to the mounting points of the multiple Z axis drives (leadscrews). If there are differences (tilt), the firmware compensates them by driving one of the motors so the distances are matching - to null out the differences.
So as I described above, having two Z drives (connected to separate drivers on Duet) I’m using the G32 before each print. After the G32 is executed and both sides of the bed leveled, the height map is loaded to compensate any bumps on the bed during print.
Yes, if your two Z motors are connected to separate drivers.
Evening Guys.
Brilliant, thanks for your replies.
I see, currently I'm using the Z motors series connectors on the Duet, however with the explanations in this post I can see the benefits to re-applying G32.
While I wouldn't say my Z is overly heavy perhaps, although it could be (Hypercube Evo using 2020 profiles for the bed) it sounds like a good idea to be able to automatically syncronise the two sides of the bed. I've had a couple of instances where the BLTouch doesn't stop the Z axis during homing, not sure what the link is yet to this but it seems to follow a print cancel more than anything else or leaving the printer a while following cancelling a print. It's at these times I wodner if one lead screw has been held out of sync to the other.
Maybe a future setup change I think.
Thanks.
Ian
