Added settings documentation. Very minor bug fix to step direction handling.
- Added v1.1 settings documentation to the markdown folder. - Fixed a very minor bug in the step direction handling upon wakeup. The direction mask would temporarily go back to default mask for about a millisecond when moving in the same non-default direction. It did not effect Grbl behavior before, but fixed for consistency.
This commit is contained in:
parent
6ab3cfbe7d
commit
a0e96eb11a
@ -1,3 +1,15 @@
|
||||
----------------
|
||||
Date: 2016-10-12
|
||||
Author: Sonny Jeon
|
||||
Subject: Spindle speed bug fix.
|
||||
|
||||
- Spindle speed updating wasn’t working in the g-code parser due to
|
||||
some borked up logic on my part. Fixed it and should be operating as
|
||||
intended for both normal and laser spindle modes.
|
||||
|
||||
- Elaborated a little more on the new sleep mode in the documentation.
|
||||
|
||||
|
||||
----------------
|
||||
Date: 2016-10-11
|
||||
Author: Sonny Jeon
|
||||
|
@ -1,6 +1,6 @@
|
||||
## Grbl v1.1 Realtime commands
|
||||
|
||||
Realtime commands are single control characters that may be sent to Grbl to command and perform an action in real-time, regardless of what Grbl is doing at the time. These commands include a reset, feed hold, resume, status report query, and overrides (in v1.1).
|
||||
Realtime commands are single control characters that may be sent to Grbl to command and perform an action in real-time. This means that they can be sent at anytime, anywhere, and Grbl will immediately respond, regardless of what it is doing at the time. These commands include a reset, feed hold, resume, status report query, and overrides (in v1.1).
|
||||
|
||||
A realtime command:
|
||||
|
||||
@ -8,10 +8,12 @@ A realtime command:
|
||||
|
||||
- Is a single character that may be sent to Grbl at any time.
|
||||
|
||||
- Does not require a line feed or carraige return after them.
|
||||
- Does not require a line feed or carriage return after them.
|
||||
|
||||
- Is not considered a part of the streaming protocol.
|
||||
|
||||
- Are intercepted when they are received and never placed in a buffer to be parsed by Grbl.
|
||||
|
||||
- Will ignore multiple commands until it has executed the first received command.
|
||||
|
||||
- May be tied to an input pin and may be operated with a button or switch.
|
||||
@ -21,11 +23,11 @@ A realtime command:
|
||||
- Descriptions explain how they work and what to expect.
|
||||
|
||||
#### ASCII Realtime Command Descriptions
|
||||
The normal ASCII realtime command characters used in Grbl v0.9 have been retained in Grbl v1.1 and are described below for completeness.
|
||||
Four realtime commands are type-able by users on a keyboard and shown in the `$` Grbl help message. These realtime command characters control some of Grbl's basic functions.
|
||||
|
||||
- `0x18` (ctrl-x) : Soft-Reset
|
||||
|
||||
- Immediately halts and resets Grbl.
|
||||
- Immediately halts and safely resets Grbl without a power-cycle.
|
||||
- Accepts and executes this command at any time.
|
||||
- If reset while in motion, Grbl will throw an alarm to indicate position may be lost from the motion halt.
|
||||
- If reset while in not motion, position is retained and re-homing is not required.
|
||||
@ -57,7 +59,7 @@ The normal ASCII realtime command characters used in Grbl v0.9 have been retaine
|
||||
|
||||
#### Extended-ASCII Realtime Command Descriptions
|
||||
|
||||
Grbl v1.1 installed more than a dozen new realtime commands to control feed, rapid, and spindle overrides. To help prevent users from inadvertently altering overrides with a keystroke and allow for more commands later on, all of the new control characters have been moved to the extended ASCII character set. These are not readily type-able on a keyboard, but, depending on the OS, they may be entered using specific keystroke and code. GUI developers will need to be able to send extended ASCII characters, values `128 (0x80)` to `255 (0xFF)`, to Grbl to take advantage of these new features.
|
||||
Grbl v1.1 installed more than a dozen new realtime commands to control feed, rapid, and spindle overrides. To help prevent users from inadvertently altering overrides with a keystroke and allow for more commands later on, all of the new control characters have been moved to the extended ASCII character set. These are not easily type-able on a keyboard, but, depending on the OS, they may be entered using specific keystroke and code. GUI developers will need to be able to send extended ASCII characters, values `128 (0x80)` to `255 (0xFF)`, to Grbl to take advantage of these new features.
|
||||
|
||||
- `0x84` : Safety Door
|
||||
|
||||
@ -124,10 +126,10 @@ 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 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.
|
||||
- The command is otherwise ignored, especially while in motion. This prevents accidental disabling during a job that can either destroy the part/machine or cause 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.
|
||||
- If a safety door is opened, the DOOR state will supercede the spindle stop override, where it will manage the spindle re-energizing itself upon closing the door and resuming. The prior spindle stop override state is cleared and reset.
|
||||
- If a safety door is opened, the DOOR state will supersede the spindle stop override, where it will manage the spindle re-energizing itself upon closing the door and resuming. The prior spindle stop override state is cleared and reset.
|
||||
|
||||
|
||||
- `0xA0` : Toggle Flood Coolant
|
||||
|
@ -15,26 +15,17 @@ Set the baud rate to **115200** as 8-N-1 (8-bits, no parity, and 1-stop bit.)
|
||||
|
||||
Once connected
|
||||
you should get the Grbl-prompt, which looks like this:
|
||||
|
||||
```
|
||||
Grbl 0.9i ['$' for help]
|
||||
Grbl 1.1c ['$' for help]
|
||||
```
|
||||
|
||||
Type $ and press enter to have Grbl print a help message. You should not see any local echo of the $ and enter. Grbl should respond with:
|
||||
|
||||
```
|
||||
$$ (view Grbl settings)
|
||||
$# (view # parameters)
|
||||
$G (view parser state)
|
||||
$I (view build info)
|
||||
$N (view startup blocks)
|
||||
$x=value (save Grbl setting)
|
||||
$Nx=line (save startup block)
|
||||
$C (check gcode mode)
|
||||
$X (kill alarm lock)
|
||||
$H (run homing cycle)
|
||||
~ (cycle start)
|
||||
! (feed hold)
|
||||
? (current status)
|
||||
ctrl-x (reset Grbl)
|
||||
[HLP:$$ $# $G $I $N $x=val $Nx=line $J=line $SLP $C $X $H ~ ! ? ctrl-x]
|
||||
```
|
||||
|
||||
The ‘$’-commands are Grbl system commands used to tweak the settings, view or change Grbl's states and running modes, and start a homing cycle. The last four **non**-'$' commands are realtime control commands that can be sent at anytime, no matter what Grbl is doing. These either immediately change Grbl's running behavior or immediately print a report of the important realtime data like current position (aka DRO).
|
||||
|
||||
***
|
||||
@ -44,38 +35,43 @@ The ‘$’-commands are Grbl system commands used to tweak the settings, view o
|
||||
#### $$ - View Grbl settings
|
||||
To view the settings, type `$$` and press enter after connecting to Grbl. Grbl should respond with a list of the current system settings, as shown in the example below. All of these settings are persistent and kept in EEPROM, so if you power down, these will be loaded back up the next time you power up your Arduino.
|
||||
|
||||
The `x` of `$x=val` indicates a particular setting, while `val` is the setting value. In prior versions of Grbl, each setting had a description next to it in `()` parentheses, but Grbl v1.1+ no longer includes them unfortunately. This was done to free up precious flash memory to add the new features available in v1.1. However, most good GUIs will help out by attaching descriptions for you, so you know what you are looking at.
|
||||
|
||||
```
|
||||
$0=10 (step pulse, usec)
|
||||
$1=25 (step idle delay, msec)
|
||||
$2=0 (step port invert mask:00000000)
|
||||
$3=6 (dir port invert mask:00000110)
|
||||
$4=0 (step enable invert, bool)
|
||||
$5=0 (limit pins invert, bool)
|
||||
$6=0 (probe pin invert, bool)
|
||||
$10=3 (status report mask:00000011)
|
||||
$11=0.020 (junction deviation, mm)
|
||||
$12=0.002 (arc tolerance, mm)
|
||||
$13=0 (report inches, bool)
|
||||
$20=0 (soft limits, bool)
|
||||
$21=0 (hard limits, bool)
|
||||
$22=0 (homing cycle, bool)
|
||||
$23=1 (homing dir invert mask:00000001)
|
||||
$24=50.000 (homing feed, mm/min)
|
||||
$25=635.000 (homing seek, mm/min)
|
||||
$26=250 (homing debounce, msec)
|
||||
$27=1.000 (homing pull-off, mm)
|
||||
$100=314.961 (x, step/mm)
|
||||
$101=314.961 (y, step/mm)
|
||||
$102=314.961 (z, step/mm)
|
||||
$110=635.000 (x max rate, mm/min)
|
||||
$111=635.000 (y max rate, mm/min)
|
||||
$112=635.000 (z max rate, mm/min)
|
||||
$120=50.000 (x accel, mm/sec^2)
|
||||
$121=50.000 (y accel, mm/sec^2)
|
||||
$122=50.000 (z accel, mm/sec^2)
|
||||
$130=225.000 (x max travel, mm)
|
||||
$131=125.000 (y max travel, mm)
|
||||
$132=170.000 (z max travel, mm)
|
||||
$0=10
|
||||
$1=25
|
||||
$2=0
|
||||
$3=0
|
||||
$4=0
|
||||
$5=0
|
||||
$6=0
|
||||
$10=1
|
||||
$11=0.010
|
||||
$12=0.002
|
||||
$13=0
|
||||
$20=0
|
||||
$21=0
|
||||
$22=1
|
||||
$23=0
|
||||
$24=25.000
|
||||
$25=500.000
|
||||
$26=250
|
||||
$27=1.000
|
||||
$30=1000.
|
||||
$31=0.
|
||||
$32=0
|
||||
$100=250.000
|
||||
$101=250.000
|
||||
$102=250.000
|
||||
$110=500.000
|
||||
$111=500.000
|
||||
$112=500.000
|
||||
$120=10.000
|
||||
$121=10.000
|
||||
$122=10.000
|
||||
$130=200.000
|
||||
$131=200.000
|
||||
$132=200.000
|
||||
```
|
||||
|
||||
#### $x=val - Save Grbl setting
|
||||
@ -93,19 +89,19 @@ If everything went well, Grbl will respond with an 'ok' and this setting is stor
|
||||
|
||||
## Grbl's `$x=val` settings and what they mean
|
||||
|
||||
**NOTE: Settings numbering has changed since v0.8c for future-proofing purposes.**
|
||||
**NOTE: From Grbl v0.9 to Grbl v1.1, only `$10` status reports changed and new `$30`/ `$31` spindle rpm max/min and `$32` laser mode settings were added. Everything else is the same.**
|
||||
|
||||
#### $0 – Step pulse, microseconds
|
||||
|
||||
Stepper drivers are rated for a certain minimum step pulse length. Check the data sheet or just try some numbers. You want the shortest pulses the stepper drivers can reliably recognize. If the pulses are too long, you might run into trouble when running the system at very high feed and pulse rates, because the step pulses can begin to overlap each other. We recommend something around 10 microseconds, which is the default value.
|
||||
|
||||
#### $1 - Step idle delay, msec
|
||||
#### $1 - Step idle delay, milliseconds
|
||||
|
||||
Every time your steppers complete a motion and come to a stop, Grbl will delay disabling the steppers by this value. **OR**, you can always keep your axes enabled (powered so as to hold position) by setting this value to the maximum 255 milliseconds. Again, just to repeat, you can keep all axes always enabled by setting `$1=255`.
|
||||
|
||||
The stepper idle lock time is the time length Grbl will keep the steppers locked before disabling. Depending on the system, you can set this to zero and disable it. On others, you may need 25-50 milliseconds to make sure your axes come to a complete stop before disabling. This is to help account for machine motors that do not like to be left on for long periods of time without doing something. Also, keep in mind that some stepper drivers don't remember which micro step they stopped on, so when you re-enable, you may witness some 'lost' steps due to this. In this case, just keep your steppers enabled via `$1=255`.
|
||||
|
||||
#### $2 – Step port invert mask:binary
|
||||
#### $2 – Step port invert, mask
|
||||
|
||||
This setting inverts the step pulse signal. By default, a step signal starts at normal-low and goes high upon a step pulse event. After a step pulse time set by `$0`, the pin resets to low, until the next step pulse event. When inverted, the step pulse behavior switches from normal-high, to low during the pulse, and back to high. Most users will not need to use this setting, but this can be useful for certain CNC-stepper drivers that have peculiar requirements. For example, an artificial delay between the direction pin and step pulse can be created by inverting the step pin.
|
||||
|
||||
@ -122,44 +118,46 @@ This invert mask setting is a value which stores the axes to invert as bit flags
|
||||
| 6 | 00000110 |N | Y | Y |
|
||||
| 7 | 00000111 |Y | Y | Y |
|
||||
|
||||
#### $3 – Direction port invert mask:binary
|
||||
#### $3 – Direction port invert, mask
|
||||
|
||||
This setting inverts the direction signal for each axis. By default, Grbl assumes that the axes move in a positive direction when the direction pin signal is low, and a negative direction when the pin is high. Often, axes don't move this way with some machines. This setting will invert the direction pin signal for those axes that move the opposite way.
|
||||
|
||||
This invert mask setting works exactly like the step port invert mask and stores which axes to invert as bit flags. To configure this setting, you simply need to send the value for the axes you want to invert. Use the table above. For example, if want to invert the Y axis direction only, you'd send `$3=2` to Grbl and the setting should now read `$3=2 (dir port invert mask:00000010)`
|
||||
|
||||
#### $4 - Step enable invert, bool
|
||||
#### $4 - Step enable invert, boolean
|
||||
|
||||
By default, the stepper enable pin is high to disable and low to enable. If your setup needs the opposite, just invert the stepper enable pin by typing `$4=1`. Disable with `$4=0`. (May need a power cycle to load the change.)
|
||||
|
||||
#### $5 - Limit pins invert, bool
|
||||
#### $5 - Limit pins invert, boolean
|
||||
|
||||
By default, the limit pins are held normally-high with the Arduino's internal pull-up resistor. When a limit pin is low, Grbl interprets this as triggered. For the opposite behavior, just invert the limit pins by typing `$5=1`. Disable with `$5=0`. You may need a power cycle to load the change.
|
||||
|
||||
NOTE: If you invert your limit pins, you will need an external pull-down resistor wired in to all of the limit pins to prevent overloading the pins with current and frying them.
|
||||
|
||||
#### $6 - Probe pin invert, bool
|
||||
#### $6 - Probe pin invert, boolean
|
||||
|
||||
By default, the probe pin is held normally-high with the Arduino's internal pull-up resistor. When the probe pin is low, Grbl interprets this as triggered. For the opposite behavior, just invert the probe pin by typing `$6=1`. Disable with `$6=0`. You may need a power cycle to load the change.
|
||||
|
||||
NOTE: If you invert your probe pin, you will need an external pull-down resistor wired in to the probe pin to prevent overloading it with current and frying it.
|
||||
|
||||
|
||||
#### $10 - Status report mask:binary
|
||||
#### $10 - Status report, mask
|
||||
|
||||
This setting determines what Grbl real-time data it reports back to the user when a '?' status report is sent. By default, Grbl will send back its running state (can't be turned off), machine position, and work position (machine position with coordinate offsets and other offsets applied). Three additional reporting features are available that are useful for interfaces or users setting up their machines, which include the serial RX buffer, planner block buffer usage, and limit pin states (as high or low, shown in the order ZYX).
|
||||
This setting determines what Grbl real-time data it reports back to the user when a '?' status report is sent. This data includes current run state, real-time position, real-time feed rate, pin states, current override values, buffer states, and the g-code line number currently executing (if enabled through compile-time options).
|
||||
|
||||
To set them, use the table below to determine what data you'd like Grbl to send back. Select the report types you'd like to see in the status reports and add their values together. This is the value you use to send to Grbl. For example, if you need machine and work positions, add the values 1 and 2 and send Grbl `$10=3` to set it. Or, if you need machine position only and limit pin state, add the values 1 and 16 and send Grbl `$10=17`.
|
||||
By default, the new report implementation in Grbl v1.1+ will include just about everything in the standard status report. A lot of the data is hidden and will appear only if it changes. This increases efficiency dramatically over of the old report style and allows you to get faster updates and still get more data about your machine. The interface documentation outlines how it works and most of it applies only to GUI developers or the curious.
|
||||
|
||||
In general, keep this real-time status data to a minimum, since it takes resources to print and send this data back at a high rate. For example, limit pins reporting is generally only needed when users are setting up their machine. Afterwards, it's recommended to disable it, as it isn't very useful once you've got everything figured out.
|
||||
To keep things simple and consistent, Grbl v1.1 has only two reporting options. These are primarily here just for users and developers to help set things up.
|
||||
|
||||
| Report Type | Value |
|
||||
|:-------------:|:----:|
|
||||
| Machine Position | 1 |
|
||||
| Work Position | 2 |
|
||||
| Planner Buffer | 4 |
|
||||
| RX Buffer | 8 |
|
||||
| Limit Pins | 16 |
|
||||
- Position type may be specified to show either machine position (`MPos:`) or work position (`WPos:`), but no longer both at the same time. Enabling work position is useful in certain scenarios when Grbl is being directly interacted with through a serial terminal, but _machine position reporting should be used by default._
|
||||
- Usage data of Grbl's planner and serial RX buffers may be enabled. This shows the number of blocks or bytes available in the respective buffers. This is generally used to helps determine how Grbl is performing when testing out a streaming interface. _This should be disabled by default._
|
||||
|
||||
Use the table below enables and disable reporting options. Simply add the values listed of what you'd like to enable, then save it by sending Grbl your setting value. For example, the default report with machine position and no buffer data reports setting is `$10=1`. If work position and buffer data are desired, the setting will be `$10=2`.
|
||||
|
||||
| Report Type | Value | Description |
|
||||
|:-------------:|:----:|:----:|
|
||||
| Position Type | 1 | Enabled `MPos:`. Disabled `WPos:`. |
|
||||
| Buffer Data | 2 | Enabled `Buf:` field appears with planner and serial RX available buffer.
|
||||
|
||||
#### $11 - Junction deviation, mm
|
||||
|
||||
@ -173,17 +171,17 @@ Grbl renders G2/G3 circles, arcs, and helices by subdividing them into teeny tin
|
||||
|
||||
For the curious, arc tolerance is defined as the maximum perpendicular distance from a line segment with its end points lying on the arc, aka a chord. With some basic geometry, we solve for the length of the line segments to trace the arc that satisfies this setting. Modeling arcs in this way is great, because the arc line segments automatically adjust and scale with length to ensure optimum arc tracing performance, while never losing accuracy.
|
||||
|
||||
#### $13 - Report inches, bool
|
||||
#### $13 - Report inches, boolean
|
||||
|
||||
Grbl has a real-time positioning reporting feature to provide a user feedback on where the machine is exactly at that time, as well as, parameters for coordinate offsets and probing. By default, it is set to report in mm, but by sending a `$13=1` command, you send this boolean flag to true and these reporting features will now report in inches. `$13=0` to set back to mm.
|
||||
|
||||
#### $20 - Soft limits, bool
|
||||
#### $20 - Soft limits, boolean
|
||||
|
||||
Soft limits is a safety feature to help prevent your machine from traveling too far and beyond the limits of travel, crashing or breaking something expensive. It works by knowing the maximum travel limits for each axis and where Grbl is in machine coordinates. Whenever a new G-code motion is sent to Grbl, it checks whether or not you accidentally have exceeded your machine space. If you do, Grbl will issue an immediate feed hold wherever it is, shutdown the spindle and coolant, and then set the system alarm indicating the problem. Machine position will be retained afterwards, since it's not due to an immediate forced stop like hard limits.
|
||||
|
||||
NOTE: Soft limits requires homing to be enabled and accurate axis maximum travel settings, because Grbl needs to know where it is. `$20=1` to enable, and `$20=0` to disable.
|
||||
|
||||
#### $21 - Hard limits, bool
|
||||
#### $21 - Hard limits, boolean
|
||||
|
||||
Hard limit work basically the same as soft limits, but use physical switches instead. Basically you wire up some switches (mechanical, magnetic, or optical) near the end of travel of each axes, or where ever you feel that there might be trouble if your program moves too far to where it shouldn't. When the switch triggers, it will immediately halt all motion, shutdown the coolant and spindle (if connected), and go into alarm mode, which forces you to check your machine and reset everything.
|
||||
|
||||
@ -191,7 +189,7 @@ To use hard limits with Grbl, the limit pins are held high with an internal pull
|
||||
|
||||
Keep in mind, that a hard limit event is considered to be critical event, where steppers immediately stop and will have likely have lost steps. Grbl doesn't have any feedback on position, so it can't guarantee it has any idea where it is. So, if a hard limit is triggered, Grbl will go into an infinite loop ALARM mode, giving you a chance to check your machine and forcing you to reset Grbl. Remember it's a purely a safety feature.
|
||||
|
||||
#### $22 - Homing cycle, bool
|
||||
#### $22 - Homing cycle, boolean
|
||||
|
||||
Ahh, homing. For those just initiated into CNC, the homing cycle is used to accurately and precisely locate a known and consistent position on a machine every time you start up your Grbl between sessions. In other words, you know exactly where you are at any given time, every time. Say you start machining something or are about to start the next step in a job and the power goes out, you re-start Grbl and Grbl has no idea where it is. You're left with the task of figuring out where you are. If you have homing, you always have the machine zero reference point to locate from, so all you have to do is run the homing cycle and resume where you left off.
|
||||
|
||||
@ -204,7 +202,7 @@ Also, one more thing to note, when homing is enabled. Grbl will lock out all G-c
|
||||
NOTE: Check out config.h for more homing options for advanced users. You can disable the homing lockout at startup, configure which axes move first during a homing cycle and in what order, and more.
|
||||
|
||||
|
||||
#### $23 - Homing dir invert mask, int:binary
|
||||
#### $23 - Homing dir invert, mask
|
||||
|
||||
By default, Grbl assumes your homing limit switches are in the positive direction, first moving the z-axis positive, then the x-y axes positive before trying to precisely locate machine zero by going back and forth slowly around the switch. If your machine has a limit switch in the negative direction, the homing direction mask can invert the axes' direction. It works just like the step port invert and direction port invert masks, where all you have to do is send the value in the table to indicate what axes you want to invert and search for in the opposite direction.
|
||||
|
||||
@ -216,7 +214,7 @@ The homing cycle first searches for the limit switches at a higher seek rate, an
|
||||
|
||||
Homing seek rate is the homing cycle search rate, or the rate at which it first tries to find the limit switches. Adjust to whatever rate gets to the limit switches in a short enough time without crashing into your limit switches if they come in too fast.
|
||||
|
||||
#### $26 - Homing debounce, ms
|
||||
#### $26 - Homing debounce, milliseconds
|
||||
|
||||
Whenever a switch triggers, some of them can have electrical/mechanical noise that actually 'bounce' the signal high and low for a few milliseconds before settling in. To solve this, you need to debounce the signal, either by hardware with some kind of signal conditioner or by software with a short delay to let the signal finish bouncing. Grbl performs a short delay, only homing when locating machine zero. Set this delay value to whatever your switch needs to get repeatable homing. In most cases, 5-25 milliseconds is fine.
|
||||
|
||||
@ -224,6 +222,20 @@ Whenever a switch triggers, some of them can have electrical/mechanical noise th
|
||||
|
||||
To play nice with the hard limits feature, where homing can share the same limit switches, the homing cycle will move off all of the limit switches by this pull-off travel after it completes. In other words, it helps to prevent accidental triggering of the hard limit after a homing cycle.
|
||||
|
||||
#### $30 - Max spindle speed, RPM
|
||||
|
||||
This sets the spindle speed for the maximum 5V PWM pin output. Higher programmed spindle RPMs are accepted by Grbl but the PWM output will not exceed the max 5V. By default, Grbl linearly relates the max-min RPMs to 5V-0.02V PWM pin output in 255 increments. When the PWM pin reads 0V, this indicates spindle disabled. Note that there are additional configuration options are available in config.h to tweak how this operates.
|
||||
|
||||
#### $31 - Min spindle speed, RPM
|
||||
|
||||
This sets the spindle speed for the minimum 0.02V PWM pin output (0V is disabled). Lower RPM values are accepted by Grbl but the PWM output will not go below 0.02V, except when RPM is zero. If zero, the spindle is disabled and PWM output is 0V.
|
||||
|
||||
#### $32 - Laser mode, boolean
|
||||
|
||||
When enabled, Grbl will move continuously through consecutive `G1`, `G2`, or `G3` motion commands when programmed with a `S` spindle speed (laser power). The spindle PWM pin will be updated instantaneously through each motion without stopping. However, Grbl will still stop motion if a spindle state is commanded and altered, like `M3`, `M4`, or `M5`. If the spindle needs to be disabled while under continuous motion, program a `S0`, zero spindle speed, to disable the spindle with a supported motion command.
|
||||
|
||||
When disabled, Grbl will operate as it always has, stopping motion with every `S` spindle speed command. This is the normal operating
|
||||
|
||||
#### $100, $101 and $102 – [X,Y,Z] steps/mm
|
||||
|
||||
Grbl needs to know how far each step will take the tool in reality. To calculate steps/mm for an axis of your machine you need to know:
|
||||
@ -246,7 +258,7 @@ NOTE: This max rate setting also sets the G0 seek rates.
|
||||
|
||||
#### $120, $121, $122 – [X,Y,Z] Acceleration, mm/sec^2
|
||||
|
||||
This sets the axes acceleration parameters in mm/second/second. Simplistically, a lower value makes Grbl ease slower into motion, while a higher value yields tighter moves and reaches the desired feedrates much quicker. Much like the max rate setting, each axis has its own acceleration value and are independent of each other. This means that a multi-axis motion will only accelerate as quickly as the lowest contributing axis can.
|
||||
This sets the axes acceleration parameters in mm/second/second. Simplistically, a lower value makes Grbl ease slower into motion, while a higher value yields tighter moves and reaches the desired feed rates much quicker. Much like the max rate setting, each axis has its own acceleration value and are independent of each other. This means that a multi-axis motion will only accelerate as quickly as the lowest contributing axis can.
|
||||
|
||||
Again, like the max rate setting, the simplest way to determine the values for this setting is to individually test each axis with slowly increasing values until the motor stalls. Then finalize your acceleration setting with a value 10-20% below this absolute max value. This should account for wear, friction, and mass inertia. We highly recommend that you dry test some G-code programs with your new settings before committing to them. Sometimes the loading on your machine is different when moving in all axes together.
|
||||
|
||||
@ -267,7 +279,7 @@ G-code parameters store the coordinate offset values for G54-G59 work coordinate
|
||||
|
||||
G54-G59 work coordinates can be changed via the `G10 L2 Px` or `G10 L20 Px` command defined by the NIST gcode standard and the EMC2 (linuxcnc.org) standard. G28/G30 pre-defined positions can be changed via the `G28.1` and the `G30.1` commands, respectively.
|
||||
|
||||
When `$#` is called, Grbl will respond with the stored offsets from machine coordinates for each system as follows. `TLO` denotes tool length offset, and `PRB` denotes the coordinates of the last probing cycle.
|
||||
When `$#` is called, Grbl will respond with the stored offsets from machine coordinates for each system as follows. `TLO` denotes tool length offset (for the default z-axis), and `PRB` denotes the coordinates of the last probing cycle, where the suffix `:1` denotes if the last probe was successful and `:0` as not successful.
|
||||
|
||||
```
|
||||
[G54:4.000,0.000,0.000]
|
||||
@ -279,16 +291,16 @@ When `$#` is called, Grbl will respond with the stored offsets from machine coor
|
||||
[G28:1.000,2.000,0.000]
|
||||
[G30:4.000,6.000,0.000]
|
||||
[G92:0.000,0.000,0.000]
|
||||
[TLO:0.000,0.000,0.000]
|
||||
[PRB:0.000,0.000,0.000]
|
||||
[TLO:0.000]
|
||||
[PRB:0.000,0.000,0.000:0]
|
||||
```
|
||||
|
||||
#### `$G` - View gcode parser state
|
||||
|
||||
This command prints all of the active gcode modes in Grbl's G-code parser. When sending this command to Grbl, it will reply with something like:
|
||||
This command prints all of the active gcode modes in Grbl's G-code parser. When sending this command to Grbl, it will reply with a message starting with an `[GC:` indicator like:
|
||||
|
||||
```
|
||||
[G0 G54 G17 G21 G90 G94 M0 M5 M9 T0 S0.0 F500.0]
|
||||
[GC:G0 G54 G17 G21 G90 G94 M0 M5 M9 T0 S0.0 F500.0]
|
||||
```
|
||||
|
||||
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.
|
||||
@ -315,6 +327,8 @@ In addition to the G-code parser modes, Grbl will report the active `T` tool num
|
||||
#### `$I` - View build info
|
||||
This prints feedback to the user the Grbl version and source code build date. Optionally, `$I` can also store a short string to help identify which CNC machine you are communicating with, if you have more than machine using Grbl. To set this string, send Grbl `$I=xxx`, where `xxx` is your customization string that is less than 80 characters. The next time you query Grbl with a `$I` view build info, Grbl will print this string after the version and build date.
|
||||
|
||||
NOTE: Some OEMs may block access to over-writing the build info string so they can store product information and codes there.
|
||||
|
||||
#### $N - View startup blocks
|
||||
|
||||
`$Nx` are the startup blocks that Grbl runs every time you power on Grbl or reset Grbl. In other words, a startup block is a line of G-code that you can have Grbl auto-magically run to set your G-code modal defaults, or anything else you need Grbl to do everytime you start up your machine. Grbl can store two blocks of G-code as a system default.
|
||||
@ -335,16 +349,18 @@ Not much to go on, but this just means that there is no G-code block stored in l
|
||||
|
||||
To set a startup block, type `$N0=` followed by a valid G-code block and an enter. Grbl will run the block to check if it's valid and then reply with an `ok` or an `error:` to tell you if it's successful or something went wrong. If there is an error, Grbl will not save it.
|
||||
|
||||
For example, say that you want to use your first startup block `$N0` to set your G-code parser modes like G54 work coordinate, G20 inches mode, G17 XY-plane. You would type `$N0=G20 G54 G17` with an enter and you should see an 'ok' response. You can then check if it got stored by typing `$N` and you should now see a response like `$N0=G20G54G17`.
|
||||
For example, say that you want to use your first startup block `$N0` to set your G-code parser modes like G54 work coordinate, G20 inches mode, G17 XY-plane. You would type `$N0=G20 G54 G17` with an enter and you should see an `ok` response. You can then check if it got stored by typing `$N` and you should now see a response like `$N0=G20G54G17`.
|
||||
|
||||
Once you have a startup block stored in Grbl's EEPROM, everytime you startup or reset you will see your startup block printed back to you, starting with an open-chevron `>`, and a `:ok` response from Grbl to indicate if it ran okay. So for the previous example, you'll see:
|
||||
|
||||
Once you have a startup block stored in Grbl's EEPROM, everytime you startup or reset you will see your startup block printed back to you and a response from Grbl to indicate if it ran okay. So for the previous example, you'll see:
|
||||
```
|
||||
Grbl 0.9i ['$' for help]
|
||||
G20G54G17ok
|
||||
Grbl 1.1c ['$' for help]
|
||||
>G20G54G17:ok
|
||||
|
||||
```
|
||||
If you have multiple G-code startup blocks, they will print back to you in order upon every startup. And if you'd like to clear one of the startup blocks, (e.g., block 0) type `$N0=` without anything following the equal sign.
|
||||
|
||||
Also, if you have homing enabled, the startup blocks will execute immediately after the homing cycle, not at startup.
|
||||
NOTE: There are two variations on when startup blocks with run. First, it will not run if Grbl initializes up in an ALARM state or exits an ALARM state via an `$X` unlock for safety reasons. Always address and cancel the ALARM and then finish by a reset, where the startup blocks will run at initialization. Second, if you have homing enabled, the startup blocks will execute immediately after a successful homing cycle, not at startup.
|
||||
|
||||
#### `$C` - Check gcode mode
|
||||
This toggles the Grbl's gcode parser to take all incoming blocks and process them completely, as it would in normal operation, but it does not move any of the axes, ignores dwells, and powers off the spindle and coolant. This is intended as a way to provide the user a way to check how their new G-code program fares with Grbl's parser and monitor for any errors (and checks for soft limit violations, if enabled).
|
||||
@ -356,54 +372,66 @@ Grbl's alarm mode is a state when something has gone critically wrong, such as a
|
||||
|
||||
But, tread carefully!! This should only be used in emergency situations. The position has likely been lost, and Grbl may not be where you think it is. So, it's advised to use G91 incremental mode to make short moves. Then, perform a homing cycle or reset immediately afterwards.
|
||||
|
||||
As noted earlier, startup lines do not execute after a `$X` command. Always reset when you have cleared the alarm and fixed the scenario that caused it. When Grbl resets to idle, the startup lines will then run as normal.
|
||||
|
||||
#### `$H` - Run homing cycle
|
||||
This command is the only way to perform the homing cycle in Grbl. Some other motion controllers designate a special G-code command to run a homing cycle, but this is incorrect according to the G-code standards. Homing is a completely separate command handled by the controller.
|
||||
|
||||
TIP: After running a homing cycle, rather jogging manually all the time to a position in the middle of your workspace volume. You can set a G28 or G30 pre-defined position to be your post-homing position, closer to where you'll be machining. To set these, you'll first need to jog your machine to where you would want it to move to after homing. Type G28.1 (or G30.1) to have Grbl store that position. So then after '$H' homing, you could just enter 'G28' (or 'G30') and it'll move there auto-magically. In general, I would just move the XY axis to the center and leave the Z-axis up. This ensures that there isn't a chance the tool in the spindle will interfere and that it doesn't catch on anything.
|
||||
|
||||
#### `$Jx=line` - Run jogging motion
|
||||
|
||||
New to Grbl v1.1, this command will execute a special jogging motion. There are three main differences between a jogging motion and a motion commanded by a g-code line.
|
||||
|
||||
- Like normal g-code commands, several jog motions may be queued into the planner buffer, but the jogging can be easily canceled by a jog-cancel or feed-hold real-time command. Grbl will immediately hold the current jog and then automatically purge the buffers of any remaining commands.
|
||||
- Jog commands are completely independent of the g-code parser state. It will not change any modes like `G91` incremental distance mode. So, you no longer have to make sure that you change it back to `G90` absolute distance mode afterwards. This helps reduce the chance of starting with the wrong g-code modes enabled.
|
||||
- If soft-limits are enabled, any jog command that exceeds a soft-limit will simply return an error. It will not throw an alarm as it would with a normal g-code command. This allows for a much more enjoyable and fluid GUI or joystick interaction.
|
||||
|
||||
Executing a jog requires a specific command structure, as described below:
|
||||
|
||||
- The first three characters must be '$J=' to indicate the jog.
|
||||
- The jog command follows immediate after the '=' and works like a normal G1 command.
|
||||
- Feed rate is only interpreted in G94 units per minute. A prior G93 state is ignored during jog.
|
||||
- Required words:
|
||||
- XYZ: One or more axis words with target value.
|
||||
- F - Feed rate value. NOTE: Each jog requires this value and is not treated as modal.
|
||||
- Optional words: Jog executes based on current G20/G21 and G90/G91 g-code parser state. If one of the following optional words is passed, that state is overridden for one command only.
|
||||
- G20 or G21 - Inch and millimeter mode
|
||||
- G90 or G91 - Absolute and incremental distances
|
||||
- G53 - Move in machine coordinates
|
||||
- All other g-codes, m-codes, and value words are not accepted in the jog command.
|
||||
- Spaces and comments are allowed in the command. These are removed by the pre-parser.
|
||||
|
||||
- Example: G21 and G90 are active modal states prior to jogging. These are sequential commands.
|
||||
- `$J=X10.0 Y-1.5` will move to X=10.0mm and Y=-1.5mm in work coordinate frame (WPos).
|
||||
- `$J=G91 G20 X0.5` will move +0.5 inches (12.7mm) to X=22.7mm (WPos). Note that G91 and G20 are only applied to this jog command.
|
||||
- `$J=G53 Y5.0` will move the machine to Y=5.0mm in the machine coordinate frame (MPos). If the work coordinate offset for the y-axis is 2.0mm, then Y is 3.0mm in (WPos).
|
||||
|
||||
Jog commands behave almost identically to normal g-code streaming. Every jog command will
|
||||
return an 'ok' when the jogging motion has been parsed and is setup for execution. If a
|
||||
command is not valid or exceeds a soft-limit, Grbl will return an 'error:'. Multiple jogging commands may be queued in sequence.
|
||||
|
||||
NOTE: See additional jogging documentation for details on using this command to create a low-latency joystick or rotary dial interface.
|
||||
|
||||
|
||||
#### `$RST=$`, `$RST=#`, and `$RST=*`- Restore Grbl settings and data to defaults
|
||||
These commands are not listed in the main Grbl `$` help message, but are available to allow users to restore parts of or all of Grbl's EEPROM data. Note: Grbl will automatically reset after executing one of these commands to ensure the system is initialized correctly.
|
||||
|
||||
- `$RST=$` : Erases and restores the `$$` Grbl settings back to defaults, which is defined by the default settings file used when compiling Grbl. Often OEMs will build their Grbl firmwares with their machine-specific recommended settings. This provides users and OEMs a quick way to get back to square-one, if something went awry or if a user wants to start over.
|
||||
- `$RST=#` : Erases and zeros all G54-G59 work coordinate offsets and G28/30 positions stored in EEPROM. These are generally the values seen in the `$#` parameters printout. This provides an easy way to clear these without having to do it manually for each set with a `G20 L2/20` or `G28.1/30.1` command.
|
||||
- `$RST=*` : This clears and restores all of the EEPROM data used by Grbl. This includes `$$` settings, `$#` parameters, `$N` startup lines, and `$I` build info string. Note that this doesn't wipe the entire EEPROM, only the data areas Grbl uses. To do a complete wipe, please use the Arduino IDE's EEPROM clear example project.
|
||||
|
||||
NOTE: Some OEMs may restrict some or all of these commands to prevent certain data they use from being wiped.
|
||||
|
||||
#### `$SLP` - Enable Sleep Mode
|
||||
|
||||
This command will place Grbl into a de-powered sleep state, shutting down the spindle, coolant, and stepper enable pins and block any commands. It may only be exited by a soft-reset or power-cycle. Once re-initialized, Grbl will automatically enter an ALARM state, because it's not sure where it is due to the steppers being disabled.
|
||||
|
||||
This feature is useful if you need to automatically de-power everything at the end of a job by adding this command at the end of your g-code program, BUT, it is highly recommended that you add commands to first move your machine to a safe parking location prior to this sleep command. It also should be emphasized that you should have a reliable CNC machine that will disable everything when its supposed to, like your spindle. Grbl is not responsible for any damage it may cause. It's never a good idea to leave your machine unattended. So, use this command with the utmost caution!
|
||||
|
||||
|
||||
|
||||
***
|
||||
|
||||
## Real-Time Commands: `~, !, ?, and Ctrl-X`
|
||||
|
||||
The last four of Grbl's commands are real-time commands. This means that they can be sent at anytime, anywhere, and Grbl will immediately respond, no matter what it's doing. For those that are curious, these are special characters that are 'picked-off' from the incoming serial stream and will tell Grbl to execute them, usually within a few milliseconds.
|
||||
|
||||
#### `~` - Cycle start
|
||||
This is the cycle start or resume command that can be issued at any time, as it is a real-time command. When Grbl has motions queued in its buffer and is ready to go, the `~` cycle start command will start executing the buffer and Grbl will begin moving the axes. However, by default, auto-cycle start is enabled, so new users will not need this command unless a feed hold is performed. When a feed hold is executed, cycle start will resume the program. Cycle start will only be effective when there are motions in the buffer ready to go and will not work with any other process like homing.
|
||||
|
||||
#### `!` - Feed hold
|
||||
The feed hold command will bring the active cycle to a stop via a controlled deceleration, so as not to lose position. It is also real-time and may be activated at any time. Once finished or paused, Grbl will wait until a cycle start command is issued to resume the program. Feed hold can only pause a cycle and will not affect homing or any other process.
|
||||
|
||||
If you need to stop a cycle mid-program and can't afford losing position, perform a feed hold to have Grbl bring everything to a controlled stop. Once finished, you can then issue a reset. Always try to execute a feed hold whenever the machine is running before hitting reset, except of course if there is some emergency situation.
|
||||
|
||||
#### `?` - Current status
|
||||
|
||||
The `?` command immediately returns Grbl's active state and the real-time current position, both in machine coordinates and work coordinates. Optionally, you can also have Grbl respond back with the RX serial buffer and planner buffer usage via the status report mask setting. The `?` command may be sent at any time and works asynchronously with all other processes that Grbl is doing. The `$13` Grbl setting determines whether it reports millimeters or inches. When `?` is pressed, Grbl will immediately reply with something like the following:
|
||||
|
||||
```
|
||||
<Idle,MPos:5.529,0.560,7.000,WPos:1.529,-5.440,-0.000>
|
||||
```
|
||||
|
||||
The active states Grbl can be in are: **Idle, Run, Hold, Door, Home, Alarm, Check**
|
||||
- **Idle**: All systems are go, no motions queued, and it's ready for anything.
|
||||
- **Run**: Indicates a cycle is running.
|
||||
- **Hold**: A feed hold is in process of executing, or slowing down to a stop. After the hold is complete, Grbl will remain in Hold and wait for a cycle start to resume the program.
|
||||
- **Door**: (New in v0.9i) This compile-option causes Grbl to feed hold, shut-down the spindle and coolant, and wait until the door switch has been closed and the user has issued a cycle start. Useful for OEM that need safety doors.
|
||||
- **Home**: In the middle of a homing cycle. NOTE: Positions are not updated live during the homing cycle, but they'll be set to the home position once done.
|
||||
- **Alarm**: This indicates something has gone wrong or Grbl doesn't know its position. This state locks out all G-code commands, but allows you to interact with Grbl's settings if you need to. '$X' kill alarm lock releases this state and puts Grbl in the Idle state, which will let you move things again. As said before, be cautious of what you are doing after an alarm.
|
||||
- **Check**: Grbl is in check G-code mode. It will process and respond to all G-code commands, but not motion or turn on anything. Once toggled off with another '$C' command, Grbl will reset itself.
|
||||
|
||||
#### `Ctrl-x` - Reset Grbl
|
||||
This is Grbl's _soft_ reset command. It's real-time and can be sent at any time. As the name implies, it resets Grbl, but in a controlled way, *retains* your machine position, and all is done without powering down your Arduino. The only times a soft-reset could lose position is when problems arise and the steppers were killed while they were moving. If so, it will report if Grbl's tracking of the machine position has been lost. This is because an uncontrolled deceleration can lead to lost steps, and Grbl has no feedback to how much it lost (this is the problem with steppers in general). Otherwise, Grbl will just re-initialize, run the startup lines, and continue on its merry way.
|
||||
|
||||
Please note that it's recommended to do a soft-reset before starting a job. This guarantees that there aren't any G-code modes active that from playing around or setting up your machine before running the job. So, your machine will always starts fresh and consistently, and your machine does what you expect it to.
|
||||
|
||||
|
||||
## Other Resources:
|
||||
* **[DANK](http://dank.bengler.no/-/page/show/5474_configuringgrbl)** _Last updated 2/2011._ Only applies to grbl v0.6.
|
||||
|
@ -202,8 +202,7 @@ void st_wake_up()
|
||||
if (bit_istrue(settings.flags,BITFLAG_INVERT_ST_ENABLE)) { STEPPERS_DISABLE_PORT |= (1<<STEPPERS_DISABLE_BIT); }
|
||||
else { STEPPERS_DISABLE_PORT &= ~(1<<STEPPERS_DISABLE_BIT); }
|
||||
|
||||
// Initialize stepper output bits
|
||||
st.dir_outbits = dir_port_invert_mask;
|
||||
// Initialize stepper output bits to ensure first ISR call does not step.
|
||||
st.step_outbits = step_port_invert_mask;
|
||||
|
||||
// Initialize step pulse timing from settings. Here to ensure updating after re-writing.
|
||||
@ -294,7 +293,6 @@ void st_go_idle()
|
||||
// with probing and homing cycles that require true real-time positions.
|
||||
ISR(TIMER1_COMPA_vect)
|
||||
{
|
||||
// SPINDLE_ENABLE_PORT ^= 1<<SPINDLE_ENABLE_BIT; // Debug: Used to time ISR
|
||||
if (busy) { return; } // The busy-flag is used to avoid reentering this interrupt
|
||||
|
||||
// Set the direction pins a couple of nanoseconds before we step the steppers
|
||||
@ -416,7 +414,6 @@ ISR(TIMER1_COMPA_vect)
|
||||
|
||||
st.step_outbits ^= step_port_invert_mask; // Apply step port invert mask
|
||||
busy = false;
|
||||
// SPINDLE_ENABLE_PORT ^= 1<<SPINDLE_ENABLE_BIT; // Debug: Used to time ISR
|
||||
}
|
||||
|
||||
|
||||
@ -480,6 +477,7 @@ void st_reset()
|
||||
busy = false;
|
||||
|
||||
st_generate_step_dir_invert_masks();
|
||||
st.dir_outbits = dir_port_invert_mask; // Initialize direction bits to default.
|
||||
|
||||
// Initialize step and direction port pins.
|
||||
STEP_PORT = (STEP_PORT & ~STEP_MASK) | step_port_invert_mask;
|
||||
|
Loading…
Reference in New Issue
Block a user