Bug in resume logic after a heater fault ...
-
I was going to put a bug report in for this, but the prompts in github said to post in the forums first. I'm pretty confident this is an incorrect behavior.
Its pretty easy to reproduce...
- Start a print
- Wait on a tool or bed to hit temperature via M190
- Trigger a temperature fault
- Clear the fault
- Resume the print
- Note that the resume happens on the next gcode, and the print does not wait for temperatures to come back up
This happens to me pretty frequently, because I have a 120v bed heater on a separate power switch, and I invariably forget to turn it on when I first print something in a given day. After clearing the fault, and resuming the prints, the system just continues as if the bed was already to temperature.
I'm assuming this happens because, in normal operation, a pause occurs at the end of a gcode operation so you wouldn't want to continue, but in the case of a long-running one where the system and not the user triggers the pause, you really want to restart the long-running gcode.
My first thought, as a work-around, was to just put an M116 in the resume.g, but the fact that its not there by default makes me wonder if that's a reasonable work-around.
-
@dotorg said in Bug in resume logic after a heater fault ...:
My first thought, as a work-around, was to just put an M116 in the resume.g, but the fact that its not there by default makes me wonder if that's a reasonable work-around.
I think this is the most reasonable workaround. The user is in control of what happens on a resume. Having a M116 in there makes sense to ensure your temps are what they should be.
In 3.4 you also have the events system to handle faults like this.
https://docs.duet3d.com/en/User_manual/RepRapFirmware/Events
-
@dotorg I think that's a reasonable workaround. On machines with multiple nozzles, it is common to put the current tool in standby in pause.g. It gets reactivated automatically when you resume. There is normally a M116 command in the tpost#.g file that waits for temperatures to be restored when this happens.
I will log this as a probable bug.
-
@dotorg To add to what @Phaedrux has said, you need to bear in mind that duet boards and firmware are used by a variety of people using different applications such as clay (and even concrete) printers and CNC subtractive machines and routers. That's why the focus is more on giving users complete control as to what happens with things like pause and resume, rather than setting this behaviour in firmware. An M116 in resume.g would work well for a 3D printer but might cause odd or unpredictable behaviour for other types of machine which may, or may not have heaters.
-
Sorry, guys. For some reason I never got a notification about any replies to this.
Just to clarify what I was talking about, the behavior I was claiming was a bug was not the lack of resumption of waiting for the heater. My work around would fix that particular problem.
The bug was that the system resumes on the gcode statement after the one that was executing when the fault happened. That means, in practice, a gcode is going to get skipped. In my example case, it was an M190, but any command that failed during execution would be skipped.
In programming parlance, it'd be like a return-from-interrupt incorrectly incrementing the program counter when pulling it back off the stack, causing an instruction to be skipped. Sure, you could say "hey, I'll just add the instruction that's being skipped into my ISR", but that's not really addressing the issue.
-
@dotorg I think pausing because of a heater fault while M190 is being executed is a special case, and you will find that if the pause happens during any command except one that waits for a temperature to be reached, it will resume at the correct command.
-
@dotorg I've implemented a fix which should be included in 3.5-b4.
