can't kill print until hotend temp is reached
Everything works fine..............but today I started a print and realized I needed something else so I killed it. The hotend kept heating until it reached temp, then it killed. Marlin or Repetier bug?
Comments
seems like it should accept commands to kill it without having to do an emergency stop, don't you think?
What I found out is it appears Marlin has a function that does not work. And I don't understand the logic.
Supposedly, Marlin blocks further commands when M109 is issued. Obviously, it can't start printing until it reaches temp. BUT if I chose to end the print why block M112 or other commands to terminate the M109 command and stop the print? This forces me to issue an EMERGENCY STOP/printer reset, which apparently is the only thing that will work. There is an EMERGENCY PARSER in Marlin, which when enabled is suppose to parse out and pass M108, M112 commands, but it does not work. IMHO, it should be the default operation without an enable. But they have to get it to work first.
Now I guess the question is, does it not work because Repetier is also blocking these commands. If Repetier were blocking these commands, why does clicking the on/off button for the heater change the icon but does not stop the heating? None of the commands will appear in the log, but I don't know if that is because Marlin hasn't acknowledge the command or Repetier hasn't sent it.
SO, when does the command appear in the log?
What command is sent when KILL is clicked and I don't have any script entered?
Is Repetier blocking further commands after M109 is issued and temp hasn't been reached?
If so, that is the problem with Marlin's function and it needs to be fixed in Repetier.
If the hotend is heating from an m109 command then it is waiting for temp b4 continuing to process commands.
You are saying that the buffer is full at this time. So no commands can be parsed. Therefore an emergency stop must not be a 'command', because it does stop the heating. It must activate a reset and not go thru the buffer. But if the board resets it should also disconnect but it does not. But you didn't tell me what Repetier sends as an emergency stop. But then if Repetier can't send any commands why does it change the heating icon to off when I click it. Did it send the command? If it did then the buffer isn't full. If it did not then why does the icon go to off?
The way Marlin explained it to me, an M112 and M108 should get thru with the emergency parser activated. But then he didn't mention whether that depends on the buffer being full or not. If it depends on the buffer then that is a bad design - no wonder it doesn't work.
Obviously, a command needs to get into the buffer in order to be processed in any way. If they are going to allow an M112 command thru, they need to tell Host the buffer is full when there is still room for an M112 and Host should know that so it will send it even though it has the buffer full flag.
Sounds like there may be a problem on both ends and a communication problem (as in protocol). If you guys talk, now might be a good time.
OH, I guess the emergency stop does do a hard reset but then immediately reconnects.
Version doe snot say anything. Many vendors completely rename the name and version, so that is no reliable way to detect a feature. And unless there is a reliable way to detect a feature we just do not use it for safety. I have an idea to not use full buffer for sending M108/M112. That would reduce efficiency but enable what you need. Question is if the price is too high or not. Or if we can lower buffer usage only when slow commands are in the queue. That way we get a good compromise I think.
With the 'emergency command parser' we did our part. We can receive, evaluate and execute M108, M112, M410 at every time, even when all buffers are full - and try to inform the hosts via the EXTENDED_CAPABILITIES_REPORT about this possibility.
Now the hosts have to do their homework.
I have no idea what that means, maybe you do. I also have no idea what an M410 command is.
http://reprap.org/wiki/Firmware_Capabilities_Protocol
I see they have meanwhile added the description for it.