Duet GCode G32 query

Hello all,

can anyone advise me on the following...

I have a Kossel Mini that uses the Duet board (apologies if this post is in the wrong place)

When I run bed-calibration using a G32 command, there are some numbers in the message output relating to the x,y and z axes which I take to be adjustments/offsets. Am I correct in believing that these adjustments are then used by the 'current session' or are they not used at all? Should I be adding these figures to my config.g file?

If they are used, are they lost when I Home the axes? Are the values written to the firmware perhaps? I ask because the last thing a G32 does is Home the axes again.

Sorry for what may seem obvious questions but I need to get better understanding of the controller fundamentals, and thanks in advance for any replies.

Bill

Quote
BillHall
Hello all,

can anyone advise me on the following...

I have a Kossel Mini that uses the Duet board (apologies if this post is in the wrong place)

When I run bed-calibration using a G32 command, there are some numbers in the message output relating to the x,y and z axes which I take to be adjustments/offsets. Am I correct in believing that these adjustments are then used by the 'current session' or are they not used at all? Should I be adding these figures to my config.g file?

If they are used, are they lost when I Home the axes? Are the values written to the firmware perhaps? I ask because the last thing a G32 does is Home the axes again.

When you execute G32, file sys/bed.g is executed. The one I provide for the Mini Kossel homes the printer at the end, but this should not be necessary - and it may actually be better not to home the printer again, in case your endstop switches don't give repeatable results.

The values output are indeed used by the current session. They are not destroyed by homing the printer. Currently, they are not saved to flash, so you need to auto calibrate again when you next turn on or reset the printer.

You can add those figures into config.g if you like. If there is more than 0.5mm difference between the highest and the lowest, doing so may improve the accuracy of auto calibration a little. However, I prefer to adjust the positioning of the endstops (or the endstop trigger screws if you have any in your build) to get the endstop adjustment values produced by auto calibration within a 0.5mm range.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

I appreciate the quick and knowledgeable reply dc42.

I am using the 1.09a release of your firmware. I had started using the G32 command at the beginning of each print to reassure myself that I was beginning from a decent starting point but I became uncertain and wanted to understand if this was necessary or even useful. Thanks for confirming that it is a workable approach, the extra 30 seconds it takes to run is a small overhead, though I might now modify the bed.g code to remove the last home based on what you have said.

From the videos they have posted showing their new Fisher printer, it looks like RepRapPro have G32 in the slic3r start gcode too, since the printer appears to do a 4-factor auto-calibration at the start of each print.

I expect to release version 1.09b of the firmware soon. At the same time I'll test auto calibration without homing at the end of bed.g, with a view to removing it form my sample bed.g file. The homing command used to be necessary to make the machine take account of the modified endstop corrections, but it takes account of them immediately after auto calibration now.

Edited 1 time(s). Last edit at 06/05/2015 12:09PM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].