grbl/grbl — Issue #71: Advanced settings and grbl-system commands.
Author: chamnit
Created: 2012-03-04 17:08:55+00:00
State: open

I've been holding out on this topic for one of the last big pushes for v0.8 edge (status reports and homing/jogging still need to be worked out, but are going to be treated separately.) This topic is about advanced settings and grbl system commands, which opens up a big can of worms, as they say, or pandora's box. The problem here is that once we start adding things, it can get really easy to get carried away to just add everything. I'd like to start a discussion on what needs to be stored in EEPROM, what can stay in the compile-time config.h file, and what and how grbl system commands should look like and behave. Like I said there's a lot here to talk about.

So to begin, I've compiled and aggregated a list of things that will likely need to be installed, some maybe's or future items, and a start on some system commands.

### Grbl EEPROM Settings
```
$0 = 314.95 (steps/mm x)
$1 = 314.96 (steps/mm y)
$2 = 314.96 (steps/mm z)
$3 = 20 (microseconds step pulse)
$4 = 254.00 (mm/min default feed rate)
$5 = 635.00 (mm/min default seek rate)
$6 = 0.10 (mm/arc segment)
$7 = 192 (step port invert mask. binary = 11000000)
$8 = 50.00 (acceleration in mm/sec^2)
$9 = 0.05 (cornering junction deviation in mm)
'$x=value' to set parameter or just '$' to dump current settings
```

Right now we have this, and here's a short list of the things that I think that need to be installed here.

* (sleep, limit, spindle invert mask. binary=00000000)
* (cycle auto-start default. 1=on, 0=off)
* (serial baudrate. 1=9600, 2=19200, 3=57600)
* (jogging default axis. 1=x, 2=y, 3=z)
* (jogging default feed rate in mm/min)
* (homing default feed rate in mm/min)
* (homing debounce delay in ms)
* (status report decimal places)
* (status report units. 1=mm, 2=inch, 3=steps)
* (status report item mask. binary=10000101) -> This mask sets up the items that will be reported real-time by the status reporting runtime command. A separate report command will be set up to report g-code modes that I will discuss later. Items like Grbl state [Idle,Run,Hold,Jog,Home,Sleep,Abort], MPOS, WPOS, Buffer size, feed rate, overrides, line number, spindle speed/dir can be included into the mask.

Also, instead of using an invert mask in the settings, I think we can hide this from the user and store the mask internally. We could just have the user see a true/false statement like ``$7=1 (invert x-direction. 1=true,0=false)`` for each item in the mask. This would make the settings source bigger, but this might make things easier to learn for a user to re-configure the masks this way.

Lastly, I think we should keep the numbering convention we already have with setting EEPROM defaults. This would make things consistent and a user would be able to see easily what number corresponds to which setting by printing the '$' settings dump.

### Grbl Advanced or Extra Settings?

Here's a list of things that may or may not be needed to be included to be saved into the EEPROM memory. Some of these things are nice-to-have's but not completely necessary. I'd like to see what you all think about these.

* G54 work position default. This could be useful. A user could store the coordinate system into EEPROM and always have work zero defined right after a homing cycle. But, this can be set by an explicit G10 command in a program also.
* G28 and G30 home positions (not necessarily at machine zero)
* Default work coordinate system. Usually G54, but only needed if more than one work coordinate system is used
* G92 coordinate offset position defaults and enable/disable.
* Workspace volume limits or soft limits. A soft limit is where Grbl would internally track where it is in machine space and when it hits a soft limit, it would automatically start a feed hold and stop before hitting a limit switch.
* Default toggles: block deletes, optional stop, single block mode, dry-run

### Grbl system commands

What I mean by system command is that these are commands that setup how Grbl runs special modes like jogging, or toggling runtime options like block deletes and optional stops. I think we should use the '$' characters to indicate a special command, but start using letters or words to define these, and there are a bunch.

* Runtime toggles: These would set how the g-code parser would operate with feature that have yet be installed, but really easy to with minimal overhead. I think these are very useful and should be installed. These toggles are auto-start, block deletes, optional stop, single block mode, and dry-run. All of these would be set as false by default (unless added to EEPROM as otherwise). To set them, I was thinking something like ``$BLKDEL=0`` for false or ``$OPTSTOP=1`` for true.

* Jogging: There needs to be a way to set jogging axes and feedrates without g-code commands and to operate them by some command for interfaces. To set the axes, we can do something like ``$JX`` to enable the x-axis for jogging and ``$JF=100.0`` to set the feedrate. For hardware UI's, we can have a jogging enable/disable toggle and direction pin. For software UI's, we can have soemthing like a ``$J+`` to begin positive axes motion, ``$J-`` for negative, and ``$J0`` to stop. All of this is up for debate. There's probably a lot better ways of doing this.

* Set machine position: In grbl, there is no way for a user to set machine position other than by performing a homing cycle or hard resetting the Arduino, both of which zero them out. I'd like to discuss whether or not we need to install a way to set machine position manually. For example, ``$MX=1.0`` sets machine x to 1.0mm or ``$M0`` zeros all axes at current position.

* Print non-realtime status reports: Right now '?' immediately prints a real-time status report of grbl's position, but I think we need a way to print out a complete status report that is not real-time. The report would include everything about the current state of grbl, including the position at the time of the print out and g-code parser state. This would be important for UI's knowing the complete state of things in grbl. We can use a command like ``$STATUS`` for this.

I know this is a lot of stuff to cram into one post, but all of this is intertwined. I'm not going to go forward with coding until some type of gorup consensus development on how all of this should look. Keep in mind that one of Grbl's missions is to keep things as simple as possible. But there are many things that are in grey areas and we just have to figure out where and how to integrate them.