#Grbl controller 3.6.1 screen hangs ups install
#Grbl controller 3.6.1 screen hangs ups software

For example, $MX=1.0 sets machine x to 1.0mm or $M0 zeros all axes at current position.

#Grbl controller 3.6.1 screen hangs ups install

I'd like to discuss whether or not we need to install a way to set machine position manually.

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.

There's probably a lot better ways of doing this.

#Grbl controller 3.6.1 screen hangs ups software

For software UI's, we can have soemthing like a $J+ to begin positive axes motion, $J- for negative, and $J0 to stop. For hardware UI's, we can have a jogging enable/disable toggle and direction pin. 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.

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 them, I was thinking something like $BLKDEL=0 for false or $OPTSTOP=1 for true. All of these would be set as false by default (unless added to EEPROM as otherwise). These toggles are auto-start, block deletes, optional stop, single block mode, and dry-run. I think these are very useful and should be installed.

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 we should use the '$' characters to indicate a special command, but start using letters or words to define these, and there are a bunch. 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.

Default toggles: block deletes, optional stop, single block mode, dry-run.

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.

Workspace volume limits or soft limits.

G92 coordinate offset position defaults and enable/disable.

Usually G54, but only needed if more than one work coordinate system is used

G28 and G30 home positions (not necessarily at machine zero).

But, this can be set by an explicit G10 command in a program also. A user could store the coordinate system into EEPROM and always have work zero defined right after a homing cycle. I'd like to see what you all think about these. Some of these things are nice-to-have's but not completely necessary. Here's a list of things that may or may not be needed to be included to be saved into the EEPROM memory. 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. Lastly, I think we should keep the numbering convention we already have with setting EEPROM defaults. 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. 1=true,0=false) for each item in the mask. We could just have the user see a true/false statement like $7=1 (invert x-direction.

Items like Grbl state, MPOS, WPOS, Buffer size, feed rate, overrides, line number, spindle speed/dir can be included into the mask.ДЄlso, instead of using an invert mask in the settings, I think we can hide this from the user and store the mask internally. A separate report command will be set up to report g-code modes that I will discuss later. binary=10000101) -> This mask sets up the items that will be reported real-time by the status reporting runtime command.

Right now we have this, and here's a short list of the things that I think that need to be installed here. '$x=value' to set parameter or just '$' to dump current settings $9 = 0.05 (cornering junction deviation in mm)