Code: Select all
first part of program
.
.
(Tool Change...)
G90 G00 Z70 //arbitrary Z safety height since I don’t have my S3 yet ):
X0 Y0 M5 //go to a reachable position for manual tool change (home maybe?)
M0 //pause program when tool change position is reached
**Actual tool change happens here, after done hit cycle start** (might be a good idea to keep power to motors on to avoid axis movement while changing the tool)
X10 Y400 //arbitrary/permanent touch plate location
Z35 //so probing wont take that long (careful with long tools?)
G49 //delete previous tool offset
G38.2 Z0 F25.4 //probe cycle to Z0 with 1 in/min feed rate
G43.1 Z[#5063 - TOUCHPLATE_THICKNESS] //apply dynamic tool offset
//variable #5063 is the standard storage location for the z coordinate
//when the probe switch triggers
G00 Z35 //return tool to safety Z height
M3 //turn on spindle
G4 P3 //give time in seconds for spindle get to desired speed
(End of tool change…)
.
.
program continues
- grbl wont allow movement on M0 commands for safety issues as chamnit have previously stated on github if i remember correctly which i think is best
- M6 commands are not supported
- tool tables are not supported due to table managment resources needed
- variables/arithmetic is not supported by grbl in the gcode file
Case:
When the G43.2 command is completed without an error, the tool is touching the touchplate, motion stops and the Z coordinate is known. With this in mind, if there could be a variable TOUCHPLATE_THICKNESS or alike in the grbl settings for the user to set, then grbl could compute the offset internally whenever the G38.2/G38.3 is called and output/return/storage the value to a known variable, lets say COMPUTED_OFFSET.
If this could be done, then the code above would change to:
Code: Select all
.
.
G38.2 Z0 F25.4 //probe cycle to Z0 with 1 in/min feed rate
G43.1 Z COMPUTED_OFFSET //apply dynamic tool offset (SOME KIND OF POINTER WOULD NEED TO BE PLACED IN ORDER TO LET THE PARSER KNOW TO RETRIEVE THE VALUE STORED IN COMPUTED_OFFSET)
.
.
with this, arithmetic within the gcode is not needed and it would only need those two variables (only one in the gcode with a predefined name)
tool table would not be needed since the dynamic tool offset is only set for the tool being used and recalculated with each tool change
this would eliminate the need for a specific GUI for tool offsetting
it could also eliminate the tedious task of slicing gcode files into subfiles for every tool change
could eliminate using some other method for tool lenght setting such as bit stop collars
would be repeatable, accurate and reliable
and you could virtually have any tool changes as you like without worring about how far the tool is in the shank when a tool change is done
only one variable handling would be needed from the parser (COM{UTED_OFFSET)
cons:
it would require the user to keep an eye on the machine for when the machine stops for a tool chnge (which he might already be )
if tool change takes too long, motors might get too warm? (if power to motors is on all the time to keep position)
dont know about how difficut / time consuming would be to adapt grbl code (or even if its possible)
Question:
How viable/hard would this solution be to implement on grbl? does it sound good or im just loosing my mind over this?
any comments are pretty much appreciated
Rod