Pause Cancel extruder not heating up on next print 3.2
-
I"m not sure where to put this, so please move it wherever it should land..
This is in reference to release 3.2 running on a Duet 3 / RPi.
After canceling a print, the extruder is not heating up for the next print started, yet the print starts as if it's hot. The only work around I've found is an emergency stop or reboot.
Steps to reproduce:
- Start a print
- Cancel it after it has started
- Click Print Again or select another job to run (from either DWS or PanelDue)
- Note the hotend is not enabled and the print starts with the xtruder cold
I've tested this enough time to know that it is repeatable on my machine. If it cannot be recreated, please let me know what logging you need me to provide to diagnose what is happening. Thanks
-
Hi,
What does your pause.g macro look like?
What does your cancel.g macro look like?
Thanks.
Frederick
-
@oozeBot As it happens I had only just started a print, so I cancelled and restarted (from DWC)
No problems on Duet 2 Wifi running RRF 3.2 -
Thanks - this machine is a new build and was missing both pause.g and cancel.g. Adding both corrected the issue, however neither file contain any gCode - they are simply null.
Strange this results in such an odd side effect..
-
@oozeBot Odd indeed - or maybe not. TBH, I've always had problems starting a print after cancelling a prior one. That's regardless of what commands pause.g and cancel.g contain and it goes back years. I've got in the habit of always cycling power if I ever cancel a print. Otherwise, strange and unpredictable things have always happened. It might be fixed now but it's another "work around" that I've got in the habit of doing......
-
In regards to what @deckingman posted:
Using in the past firmware 2.51 and now 3.1.1, I've never had a problem using pause/cancel/print again
I would guess if it is not working for @deckingman (or others) it would be that something is done during the reboot that is not being done when starting the print again.
Frederick
-
@oozeBot said in Potential bug in release 3.2:
Thanks - this machine is a new build and was missing both pause.g and cancel.g. Adding both corrected the issue, however neither file contain any gCode - they are simply null.
Strange this results in such an odd side effect..
Thanks for reporting this, it's still a bug.
-
@fcwilt said in Potential bug in release 3.2:
In regards to what @deckingman posted:
Using in the past firmware 2.51 and now 3.1.1, I've never had a problem using pause/cancel/print again
I would guess if it is not working for @deckingman (or others) it would be that something is done during the reboot that is not being done when starting the print again.
Frederick
That is obviously the case. I guess running M98 P "config.g" might also have the same effect as cycling the power.
Or indeed, it might be fixed. Like I said, it started being an issue for me years ago. That is to say, strange, unpredictable and inconsistent behaviour after cancelling a print, so I've just got used to always cycling the power on the rare occasions that I cancel a print. If I do that, I know for sure that the next print will start without issues that I have experienced in the past. -
Interesting, I frequently cancel a print and then start it again without power cycling. I have a cancel.g file so that the temperatures are maintained after cancelling a print.
-
@dc42 said in Potential bug in release 3.2:
Interesting, I frequently cancel a print and then start it again without power cycling. I have a cancel.g file so that the temperatures are maintained after cancelling a print.
For my use case, I would always want to turn off heaters if I cancel a print, so that might be significant. On most occasions where it is necessary (to cancel a print), it is usually because something has gone horribly wrong so I like to turn everything off. As I said, a power cycle might no longer be necessary - it's just a something that has become almost habit.
-
@deckingman said in Potential bug in release 3.2:
That is obviously the case. I guess running M98 P "config.g" might also have the same effect as cycling the power.
Well I can say for sure that on my printer, using firmware 3.1.1, cycling power is NOT needed.
I would examine your config.g file and find the commands that perhaps need to be in your "print begin" macro or whatever you do that is is equivalent.
Frederick
-
@fcwilt said in Potential bug in release 3.2:
@deckingman said in Potential bug in release 3.2:
That is obviously the case. I guess running M98 P "config.g" might also have the same effect as cycling the power.
Well I can say for sure that on my printer, using firmware 3.1.1, cycling power is NOT needed.
I would examine your config.g file and find the commands that perhaps need to be in your "print begin" macro or whatever you do that is is equivalent.
Frederick
That is not nice, neither is it clever.
I mean selectively taking a part of what I posted and selectively leaving out the rest of that same post, in order to make it seem that I said something different. Presumably you had some reason for doing so?
The part of my post that you chose to leave out says quote ....... " As I said, a power cycle might no longer be necessary - it's just a something that has become almost habit.".......end of quote.
Then again, in a post prior to that, I wrote, quote "Or indeed, it might be fixed. "
And finally in my post prior to both of those I wrote, quote"
"It might be fixed now but it's another "work around" that I've got in the habit of doing...... "
So that's THREE times that I have stated or implied that cycling the power after cancelling a print may no longer be necessary.
Presumably, by ignoring or selectively excluding those three separate statements you wanted to make some sort of point. What is that point exactly?
-
@deckingman said in Potential bug in release 3.2:
That is not nice, neither is it clever.
I was trying to be helpful.
You indeed stated that it might not be needed. I was simply pointing out that it is NOT needed. MIGHT NOT is not the same as NOT.
The fact that you needed to cycle power suggests there may be something not quite right about your "print begin" macro - or whatever it is that you use which is equivalent.
Sorry if my trying to help upset you - I will refrain from trying to help in the future.
Frederick
-
@fcwilt said in Potential bug in release 3.2:
............................I will refine from trying to help in the future.
Frederick
Thank you - that would be much appreciated.