M577 and queued movements

[aconz2]

I've tried reading through the source code to figure this out but haven't found anything conclusive. I'm wondering if moves are queued while waiting for an M577 or if they only get queued after the M577 trigger is complete. I see that HandleGcode keeps getting called until the M577 is triggered but I don't yet have an understanding on how that interacts with the DDARing.

If moves are not queued until the M577 is complete, I'm wondering if there are any ballpark latency numbers on time from M577 complete to when the next G1 (for example) move would begin. 1 us, 10 us, 100 us, 1 ms, 10 ms?

[dc42]

When the M577 command is reached, RRF will stop processing further commands. However, moves that have already been processed and queued (for example, moves) will continue to be executed until the queue is empty.

If you want to watt for all previous commands to be completed and then to wait for a pin to be triggered, use M400 and then M577.

[aconz2]

Thank you, that is what I suspected. And do you have an idea on latency to begin moving from an empty queue?

My use case looks roughly like

G1 X1
M400
M577 P1 S1
G1 X1

I'm hoping to get a handle on the elapsed time between the M577 and the start of the next move. My guess might be something like 1000 clocks so we're looking at 1ms, does that seem reasonable?

If anyone is curious, I'm looking to synchronize the movement of a piece of wood so that moves only occur on the downstroke of a saw blade. First couple seconds of this video should give an idea.

[aconz2]

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.

[dc42]

When receiving moves and the move queue is empty, RRF waits for one of the following before starting to execute moves from the queue:

1. The main loop is called 10 times without another move becoming available. In RRF 3.3beta there is an additional configurable timeout that must have elapsed too.
2. The movement queue becomes full.
3. A command that waits for movement to finish (e.g. M400) is executed.

So one option may be to send G1 Xxxx M400 as a single line. That will ensure that the move is executed immediately.

[aconz2]

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?

[dc42]

You don't need to send G1 and M400 on a single line, but it's slightly more efficient if you do.

[aconz2]

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.