cannot pause print with gcode

[jon-daemon]

I have a gcode file to be executed before each print (to clean my nozzle and prepare the surface for printing) and I use M0 command to pause the printing process inside this file.
Since the last update these M0 commands are not executed properly. The message after M0 is not displayed on the screen, the next command (M104) is exexuted without resuming print and I have to resume print from octoprint to execute the next G1 commands.

Also when I was able to pause my printer with M0 command I had to resume with octoprint. Other programs allow me to resume with the rotary encoder on my LCD screen.
What could I do to slove this?
Thank you,
John

[GitIssueBot]

Hi @HackerMagnet,

It looks like there is some information missing from your bug report that will be needed in order to solve the problem. Please take a look at the Contribution Guidelines which will provide you with a template to fill out here so that your bug report is ready to be investigated (I promise I'll go away then too!).

If you did not intend to report a bug, please take special note of the title format to use as described in the Contribution Guidelines.

I'm marking this one now as needing some more information. Please understand that if you do not provide that information within the next two weeks (until 2016-08-28 13:50) I'll close this ticket so it doesn't clutter the bug tracker. This is nothing personal, so please just be considerate and help the maintainers solve this problem quickly by following the guidelines linked above. Remember, the less time the devs have to spend running after information on tickets, the more time they have to actually solve problems and add awesome new features. Thank you!

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being, so don't expect any replies from me :) Your ticket is read by humans too, I'm just not one of them.

[foosel]

Cannot reproduce, tested with

M117 before pause
M0
M117 after pause

OctoPrint paused the print after sending the first M117 line and on resume sent the second M117. M0 is not sent to the printer (and it never was since the very first preview versions of OctoPrint from back in 2012), since pausing and resuming of streamed files is something that needs to be fully handled on the host side due to how the whole protocol of printer firmwares works. It's not possible to react to encoder clicks from the printer side without firmware extensions which for example utilize action commands to tell OctoPrint that something happened on the printer, the regular serial protocol simply does not allow for that kind of bidirectional communication.

In a nutshell: Everything working as expected. Impossible to debug further without a filled out ticket template, so either provide that (including octoprint.log, the contents of your terminal tab, a demo GCODE file) or the ticket will be closed.

[jon-daemon]

What were you doing?

Having issues with M0 command

What did you expect to happen?

Sending this command:
M109 S140 M0 Resume When Ready M104 S188
I wanted to set the temperature at 140˚C, wait until reached, display the message "Resume When ready" and then set it at 188˚ after resuming the print.

What happened instead?

I reinstalled everything and now it seems M0 pauses my print job but the next command is always executed.(like M104 S188 above). Also the text after M0 is not displayed on the screen. (I also tried to remove this text with no luck. The next command is also executed).

Branch & Commit or Version of OctoPrint

Version: 1.2.15 (master branch). I use Octopi 0.13.0. I have already posted this issue on Octopi page but I was guided to post this here since it's an OctoPrint issue.

Printer model & used firmware incl. version

Prusa i3 with Marlin 1.1.0-RC6

Browser and Version of Browser, Operating System running Browser

Safari 9.1.2 on Mac OS X 10.11.6

Link to octoprint.log

http://pastebin.com/PvYYw3Mp

I have read the FAQ.

[foosel]

M0 doesn't display text and I'm not aware of any firmware derivatives where that would be different. Also, as already said, M0 doesn't get sent to the printer (and that's behaviour unchanged since the very first release back in late 2012) but instead is used as a pause marker.

Displaying text on the printer is what M117 is for (which you'd need to place before the M0 command).

You still haven't provided the contents of your terminal tab. I did another test with

M109 S140
M117 Resume when ready
M0
M104 S188

and this time could reproduce the issue though. Will look into it. In the future though, please provide all logs you are asked for. Having to run after that kind of information takes up time better used for fixing bugs and adding new functionality. Thanks.

[jon-daemon]

Link to contents of terminal tab or serial.log

http://pastebin.com/MNHCBrC3

I thought M0 could show text on the screen. I tried that with pronterface and M0 showed the text next to it. Also with pronterface it is possible to resume with the rotary encoder on the printer. How did they accomplish that?

[foosel]

How did they accomplish that?

Probably by actually sending the M0 to the machine, thus inducing a complete block of the communication indistinguishable from a printer that has simply vanished until the user presses the button. This is not a good idea since you do not know if you are still talking to a printer or not, can't query the printer state at all ("the temperature graph doesn't update"), can't issue any commands etc. You basically make the printer controller stop responding completely until an arbitrary button is pressed (or not pressed, in case the user doesn't happen to be physically able to). Works if you only want to stop and wait? Yes. Works if you actually want to DO anything during the pause (e.g. filament changes for multi material printing? Not at all. Good idea for a host that's supposed to first and foremost provide reliable remote access? Definitely not.

I thought M0 could show text on the screen

Quoting http://reprap.org/wiki/G-code#M0:_Stop_or_Unconditional_stop:

M0: Stop or Unconditional stop

Parameters:

This command can be used without any additional parameters.
Pnnn Time to wait, in milliseconds
Snnn Time to wait, in seconds

Example:

M0

The RepRap machine finishes any moves left in its buffer, then shuts down. All motors and heaters are turned off. It can be started again by pressing the reset button on the master microcontroller, although this step is not mandatory on RepRapFirmware. See also M1, M112.
The Marlin Firmware does wait for user to press a button on the LCD, or a specific time. "M0 P2000" waits 2000 milliseconds, "M0 S2" waits 2 seconds.

Nothing about a message. Firmwares SHOULD however also shut off the motors and heaters according to that definition, which would most likely not be what you desire when performing a pause mid-print (e.g. to change the filament), since with the motors shut off it's easy to lose the position, and having to reheat also is usually undesired. Might be that some firmware variants also support sending a message with M0, however sticking to that description actually sending an M0 to the printer would be the same as basically suiciding the connection and print job, especially since "then shuts down [...] It can be started again by pressing the reset button on the master microcontroller" can be read as "go into kill state".

Taking a look into the current Marlin code however, once again we have a case of a command being stated to do one thing in the only resemblance of a protocol definition that we have available in the community and doing another a thing entirely in at least one actual firmware implementation. In this case in current Marlin it actually does "just" stop all communication completely until the user presses the LCD click encoder (good luck if your printer doesn't have one, no, they are not mandatory). As said above, that's bad news for reliable printer communications.

So what I will do is looking into why the next command after M0 still makes it through to the printer here. What I won't do is actually sending M0 to the printer, chances are just too high it will ruin people's prints. What I might do though is making that behaviour something to "opt-out" of, meaning a new checkbox to actually have OctoPrint send M0 to the printer - with all negative consequences attached as stated above and at the peril of operator.

Focus for fixing this ticket however is figuring out why the pause pauses "too late".

[foosel]

Figured it out, fixed on the maintenance branch (and soon the devel branch too), will be part of the next release.

[jon-daemon]

Thanks for fixing this issue

What I might do though is making that behaviour something to "opt-out" of, meaning a new checkbox to actually have OctoPrint send M0 to the printer...

That's what I'd like to see. It won't cause any troubles for me since I never pause in the middle of the printing process. I use M0 before starting to print to cover with glue the bed and clean the nozzle.

[foosel]

Fixed in 1.2.16 which was released yesterday. Also fixed on devel.

Will open a new request for the m0/m1 sending check box, closing this one.

[thewavelength]

Hey @foosel - thanks for the detailed explanation. You actually nailed what happened to me twice. As I need to pause while I am printing to change filaments: what is the alternative which I should use instead of M0?

[foosel]

@thewavelength Take a look at @ commands.