search

chilipeppr / tinyg

The tracking location for tickets for the chilipeppr.com/tinyg workspace.
28 stars 16 forks source link

Support history of coordinate offsets and direct setting #15

Open matthijskooijman opened 9 years ago

matthijskooijman commented 9 years ago

I've observed this with grbl, but I'd expect it to apply to tinyg as well.

When working with coordinate offsets, the chilipeppr interface for the G92 comands mostly works nicely. However, I've found that sometimes the coordinate offset gets lost (due to an M2 command, or some hardware problem or end stop trigger that needs a grbl reset). In these cases, it would be good if you could easily restore a previous offset. Also, when doing multiples of a single product, you might want to mill multiple products with a single tool, then mill them all with a second tool, which requires switching between multiple offsets a few times.

To support this case, I would suggest adding the following:

I guess all of this makes the most sense as an option in the box that shows the current offset now?

I realize that part of this can be done in gcode already, using G10 L2 / G54 etc., but AFAIK those are coordinate offsets that exist on top of (or below) the G92 offset. Since the G92 offset is easy to control within chilipeppr, it seems easier to use that instead of switching to the G54 coordinate systems that require doing everything manually then.

How does this sound?

matthijskooijman commented 9 years ago

I just had a look at the tinyg workspace, which seems to have some support for the G54 etc. offsets. There's a nice stack of coordinate offsets that you can switch and off (I think?) but I'm not quite sure how that works (how do you set them, for example?). I don't have a tinyg machine to test either :-)

matthijskooijman commented 9 years ago

Btw, suggestions on where my workflow sucks and could be improved to not need the above are of course also welcome :-)

johnlauer commented 9 years ago

Matthijs, I don't use offsets much but I did make an attempt to do a modern offset widget that's now in the TinyG workspace. Sounds like you've looked at it. I do kind of like the idea of showing a history of the offsets as well, but what I'm struggling with is the exact use case. Could you maybe describe more detail around your workflow? You started to go into it, but could you go deeper?

For example: You get G28.2 X0 Y0 Z0 to be at machine zero in lower left corner of machine You enter G10 L2 P1 X100 Y100 Z0 to get a center offset of your machine in G54 etc...

matthijskooijman commented 9 years ago

My usecase is currently mostly milling PCB's. I'm using an offset to define the top left corner of the PCB, since my actual gcode has 0,0 as the top left corner of my design. There's basically two reasons I'd like a history:

  1. Sometimes grbl (and or the coordinate offset) gets reset. This could be an M2 command in my gcode I forgot to remove, a trigger of a limit switch (requiring a grbl reset), a problem with my gcode (requiring a reset to flush the buffer), or some other problem. Afterwards, I want to restart the process in the same location, so I need to re-set the old offset. Manually jogging and zero-ing out is guaranteed to not get the offset exactly right.
  2. Sometimes I make a few PCB's, by setting an offset, running my gcode, setting a different offset and running the same gcode. Since a PCB needs a few runs with different tools, and I want to minimize toolchanges, I need to switch between different offsets a few times.

In your response, you're talking about G28.2 and G10 commands, but I'm not using any of those. I'm just using the zero-out buttons in the GUI, which uses the G92 command to set the current position at zero.

Does this answer your question?

matthijskooijman commented 8 years ago

I've been working with my grbl machine a bit more, and decided to investigate these coordinate offsets a bit further. I've found that:

I also had a look at the xyz and wcs widgets in tinyg, and I believe that that widget would be usable for grbl almost as-is. The only thing that grbl doesn't support is the G28 commands for resetting the machine coordinates (and homing, which uses $H on grbl). Simply hiding the related buttons for grbl would, I think, be enough. Looking more closely at the code, it seems that buttons are already being hidden in the current version of the grbl widget.

I tried adding the tinyg xyz widget to the grbl workspace (result is here, but I couldn't get it to work properly. The GRBL widget didn't load properly (it just says "Load GRBL here"), and looking at the chilipeppr.com/grbl, it seems there is more javascript on that page than just loading a single fiddle and the fiddle that is being loaded is not the one you get when you select "fork" in the "GRBL Workspace" widget. I tried tracing the path of fiddles being loaded, but couldn't find where the main workspace was loaded. Is there any documentation on how this works and/or how to get fork the workspace and replace/edit a widget?

chilipeppr commented 8 years ago

You should be able to add that Work Coordinate System widget in fairly easily. I agree with your assessment that there's very little stuff that would likely need to change. I don't recall why, but Jarrett Luft did make his own fork of the Axes widget. Had he not, you would have had the WCS widget a long time ago. So, you'd have to either fully take my Axes widget from TinyG and merge it into Grbl or try to upgrade the Grbl widget. I do think the Grbl widget is very old now because it doesn't get the kind of attention the TinyG workspace gets.

YOu're correct that Jarrett points to the wrong URL in that widget. That's thrown me off a few times as well. You can trace where all of the loading came from by Inspecting the DOM. All of the merged HTML from Firebug has the answers. I inject the actual URL I load stuff from via the ChiliPeppr web server so it's guaranteed to be correct. Just look in the DOM.

On Wed, Dec 16, 2015 at 3:33 AM, Matthijs Kooijman <notifications@github.com

wrote:

I've been working with my grbl machine a bit more, and decided to investigate these coordinate offsets a bit further. I've found that:

  • Grbl supports G10/G54+ work coordinates offsets, and stores them to EEPROM
  • Using these persistent and switchable offsets would entirely solve both of my usecases - they are preserved across a reset or M2 command, and I can switch between a few of them without having to remember exact coordinates and do calculations (as with G92).

I also had a look at the xyz and wcs widgets in tinyg, and I believe that that widget would be usable for grbl almost as-is. The only thing that grbl doesn't support is the G28 commands for resetting the machine coordinates (and homing, which uses $H on grbl). Simply hiding the related buttons for grbl would, I think, be enough. Looking more closely at the code, it seems that buttons are already being hidden in the current version of the grbl widget.

I tried adding the tinyg xyz widget to the grbl workspace (result is here http://jsfiddle.net/matthijskooijman/y38wewun/embedded/result/, but I couldn't get it to work properly. The GRBL widget didn't load properly (it just says "Load GRBL here"), and looking at the chilipeppr.com/grbl, it seems there is more javascript on that page than just loading a single fiddle and the fiddle that is being loaded is not the one you get when you select "fork" in the "GRBL Workspace" widget. I tried tracing the path of fiddles being loaded, but couldn't find where the main workspace was loaded. Is there any documentation on how this works and/or how to get fork the workspace and replace/edit a widget?

— Reply to this email directly or view it on GitHub https://github.com/chilipeppr/tinyg/issues/15#issuecomment-165075672.

matthijskooijman commented 8 years ago

Ah, a closer look at the scripts and dom shows that it the 2H9us root panel loads http://www.chilipeppr.com/dataget?key=userUrl:grbl which in turn loads the grbl W7QJH grbl workspace, thanks!

I haven't figured out where the #com-chilipeppr-widget-grbl widget is being loaded (since it doesn't happen when viewing the W7QJH grbl workspace separately, even though all the other widgets do get loaded correctly. Out of time for now, I'll have to look again later.

matthijskooijman commented 8 years ago

@johnlauer, found the problem and reported as #34. Now, I'm trying the coordinate offset stuff, seems that the "Set G54 zero" button doesn't actually work as expected, so I'll dive into that code. It does appear that editing javascript using this jsfiddle stuff is a fairly painful endeavor - finding in the source doesn't work, there is no easy way to see previous versions, or get a diff of versions (this service seems to work, but doesn't give a concise unified diff showing only changes, still making it bulky). I thought you couldn't set breakpoints in chrome because script tags appear as one big line in the elements tab and these dynamically loaded scripts do not appear in the sources tab, but I think they appear concatenated into one "index" file belong fiddle.jshell.net there, which also partially solves the finding problem (though I still have to manually scroll to make an edit...).

Are there some tools or tricks you can recommend to make this stuff a bit easier to work with?

matthijskooijman commented 8 years ago

but I think they appear concatenated into one "index" file belong fiddle.jshell.net there, which also partially solves the finding problem (though I still have to manually scroll to make an edit...).

Or not, that was just the primary fiddle, not any of the subsequently loaded ones...

johnlauer commented 8 years ago

Yeah, a couple of us ChiliPeppr guys are using Cloud9 recently instead of Jsfiddle. Check out https://ide.c9.io/johnlauer/chilipeppr-machinevision

Also, you can definitely debug any and all Javascript these days regardless of it being inlined.

matthijskooijman commented 8 years ago

Thanks, I'll check out cloud9.

Also, you can definitely debug any and all Javascript these days regardless of it being inlined.

I just found that I could use the console output to click through to the javascript "files" in the sources tab, having names like "VM906". I haven't found a way to directly go to such a file, without any console login present.

Also, the problem I mentioned with Set G54 Zero button seems to be because the machine coordinates aren't forwarded properly to the xyz widget, so that's a problem in my integration, not the xyz widget. Figuring out how to fix that now :-)

matthijskooijman commented 8 years ago

Here's a grbl workspace with my work in progress: http://jsfiddle.net/matthijskooijman/y38wewun/7/show/light/ @jarretluft, you might have an opinion on this :-)

This workspace replaces the xyz widget with the latest version (which includes the wcs widget). A lot of the customizations on that widget do not seem needed anymore, so I removed them. Here's a diff, and a complete list of changes I made:

The grbl widget also changed slightly. [Again, here's a diff](). I only changed the way that current position updates are sent. Previously, it would only send either work or machine coordinates, now it sends a single update containing whatever coordinates were present in the status update. I noticed there is some other bit of code that sends out an axes message in response to a 3d viewer scene changed message, which I haven't updated yet (though it really feels like insufficient separation between the grbl widget and the 3d viewer - if the 3d viewer needs the current position, it should just cache or request it).

@johnlauer, I also have some remarks regarding the xyz widget itself.

chilipeppr commented 8 years ago

This is pretty awesome progress. Nice work.

On the G53, there is no real point on that. Clicking that layer should really not send a G53 as it's pointless.

On the G92 toggling, I do think the most intuitive behavior is how it's setup right now. It should take the current position as the new 0. I think if there's a history menu then it could be done the way you mention, but I'm also game for you doing however you want it for the Grbl workspace since you're the one making the changes.

The problem with ChiliPeppr not knowing the G92 is actually Grbl's problem. The major problem with Grbl is that the Atmega 328p chip is so underpowered that it has no way of reporting statuses as a push method back to a UI like ChiliPeppr. So there's no way to know if G92 is on or not. You'd have to manually query Grbl on some kind of schedule, which would be up to you.

The inch/mm doesn't make sense to me. All Gcode that's sent to the controller should show in the serial port console.

All of the good work you're doing would possibly get the Grbl workspace closer to the TinyG's advanced features, so nice work on that. The major thing missing would be dynamic feed rate override during a job that TinyG has in it's workspace. I have found that to be almost indispensable now.

On Thu, Dec 17, 2015 at 1:24 AM, Matthijs Kooijman <notifications@github.com

wrote:

Here's a grbl workspace with my work in progress: http://jsfiddle.net/matthijskooijman/y38wewun/7/show/light/ @jarretluft https://github.com/jarretluft, you might have an opinion on this :-)

This workspace replaces the xyz widget with the latest version (which includes the wcs widget). A lot of the customizations on that widget do not seem needed anymore, so I removed them. Here's a diff http://jsfiddlediff.stapps.io/diff?url1=%2Fjarret%2FW7QJH%2F&url2=%2Fmatthijskooijman%2Fy38wewun%2F, and a complete list of changes I made:

  • The processing of the axes status messages in xyz was modified by the workspace, but instead I modified the grbl widget to simply send out the correct format in the first place, see below (the code in the workspace would have needed updates to work with the new xyz widget anyway).
  • I removed the updated tooltip text for

    com-chilipeppr-widget-xyz-ftr .joggotozero, it seems the one in the

    current xyz widget is already fine.

  • I removed the rebinding of the zero out button from G28 to G92, and instead removed the zero out machine G28 button, since the G5x zero out is now present. I guess it would make sense to still have a G92 zero out button, but perhaps that should be added to the xyz widget instead?
  • I left more buttons intact in the per-axis popups, still removing the G28.2 and G28.3 ones (set machine origin and home single axis).
  • I removed some of the inch/mm conversion code. I haven't tested this yet, it probably doesn't work yet, but the workspace seemed like the wrong place to handle this kind of thing. Can someone summarize how the unit handling works now? I think the grbl/tinyg widget publishes the current units to "/com-chilipeppr-interface-cnccontroller/units", and it seems that that is used for both generating GCode commands (e.g. jogging), as well as interpreting status updates (at least the work coordinates, if I read updateAxesFromStatus() in the xyz widget correctly, machine coordinates are always passed in mm? I wonder if it makes sense to always publish all coordinates in mm and let the grbl/tinyg widgets take care of the conversion to mm, and the xyz or whatever widget convert to the units they want to display, or the current machine's units for e.g. jogging?
  • There is still some grbl-specific jogging code left in the workspace, I haven't tested it, or looked if it is even still needed.

The grbl widget http://jsfiddle.net/matthijskooijman/0rvpnb15/ also changed slightly. Again, here's a diff. I only changed the way that current position updates are sent. Previously, it would only send either work or machine coordinates, now it sends a single update containing whatever coordinates were present in the status update. I noticed there is some other bit of code that sends out an axes message in response to a 3d viewer scene changed message, which I haven't updated yet (though it really feels like insufficient separation between the grbl widget and the 3d viewer - if the 3d viewer needs the current position, it should just cache or request it).

@johnlauer https://github.com/johnlauer, I also have some remarks regarding the xyz widget itself.

  • What is the point of sending "G53" when you click the G53 / machine tile? AFAICS G53 only affects a move command on the same line, it is not modal like G54+?

  • Clicking G92 to enable/disable the temporary offset seems a bit counter-intuitive. If you disable it, it gets cleared as expected, but when you enable it, the current position becomes 0,0,0. I sortof expected the old offset to be restored. Since the machine itself doesn't store the old offset, I guess this is unpractical and once you see what happens, it becomes clear, so this is probably not an actual problem (just something I

    noticed).

    A related problem is that chilipeppr doesn't seem to be properly aware of whether G92 is active or not. If you use the G92 tile to zero out, it will show as enabled, but using any of the other zero out buttons, or manually sending G92, will not enable the G92 tile. Looking at the info grbl returns, it does not even indicate if any G92 translation is active. Does this work somehow for tinyg, or does it have the same problem?

    Looking at the grbl source, it seems the $# command prints detailed status info on the coordinate systems:

    $# [G54:-4.000,3.000,4.000] [G55:-8.000,6.000,4.000] [G56:0.000,0.000,0.000] [G57:0.000,0.000,0.000] [G58:0.000,0.000,0.000] [G59:0.000,0.000,0.000] [G28:0.000,0.000,0.000] [G30:0.000,0.000,0.000] [G92:-5.000,0.000,0.000] [TLO:0.000] [PRB:0.000,0.000,0.000:0]

    Might be useful to query that status as well occasionally.

    When switching between inch and mm in the xyz widget, a G20/G21 command is sent, but it is not displayed in the serial port console. From a quick look, the only difference between that command and e.g. jogging commands, is that G20/G21 uses "/com-chilipeppr-widget-serialport/send" whereas the others use "/com-chilipeppr-widget-serialport/jsonSend". I haven't looked into the serial port widget yet to see where it gets its info from.

— Reply to this email directly or view it on GitHub https://github.com/chilipeppr/tinyg/issues/15#issuecomment-165392436.

matthijskooijman commented 8 years ago

(it seems github hides most of your post in the webinterface, probably trying to hide my original message and failing somehow. Clicking the tiny button shows all of it).

On the G53, there is no real point on that. Clicking that layer should really not send a G53 as it's pointless.

Yeah, so that's something that you should change in the wcs widget, I think?

On the G92 toggling, I do think the most intuitive behavior is how it's setup right now. It should take the current position as the new 0.

I guess it is, if you realize how the gcode works, so no need to change anything I guess.

The problem with ChiliPeppr not knowing the G92 is actually Grbl's problem. The major problem with Grbl is that the Atmega 328p chip is so underpowered that it has no way of reporting statuses as a push method back to a UI like ChiliPeppr.

But tinyg does send status updates for these on change automatically?

I actually think grbl should be capable of this as well, since all the footwork of reporting the status is present, it's just a matter of triggering the status automatically. I'll see if I can work with the grbl maintainer to add this.

The major thing missing would be dynamic feed rate override during a job that TinyG has in it's workspace. I have found that to be almost indispensable now.

What is that exactly? There is a feedrate change feature in the gcode player in the grbl workspace already, do you mean that? I have noticed its use is limited, since it only modifies F-values already existing in the gcodes sent, so it typically takes a long time for a change to take effect. Perhaps tinyg supports some asynchronous way to set a scaling on all feedrates?

jarretluft commented 8 years ago

Hey Matthijs, A few thoughts after using your workspace briefly:

You removed the popup box description change on the homing button, but you kept the homing as $H, so now the popup box is telling users that homing is sending a G28.2 command when it is not (grbl doesn't support g28.2)

You added the individual G92.1 X0, G92.1 Y0 and G92.1 Z0 commands back into the widget, but those commands are not supported. Running any of those commands will clear all three axes (grbl does not have a command to clear individual axes - that's why they were removed).

Your removal of the units conversion appears to have broken it. If I switch to inches mode and jog 1, the XYZ widget shows a move of 25.4 inches... Also, those conversions were intended to keep the axes, 3d viewer and grbl widget in sync IE: when you're jogging in inches but have a mm gcode file loaded, before it would mess up the toolhead marker on the 3d viewer, and vice versa. This was the fix for that. There is also the situation where a user can change their $13 variable to report status in inches, i'm not sure if you have accounted for that in your changed code, but it's not safe to assume status messages are always metric.

In both your version and mine, when I toggle Inch/MM mode, it sends the correct G20/G21 command and it displays in the serial port console, not sure what you're seeing on your end but that doesn't sound right. It shouldn't matter if it's sent with send or jsonSend.

Ultimately, there are enough customizations to the XYZ widget that at some point it is probably worth just forking off a copy and making the changes right inside the widget. I was only making those changes as workspace overrides to try and keep John's underlying widget intact, but now that I have had to freeze it on an old version to make sure his updates don't mess up my overrides, it might as well just be a separate widget for GRBL XYZ.

As an additional note, chamnit has indicated to me that he will be releasing a beta v1.0 of GRBL shortly (within the next few weeks), which will apparently add the ability for dynamic feedrates on the controller side. This would be ideal as it should mean minimal change to chilipeppr or SPJS to make it work, and just passing a special command in with the new feedrate and letting GRBL adjust the code on the fly. Also, there was some discussion of him adding push responses when $G variables change, which would eliminate the need for querying the $G entirely, i'm just not sure if that was a goal of v1.0b or a future GRBL version on more powerful hardware.

On Thu, Dec 17, 2015 at 2:24 AM, Matthijs Kooijman <notifications@github.com

wrote:

Here's a grbl workspace with my work in progress: http://jsfiddle.net/matthijskooijman/y38wewun/7/show/light/ @jarretluft https://github.com/jarretluft, you might have an opinion on this :-)

This workspace replaces the xyz widget with the latest version (which includes the wcs widget). A lot of the customizations on that widget do not seem needed anymore, so I removed them. Here's a diff http://jsfiddlediff.stapps.io/diff?url1=%2Fjarret%2FW7QJH%2F&url2=%2Fmatthijskooijman%2Fy38wewun%2F, and a complete list of changes I made:

  • The processing of the axes status messages in xyz was modified by the workspace, but instead I modified the grbl widget to simply send out the correct format in the first place, see below (the code in the workspace would have needed updates to work with the new xyz widget anyway).
  • I removed the updated tooltip text for

    com-chilipeppr-widget-xyz-ftr .joggotozero, it seems the one in the

    current xyz widget is already fine.

  • I removed the rebinding of the zero out button from G28 to G92, and instead removed the zero out machine G28 button, since the G5x zero out is now present. I guess it would make sense to still have a G92 zero out button, but perhaps that should be added to the xyz widget instead?
  • I left more buttons intact in the per-axis popups, still removing the G28.2 and G28.3 ones (set machine origin and home single axis).
  • I removed some of the inch/mm conversion code. I haven't tested this yet, it probably doesn't work yet, but the workspace seemed like the wrong place to handle this kind of thing. Can someone summarize how the unit handling works now? I think the grbl/tinyg widget publishes the current units to "/com-chilipeppr-interface-cnccontroller/units", and it seems that that is used for both generating GCode commands (e.g. jogging), as well as interpreting status updates (at least the work coordinates, if I read updateAxesFromStatus() in the xyz widget correctly, machine coordinates are always passed in mm? I wonder if it makes sense to always publish all coordinates in mm and let the grbl/tinyg widgets take care of the conversion to mm, and the xyz or whatever widget convert to the units they want to display, or the current machine's units for e.g. jogging?
  • There is still some grbl-specific jogging code left in the workspace, I haven't tested it, or looked if it is even still needed.

The grbl widget http://jsfiddle.net/matthijskooijman/0rvpnb15/ also changed slightly. Again, here's a diff. I only changed the way that current position updates are sent. Previously, it would only send either work or machine coordinates, now it sends a single update containing whatever coordinates were present in the status update. I noticed there is some other bit of code that sends out an axes message in response to a 3d viewer scene changed message, which I haven't updated yet (though it really feels like insufficient separation between the grbl widget and the 3d viewer - if the 3d viewer needs the current position, it should just cache or request it).

@johnlauer https://github.com/johnlauer, I also have some remarks regarding the xyz widget itself.

  • What is the point of sending "G53" when you click the G53 / machine tile? AFAICS G53 only affects a move command on the same line, it is not modal like G54+?

  • Clicking G92 to enable/disable the temporary offset seems a bit counter-intuitive. If you disable it, it gets cleared as expected, but when you enable it, the current position becomes 0,0,0. I sortof expected the old offset to be restored. Since the machine itself doesn't store the old offset, I guess this is unpractical and once you see what happens, it becomes clear, so this is probably not an actual problem (just something I

    noticed).

    A related problem is that chilipeppr doesn't seem to be properly aware of whether G92 is active or not. If you use the G92 tile to zero out, it will show as enabled, but using any of the other zero out buttons, or manually sending G92, will not enable the G92 tile. Looking at the info grbl returns, it does not even indicate if any G92 translation is active. Does this work somehow for tinyg, or does it have the same problem?

    Looking at the grbl source, it seems the $# command prints detailed status info on the coordinate systems:

    $# [G54:-4.000,3.000,4.000] [G55:-8.000,6.000,4.000] [G56:0.000,0.000,0.000] [G57:0.000,0.000,0.000] [G58:0.000,0.000,0.000] [G59:0.000,0.000,0.000] [G28:0.000,0.000,0.000] [G30:0.000,0.000,0.000] [G92:-5.000,0.000,0.000] [TLO:0.000] [PRB:0.000,0.000,0.000:0]

    Might be useful to query that status as well occasionally.

    When switching between inch and mm in the xyz widget, a G20/G21 command is sent, but it is not displayed in the serial port console. From a quick look, the only difference between that command and e.g. jogging commands, is that G20/G21 uses "/com-chilipeppr-widget-serialport/send" whereas the others use "/com-chilipeppr-widget-serialport/jsonSend". I haven't looked into the serial port widget yet to see where it gets its info from.

— Reply to this email directly or view it on GitHub https://github.com/chilipeppr/tinyg/issues/15#issuecomment-165392436.

matthijskooijman commented 8 years ago

You removed the popup box description change on the homing button, but you kept the homing as $H, so now the popup box is telling users that homing is sending a G28.2 command when it is not (grbl doesn't support g28.2)

Oh, that wasn't intentional. I'll see what happened and undo that.

You added the individual G92.1 X0, G92.1 Y0 and G92.1 Z0 commands back into the widget, but those commands are not supported. Running any of those commands will clear all three axes (grbl does not have a command to clear individual axes - that's why they were removed).

Ah, I didn't realize. I'll re-remove them again :-)

Your removal of the units conversion appears to have broken it.

I pretty much expected that, yes :-)

If I switch to inches mode and jog 1, the XYZ widget shows a move of 25.4 inches... Also, those conversions were intended to keep the axes, 3d viewer and grbl widget in sync IE: when you're jogging in inches but have a mm gcode file loaded, before it would mess up the toolhead marker on the 3d viewer, and vice versa. This was the fix for that. There is also the situation where a user can change their $13 variable to report status in inches, i'm not sure if you have accounted for that in your changed code, but it's not safe to assume status messages are always metric.

Right. In the end, I guess there should be a few different "units" states:

Ideally, these things would be somewhat independent and the interfaces would have use well-defined units (e.g. "axes" updates always in mm, or always have explicit units attached to them). I'm to fuzzy right now to turn this into a proper proposal, though.

Ultimately, there are enough customizations to the XYZ widget that at some point it is probably worth just forking off a copy and making the changes right inside the widget. I was only making those changes as workspace overrides to try and keep John's underlying widget intact, but now that I have had to freeze it on an old version to make sure his updates don't mess up my overrides, it might as well just be a separate widget for GRBL XYZ.

I actually think it might make sense to make some changes to the xyz widget so it becomes a bit more decoupled from the tinyg implementation, allowing the same widget to be re-used by both grbl and tinyg. It might still make sense to use a specific version of it in the grbl workspace, but pinning a version makes updating easier than a full fork (though I guess the difference is just one copy-paste, so not much).

In any case, I would like to see the inch/mm stuff fixed by better defining the contracts/interfaces for the 3d viewer, xyz widget and grbl/tinyg widget, and fix things inside these widgets, instead of hotpatching things from the workspace.