Closed holla2040 closed 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
you get the number of the current active coordinate system
// #5220 = 0.000000
After changing to G54, we see coordinate system 1 active:
G54 ok
// #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 = 11.000000
// #5222 = 22.000000
// #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
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.
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:
… …
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
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.
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.
I've opened #38 to discuss status server stuff.
what? my json dreams are already in the works? you are the man! Will check it out a little later.
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.
Moved discussion to #38
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.