Stream True Current Position

Veti

@aconz2

60 hz is to much. you would probably cause quite a bit of load that way.

you can implement pull quite easily with existing functionality.

DWC calls http://<ip of duet>/rr_model?flags=d99fn in an interval to get those information in json.

so just write a script that gets that information in the frequency you need.

o_lampe

@veti said in Stream True Current Position:

DWC calls http://<ip of duet>/rr_model?flags=d99fn in an interval to get those information in json.

If you start a really slow move you can see in DWC that the axis "is already there", long before it is actually there.
IMHO it won't make a difference to poll this data more often, when it shows you the end position of the move right away.
There is no interpolation AFAIK.

dc42

@aconz2 you can get more up to date coordinates if you enable segmentation in RRF 3.3. See the S and T parameters of the M669 command.

o_lampe

@dc42 said in Stream True Current Position:

@aconz2 you can get more up to date coordinates if you enable segmentation in RRF 3.3. See the S and T parameters of the M669 command.

Is there a way to determine max S- parameter suitable for Duet2 for a Delta?

dc42

@o_lampe I can't think of one, other than by experimentation.

aconz2

@dc42 Interesting I will test that out. Thanks

Do you have a gut instinct on how feasible my original idea is? ie. keep a realtime step count and output it on a timer

dc42

@aconz2 said in Stream True Current Position:

Do you have a gut instinct on how feasible my original idea is? ie. keep a realtime step count and output it on a timer

It's not difficult to retrieve the step count; but in the general case it is necessary to apply the forward kinematics transform to the step counts in order to get the Cartesian position. For some kinematics (e.g. delta and SCARA), that transform is quite expensive to apply. So updating as fast as 60Hz might not be practical.

aconz2

@dc42 Thanks for the quick reply and for such a great project!

I've hacked in an initial version that seems to work fine at 60 Hz (target) so far, outputting a timestamp and step counts for the 3 axes I care about. I'm getting more like 20ms between readings so I might have already found the limit (50 Hz). I still have some optimizations to try and/or disabling things I know I don't use.

This is obviously much harder to do in a general manner but it makes me really appreciate open source projects for their flexibility to fit exact use cases in situations exactly like this. Thanks again

aconz2

Figured out why it was locked at 50 Hz: I was outputting the message from the Move task loop, which yields for 20 ms, so of course I wasn't going to get faster than that! I moved it to Platform spin and I'm getting 60 Hz no issue so far.

I also added a fast path to write directly to the USB output buffer if there is room (maybe not atomic?) so that there isn't the latency of copying buffers and then flushing later. The fast path is used 100% of the time so far which makes sense because the message is short and nothing else is sending.

The only weird thing I see is when I close the USB connection on the computer while the duet is still running the DWC I have open in the browser goes in a loop of disconnect + reconnect. I think maybe messages build up and the network task gets delayed long enough to close the connection but then has no problem reconnecting. The root seems to be that the SerialCDC isn't getting notified of the disconnect (as in core_cdc_disable isn't getting called); but note that things don't have an issue when I unplug the USB cable entirely.

On a Duet2Wifi with 3.3RC3 everything.

Only other thing of note right now is that I accidentally uploaded a firmware build without the crc32 at the end (wasn't in PATH and since the build does this in place I didn't see the error but the file was there so I thought it was fine). This flashed fine but then loops at bootup so I had to reflash manually. It might be nice to check this either on upload from DWC and/or checking in the M997. Happy to contribute this if you advised on the desired location for that check.

dc42

@aconz2 I advise against using the Move task to output any data, because it may prevent that task from keeping up to date with movement. The Main task is better for that purpose.

Writing directly to the USB buffer will bypass the mechanism that handles disconnection of the USB port.

What are you trying to do that needs such a frequent update of position?

aconz2

@dc42 I'm experimenting with closed loop control from a computer that reads video frames at 60 fps so I wanted to match that update frequency with the true position of the machine (this video talks about the video sensor https://youtu.be/5vjdLNiMfcc)

Not sure I see where I'm messing with the USB but I'm probably just missing something. Seems to work well enough for a prototype so I'm going to keep going with it.