[FeatureRequest]: Access second motion system OM data with Subscription Connection

[AndyEveritt]

Is your feature request related to a problem? Please describe.

Currently there are a number of OM fields that return data specific to the current motion system used by the input channel that queried the OM. currentTool, speedFactor, etc. To access these with M409 you need to first set the MS number like this M596 P1 M409 K"move.speedFactor".

There is currently no way for the DSF SubscriptionConnection to access the data for the second motion system

Describe the solution you propose.

Maybe return all fields that change depending on MS as an object

{
   "current": <value for current MS>,
   "motion_system": [
      <value for MS1>,
      <value for MS2>
   ]
}

Describe alternatives you've considered

Provide any additional context or information.

[dc42]

This proposal would introduce a major incompatibility in GCode expressions because it would be necessary to insert "current." in any expressions that use these parameters.

An alternative would be to add a new array move.motionSystems[] that contains the motion-system dependent values. They would also be returned in their current positions in the OM for backwards compatibility.

Another possibility would be for M409 and rr_model to accept an additional parameter in the flags field that specifies which motion system we are interested in, with the default being as now (i.e. current motion system for the channel on which the command is received).

[chrishamm]

I'd favour an extra array that is independent from the channel because DSF maintains a global object model instance that is served to plugins and the UI. We can say the data passed by move or state.currentTool always represents the first motion system as is currently the case.

[chrishamm]

We've got move.motionSystems in v3.7. Closing.