Add M400 dummy command for Octoprint workaround

[vegetablejedi]

• Octoprint calls M400 every printing job is ended.
• Fixed an issue where the M400 command was not implemented and disconnected each time.

[vegetablejedi]

I remove my PR that I did not want, and I work again to request a pull. :-)

[justinclift]

@ril3y @giseburt @aldenhart This should be ok to merge as-is yeah? 😄

[ril3y]

Rob said it will take a look at it soon. Leave it for now. Thanks!

…

On Sat, Dec 29, 2018 at 10:14 AM Justin Clift ***@***.***> wrote: @ril3y <https://github.com/ril3y> @giseburt <https://github.com/giseburt> @aldenhart <https://github.com/aldenhart> This should be ok to merge as-is yeah? 😄 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#391 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAOJMyYvcBwtr70NTg0vgDVARzFYy5NAks5u94bkgaJpZM4ZkkcH> .

[justinclift]

No worries. 😄

[giseburt]

Hello @vegetablejedi ,

Thanks for this PR. I appreciate you taking the time on this. This version is also cleaner than the last so thanks for that as well.

The only suggestion I have for this PR is that I’d prefer it not be a non-op when it’s a little more work to make it do what M400 is supposed to do.

According to the RepRap wiki:

Finishes all current moves and and thus clears the buffer.

I feel that’s slightly vague, but I interpret that as meaning that after an M400 is issued, no other gcodes will be interpreted until all previously issued commands are executed and motion is stopped. Also, since it’s Marlin, we don’t want an ok on parse but when the command is done executing. We already do similar (but not the response part) in a few other commands. More specifically, in Marlin compatibility we have the temperature commands that wait until the temperature has been reached.

This breaks down to three parts:

1. Handle the M400 command in the parser and pass it to the marlin compatibility code. Suppress the ok response.
2. Stop reading new gcode until the condition is met. The condition is two-part:
   A. All other commands issued and read up until this one have been executed.
   B. All motion is stopped.
3. Issue the ok response.

Part 1 has plenty of examples near where you already edited, so I won’t go into detail there (but feel feee to ask if it’s not clear). I would suggest using an enum in mst (see MarlinStateExtended) that is a state engine for M400 with states like idle/off, waiting, and done (response pending).

The exception to those examples being suppressing the ok, which is a little more involved and not currently handled by anything else. (Also we need to confirm that Marlin does hold the ok until motion has stopped, or perhaps it does something else?) The ok comes from marlin_response() which is called (roughly) like: marlin_response(gcode_parser(...), ...); I looked and we have the status of STAT_NO_DISPLAY reserved for this (but not used). So gcode_parser() (actually _execute_gcode_block_marlin()) would return STAT_NO_DISPLAY and marlin_response() would be modded to treat it the same as cs.responses_suppressed.

Part 2 is a little less obvious. To stop interpreting new gcode, marlin_callback() responds STAT_EAGAIN until the conditions are met.

Part 2a and 2b can be handled like homing handles the same situation, by queueing a command that calls a function that sets a flag that tells the callback that the queue is empty up to where the M400 was issued and that all previous motion has stopped. (Note the callback cannot take direct action such as writing output, it will lock up the system.)

Part 3 is just calling marlin_response() from marlin_callback() to write the ok (Which ignores the buffer it’s handed and uses it’s own, so you can pass nullptr): marlin_response(STAT_OK, nullptr); Don’t forget to reset the state engine (enum mentioned above for step 1) back to idle/off.

Do you feel like giving that a shot? Either way let us know.

Thank you!
-Rob

[justinclift]

@vegetablejedi Still interested in having this merged?

[solhuebner]

@vegetablejedi I would appreciate if we could get M400 implemented as it is also related to #138 and I would like to see G2 as a viable option for OpenPNP :)

[justinclift]

@giseburt Would it be workable to merge this now, to get things working... and improvements for the M400 behaviour could optionally be done at a later point if it turns out to be needed?