G4 not dwelling with non-movement commands
G4 will not dwell if surrounded by non-movement commands.
Example:
G0 X10
G4 P4
G0 X0
M30
Will dwell correctly.
M3
G4 P4
M30
Will not.
Added this from Ted Hall:

So this is an inadvertent change of behavior. "Cycle end" (which happens when the queue empties and there is no more motion on the steppers) used to do a full M0 as a queued command, which is unnecessary and complicated handling of the M2/M30 code that does need that (and more).
So, when I cleaned it up, I accidentally forgot the immediate status report, so stat:3 isn't immediately shown like it should.
Also, G4 isn't correctly preventing the stat from changing to 3 before the dwell is over like it should, instead it's actually changing it immediately, so that during the dwell, the stat shows 3 which it shouldn't.
Also, an M30 at the end of a job might end with an stat:3 instead of an stat:4, which is what you get when you send an M30 after all motion has stopped and you're already at stat:3.
I'm looking into how to make the dwell hold changing the stat, but it's tricky to not create other unexpected side effects.
One more thing: Watching for stat as you see is very tricky, and for programmatic waiting for motion to come to a certain point in the system we recommend using mark. It takes a number, and simply stores the last one given. By default that's 0. You add that to your status reports and you see when something has reached that part of your gcode (when delivered with an M100). An example:
(> means sending, and [[<…]] means timestamped response)
>M100 ({mark:0}) ; clear mark to zero
>g0 x10
>G4 P5
[[<1603079542488]]{"r":{},"f":[1,0,24]}
[[<1603079542489]]{"r":{},"f":[1,0,7]}
>M100 ({mark:1}) ; set it to 1
[[<1603079542493]]{"r":{},"f":[1,0,6]}
[[<1603079542494]]{"r":{},"f":[1,0,30]}
[[<1603079542617]]{"sr":{"posx":2.13147,"vel":3284.31,"stat":5,"mark":0}}
[[<1603079542871]]{"sr":{"posx":10,"vel":0.02}}
[[<1603079545315]]{"sr":{"vel":0,"stat":3,"mark":1}}
As you can see, after the motion and the 5-second dwell complete, the mark turns to 1.
For mark any 32-bit integer value will suffice, but repeated values won't trigger a status report, as the status report is only showing changed values.
-Rob
Will check out "mark"
I'm still digging into this. I have found a case where G4 if it's the last thing sent from the controller (and thus the last thing in the buffer) will get skipped. I'm still analyzing
👍