Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

G4 not dwelling with non-movement commands #478

Open
wholetthedogsout opened this issue Oct 7, 2020 · 5 comments
Open

G4 not dwelling with non-movement commands #478

wholetthedogsout opened this issue Oct 7, 2020 · 5 comments
Assignees

Comments

@wholetthedogsout
Copy link

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.

@aldenhart
Copy link
Member

Added this from Ted Hall:

image

@justinclift justinclift added the bug label Oct 7, 2020
@giseburt giseburt self-assigned this Oct 17, 2020
@giseburt
Copy link
Member

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

@tedh-shopbot
Copy link

Will check out "mark"

@giseburt
Copy link
Member

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

@tedh-shopbot
Copy link

👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants