TL;DR: I am thinking of trying to make a further improvement by modifying the code (either in webcontrol or firmware, or both) to:
Prompt the user to verify the correct tool is inserted after every tool change (with a setting to enable/disable this functionality)
When the gcode is loaded, it is parsed to determine if there are tool changes present and if so, offer the user an option to define what tool size (e.g., 1/8-inch upcut) is associated with each tool value. When a tool change command is received from the firmware, this value is looked-up and the tool type is reported as well as the tool number.
Give user the option to save the tool information from 2) to a comment at the beginning of the gcode that can be parsed by webcontrol if its reloaded.
Indicate on screen what tool the firmware thinks its using.
Some gcode processors might report tool sizes in their gcode, I don’t know… is there any standard?
Any thoughts on the above?
…
One of the operations that can cause cutting to go wrong is the tool change operation and if something goes wrong, youu can end up cutting with the wrong size tool. For background, the firmware keeps track of the current tool being used (sys.lastTool) and when it receives a tool change command, it compares the new tool value with the current tool value and if it’s different, it sends a message to ground control / webcontrol to notify the user to change the tool. sys.lastTool is not explicitly initialized on startup, so I believe it gets initialized with a zero value. This value is an integer, not the size of the tool. If something goes wrong and the machine thinks it’s using Tool 1 but is really using Tool 2 and sees a command to change to Tool 1, it will be ignored and cutting won’t stop.
Also, from a user perspective, all that gets reported to the user is to change the tool to the new number. The user needs to know what tools correspond to the tool change value (e.g., 1 = 1/8 inch, 2 = 1/16 inch, whatever…) generated by the CAM software.
I think an issue can potentially arise when a user restarts cutting when there is tool change gcode present in the file. My recollection of ground control is that its up to the user to verify that the correct tool is inserted into the router and that they always start at a z-axis move whenever they try to restart a run at a particular spot (not unpause, but actually start again). In webcontrol, I completely rewrote the routine to parse through the gcode and determine the state the machine should be in at the line from which the user wants to start. For example, if there was a spindle-on or tool change command, it would be captured and performed. I think the additions I mentioned in the TL;DR section would help improve how tool changes are handled and possibility eliminate somme of these potential issues.
I think tool changes are something which can absolutely be improved. Some gcode generators throw a T0 in front of every block of moves which would result in the user seeing a “Is tool 0 still in the machine” option pop up very often which would get annoying, but I think that’s really an issue on the part of the gcode generator and you handle it by having a setting.
One thought would be to have the webcontrol manage the tool changes entirely and not depend on the controller (i.e., don’t even send the tool change gcode to the controller). I think this would make it much more manageable and wouldn’t require any special coding of the current firmware(s).
I don’t like this idea. It works currently, but it has the potential to bite us
in the future (say if we have a 4-motor sled that has more than one tool on it)
Also, it makes the tool change feature behave differently if you are feeding the
g-code from WC than from some other g-code sender, which means that the tool
change code in the firmware won’t get excercised and tested.
After posting the idea, I thought it might still be useful to send the gcode and use the resulting tool change message back as some sort of confirmation.
Do you know how other firmwares & senders interact with tool change commands? Do firmwares universally pause when they see a tool change command and send a “standard” message to the sender to notify the user?
Standard grbl doesn’t support M06 tool changes (reports as unsupported). It tracks the tool value, but doesn’t stop when the tool value changes or an M06 is issued.
The esp32 version issues a:
“[MSG:Tool Change]”
I don’t know if that causes the controller to pause…I hope it does or the sender recognizes it and stops sending.
Maslow’s firmware issues a:
"Tool Change: Please insert tool "
and causes the controller to turn off the spindle and pause. It waits to see a resume command from the sender.
Right now I see this handled in GRBL by grouping all cuts of a certain tool to a single file. Say all 1/4 inch flat end mill operations in .25inch_flat.nc, then all 1/8 inch end mill cuts and so on. You gain control between the files. You swap the bit and re set the Z hight. X&Y use the same point of origin to keep the same reference between tools.
Some advanced users hand edit the Gcode to lift the bit, replace it and issue a Z touch probe command.
I recently tried to include a M06 and M00 in my code and my Maslow didn’t stop. I had the most up to date GC and firmware as of a couple weeks ago when I was home using it. I would really like it to at least pause, although have a max Z height would be excellent. I know the modern CNC machines I’ve worked on know how far they can move and have that stored as a value so they know when a command tells them to move out of their work envelope. I would hope we could mimic something like that.
The M06 command should/will result in a pause only if the associated tool change command (e.g. T1, T2) is different than the current tool. I think the M and T commands might have to be on separate lines as well… not 100% sure about that (or which one comes first)… whatever makercam produces is what it needs to be.
I looked at firmware code. M0 is ignored, but M1 will pause. For tool change, I think the T command has to come before the M6 command. Still not sure about same line or separate lines.
Oh ok, I figured the M00 would be implemented before M01 lol. That’s what I get for doing my own thinking. I had the T before the M06 so I’m guessing that they have to be on separate lines. Thanks!