Luca Nervetti John Lauer the current grbl widget (and perhaps the tinyg - i

@Luca_Nervetti @jlauer

the current grbl widget (and perhaps the tinyg - i haven’t checked) deals with reporting of position rather oddly. so if you are in G20 the controller still sends back mm reports and the display in the axis widget is still in mm (even though it says inches). there is both a bug and an anomaly.

so here is the question: is there a good rationale for setting the controller into G20 mode and continuing the display and reporting in mm? Or should we enforce consistency across mode, reporting and display? If the latter then setting $13=1 would also automatically set G20. and $13=0: G20. and vice versa of course.

I cannot see the use case for the three to be inconsistent, although perhaps the hassle of converting imported gcode might be one.

hoping someone with more experience than me might chip in!

TinyG sends back all info in the current units so it does the conversion for you. In trying to recall I think the Grbl workspace had to do it’s own units conversion because Grbl doesn’t do it for you.

Grbl will report in whatever units you tell it.

So the real question is whether there is a use case for having the CP display different to the working units and/or the reporting units (grbl will report in mm and accept inches if you wish).

Also, one thing added a long time ago was to scan the Gcode on load and check if it had a G20/G21 in it. If it did not, you are asked to tell ChiliPeppr G20 or G21 and CP adds it to your Gcode at the start of it. This solved a confusion issue people would have if they didn’t specify units because they’d start playing inches Gcode, but their device was in mm and everything would come out super small and cause them to think there’s a bug. I believe only when you start playing your Gcode are you then telling your device which units to use (we don’t pre-send that to the cnc on load of the file).

The way TinyG workspace does this is: 1) The 3D viewer displays the units of your Gcode up where it shows the fps rendering value. 2) The Axes widget shows whatever the units were from the position report from TinyG. TinyG sends back position reports anytime a change occurs and it tells you what units it’s in. So CP just shows that.

So, if you toggle G20 or G21 in serial port console, the position report comes back in the new units and Axes picks up on it. Then you’re jogging in those new units because jog moves don’t specify units, rather the cnc controller is just deciding.

If you then play your Gcode and it has an alternate G20 or G21 from your jogging, it should work accurately and the Axes widget picks up the unit change on the next position report.

No unit conversion happens in any Javascript in the TinyG workspace.

So, if you just want to reflect that in Grbl workspace, that would seem to be a good balance, but totally up to you what you think is best.

That seems consistent with my thinking.

Essentially no use case for wanting any of the three classes of data to be in different units.

The key difference between tinyg and grbl seems here to be that g20/21 does not change the reporting, just the working units. So for grbl we need to push a setting change whenever G20/21 is changed and vice versa.


I believe that’s why jarett luft did do unit conversion in Javascript in the Grbl widget to deal with the fact that Grbl doesn’t report in the different unit. He was trying to get it to act like the TinyG workspace, but had to do the unit conversion in Javascript.

Hmm. I will check the 0.9 codebase. Fairly sure that grbl has always converted since $13 doesn’t seem to be a new setting.

But it is possible that it was because the config change interface wasn’t finished.

Just guessing here, but maybe the reason would be because he’d have to inline a $13=0 or 1 in the Gcode when a G20 or G21 is sent, and he didn’t want to inline that. In TinyG it just happens automatically when you do a G20 or G21 so you end up not having to worry about that issue.