You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Prints done over USB never "finish" from Marlin's perspective. That is to say, the object completes just fine, all the way through the last commands in my slicer's "end" g-code. But, Marlin still thinks a print is going, i.e. it says "Printing..." on the display, instead of "xxxx ready", and the menus' contents are rearranged accordingly.
This happens on two different printers, running bugfix-2.0.x at commits 0ebd2f4 and b26f7fc.
I am not sure when it broke, except that it was reasonably recent (say, within the past few months).
While writing this issue, I kept trying to find some way to "clear" this confused state, and found that clicking my custom "all off" button twice in a row (with a brief pause in between) seems to work. That button executes these commands:
M104S0M140S0M107M84 XYE
But aside from the XYE (which my i3 needs, as this button needs to work for both machines), those commands are also present in the above-pasted "end" g-code and clearly should not need to be executed twice.
Normally, I'd just ignore this, but aside from it triggering my OCD 😁 it interferes with doing some things through the LCD menus, as some options are hidden from the user if Marlin thinks a print is in progress, primarily motion/jog controls.
Pause the print from the host (I'm assuming Pronterface here)
Wait.
???
Profit! 😁
Expected behavior:
Marlin should switch back to its "ready" state when the host stops sending data (other than e.g. M105 or whatever else might be used to monitor the printer's state), or at least when it has been told to turn off its heaters and fans.
Actual behavior:
Marlin just stays in its "Printing..." state, even hours after a print ends and the entire machine has cooled back down to room temperature.
The text was updated successfully, but these errors were encountered:
Bug Description
Prints done over USB never "finish" from Marlin's perspective. That is to say, the object completes just fine, all the way through the last commands in my slicer's "end" g-code. But, Marlin still thinks a print is going, i.e. it says "Printing..." on the display, instead of "xxxx ready", and the menus' contents are rearranged accordingly.
Here's the end g-code my prints normally use:
This happens on two different printers, running
bugfix-2.0.x
at commits 0ebd2f4 and b26f7fc.I am not sure when it broke, except that it was reasonably recent (say, within the past few months).
While writing this issue, I kept trying to find some way to "clear" this confused state, and found that clicking my custom "all off" button twice in a row (with a brief pause in between) seems to work. That button executes these commands:
But aside from the
XYE
(which my i3 needs, as this button needs to work for both machines), those commands are also present in the above-pasted "end" g-code and clearly should not need to be executed twice.Normally, I'd just ignore this, but aside from it triggering my OCD 😁 it interferes with doing some things through the LCD menus, as some options are hidden from the user if Marlin thinks a print is in progress, primarily motion/jog controls.
My Configurations
Configuration.zip
Steps to Reproduce
Expected behavior:
Marlin should switch back to its "ready" state when the host stops sending data (other than e.g.
M105
or whatever else might be used to monitor the printer's state), or at least when it has been told to turn off its heaters and fans.Actual behavior:
Marlin just stays in its "Printing..." state, even hours after a print ends and the entire machine has cooled back down to room temperature.
The text was updated successfully, but these errors were encountered: