g2
g2 copied to clipboard
Potential new Marlin code to add: M400
While poking around the Printrbot website(s), looking for info on which of their products use g2core, this problem showed up:
It looks like Octoprint uses M400, which we don't yet recognise.
That seems to be a print queue related command, something like "keep printing, but stop accepting new G-Code until the queue is empty".
Not seeing any support for it yet in what seems like the right code area.
This might be something to look at as a future feature. :smile:
(and probably other new Marlin M codes related to this)
The behaviour described by the M400 doc sounds similar to the behaviour desired in #138 for G4P0.
Thanks for filing this, Justin!
You're welcome @BDFife. :smile:
This one is confusing to me. I’m not sure what M400 is expected to do. It looks like a workaround for a badly thought out planner.
http://marlinfw.org/docs/gcode/M400.html
Their example doesn’t make sense. M5 would always happen after the moves described before it.
What are we expected to do? We could ignore it I guess.
Yeah. Reading the description page, it sounds like a workaround command for M5 perhaps operating asyncronously or similar.
In the example, I think after the M400 there's an implied wait by Marlin for the planner to finish executing all commands. When this wait start it somehow blocks - not accepting new G-Code. After all the moves in the planner have been executed, Marlin unblocks the input channel so the M5 is then accepted.
For our implementation, where M5 is executed in the planner order given... it seems like M400 could be a no-op (ignored) and things would work.
We'll probably want to ask the Octoprint people though (easily done), just in case we're misunderstanding something. :smile:
So after some digging I found that M400 is acting in place of watching state in the status reports - IOW when in Marlin protocol the OK for the M400 won’t come back until motion has stopped.
Any progress on this or the OpenPNP related one?
The behaviour described by the M400 doc sounds similar to the behaviour desired in #138 for
G4P0.