I'm trying to use the object model "move.axes[X].drivers[0]" can and driver address to use in M569.X commands to setup closed loop (1hcl) during a home without having to specifically put it in the can address into the home file. Essentially I search for the drive letter, and when I've found it I want to set a variable that has the address. Unfortunately there doesn't seem to be away to turn the string "51.0" in the object model into 51.0 (float?) in the m569.X commands. For instance.

var address = 51.0
M569.1 P{var.address} T2 C1000 S200 R150 I50 D0.1 V500 A1 E4.0:2.0 D1;
Will work fine.

But below code gives a "M569: expected numeric operand" error.

var ind = 0
var driverAddress = 0.0

while exists (move.axes[{var.ind}].letter) ;go through all axis in order till I find the correct one.
if move.axes[{var.ind}].letter == "'a"
set var.driverAddress = move.axes[{var.ind}].drivers[0]
set var.ind = var.ind +1;

M569.1 P{var.driverAddress} T2 C1000 S200 R150 I50 D0.1 V500 A1 E4.0:2.0 D1;

@LindsayC Although weirdly the position error is associated with the 1HCL board driver itself (boards->2->drivers->positionError) and not the axis it's assigned to (Move->axes) as you'd expect.

@dc42 I have an application with hard mechanical endstops for 2 positions built into a rotary valve. driven through a gearbox (5:1 precision planetary) with a NEMA 17 stepper and encoder. Angles can be between ~10 degrees up to ~90 degrees depending on application between the stops depending on valve design. In the application getting between the 2 positions quickly (sub 200 ms) and accurately is useful for various reasons.

The idea is to home and accurately find the 2 relative positions. First move in one direction stall and find the angle between them by finding the stall position and corresponding encoder count for position 1. Then move in the opposite direction till I hit the stop and stall and find the encoder count there and calculate the 2 positions based on that information . I have now discovered that there is a position error in full steps in the object model I can use instead that should work for this purpose when combined with the current position.

Another option. Rework M569.5: Closed loop data collection, so it can output to the standard output (eg the console) instead of to a file. This way it is something G-code could read back in the "reply" parameter and use, as well as external programs just getting the data stream directly instead of having to ask to download the file created and then parse it.

That should be M569.3. Typo in the title.
[Fixed by Moderator]

@LindsayC Just an update on what I've ended up doing. As we wanted to use the ethernet connection as our main comms, we've implemented the DuetHTTPclient and telnet connection together.

The DuetHTTPclient has the full object model updating in the background that can be queried regularly with less time-critical stuff like reporting in the UI things like temperatures of chambers etc.

The telnet allows more time-critical comms without the overhead of the DuetHTTPClient like needing to wait for update of the object model.

Single cable solution with a lot of flexibility.

@dc42 OK thanks yes it does work, so I can send a home command through the usb serial device and query the object model through the telnet port. So the only small issue here is having to have 2 physical connections.

Duet 3s have dual asynchronous movement queues in development. Would it be possible to allow through the usb serial port or telnet port, the querying of the object model in an asynchronous manner?

Essentially be able to use the first queue to have move commands and second queue for relaying core information about the duet while the move commandsare working.

@LindsayC And make it a parameter in the object model. This is actually more important.

Be able to assign the index (channel Z) output of quadrature encoder plugged into a 1HCL into the normal encoder input as an endstop.

This would allow homing to a defined place on the encoder itself. It does work if you actually plug the index channel output into a normal endstop input on the board with a separate plug but it makes sense for a single plug solution and potentially allows for both homing and counting full rotations together in the future.