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.