-
Notifications
You must be signed in to change notification settings - Fork 295
Configuring 0.99 System Groups
<<< Back to Configuring Version 0.99 Main Page
The system groups contain the following global machine and communication settings. The system groups can be listed by requesting {sys:n} or $sys
- Identification Parameters
- Global Machining Parameters
- Communications Parameters
- Gcode Initialization Defaults
These are reported in the startup strings and should be included in any support discussions. All parameters are read-only unless otherwise noted.
Setting | Description | Notes |
---|---|---|
{fv:n} | Firmware Version | Version number, e.g. 0.99 |
{fb:n} | Firmware Build | Build number, e.g. 100.00 |
{fbs:n} | Firmware Build String | Git string |
{fbc:n} | Firmware Build Config | Name of settings file |
{hp:n} | Hardware_Platform | 1=Xmega, 2=Due, 3=v9(ARM) |
{hv:n} | Hardware Version | Always set to 0 (used in v8 for HW configuration) |
{id:n} | board ID | Each board has a read-only unique ID |
Read-only value. Example fv:0.99
. Indicates the major version of the firmware; changes infrequently. Generally all settings, behaviors and other system functions will remain the same within a version - that's why this page is useful for all 0.99 versions.
Read-only value. Example "fb":100.00
.
Indicates the build of firmware and changes frequently. Please provide this number in any communication about an issue.
Git "describe" string / aka full version. Example "fbs":"086.03-57-g843e-dirty"
.
The format is "TAG-NN-sha1" with optional "-dirty", where NN is how many commits past the tag, and sha1 being the exact unique sha1 prefix. "-dirty" should not be seen unless you're doing development, and means there are uncommitted changes in the repo when it's built.
Filename of the settings file (config) complied for the build.
Example "fbc":"settings_makeblock.h"
Read-only value. Returns:
{hv:1} TinyG Xmega series {hv:2} Arduino Due G2 (ARM) {hv:3} TinyG v9 G2 (ARM)
Unused in g2core. This value is writable in TinyG and is used to set behaviors inside the firmware. Defaults to 8 for v8. If you have a TinyG v6 or earlier you must set this value to 6.
Read-only value derived from factory settings in the ARM chip
Setting | Description | Notes |
---|---|---|
{jt:...} | Junction Integration Time | Global cornering acceleration value |
{ct:...} | Chordal Tolerance | Sets precision of arc drawing. Trades off precision for max arc draw rate |
{mt:...} | Motor_disable_Timeout | Number of seconds before power to motors is removed. Maximum value is 40 million seconds. |
The{jt:...}
parameter is the way to set cornering velocity limits. JT is a normalized scaled factor that is nominally set to 1.000. Set to less than 1 for slower cornering (less aggressive), greater than 1 (but probably less than 2) for more aggressive cornering.
{jt:0.01} Lower limit - probably will fail {jt:0.75} Good value for slower machines {jt:1.00} Nominal value {jt:1.20} Good value for fast machines {jt:5.00} Upper limit. Absolutely will fail
If the JT parameter is set too low the machine will exhibit "stuttering" motion as mild corners will decelerate, possibly to zero. One way to tell if the setting is too low is to run some arcs, which are composed of many short lines joined at angles. The chordal tolerance controls the resolution of the lines. Run a large arc, such as the following sequence. Reducing the radius from I50 will test tighter and tighter corners.
(Starting with machine at (0,0) with at least 50mm clearance in X and Y) G17 G21 G90 G91.1 G94 G2 I50 F2000
Note: The JT parameter replaces Junction Acceleration {ja:...}
and the axis Junction Deviation commands - e.g. {xjd:0.01}
found in earlier builds. Cornering now obeys full jerk limitation instead of the centripetal acceleration heuristic, making it much more accurate and more true to the jerk limits set for the machine.
Arcs are generated as sets of very short straight lines that approximate a curve. Each line is a "chord" that spans the endpoints of that segment of the arc. Chordal tolerance sets the maximum allowable deviation between the true arc and straight line that approximates it - which will be the value of the deviation in the middle of the line / arc.
Setting chordal tolerance high will make curves "rougher", but they can execute faster. Setting them smaller will make for smoother arcs that may take longer to execute. The lower-limit of $ct is set by the minimum arc segment length, which is set in the firmware and really should not be changed.
{ct:0.01} Normally a good value (in mm)
Sets the number of seconds motors will remain powered after the last 'event'. E.g. set to 60 to keep motors powered for 1 minute after a move completes. Only applies to motors with power management modes that actually time out the motors (modes 2 and 3). See also $ME and $MD commands and other Power Management commands.
{mt:5} Keep motors energized for 5 seconds after last movement command {mt:1000000} Keep motors energized for 1 million seconds after last movement command (11.57 days)
Set communications speeds and modes.
Setting | Description | Notes |
---|---|---|
{ej:...} | Enable JSON mode | 0=text mode, 1=JSON mode, 2=auto mode |
{jv:...} | JSON verbosity | 0=silent ... 5=verbose |
{tv:...} | Text mode verbosity | 0=silent, 1=verbose |
{qv:...} | Queue report verbosity | 0=off, 1=filtered, 2=verbose |
{sv:...} | Status_report_Verbosity | 0=off, 1=filtered, 2=verbose |
{si:...} | Status report interval | in milliseconds (100 ms minimum interval) |
{ex:...} | Enable flow control | no function in 0.99 but remains for future use |
Note: As of 0.99 JSON syntax ({js:n}
) has been removed. All responses are strict JSON format. G2core accepts commands in strict or relaxed JSON format
Note: The behavior of EJ has changed in 0.99
Enable JSON mode sets the g2core response mode:
{ej:0} TEXT: Responses provided as Text (input commands are accepted in either format) {ej:1} JSON: Responses provided as JSON (input commands are accepted in either format) {ej:2} AUTO: Responses provided in the format of the request
By selecting TEXT or JSON the setting is "sticky". Commands are accepted in either text or JSON mode, but responses are delivered in the selected mode.
By selecting AUTO g2core will send responses in the same format as the command (it auto-configures according to the input). JSON mode is set by sending a line starting with an open curly '{'. TEXT mode is set by sending a line starting with '$', '?' or 'h'. Gcode commands do not change the auto mode. Responses to Gcode are returned in the current mode
Note: The two startup lines on reset will always be in JSON format regardless of setting in order to allow UIs to sync with an unknown board.
Sets how much information is returned in JSON mode. If you are using JSON mode with high-speed files (many short lines at high feed rates) you probably do not full verbose mode (5).
{jv:0} Silent - No response is provided for any command {jv:1} Footer - Returns footer only - no command echo, gcode blocks or messages {jv:2} Messages - Returns footers, exception messages and gcode comment messages {jv:3} Configs - Returns footer, messages, config command body {jv:4} Linenum - Returns footer, messages, config command body, and gcode line numbers if present {jv:5} Verbose - Returns footer, messages, config command body, and gcode blocks
Sets how much information is returned in text mode. We recommend using Verbose, except for very special cases.
{tv:0} Silent - no response is provided {tv:1} Verbose - returns OK and error responses
Queue reports return the number of available buffers in the planner queue. The planner queue has 28 buffers and therefore can have as many as 28 Gcode blocks queued for execution. An empty queue will report 28 available buffers. A full one will report 0.
Using the planner queue depth as a way to manage flow control when sending a Gcode file is actually a much better way than managing the serial input buffer. If you keep the planner full to about 2 blocks available it will run really smoothly. You also want to make sure the queue doesn't starve, say - more than 20 blocks available.
Verbosity settings are:
{qv:0} Silent - queue reports are off {qv:1} Single - returns reports when depth changes and is above hi water mark or below low water mark {qv:2} Triple - returns queue reports for every block queued to the planner buffer
You can also get a manual queue report by sending $qr
Note: In general you don't want to fill up the buffer with more than 24 commands as some Gcode blocks can occupy multiple planner buffer slots (4 are allowed).
Please see Status Reports for a discussion of $sv and $si status report settings.
{sv:0} Silent - status reports are off {sv:1} Filtered - returns only changed values in status reports {sv:2} Verbose - returns all values in status reports
The minimum is 100 ms. Trying to set a value below the minimum will set the minimum value.
{si:250} Status interval in milliseconds
This setting has no effect, but will not return an error if used.
Prior to 0.99 ex
was used to select XON/XOFF, RTS/CTS or no flow control. In 0.99 there are two ways to communication o the board. (1) USB, which does its own flow control and therefore needs no configuration, and (2) UART serial which assumes (and currently requires) hardware RTS/CTS flow control. In the future we anticipate adding XON/XOFF software flow control back into the firmware, so this variable has not been removed.
NOTE: g2core currently does not support local persistence (i.e. on-board EEPROM or equivalent), so these Gcode initialization settings are effectively read-only. They can be set during compile time to change them, but a reset or power-on will always load the compiled values. Any changes that have been made to the values through the settings API are not applied.
Gcode settings loaded on power up and reset. Changing these does NOT change the current Gcode state, only the initialization settings. Being as how g2core does not have any native persistence these commands are only set at compile time and will not have an effect is written.
Setting | Description | Notes |
---|---|---|
{gpl:_} | PLane selection | 0=XY plane (G17), 1=XZ plane (G18), 2=YZ plane (G1) |
{gun:_} | UNits mode | 0=inches mode (G20), 1=mm mode (G21) |
{gco:_} | COordinate system | 1=G54, 2=G55, 3=G56, 4=G57, 5=G58, 6=G59 |
{gpa:_} | PAth_control_mode | 0=Exact path mode (G61), 1=Exact stop mode (G61.1), 2=Continuous mode (G64) |
{gdi:_} | Distance mode | 0=Absolute mode (G90), 1=Incremental mode (G91) |
These parameters set the values for the Gcode model on power-up or reset. They do not affect the current gcode dynamic model. For example, entering $gun=0 will cause the system to start up from reset or power up in inches mode, but will not change the system to inches mode when it is entered. A G20 or G21 received in the Gcode stream will change the units to inches or MM mode, respectively. On reset or restart they will change back to the $gun setting.
These parameters are reported as part of the "sys" group.
{gpl:0} G17 (XY plane) {gpl:1} G18 (XZ plane) {gpl:2} G19 (YZ plane)
{gun:0} G20 (inches) {gun:1} G21 (millimeters)
{gco:1} G54 (coordinate system 1) {gco:2} G55 (coordinate system 2) {gco:3} G56 (coordinate system 3) {gco:4} G57 (coordinate system 4) {gco:5} G58 (coordinate system 5) {gco:6} G59 (coordinate system 6)
{gpa:0} G61 (exact path mode) {gpa:1} G61.1 (exact stop mode) {gpa:2} G64 (continuous mode)
{gdi:0} G90 (absolute mode) {gdi:1} G91 (incremental mode)
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