Allow probing in other WCS systems as well

[petervanderwalt]

https://openbuilds.com/threads/openbuilds-control-software.13121/page-66#post-120688

[sharmstr]

Along these lines, it would be nice to display current WCS. Maybe in the space above setzero X button. I tried to do this myself but couldnt figure out how to get the $G info back from grbl. Thought it might be in laststatus.

Anyhow, not a must have for sure. But if that info was available we could do some trick messages in the probe wizards and warning messages when starting a job that changes to a different WCS other than the current WCS. Maybe tie that into your planned "check if homed and for G53" feature you have planned.

[petervanderwalt]

Updated G10 to P0 5556561 up for testing as v1.0.306

[petervanderwalt]

Along these lines, it would be nice to display current WCS. Maybe in the space above setzero X button. I tried to do this myself but couldnt figure out how to get the $G info back from grbl. Thought it might be in laststatus.

Anyhow, not a must have for sure. But if that info was available we could do some trick messages in the probe wizards and warning messages when starting a job that changes to a different WCS other than the current WCS. Maybe tie that into your planned "check if homed and for G53" feature you have planned.

Leaving ticket open - would be good to add it to the Parser from the backend side - I have done it for my old GrblJS host https://github.com/openhardwarecoza/grbljs/blob/master/index.js#L1090-L1258 so relatively easy to port

In GrblJS I only request $G upon first connection, and when a G54-G59 is sent https://github.com/openhardwarecoza/grbljs/blob/master/index.js#L746-L751 - to be extended to all other Modals actually:

 modals: {
      motionmode: "G0", // G0, G1, G2, G3, G38.2, G38.3, G38.4, G38.5, G80
      coordinatesys: "G54", // G54, G55, G56, G57, G58, G59
      plane: "G17", // G17, G18, G19
      distancemode: "G90", // G90, G91
      arcdistmode: "G91.1", // G91.1
      feedratemode: "G94", // G93, G94
      unitsmode: "G21", // G20, G21
      radiuscomp: "G40", // G40
      tlomode: "G49", // G43.1, G49
      programmode: "M0", // M0, M1, M2, M30
      spindlestate: "M5", // M3, M4, M5
      coolantstate: "M9", // M7, M8, M9
      tool: "0",
      spindle: "0",
      feedrate: "0"
    },

[sharmstr]

Awesome!

I'll do some probe testing here shortly. Thanks!

[petervanderwalt]

Will post the release shortly, Github Actions seems to have broken and isn't creating the "release" looking into that now

[petervanderwalt]

Released (:

[sharmstr]

Tested most to them and they work as expected. Thank you

[petervanderwalt]

Comments?

Sneaked a somewhat hidden little button up here

Has a dropdown menu so you don't need to use the Console:

And the parser picks up the coordinate system from $G and updates what's shown on the button (current state)

[sharmstr]

That's exactly what I was thinking. I didnt want to push my luck by asking for it to switch WCS as well. Whoop!

[petervanderwalt]

Made it a little prettier, and added the Checkmarks so you also see in the Menu where you are

Will be out as v1.0.308 (:

Now... someday when I have a week to work on it - we gotta add 3D view of the machine+work coordinates (just colored rects showing machine size (from Grbl Max travel) and relative work offsets (:

[petervanderwalt]

In GrblJS I only request $G upon first connection, and when a G54-G59 is sent https://github.com/openhardwarecoza/grbljs/blob/master/index.js#L746-L751

This section introduced a bug, will fix today
When I wrote that for GrblJS it was still based off an older version of node-serialport - which handled the "realtime" command without interfering with the running stream - in the later versions of node-serialport used by CONTROL, it seems to interject the realtime command over the running stream corrupting commands :(