search

hzeller / beagleg

G-code interpreter and stepmotor controller for crazy fast coordinated moves of up to 8 steppers. Uses the Programmable Realtime Unit (PRU) of the Beaglebone.
http://beagleg.org/
GNU General Public License v3.0
122 stars 51 forks source link

[feature] m command for get parser state #37

Closed holla2040 closed 6 years ago

holla2040 commented 6 years ago

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 commented 6 years ago

On 14 May 2018 at 11:35, Craig Hollabaugh notifications@github.com 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 commented 6 years ago

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_g0g1? I'm sure there is, I just need to figure out which one it is. Thanks for the comment.

hzeller commented 6 years ago

On Monday, May 14, 2018 12:14 PM, Henner Zeller wrote:

On 14 May 2018 at 11:35, Craig Hollabaugh notifications@github.com<mailto:notifications@github.com> 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 commented 6 years ago

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 commented 6 years ago

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.

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

hzeller commented 6 years ago

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

holla2040 commented 6 years ago

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

holla2040 commented 6 years ago

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 commented 6 years ago

Moved discussion to #38