@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.

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 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

@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

Just replying to myself with some difficulties with the above approach after thinking about it some more.

Sending a move and expecting it to take exactly the expected time slice. Unless you mirror exactly how the Duet is calculating velocities etc (not to mention latency of processing the move), then the time will be off. This delta t error is then cumulative which is why it becomes an issue. Reading back the M400 to know it is complete and then proceeding is better, but you then introduce an additional latency of read M400, compute target, send position.

It is pretty desirable to keep the Duet respecting acceleration and jerk limits, but you need at least 3 moves going at all times, let's call them A, B, C.

• Move A is executing, B is next in the queue, and C does not exist
• We compute the target destination using data available right now (while A is executing) and send it as move C. This must complete before B begins executing
• Duet receives move C, adds it to the queue, and adjusts the speeds of move B
• Move A finishes and B begins
• Repeat

This could get shortened down to 2 moves A and B if the Duet could modify an in-progress move (before some deadline) once B got added. But that seems super complex.

The downside is that we have to compute move C with information at the moment while A is executing, but things will change while B is executing.

Some difficulties in doing the above are:

• knowing the true machine position at the time we compute move C. The duet will be somewhere between A's start position and A's end position but we ideally would know exactly where
• knowing where the Duet is actually in the queue currently, ie. we think A is still executing but is it now executing B because our time estimate was off? (as in the first difficulty mentioned). Its almost like we want a sync pulse to be sent whenever we start a new move (and would be extra nice to have the Duet send the move duration whenever it starts a move

I'm looking to implement a feature that you could toggle on to output the true current machine position at a fixed interval (I have 60 Hz in mind right now but it would be configurable) over USB.

I've looked through the requisite code a a fair bit and one method I see would be to use DDARing::currentDda->activeDMs->GetNetStepsLeft() or something to that effect to know how far into a move we are. Is that off the table because it's accessed from the step timer?

Is there an existing place that keeps a global step count per axis? I would be fine with step count instead of real world units. Would that kill the step timer if it incremented/decremented a counter per axis each time it sent a step?

Any of these methods probably won't get a 100% accurate reading since reading all the axes step counts wouldn't be atomic with the step timer also changing them but that's okay for my use case.

Any guidance or alternatives welcome.

If all else fails I can add encoders to the axes and read them from a separate board but I figured I would try this first. Thanks!

I'm experimenting with a closed loop control system but have some questions on movement queuing.

At a fixed time slice, say 1/10 seconds, the control loop running on a computer (duet connected over USB):

• reads some sensors
• compute a new target position that I know the machine can reach in the next time slice
• send the G1 X... Y... F... M400 with the feedrate calculated so the move takes the duration of a time slice and the move executes immediately
• repeat

This works okay, but I think what happens is that the move gets scheduled with 0 startSpeed and 0 endSpeed (as in DDA.h) since the movement queue never sees the next move.

Is there an existing setting that would give a move startSpeed = endSpeed = topSpeed? If I hacked in a new mode for this, would it be as simple as overriding the move so that startSpeed = endSpeed = topSpeed in DDA::InitStandardMove?

I'm not too concerned with the high jerk this might have since the moving inertia is pretty small and most moves will have similar speeds.

Another idea is to use M595 to set the queue length to 1 (or maybe 2?) so that there would always be a next move in the queue and sending another move would cause the previous move to execute immediately. And for this would not want to send M400 right? Otherwise it would schedule the move to have 0 endSpeed.
The moves would execute 1 time slice later than anticipated but I think I could live with that.

To tack on in case anyone finds this later, I measured the "time to first step" ie. the time elapsed between M577 P1 and the first step of G1 Xxxx and am seeing 13 ms on average. My test setup was an Arduino with interrupts and wired to the input (photointerruptor in my case) and the X step pin on the duet.

So I believe you are implying that the move queue will not get filled while waiting on M577? This is my current understanding.

Does sending the G1 Xxxx M400 as a single line matter if printing from an SD card?

I completed some initial testing and so far things look promising. See this video for some quick footage. This may be useful to other machines that need to synchronize with an external trigger.

; setup 
M950 J1 C"!ext.e2stop" ; photo interruptor which goes low when saw is at top of stroke
G91

M577 J1 ; wait for saw to reach top of stroke
G1 Y1 F480 ; forward 1 mm in Y
M400 ; wait for moves to finish
; repeated 4 times in each test

This does require generating gcode with each move chopped to the length desired to move with each downstroke as well as executing that move at a feedrate so that the move finishes in the time for a single down stroke. In this test we are moving 1mm at 480mm/min so the move should last 0.125s (roughly) and the saw is moving at 4 Hz so a half period is also 0.125s.