Object model does not match DWC - RRF v3.5.0b1

[OwenD]

Duet 2 Wifi stand alone mode
Duet Web Control 3.5.0-b1
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.5beta1 (2022-12-23)
Duet WiFi Server Version: 2.1beta2

While trying to debug a macro I came across an anomaly in the object model.
DWC displays this

If I try to access the driver number as per the displayed hierarchy
move.axes[0].drivers[0].driver, I get an error

However if I just use move.axes[0].drivers[0] it works

[droftarts]

@OwenD Thanks for reporting. One for @dc42 and/or @chrishamm .

I get a slightly different response, as on mine 'board' is not null, it is '0', and board and driver appear to be reported as one response. This is an X axis, single drive, using the first on-board driver. Using the 'drivers[array]' seems to make little difference, just returns board and driver in curly brackets:

30/12/2022, 11:00:43 echo move.axes[0].drivers
{0.0}
30/12/2022, 11:00:51 echo move.axes[0].drivers[0]
0.0

When trying to get the driver info, it even complains if you don't use the array, but then gives a different error when you do!

30/12/2022, 11:01:07 echo move.axes[0].drivers.driver
Error: meta command: missing array index
30/12/2022, 11:01:14 echo move.axes[0].drivers[0].driver
Error: meta command: reached primitive type before end of selector string

Additionally, I get an error trying to query the second drive on an axis (this is my Z axis, which uses two drivers), while the first one responds correctly (at least without the extra ".driver" on the end):

30/12/2022, 11:11:17 echo move.axes[2].drivers[0]
0.2
30/12/2022, 11:11:23 echo move.axes[2].drivers[0].driver
Error: meta command: reached primitive type before end of selector string
30/12/2022, 11:11:37 echo move.axes[2].drivers[1]
Error: meta command: array index out of bounds
30/12/2022, 11:11:48 echo move.axes[2].drivers[1].driver
Error: meta command: array index out of bounds

Ian

[dc42]

@OwenD what's happening is that the type of move.axes[0].drivers[0] is DriverId which encompasses the CAN board address and the driver number on that board. RRF displays a DriverId in the same format that you would use in a M584 or M569 command, so on your Duet 2 is reports it as "4" because CAN is not supported, whereas on Duet 3 it would report it as "0.4". However, DWC knows if it a DriverId and displays the two components separately.

[droftarts]

@dc42 What about reporting the second driver of an axis?
Also, I get an empty array response if I leave out the drivers[array]

30/12/2022, 11:22:51 echo move.axes[2].drivers
{0.0}
30/12/2022, 11:23:32 echo move.axes[2].drivers[0]
0.2
30/12/2022, 11:25:18 echo move.axes[2].drivers[1]
Error: meta command: array index out of bounds

Ian

[dc42]

@droftarts said in Object model does not match DWC - RRF v3.5.0b1:

@dc42 What about reporting the second driver of an axis?

Do you have a second driver on that axis? If so then it should report it. If not, then "index out of bounds" is as expected.

Also, I get an empty array response if I leave out the drivers[array]

I discovered the same thing earlier when verifying the report in this post, and I have flagged it for fixing in beta 2.

[droftarts]

@dc42 said in Object model does not match DWC - RRF v3.5.0b1:

Do you have a second driver on that axis?

Yes I do. See the screenshot in my post earlier in the thread.

Ian

[OwenD]

@dc42 said in Object model does not match DWC - RRF v3.5.0b1:

@OwenD what's happening is that the type of move.axes[0].drivers[0] is DriverId

So even in my case (duet2), the returned data is type "DriverId" and not an integer?

I've been getting a lot of stall errors on X driver so I've attached a thermistor to X & Y see if motor temp is related.
I was trying to compare the driver attached to the X & Y axes with the param.D reported in driver-stall.g
But I kept getting an error saying that there was no conversion of the types ( or similar)
Strangely I used isnan() on both variables and they both said false, so I thought I had to be dealing with numbers.

[chrishamm]

@OwenD Thanks for reporting this. In fact, in DSF and DWC the driver type is a DriverId object with board and driver properties, but this is misleading in the object model explorer where it should be a string. I've got a fix ready for 3.5-b2.