-
-
Notifications
You must be signed in to change notification settings - Fork 19.3k
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
[BUG] M25/M125 Pause behavior #20969
Comments
+1 I'm just noticing the same issue :-/ |
Could you share your configuration files? |
@jmc5113 Could you try if the issue is still present on the latest bugfix-2.0.x? |
same thing happened on bugfix-2.0.x. was that expected to fix it? |
From the dbg output it looks like extra commands are being executed before it actually pauses... echo:M117 Place weights in slots and resume printing |
and when it does pause, I can't use the display to unpause it. I have to use M24 from serial console. |
Also when I put in M24, it initiates the purge sequence, which I do not need as I'm only trying to pause. |
It's best to test the latest bugfix-2.0.x, not to work for nothing. |
just discovered... M125 P1 // will move to park and pause and show the correct prompt on the screen. |
Still here. |
NOTE: |
Marlin/Marlin/src/gcode/sd/M24_M25.cpp Lines 91 to 97 in 2f1fd4b
@thinkyhead Thank you for looking into this. |
|
Was there some point in the past when these commands were behaving better? If so, how recently did this bad behavior start to appear? The reason I mention that |
If I remember it correctly, it behaved like this from the start when I switched from 8bit 1.1.x to 32bit 2.0.x at around 2019. Dec. |
The prompt must be dismissed by a host prompt or by |
Is there a better way to test the pause behavior to get more information? |
I don't quite understand the question.
/**
* M125: Store current position and move to parking position.
* Called on pause (by M25) to prevent material leaking onto the
* object. On resume (M24) the head will be moved back and the
* print will resume.
*
* When not actively SD printing, M125 simply moves to the park
* position and waits, resuming with a button click or M108.
* Without PARK_HEAD_ON_PAUSE the M125 command does nothing.
*
* L<linear> = Override retract Length
* X<pos> = Override park position X
* Y<pos> = Override park position Y
* Z<linear> = Override Z raise
*
* With an LCD menu:
* P<bool> = Always show a prompt and await a response
*/ |
That said, |
I see that if code was added to |
Bug Description
Pausing an SD or serial print has unexpected results.
Test results:
SD printing
Same as M25/M125
Serial (USB) printing (via Pronterface) or gcode sent manually through serial (USB)
Same as M25/M125
Same as M25/M125
When the "Press Button to resume print" message is shown on the display sending M24 to the printer has no effect.
Configuration
Printer: Ender 3
Board: SKR Mini E3 v1.2
Firmware: STM32F103RC_btt, Bugfix-2.0.x (c74f972)
Configuration files: Configuration.zip
Requirements
Steps to Reproduce
M25/M125
,M25 P0/M125 P0
,M25 P1/M125 P1
in it or send it manually via serial (USB) in mid printM24
to the printer and/or use the display prompt to resume the printingExpected behavior:
M25/M125
orM25 P0/M125 P0
should not show display prompt (unless the code explicitly says so) and wait forM24
, which should resume the print (without any display interaction?)M25 P1/M125 P1
should show display prompt (unless the code explicitly says otherwise) and be able to resume the print through the display (and withM24
too?)Actual behavior:
See "Test results" above, but in short:
M25/M125
orM25 P0/M125 P0
doesn't show display prompt and waits forM24
(as it should), but after sendingM24
to the printer the display is still needed to select "Continue" in order to resume the printM25 P0/M125 P0
shows display prompt and the print can be resumed through the display (but not withM24
(?))M25 P1/M125 P1
shows display prompt and the print can be resumed through the display (as it should) (but not withM24
(?))Additional Information
This issue is connected to #19870
The text was updated successfully, but these errors were encountered: