Storing homeing coordinates in the controller

[Jaknil]

We have been using G92 - temporary coordinate system offsets for our homeing procedures. This means that we have been storing the distance between the limit switches, probe plate, work area and spoilboard thickness as values in post-processors and homeing-gcode-files or macros.

This presents the problem of keeping the post-processors up to date when the spoilboard is planed or switch gets moved.

Grbl supports storing machine coordinate systems in persistent memory using the G10 command instead and this is the recommended method of storing homing offsets. So we should use this instead.(See https://github.com/grbl/grbl/issues/54 for a discussion of this.)

Somthing we need to figure out is how to do a tool length offset based on probing. I have not found an easy to follow instruction on this. Here is a point to start reading: Look for G43.1 in https://www.shapeoko.com/wiki/index.php/G-Code#Tool_Length_Offsets_and_Tool_Changes

The grbl-wiki wants help setting up homeing instructions so when we are done we should contribute there: https://github.com/gnea/grbl/issues/156

[theholyduck]

Im not entirely sure this is possible with the current grbl codebase

if we could create a persistent tool with g10 and load it with g43 as described here http://linuxcnc.org/docs/2.6/html/gcode/gcode.html#sec:G43 after zeroing with the plate. we would have the perfect method of applying whatever is the current offset without having to update any pre-processors. Sadly grbl only supports g43.1 which means we still need to have the correct offset in the post-processor.

Another option might be using numbered or named parameters. http://linuxcnc.org/docs/html/gcode/overview.html#sub:numbered-parameters if we were able to store and retrive one of the numbered or named parameters in eeprom and use those in our gcode we would also be able to do something like G10 L20 P1 Z#currentSpoilboardThickness and get the correct offset that way without having to update the post-processor. but i havent figured out how to use parameters/variables in gcode for grbl

[theholyduck]

I did create a version of the homing cycle script that uses g10 instead of g92

$H ;run GRBL homing cycle G10 L2 P1 X-1225 Y-2480 z-10 ;Just in case. re-set X and Y to prefered 0,0 and re-set the Z axis aswell. just in case. G0 Y2475 X45 Z-20 ;quickly jog to a good postion to start probing. X is important, Z negative is just to save some time G30.1 ;set this as a remembered position for later use if we run a manual toolchange operation and need to probe again.
G38.2 F300 Z-130 ;start probing downwards G10 L20 P1 Z0.0 ;set new zero G0 Z2 ;up 2mm G38.2 F50 Z-5 ;probe again with extra slow speed for maximum precision G10 L20 P1 Z7.0 ;set set a new zero with built in compensation for Remaining spoilboard G0 Z50 ;back to working height`

[JensDyvik]

If octoprint is used instead of UGS, all that is needed is to paste the start gcode into the gcode scripts start code section http://docs.octoprint.org/en/master/features/gcode_scripts.html#sec-features-gcode-scripts

This has been tested and verified to work with regular gcode on hattori at bitraf. I think it works so well that we should concider closing this issue.

Work on tweaking the octoprint user interface for 3 axis cnc milling is ongoing and promising so far. If it is desirable to keep UGS as a gcode sender instead of octoprint on a raspberry pi, it might be easier to tweak ugs to include the start code instead of teaking the grbl firmware.

On a side note: Octoprint gcode scripts can store the coordinates of a machine before pausing, so we can pause the machine, enter the room to verify/check and restart from last position. This could be achieved with a resume from pause script that will first execute the autohome then move above the last position, restart the spindle and move down into the material.

[Jaknil]

I have written a guide for how to do this now: https://github.com/fellesverkstedet/fabricatable-machines/wiki/Machine-setup#alternative-1-homing-with-coordinates-stored-in-the-controller

I also want to submit a new idea on the topic. That when we plane the work area we also plane the area that the probe plate is mounted on. Then we can use the probe plate thickness as a non-changing offset in the post processor. Meaning we could use the same postprocessor for all machines.