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

  • I think, that's normal. Because the program is waiting until the temp is reached and it only reads the temp and no killing command.
  • Yes, the firmware is not accepting new commands. Many firmwares do reset on connect so emergency stop might stop faster in that case.
  • edited October 2017
    are you saying it is a function of repetier or marlin?
    seems like it should accept commands to kill it without having to do an emergency stop, don't you think?

  • Yes that is what I'm saying. The problem is that M109/M190 are blocking or let's say they wait until finished and only afterwards new commands get parsed. And since we send commands until buffer is full to optimize speed and quality, the firmware can not know this and there is no way to tell. Maybe in future we will be able to find a solution for this. But only for emergency stop. Stopping a print just means not sending more of the print and instead sending the stop print gcode. And this requires keeping the command order which includes finishing heatup.
  • OK that was an either Repetier or Marlin question so I am still not sure what you are saying.
    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.
  • The marlin parser has emergency detection if following commands that fit into buffer contain that command. The problem is that at the moment you decide to do emergency stop, that buffer is already full and host knows it so it can not send the command before firmware finishes the M109 to empty a bit of the buffer. Then it gets the next (emergency stop) command. But as I also said stopping a print does not send emergency stop. On the other side emergency button would send it but in parallel also try to reset the board, so only if the board has no remote reset function the problem with the wait will take effect at all.
  • I am not following you.
    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.
  • There are in deed many conflicts here. Host shows it as it enqueues the commands, so what you see is the future state once commands are processed. Host uses a system for faster communication to improve print quality, which means input buffer is full and host can not send extra commands. I have some ideas here. Not so easy since old marlin versions do handle this completely different and still need to work and you can not see if the version is there.
  • Repetier reads version info (maybe not enough to figure it out). If one is not watching the temp (which is not terribly obvious), you would believe the heater is off.

    OH, I guess the emergency stop does do a hard reset but then immediately reconnects.

  • Yes to emergency stop.

    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.
  • this is what Marlin says

    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.

  • I know what they mean as I invented that report:-)

    http://reprap.org/wiki/Firmware_Capabilities_Protocol

    I see they have meanwhile added the description for it. 
Sign In or Register to comment.