Skip to content

Commit

Permalink
Merge tag 'v1.1f.20170131'
Browse files Browse the repository at this point in the history
  • Loading branch information
tbfleming committed Mar 11, 2017
2 parents ed82dd9 + f51268e commit ee65b9a
Show file tree
Hide file tree
Showing 19 changed files with 320 additions and 104 deletions.
7 changes: 6 additions & 1 deletion doc/csv/build_option_codes_en_US.csv
Original file line number Diff line number Diff line change
Expand Up @@ -8,9 +8,14 @@
"H","Homing single axis commands","Enabled"
"L","Two limit switches on axis","Enabled"
"A","Allow feed rate overrides in probe cycles","Enabled"
"D","Use spindle direction as enable pin","Enabled"
"0","Spindle enable off when speed is zero","Enabled"
"S","Software limit pin debouncing","Enabled"
"R","Parking override control","Enabled"
"*","Restore all EEPROM command","Disabled"
"$","Restore EEPROM `$` settings command","Disabled"
"#","Restore EEPROM parameter data command","Disabled"
"I","Build info write user string command","Disabled"
"E","Force sync upon EEPROM write","Disabled"
"W","Force sync upon work coordinate offset change","Disabled"
"W","Force sync upon work coordinate offset change","Disabled"
"L","Homing initialization auto-lock","Disabled"
83 changes: 83 additions & 0 deletions doc/log/commit_log_v1.1.txt
Original file line number Diff line number Diff line change
@@ -1,3 +1,86 @@
----------------
Date: 2017-01-29
Author: Sonny Jeon
Subject: Tidying up parking override control implementation

[new] Added a default configuration for the parking override control
upon a reset or power-up. By default, parking is enabled, but this may
be disabled via a config.h option.

[fix] Parking override control should be checking if the command word
is passed, rather than the value.


----------------
Date: 2017-01-28
Author: chamnit
Subject: v1.1f. Parking override control. Spindle enable pin option.

[ver] v1.1f update due to tweaks to interface from new parking override
control.

[new] Parking motion override control via new `M56 P0` and `M56 P1`
command, which disables and enables the parking motion, respectively.
Requires ENABLE_PARKING_OVERRIDE_CONTROL and PARKING_ENABLE enabled in
config.h. Primarily for OEMs.

[new] `M56` appears in the $G report when enabled.

[new] Five new build info identification letters. Some were missing and
a couple are new. Updated the CSV and documentation to reflect these
new items.

[new] Spindle enable pin configuration option to alter its behavior
based on how certain lasers work. By default, Grbl treats the enable
pin separately and leaves it on when S is 0. The new option turns the
enable pin on and off with S>0 and S=0. This only is in effect when a
user enables the USE_SPINDLE_DIR_AS_ENABLE_PIN option.

[fix] M4 is now allowed to work when USE_SPINDLE_DIR_AS_ENABLE_PIN is
enabled. Previously this was blocked and was problematic for laser
folks using M4.

[fix] Properly declared system variables as extern. Not sure how that
went unnoticed or why it worked up until now but it has.

[fix] EXTREMELY RARE. When AMASS is intentionally disabled and sent a
motion command that is _one step_ in length, Grbl would not actuate the
step due to numerical round-off. Applied a fix to prevent the round-off
issue.

[fix] Added a compile-time check for AMASS settings to make sure that
the numerical round-off issue doesn’t effect it. This would only happen
if someone set AMASS max levels to zero. It does not effect AMASS with
its current defaults.

[fix] Wrapped the mc_parking_motion() function in an ifdef for porting
purposes.

[fix] Fixed an issue when in inverse time mode and G0’s would require a
F word. This was not correct.

[fix] Added a note in the defaults.h file that MAX_TRAVEL values must
be positive. Some users were setting this negative and it was causing
issues.


----------------
Date: 2017-01-14
Author: Sonny Jeon
Subject: Tool number bug fix. Updated documentation.

- [fix] Tool numbers were not being tracked and reported correctly. Now
shows tool number values in $G when programmed.

- [fix] Added a max tool number value check to the g-code parser.

- [doc] Added a new error code for invalid tool number. Updated CSV and
interface documents.

- [doc] Added a implementation note for buffer state in status reports.
Don’t rely on this data for streaming.


----------------
Date: 2017-01-03
Author: Sonny Jeon
Expand Down
4 changes: 3 additions & 1 deletion doc/markdown/change_summary.md
Original file line number Diff line number Diff line change
Expand Up @@ -109,4 +109,6 @@ On a final note, these interface tweaks came about out of necessity, because mor
- `$J=line` New jogging commands. This command behaves much like a normal G1 command, but there are some key differences. Jog commands don't alter the g-code parser state, meaning a GUI doesn't have to manage it anymore. Jog commands may be queued and cancelled at any time, where they are automatically flushed from the planner buffer without requiring a reset. See the jogging documentation on how they work and how they may be used to implement a low-latency joystick or rotary dial.

- Laser mode `$` setting - When enabled, laser mode will move through consecutive G1, G2, and G3 motion commands that have different spindle speed values without stopping. A spindle speed of zero will disable the laser without stopping as well. However, when spindle states change, like M3 or M5, stops are still enforced.
- NOTE: Parking motions are automatically disabled when laser mode is enabled to prevent burning.
- NOTE: Parking motions are automatically disabled when laser mode is enabled to prevent burning.

- `G56 P1` and `G56 P0` - When enabled in config.h with Grbl's parking motion, these commands enable and disable, respectively, the parking motion. Like all override control commands, these commands are modal and are part of the g-code stream.
5 changes: 4 additions & 1 deletion doc/markdown/commands.md
Original file line number Diff line number Diff line change
Expand Up @@ -64,7 +64,7 @@ This command prints all of the active gcode modes in Grbl's G-code parser. When

These active modes determine how the next G-code block or command will be interpreted by Grbl's G-code parser. For those new to G-code and CNC machining, modes sets the parser into a particular state so you don't have to constantly tell the parser how to parse it. These modes are organized into sets called "modal groups" that cannot be logically active at the same time. For example, the units modal group sets whether your G-code program is interpreted in inches or in millimeters.

A short list of the modal groups, supported by Grbl, is shown below, but more complete and detailed descriptions can be found at LinuxCNC's [website](http://www.linuxcnc.org/docs/2.4/html/gcode_overview.html#sec:Modal-Groups). The G-code commands in **bold** indicate the default modes upon powering-up Grbl or resetting it.
A short list of the modal groups, supported by Grbl, is shown below, but more complete and detailed descriptions can be found at LinuxCNC's [website](http://www.linuxcnc.org/docs/2.4/html/gcode_overview.html#sec:Modal-Groups). The G-code commands in **bold** indicate the default modes upon powering-up Grbl or resetting it. The commands in _italics_ indicate a special Grbl-only command.

| Modal Group Meaning | Member Words |
|:----:|:----:|
Expand All @@ -80,6 +80,9 @@ A short list of the modal groups, supported by Grbl, is shown below, but more co
|Program Mode | **M0**, M1, M2, M30|
|Spindle State |M3, M4, **M5**|
|Coolant State | M7, M8, **M9** |
|Override Control | _M56_ |

Grbl supports a special _M56_ override control command, where this enables and disables Grbl's parking motion when a `P1` or a `P0` is passed with `M56`, respectively. This command is only available when both parking and this particular option is enabled.

In addition to the G-code parser modes, Grbl will report the active `T` tool number, `S` spindle speed, and `F` feed rate, which all default to 0 upon a reset. For those that are curious, these don't quite fit into nice modal groups, but are just as important for determining the parser state.

Expand Down
21 changes: 12 additions & 9 deletions doc/markdown/interface.md
Original file line number Diff line number Diff line change
Expand Up @@ -62,11 +62,9 @@ The real-time control commands, `~` cycle start/resume, `!` feed hold, `^X` sof
One important note are the override command characters. These are defined in the extended-ASCII character space and are generally not type-able on a keyboard. A GUI must be able to send these 8-bit values to support overrides.

#### EEPROM Issues
EEPROM access on the Arduino AVR CPUs turns off all of the interrupts while the CPU reads and writes to EEPROM. This poses a problem for certain features in Grbl, particularly if a user is streaming and running a g-code program, since it can pause the main step generator interrupt from executing on time. Most of the EEPROM access is restricted by Grbl when it's in certain states, but there are some things that developers need to know.
EEPROM access on the Arduino AVR CPUs turns off all of the interrupts while the CPU _writes_ to EEPROM. This poses a problem for certain features in Grbl, particularly if a user is streaming and running a g-code program, since it can pause the main step generator interrupt from executing on time. Most of the EEPROM access is restricted by Grbl when it's in certain states, but there are some things that developers need to know.

* Settings should not be streamed with the character-counting streaming protocols. Only the simple send-response protocol works. This is because during the EEPROM write, the AVR CPU also shuts-down the serial RX interrupt, which means data can get corrupted or lost.

* When changing work coordinates or accessing the `G28`/`G30` predefined positions, Grbl has to fetch them from EEPROM. There is a small chance this access can pause the stepper or serial receive interrupt long enough to cause motion issues, but since it only fetches 12 bytes at a time at 2 cycles per fetch, the chances are very small that this will do anything to how Grbl runs. We just suggest keeping an eye on this and report to us any issues you might think are related to this.
* Settings should not be streamed with the character-counting streaming protocols. Only the simple send-response protocol works. This is because during the EEPROM write, the AVR CPU also shuts-down the serial RX interrupt, which means data can get corrupted or lost. This is safe with the send-response protocol, because it's not sending data after commanding Grbl to save data.

For reference:
* Grbl's EEPROM write commands: `G10 L2`, `G10 L20`, `G28.1`, `G30.1`, `$x=`, `$I=`, `$Nx=`, `$RST=`
Expand Down Expand Up @@ -410,16 +408,16 @@ Feedback messages provide non-critical information on what Grbl is doing, what i
- `[VER:]` and `[OPT:]`: Indicates build info data from a `$I` user query. These build info messages are followed by an `ok` to confirm the `$I` was executed, like so:

```
[VER:v1.1d.20161014:Some string]
[OPT:VL]
[VER:v1.1f.20170131:Some string]
[OPT:VL,16,128]
ok
```
- The first line `[VER:]` contains the build version and date.
- A string may appear after the second `:` colon. It is a stored EEPROM string a user via a `$I=line` command or OEM can place there for personal use or tracking purposes.
- The `[OPT:]` line follows immediately after and contains character codes for compile-time options that were either enabled or disabled. The codes are defined below and a CSV file is also provided for quick parsing. This is generally only used for quickly diagnosing firmware bugs or compatibility issues.
- The `[OPT:]` line follows immediately after and contains character codes for compile-time options that were either enabled or disabled and two values separated by commas, which indicates the total usable planner blocks and serial RX buffer bytes, respectively. The codes are defined below and a CSV file is also provided for quick parsing. This is generally only used for quickly diagnosing firmware bugs or compatibility issues.

| `OPT` Code | Setting Description, Units |
| `OPT` Code | Setting Description, Units |
|:-------------:|----|
| **`V`** | Variable spindle enabled |
| **`N`** | Line numbers enabled |
Expand All @@ -429,14 +427,19 @@ Feedback messages provide non-critical information on what Grbl is doing, what i
| **`Z`** | Homing force origin enabled |
| **`H`** | Homing single axis enabled |
| **`L`** | Two limit switches on axis enabled |
| **`D`** | Spindle direction pin used as enable pin |
| **`0`** | Spindle enable off when speed is zero enabled |
| **`S`** | Software limit pin debouncing enabled |
| **`R`** | Parking override control enabled |
| **`A`** | Allow feed rate overrides in probe cycles |
| **`*`** | Restore all EEPROM disabled |
| **`$`** | Restore EEPROM `$` settings disabled |
| **`#`** | Restore EEPROM parameter data disabled |
| **`I`** | Build info write user string disabled |
| **`E`** | Force sync upon EEPROM write disabled |
| **`W`** | Force sync upon work coordinate offset change disabled |

| **`L`** | Homing initialization auto-lock disabled |

- `[echo:]` : Indicates an automated line echo from a command just prior to being parsed and executed. May be enabled only by a config.h option. Often used for debugging communication issues. A typical line echo message is shown below. A separate `ok` will eventually appear to confirm the line has been parsed and executed, but may not be immediate as with any line command containing motions.
```
[echo:G1X0.540Y10.4F100]
Expand Down
14 changes: 7 additions & 7 deletions doc/markdown/laser_mode.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@

----

Outlined in this document is how Grbl alters its running conditions for the new laser mode to provide both improved performance and enforcing some basic user safety precautions.
Outlined in this document is how Grbl alters its running conditions for the new laser mode to provide both improved performance and attempting to enforce some basic user safety precautions.

## Laser Mode Overview

Expand All @@ -29,16 +29,16 @@ The laser is enabled with the `M3` spindle CW and `M4` spindle CCW commands. The

- **`M3` Constant Laser Power Mode:**

- Constant laser power mode simply keeps the laser power as programmed, regardless if the machine is moving, accelerating, or stopped. This provides better control of the laser state. With a good g-code program, this can lead to more consistent cuts in more difficult materials.
- Constant laser power mode simply keeps the laser power as programmed, regardless if the machine is moving, accelerating, or stopped. This provides better control of the laser state. With a good G-code program, this can lead to more consistent cuts in more difficult materials.

- For a clean cut and prevent scorching with `M3` constant power mode, it's a good idea to add lead-in and lead-out motions around the line you want to cut to give some space for the machine to accelerate and decelerate.

- NOTE: `M3` can be used to keep the laser on for focusing.

- **`M4` Dynamic Laser Power Mode:**
- Dynamic laser power mode will automatically adjust laser power based on the current speed relative to the programmed rate. It'll essentially ensures the amount of laser energy along a cut is consistent even though the machine may be stopped or actively accelerating. This is very useful for clean, precise engraving and cutting on simple materials across a large range of g-code generation methods by CAM programs. It will generally run faster and may be all you need to use.
- Dynamic laser power mode will automatically adjust laser power based on the current speed relative to the programmed rate. It essentially ensures the amount of laser energy along a cut is consistent even though the machine may be stopped or actively accelerating. This is very useful for clean, precise engraving and cutting on simple materials across a large range of G-code generation methods by CAM programs. It will generally run faster and may be all you need to use.

- Grbl calculates laser power based on the assumption that laser power is linear with speed and the material. Often, this is not the case. Lasers can cut differently at varying power levels and some materials may not cut well at a particular speed and/power. In short, this means that dynamic power mode may not work for all situations. Always do a test piece prior to using this with a new material or machine.
- Grbl calculates laser power based on the assumption that laser power is linear with speed and the material. Often, this is not the case. Lasers can cut differently at varying power levels and some materials may not cut well at a particular speed and/power. In short, this means that dynamic power mode may not work for all situations. Always do a test piece prior to using this with a new material or machine.

- When not in motion, `M4` dynamic mode turns off the laser. It only turns on when the machine moves. This generally makes the laser safer to operate, because, unlike `M3`, it will never burn a hole through your table, if you stop and forget to turn `M3` off in time.

Expand Down Expand Up @@ -70,20 +70,20 @@ Describe below are the operational changes to Grbl when laser mode is enabled. P
- To have the laser powered during a jog motion, first enable a valid motion mode and spindle state. The following jog motions will inherit and maintain the previous laser state. Please use with caution though. This ability is primarily to allow turning on the laser on a _very low_ power to use the laser dot to jog and visibly locate the start position of a job.


- A `S0` spindle speed of zero will turn off the laser. When programmed with a valid laser motion, Grbl will disable the laser instantaneously without stopping for the duration of that motion and future motions until set greater than zero..
- An `S0` spindle speed of zero will turn off the laser. When programmed with a valid laser motion, Grbl will disable the laser instantaneously without stopping for the duration of that motion and future motions until set greater than zero..

- `M3` constant laser mode, this is a great way to turn off the laser power while continuously moving between a `G1` laser motion and a `G0` rapid motion without having to stop. Program a short `G1 S0` motion right before the `G0` motion and a `G1 Sxxx` motion is commanded right after to go back to cutting.


-----
###CAM Developer Implementation Notes

TODO: Add some suggestions on how to write laser g-code for Grbl.
TODO: Add some suggestions on how to write laser G-code for Grbl.

- When using `M3` constant laser power mode, try to avoid force-sync conditions during a job whenever possible. Basically every spindle speed change must be accompanied by a valid motion. Any motion is fine, since Grbl will automatically enable and disable the laser based on the modal state. Avoid a `G0` and `G1` command with no axis words in this mode and in the middle of a job.

- Ensure smooth motions throughout by turning the laser on and off without an `M3 M4 M5` spindle state command. There are two ways to do this:

- _Program a zero spindle speed `S0`_: `S0` is valid g-code and turns off the spindle/laser without changing the spindle state. In laser mode, Grbl will smoothly move through consecutive motions and turn off the spindle. Conversely, you can turn on the laser with a spindle speed `S` greater than zero. Remember that `M3` constant power mode requires any spindle speed `S` change to be programmed with a motion to allow continuous motion, while `M4` dynamic power mode does not.
- _Program a zero spindle speed `S0`_: `S0` is valid G-code and turns off the spindle/laser without changing the spindle state. In laser mode, Grbl will smoothly move through consecutive motions and turn off the spindle. Conversely, you can turn on the laser with a spindle speed `S` greater than zero. Remember that `M3` constant power mode requires any spindle speed `S` change to be programmed with a motion to allow continuous motion, while `M4` dynamic power mode does not.

- _Program an unpowered motion between powered motions_: If you are traversing between parts of a raster job that don't need to have the laser powered, program a `G0` rapid between them. `G0` enforces the laser to be disabled automatically. The last spindle speed programmed doesn't change, so if a valid powered motion, like a `G1` is executed after, it'll immediately re-power the laser with the last programmed spindle speed when executing that motion.
Loading

0 comments on commit ee65b9a

Please sign in to comment.