[feature] m command for get parser state

[holla2040]

m114 calls mprint_current_position

grbl has a 'parser state' command "$G", see https://github.com/gnea/grbl/wiki/Grbl-v1.1-Commands
which displays the parser modes, G0/G1, G90/G91, G20/G21 etc.

Having the parser state query-able enables GUIs to be restarted during GUI development. Upon reset, the GUI can query parser state and display modes of the running machine. Otherwise the GUI has a set machine's state to know values which are persisted across GUI reboots.

[hzeller]

On 14 May 2018 at 11:35, Craig Hollabaugh ***@***.***> wrote: m114 calls mprint_current_position grbl has a 'parser state' command "$G", see https://github.com/gnea/grbl/ wiki/Grbl-v1.1-Commands which displays the parser modes, G0/G1, G90/G91, G20/G21 etc.

Mmh, so this sounds very GRBL specific, I think I'd be slightly more in favor to ask the content of the standard machine variables, that contain all the coordinates and the machine state of the GCode interpreter (we might need to add more documentation in GCode.md that this is possible). The variable numbers we are using are the 'standard' variable numbers all of the big iron is using. E.g. with #5220 you get the number of the current active coordinate system #5220 // #5220 = 0.000000 After changing to G54, we see coordinate system 1 active: G54 ok #5220 // #5220 = 1.000000 The variables #5221 and ongoing contain the offsets for each of these; let's set the coordinate system and query it: G10 L2 P1 X11 Y22 Z33 ok #5221 // #5221 = 11.000000 #5222 // #5222 = 22.000000 #5223 // #5223 = 33.000000 Granted, this also depends on the extension of BeagleG to print the variable content as a comment if it is the only thing on the line, but it 'feels' a bit more standard. It would still require a lot of variable queries (though if the GUI does it, it is not a big deal), so maybe we should add an M-code to dump all variables, so that a GUI can get up to speed right away ? Hartley is working with variables a lot, I guess he'll have an opinion. We should see if there is already an M or G code that machines commonly provide to dump all the variables. Another way that might be interesting to consider implementing: having M117 actually expand the content of variables before printing, so that we could do something like M117 #5221 #5222 #5223 (<- right now, this does not expand variables yet, but might be interesting if it did).

…

-h

[holla2040]

Sorry for being a newbie here, didn't know yet about direct variable querying. I'll learn about this tonight.
Your M117 command with variable expansion will work fine as long as the machine modals have a variable representation. For example, is there a variable for modal_g0_g1_? I'm sure there is, I just need to figure out which one it is. Thanks for the comment.

[hzeller]

On Monday, May 14, 2018 12:14 PM, Henner Zeller wrote: On 14 May 2018 at 11:35, Craig Hollabaugh ***@***.******@***.***>> wrote:

m114 calls mprint_current_position grbl has a 'parser state' command "$G", see https://github.com/gnea/grbl/wiki/Grbl-v1.1-Commands which displays the parser modes, G0/G1, G90/G91, G20/G21 etc.

Mmh, so this sounds very GRBL specific, I think I'd be slightly more in favor to ask the content of the standard machine variables, that contain all the coordinates and the machine state of the GCode interpreter (we might need to add more documentation in GCode.md that this is possible). The variable numbers we are using are the 'standard' variable numbers all of the big iron is using. E.g. with #5220 you get the number of the current active coordinate system #5220 // #5220 = 0.000000 After changing to G54, we see coordinate system 1 active: G54 ok #5220 // #5220 = 1.000000 The variables #5221 and ongoing contain the offsets for each of these; let's set the coordinate system and query it: G10 L2 P1 X11 Y22 Z33 ok #5221 // #5221 = 11.000000 #5222 // #5222 = 22.000000 #5223 // #5223 = 33.000000 Granted, this also depends on the extension of BeagleG to print the variable content as a comment if it is the only thing on the line, but it 'feels' a bit more standard. It would still require a lot of variable queries (though if the GUI does it, it is not a big deal), so maybe we should add an M-code to dump all variables, so that a GUI can get up to speed right away ? Hartley is working with variables a lot, I guess he'll have an opinion. We should see if there is already an M or G code that machines commonly provide to dump all the variables.

Some CNC controllers do have the current Modal information available in variables. Fanuc uses these: #4001 Group 01 (G00, G01, G02, G03, G33, G75, G77, G78, G79) #5002 Group 02 (G17, G18, G19) #4003 Group 03 (G90, G91) #4004 Group 04 (G22, G23) #4005 Group 05 (G94, G95) #4006 Group 06 (G20, G21) #4007 Group 07 (G40, G41, G42) #4008 Group 08 (G43, G44, G49) #4009 Group 09 (G73, G74, G76, G80-G89) #4010 Group 10 (G98, G99) #4011 Group 11 (G50, G51) #4012 Group 12 (G66, G67) #4013 Group 13 (G96, G97) #4014 Group 14 (G49-G59) #4015 Group 15 (G61-G64) #4016 Group 16 (G68-G69) … … #4022 Group 22 (G50.1, G51.1) #4102 B Code #4107 D code #4109 F code #4111 H code #4113 M code #4114 Sequence number #4115 Program number #4119 S code #4120 T code #4130 P code (number of the currently selected additional workpiece coordinate system) There are additional parameters for the current position and a bunch of other stuff. Some details can be found here: https://www.cnccookbook.com/fanuc-macro-system-variables-cnc-g-code-parameterized-programming/

Another way that might be interesting to consider implementing: having M117 actually expand the content of variables before printing, so that we could do something like M117 #5221 #5222 #5223 (<- right now, this does not expand variables yet, but might be interesting if it did).

That would be a cool extension to M117. Even cooler if it could be formatted somehow: M117 G54 offset X=#5221 Y=#5222 Z=#5223 Hartley

[holla2040]

Hartley,
Thanks for the fast reply and for the great info!
Craig
ps. personally I'd like to see the format be json, so my python and js code can easily parse (1 line of code). But that introduces a funky cross pollination of formatting. Any format that easily splits will be easy for python to parse.

[hzeller]

So here is another thought: I recently added a 'status server' which allows to query basic machine parameters, but at this point it is not at all specified what we want in this service (unforttunately, this is not on the mailing list, I was mailing this directly to some developers).

Right now, you can set --status-server=<port> when running machine control. It listens on a socket and on a single-letter query 'p' prints out the current position as JSON.

Typical interaction:

p
{"x_axis":100.000, "y_axis":122.000, "z_axis":0.000, "note":"experimental"}

Right now, this is totally experimental as a proof of concept, but we should come up with a list of things that we can do with this status server, which is essentially a side-channel to the regular GCode stream.

• Query options: dump positions and variables, somewhat related to this issue. In case of a 3D printer, would also output the temperatures etc.
• Limited capability to modify the current machine that does not mess with positioning, e.g. changing speed factors or acceleration parameters.
• Issuing pause and emergency stops
• Act as an input channel for other machine pauses (e.g. tool change etc.)

I should probably open a separate issue for this to discuss.

[hzeller]

I've opened #38 to discuss status server stuff.

[holla2040]

what? my json dreams are already in the works? you are the man! Will check it out a little later.

[holla2040]

have you looked at serial-port-json-server
https://github.com/chilipeppr/serial-port-json-server
webserver with websocket promotion. It the way chilipeppr, http://chilipeppr.com/, connects browser based guis to localhosted grbl arduinos. Basically a http, websocket serial port bridge. Super simple.

ideas there may be useful for your vision of connecting your side channel to other pieces.

[holla2040]

Moved discussion to #38