-
-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Storing homeing coordinates in the controller #19
Comments
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. |
I did create a version of the homing cycle script that uses g10 instead of g92 $H ;run GRBL homing cycle |
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. |
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. |
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 grbl/grbl#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: gnea/grbl#156
The text was updated successfully, but these errors were encountered: