Heaters turn off after filament change
Have a Stacker S4 and Repetier Server 1.1.2. I updated a while back from 0.9?.??. Everything seemed to work but recently I ran out of filament on one of the heads. Clicked the control to reheat the head to change filament which worked fine. Changed filament, head at working temp. Clicked on control button to restart. Print restarted but heaters turned off. Tested a few times to see if this problem repeated and it did. Updated to 1.2.0 but no change. Is this a known issue? I'd assume this was a stacker problem except before I updated the Repetier Server (on a Raspberry Pi 4) I had no issue.
Comments
Do you mean continue button with restart?
Will test on my server, but it should of course restore old temperature before continuing the print.
At the Repetier end it does not seem to offer any functionality to change filament. Just shows the stop/ pause buttons and I did try hitting pause with the idea that I could "un-pause" it after I resumed at the Stacker but there seems to be no response until after I resume at the Stacker.
I've tried resuming after filament has been out a while and heads are cold and immediately after the filament runs out. In either case the normal routine is: Filament runs out, gantry homes, heads turn off. Press control knob to re-heat heads. Change filament. Purge heads by turning knob. Press knob to resume printing. The heads cool down at filament out, heat up for the filament change and stay hot until printing is resumed at which case I see a M104 S0 T0. Of possible note, when filament runs out it shows up as a jam if that makes any difference to Repetier. As far as I know this has been normal for the stacker.
M115
but I think it is V1.
Yes jam and out of filament is not differentiated in repetier-firmware.
You should not try to pause in server when firmware already has forced an internal pause. It would store temperature when you hit the button and as you describe it is 0 from firmware config, so on continue from server it will set 0. If you do not pause in server at all, it will not send anything on continue.
Need to check if I have a printer that behaves the same to simulate that. If you recreate this with a logging enabled and post the log around the that would be a big help I guess.
Here's what I believe is the relevant part
Recv:10:11:17.156: Set output: 13 to 255
I think I have a solution for this I can implement for next release.
Thanks again.