-
Notifications
You must be signed in to change notification settings - Fork 295
Job Exception Handling
NOTE: Functions on this page are in effect as of build 083.xx and later.
See also: Alarm Processing
Character | Operation | Description |
---|---|---|
! | Feedhold | Start a feedhold. Ignored if already in a feedhold |
~ | End Feedhold | Resume from feedhold. Ignored if not in feedhold |
% | Queue Flush | Flush remaining moves during feedhold. Ignored if not in feedhold |
^d | Kill Job | Trigger ALARM to kill current job. Send {clear:n}, M2 or M30 to end ALARM state |
^x | Reset Board | Perform hardware reset to restart the board |
-
Stop a Single Move - Feedhold + queue flush
!%
is used to terminate a single move in cases such as homing, probing, and some forms of jogging. A!%
will transition the system to a STOP. At this point the controlling program in the firmware, or on the host can perform the next action. (See g2 differences) -
Stop Multiple Moves - In some jogging implementations multiple moves may be queued up as part of a single jogging move. In this case a
!%
needs to take the system to a STOP, but not before draining all other moves that are queued before the%
. It is possible that the sender has filled the planner buffer, serial input RX buffer, USB internal buffers, and even host-based buffers for this single jog move. All these moves need to be flushed before transitioning to a STOP. -
Kill Job - Terminate the rest of the job and indicate that all new commands are to be ignored until some point defined by the host. This needs to be able to drain all queued buffers, potentially as far back as the host without having the tool do anything unpredictable (there could be multiple megabytes of data backed up on the host side). This is complicated by needing to work for both single endpoint and dual endpoints (separate control and data channels). Some cases:
-
Single USB endpoint - gcode commands and ! and % chars share the same channel. ! and % "jump the queue" once they are received by the board.
-
Dual USB endpoints - one channel is control (! and %), the other is data (gcode). We need to have some way of draining the queued buffers, potentially as far back as the host without having the tool do anything unpredictable. There could be multiple megabytes of data backed up on the host side.
-
For an SD-card data channel, the solution may be as easy as "close the file". In fact, that would be the behavior we should emulate with the dual-usb.
-
Reset System - Do a hard reset if the controller is unresponsive or has entered a SHUTDOWN state.
Additional considerations:
- The % character is commonly used at the beginning and end of a gcode file to delimit the file.
- We don't need any special handling in these cases. M2 and M30 handle the "end-of-job" case, and should be used for that purpose.
- We do NOT plan on supporting running two Gcode files concatenated. Or, at least, we don't plan on adding any special handling for that case.
-
The % character is used by some gcode generators (InkScape, for example) as a start-comment character.
-
Using % as a "buffer flush" doesn't make any sense without a ! "feed hold" proceeding it.
-
% Handling [cases 1 and 2]: Implement the following behaviors If the system is not in a feedhold replace the
%
with a;
in the serial stream. This allows the%
to act as a start-comment character for Gcode comments (supporting the Inkscape comment case). Note that g2 treats;
as a start-comment character even though this is not part of the Gcode specification. -
Control-d [case (3) - Kill Job]: Add a new control character end-of-transmission / control-d / ^d. This will set an ALARM state which stops motion and spindle, clears internal planner queues and rejects all queued and incoming commands until one of the following commands is received. ^d is intercepted by the serial system and is NOT queued, so it is acted on immediately on receipt.
- {clear:n}
- $clear
- M2
- M30
- Control-x [case (4) - Reset System]: Resets the board, exiting a SHUTDOWN state. A shutdown is unrecoverable and requires a reset:
^x
- hardware reset
- power cycle
The current g2 USB serial port implementation relies on the USB hardware's buffers, and only reads data from those buffers as the system can parse them. This doesn't allow for byte-counting flow-control methods. Programs written to use the byte-counting of v8 and that only use a single channel will likely see a "lock up" where the single channel no longer responds to incoming data if only once channel is opened.
In order to solve this, we will add a line-mode (packet-mode) to the USB Serial on g2, allowing the host to send one line at a time and only need to keep track of the number of available lines in the line buffer (no character counting)
the g2 USB serial does not perform immediate-processing of special characters !
, %
, ~
, ^x
, or ^d
. Instead it receives these from the USB sub-system and executes them as part of the normal command dispatch. However, these characters do take priority over a single command, and can "jump the queue", but will not jump the queue over multiple commands that may be backed up in the on-board USB buffers. The line-mode processing should also take care of this issue.
In g2 the queue flush operation (%) ends a feed hold if one is in effect. The !%~
sequence can be shortened to !%
The ~
is wiped from the serial RX buffer and not executed independently.
Getting Started Pages
- Home
- What is g2core?
- Who uses g2core?
- Jerk-Controlled Motion
- Getting Started with g2core
- Connecting to g2core
- Configuring g2core
- Flashing g2core
- Troubleshooting
Reference Pages
- Gcodes
- Mcodes
- Text Mode
- JSON Communications
- GPIO Digital IO
- Alarms & Exceptions
- Power Management
- Coordinate Systems
- Status Reports
- Status Codes
- G2 Communications
- Tool Offsets and Selection
- Probing
- Feedhold, Resume, Job Kill
- Marlin Compatibility
- 9 Axis UVW Operation
- gQuintic Specs
Discussion Topics
- Roadmap
- GPIO for 1.X Releases
- Toolheads
- Raster Streaming Prototol
- g2core REST Interface
- Gcode Parsing
- G2 3DP Dialect
- Consensus Gcode
- Digital DRO
- Overview of Motion Processing
Developer Pages
- Development & Contribution
- Branching and Release - DRAFT
- Getting Started with g2core Development
- Project Structure & Motate
- Compiling G2
- OSX w/Xcode
- OSX/Linux Command Line
- Windows10 w/AtmelStudio7
- Debugging G2 on OSX
- Board and Machine Profiles
- Arduino Due Pinout
- Arduino DUE External Interfaces
- Diagnostics
- Debugging w/Motate Pins
- Development Troubleshooting
- g2core Communications
- Git Procedures
- Windows 10 / VMware 8 Issues
- Dual Endpoint USB Internals
- G2core License
- VSCode Setup
- Compatibility Axioms
- Wiki History