New jog cancel real-time command. Parser typo fix from last push.

- Added a new jog cancel real-time command. Rather than depending on a
feed hold to cancel a jogging motion, this realtime command can be used
instead. The main advantage is if a feed hold is used, you can
accidentally hold the machine right when Grbl returns to IDLE after
completing a jog. And the GUI doesn’t have to worry about tracking this
either.

- Fixed a typo in the g-code parser edits from the last push. Was
causing the G10 set coordinate system command to not work correctly.

- Updated the documentation with the jog cancel command.
This commit is contained in:
Sonny Jeon
2016-09-28 21:17:02 -06:00
parent bf5fc48074
commit e2e2bb5242
10 changed files with 116 additions and 62 deletions

View File

@ -1,3 +1,18 @@
----------------
Date: 2016-09-27
Author: Sonny Jeon
Subject: Refactored g-code parser. Saved 60bytes flash and some ram. Edited Readme.
- Freed up another 60 bytes of flash and 12-24 bytes of stack RAM by
using the pre-allocated IJK arc offset vector that is guaranteed to be
not in use. Only G10 and G28/30 require fetching from EEPROM and
retaining extra data. Both commands use axis words, which rules out
G2/3 arcs using IJK offsets existing in same block. Not ideal, but
every byte helps.
- Edited README.
----------------
Date: 2016-09-27
Author: Sonny Jeon

View File

@ -31,7 +31,7 @@ The main differences are:
- During a jog, Grbl will report a 'Jog' state while executing the jog.
- A jog command will only be accepted when Grbl is in either the 'Idle' or 'Jog' states.
- Jogging motions may not be mixed with g-code commands while executing, which will return a lockout error, if attempted.
- All jogging motion(s) may be cancelled at anytime with a simple feed hold command. Grbl will automatically flush Grbl's internal buffers of any queued jogging motions and return to the 'Idle' state. No soft-reset required.
- All jogging motion(s) may be cancelled at anytime with a simple jog cancel realtime command or a feed hold or safety door event. Grbl will automatically flush Grbl's internal buffers of any queued jogging motions and return to the 'Idle' state. No soft-reset required.
- If soft-limits are enabled, jog commands that exceed the machine travel simply does not execute the command and return an error, rather than throwing an alarm in normal operation.
- IMPORTANT: Jogging does not alter the g-code parser state. Hence, no g-code modes need to be explicitly managed, unlike previous ways of implementing jogs with commands like 'G91G1X1F100'. Since G91, G1, and F feed rates are modal and if they are not changed back prior to resuming/starting a job, a job may not run how its was intended and result in a crash.
@ -48,14 +48,14 @@ With a combination of the new jog cancel and moving in `G91` incremental mode, t
- Send Grbl a very short `G91` incremental distance jog command with a feed rate based on the joystick throw.
- Wait for an 'ok' acknowledgement before restarting the loop.
- Continually read the joystick input and send Grbl short jog motions to keep Grbl's planner buffer full.
- If the joystick is returned to its neutral position, stop the jog loop and simply send Grbl a jog cancel (or feed hold) real-time command. This will stop motion immediately somewhere along the programmed jog path with virtually zero-latency and automatically flush Grbl's planner queue.
- If the joystick is returned to its neutral position, stop the jog loop and simply send Grbl a jog cancel real-time command. This will stop motion immediately somewhere along the programmed jog path with virtually zero-latency and automatically flush Grbl's planner queue. It's not advised to use a feed hold to cancel a jog, as it can lead to inadvertently suspending Grbl if its sent after returning to the IDLE state.
The overall idea is to minimize the total distance in the planner queue to provide a low-latency feel to joystick control. The main trick is ensuring there is just enough distance in the planner queue, such that the programmed feed rate is always met. How to compute this will be explain later. In practice, most machines will have a 0.5-1.0 second latency. When combined with the immediate jog cancel command, joystick interaction can be quite enjoyable and satisfying.
However, please note, if a machine has a low acceleration and is being asked to move at a high programmed feed rate, joystick latency can get up to a handful of seconds. It may sound bad, but this is how long it'll take for a low acceleration machine, traveling at a high feed rate, to slow down to a stop. The argument can be made for a low acceleration machine that you really shouldn't be jogging at a high feed rate. It is difficult for a user to gauge where the machine will come to a stop. You risk overshooting your target destination, which can result in an expensive or dangerous crash.
One of the advantages of this approach is that a GUI can deterministically track where Grbl will go by the jog commands it has already sent to Grbl. As long as a feed hold doesn't cancel the jog state, every jog command is guaranteed to execute. In the event a feed hold is sent, the GUI would just need to refresh their internal position from a status report after Grbl has cleared planner buffer and returned to the IDLE state from the JOG state. This stopped position will always be somewhere along the programmed jog path. If desired, jogging can then be quickly and easily restarted with a new tracked path.
One of the advantages of this approach is that a GUI can deterministically track where Grbl will go by the jog commands it has already sent to Grbl. As long as a jog isn't cancelled, every jog command is guaranteed to execute. In the event a jog cancel is invoked, the GUI would just need to refresh their internal position from a status report after Grbl has cleared planner buffer and returned to the IDLE (or DOOR, if ajar) state from the JOG state. This stopped position will always be somewhere along the programmed jog path. If desired, jogging can then be quickly and easily restarted with a new tracked path.
In combination with `G53` move in machine coordinates, a GUI can restrict jogging from moving into "keep-out" zones inside the machine space. This can be very useful for avoiding crashing into delicate probing hardware, workholding mechanisms, or other fixed features inside machine space that you want to avoid.

View File

@ -50,6 +50,7 @@ The normal ASCII realtime command characters used in Grbl v0.9 have been retaine
- Places Grbl into a suspend or HOLD state. If in motion, the machine will decelerate to a stop and then be suspended.
- Command executes when Grbl is in an IDLE, RUN, or JOG state. It is otherwise ignored.
- If jogging, a feed hold will cancel the jog motion and flush all remaining jog motions in the planner buffer. The state will return from JOG to IDLE or DOOR, if was detected as ajar during the active hold.
- By machine control definition, a feed hold does not disable the spindle or coolant. Only motion.
- An input pin is available to connect a button or switch.
@ -66,10 +67,18 @@ Grbl v1.1 installed more than a dozen new realtime commands to control feed, rap
- If already in a suspend state or HOLD, the DOOR state supersedes it.
- If the parking compile-time option is enabled, Grbl will park the spindle to a specified location.
- Command executes when Grbl is in an IDLE, HOLD, RUN, HOMING, or JOG state. It is otherwise ignored.
- If jogging, a safety door will cancel the jog and all queued motions in the planner buffer. When the safety door is closed and resumed, Grbl will return to an IDLE state.
- An input pin is available to connect a button or switch, if enabled with a compile-time option.
- Some builds of Grbl v0.9 used the `@` character for this command, but it was undocumented. Moved to extended-ASCII to prevent accidental commanding.
- `0x85` : Jog Cancel
- Immediately cancels the current jog state by a feed hold and automatically flushing any remaining jog commands in the buffer.
- Command is ignored, if not in a JOG state or if jog cancel is already invoked and in-process.
- Grbl will return to the IDLE state or the DOOR state, if the safety door was detected as ajar during the cancel.
- Feed Overrides
- Immediately alters the feed override value. An active feed motion is altered within tens of milliseconds.
@ -114,7 +123,7 @@ Grbl v1.1 installed more than a dozen new realtime commands to control feed, rap
- `0x9E` : Toggle Spindle Stop
- Toggles spindle enable or disable state immediately, but only while in the HOLD.
- Toggles spindle enable or disable state immediately, but only while in the HOLD state.
- The command is otherwise ignored, especially while in motion. This prevents accidental disabling during a job that can either destroy the part/machine or personal injury. Industrial machines handle the spindle stop override similarly.
- When motion restarts via cycle start, the last spindle state will be restored and wait 4.0 seconds (configurable) before resuming the tool path. This ensures the user doesn't forget to turn it back on.
- While disabled, spindle speed override values may still be altered and will be in effect once the spindle is re-enabled.