John Lauer can you briefly trace through how the units are called and shared

@jlauer can you briefly trace through how the units are called and shared in CP?

I’m trying to revert the workspace to translate the units on the fly, rather than force them to harmonise. It seems that the grbl widget maintains three unit references:

controller_units - not really used except as a holding variable
work_mode - G20/G21; and
report_mode - the mode in which grbl sends back report information

when there is a change in G20 the widget detects this in a number of ways:

  • it tracks what is sent out from the serial widget.
  • it tracks what the gShield sends back in response to a $G message.
  • it subscribes to /com-chilipeppr-interface-cnccontroller/units
  • it subscribes to /com-chilipeppr-widget-3dviewer/unitsChanged and
  • it subscribes to /com-chilipeppr-widget-3dviewer/recvUnits

when there is a change it publishes the change to /com-chilipeppr-interface-cnccontroller/units

at the moment, I’m not seeing the axis widget honour the 3d viewer settings. and there are a number of other anomalies giving headaches.


The approach used in the tinyg workspace is to report the units the way tinyg sends them back. So if tinyg is sending back mm, all widgets, in particular the axes widget, will show mm. If a user drags in an inches gcode, the 3d viewer shows inches, but axes still shows mm. The moment the user plays their gcode, the tinyg starts reporting inches because it sees the g20/g21 change, thus all other widgets see the units change. My guess is grbl doesn’t automatically do this for you, so you have to do it on your own with your own detection?

Correct. Grbl differentiates between the gcode modal state and the reporting.

Hmm. I clearly need to trace through the behaviour of each of the other widgets.