Skip to content
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

M190 and M109 may lead to zombie state #4198

Closed
miblooming opened this issue Jul 3, 2016 · 6 comments
Closed

M190 and M109 may lead to zombie state #4198

miblooming opened this issue Jul 3, 2016 · 6 comments
Labels
T: Question Questions, generally redirected to other groups.

Comments

@miblooming
Copy link

After I send "M190 S60" to Marlin from Printrun, I cannot cancel the order util the temperature of hotbed reach 60.If I don't want to wait, I have to press the RESET button on RAMPS.
If someone want to contral printer with APP in mobile phone, after "M190" or "M109" sended, he/shi cannot pause the printing task at once.Sometimes It's troublesome。
So I suggest: Marlin can deal new "M190" commond when dealing "M190". The same as "M109"

From looming

@jbrazio
Copy link
Contributor

jbrazio commented Jul 3, 2016

M190: Wait for bed temperature to reach target temp
If you don't want to wait.. M140: Set Bed Temperature

@jbrazio jbrazio added the T: Question Questions, generally redirected to other groups. label Jul 3, 2016
@thinkyhead
Copy link
Member

thinkyhead commented Jul 3, 2016

Commands that go into a loop, such as M190, M109, G29, etc., have the effect of blocking the command queue, so no further commands can be received and processed until the command is completed.

We have a request (#3611) to add a new (un-blockable) GCode to break out of some of these blocking loops, but this will require adding a more low-level check for the given command. And there is still no guarantee that a command can be received and processed while the queue is blocked, because we have to respect a full serial character buffer also. See that thread for the issues raised.

For now, until we can look at some redesign of the foundations of our command processing (preserving compatibility with host software), this is how it will have to work. I realize that M140 and M104 are not a very viable solution when printing from SD card. Sorry we don't have any better options at this time.

@maukcc
Copy link
Contributor

maukcc commented Jul 5, 2016

A patch for now is to send it a temp command that is lower then the actual temp from LCD( I dont know if this works from host), faster is the reset switch :)

@thinkyhead
Copy link
Member

@maukcc That works because commands sent from the LCD bypass the command queue.

@thinkyhead
Copy link
Member

With #4226 and #3611 merged we now have a method to break out of these loops.

@github-actions
Copy link

github-actions bot commented Apr 7, 2022

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked and limited conversation to collaborators Apr 7, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
T: Question Questions, generally redirected to other groups.
Projects
None yet
Development

No branches or pull requests

4 participants