Spurious heater faults again

ibash

Back once again to report heater faults. This time I think the issue is that my room temperature is too cold, even though my printer is enclosed, it's not perfectly sealed.

I don't need help troubleshooting, just wanted to report that the duet firmware is still buggy here.

OwenD

@ibash
In this case it's hard to agree that it's a bug.
There is a minimum temperature to catch cases where a thermistor fails.
That minimum temperature is configurable.
I believe the default is 5 degrees.
I my case the ambient temperature would only get that low once or twice a year (outside), and on those mornings I wouldn't be starting a print in the shed . Most of the time it never gets below 9-15 degrees so 5 is a good value for me.
Try setting a minimum alarm temp using M143

ibash

@owend

from a user point of view it's a bug. It says the temperature is rising too slowly when in fact it's rising just fine. This is the #1 issue affecting reliability for me.

dc42

@ibash the "temperature rising too slowly" detection is intended to catch the situation in which the thermistor becomes thermally decoupled from the heater, for example when the thermistor falls off the heater block, or the bed heater element becomes detached from the bed.

I am aware that some users are getting these error reports when nothing is amiss. If you are affected, please do the following:

Make sure you have run tuning on that heater. Tuning not only allows the PID constants to be calculated, it also informs RRF of the normal behaviour of the heater, which RRF needs in order to judge whether the temperature is rising too slowly.
Make sure that the heater tuning parameters have been fed back into the configuration. You can run M308 H# (where # is the heater number) to see what parameters are being used.
If the problems persist, please post in this thread with the following information:

The type of heater (bed, hot end, chamber, other)
The M308 parameters you are using for it, evidenced by a M308 response (see #2 above)
The temperature graph produced during M303 tuning, and the results displayed when tuning completed.

So far as I am aware, spurious "rising too slowly" messages are only seen on bed heaters that take a long time to heat up; on chamber heaters where the temperature sensor is a long way from the heater element; and on systems where there is significant noise in the temperature reading.

dc42

Is nobody getting a problem with spurious heater faults any more?

trobison

@dc42 I get them. I have a E3D toolchanger / duet 2 / RepRapFirmware for Duet 2 WiFi/Ethernet version 3.4.1 (2022-06-01 21:05:28) running on Duet Ethernet 1.02 or later + DueX5v0.11.

I seem to get this issue more often when I slice with Cura, less with SuperSlicer. This is strange, but if I heat the extruder up via console to the temp I am going to use (and bed), then submit the job, the issue doesn't happen as often.

I am printing now, but yesterday the same sliced file would not print, mid way into the print I got the heater issue. I "preheated" the extruder and let it set for several min, then committed the job and it's working. This job was sliced with Cura. It's strange, I can't explain it, but it is repeatable.

Regards,

deckingman

@trobison Can you upload the Cura gcode file to something like Dropbox or Google drive and post a link here. Also the superslicer version if you say it behaves differently. And let us know exactly what the heater error message is. Without that information, we can only speculate on what the cause might be.

trobison

@deckingman No problem. This is the cura version. https://www.dropbox.com/s/gc7tmprbw0pgb2q/CFFFP_xyzCalibration_cube.gcode?dl=0

and the superslicer version. https://www.dropbox.com/s/c3r9vwbow25h1om/xyzCalibration_cube.gcode?dl=0

This is a test print using Tool 2 with 0.6 nozzle.

deckingman

@trobison The Cura version does this............

T2
M82 ;absolute extrusion mode
; PRINTER START G-CODE START
M140 S60 ; Set bed temperature
G10 P0 S210.0 ; Set tool 0 active temperature

So you are selecting tool 2 but then setting the active temperature for tool 0 (G10 P0...).

The super slicer version first sets the active temperature for tool 2, then later on it selects tool 2.

This explains why you have to pre-heat tool 2 when using the Cura file (because the start code heats a different tool to the one you are printing with). It's difficult to know what exactly is going on the the super slicer version because there are a smattering of "T-1" commands but it looks like it might work because you set the standby temperature first.

Are you using tool change macros (tpre, tpost and tfree)? If not then you ought to. If you are then can you post them as well.

On balance, I'd say that your heater faults are due to slicer settings and/or configuration files, rather than any firmware issues.

Nuramori

@dc42 as soon as I replaced my thermistor with a pt1000 I haven’t had one since. Before I would get one with almost every print.

trobison

@deckingman Here are my tool changing configs.

tpre2.g tpost2.g tfree2.g

Cura likes to level the bed with a tool attached, and the toolchanger probes the bed without a tool. Anyway, the heater fault only happens with Cura, and not SuperSlicer.

Regards

deckingman

@trobison said in Spurious heater faults again:

,.......Anyway, the heater fault only happens with Cura, and not SuperSlicer.

.....and I've explained the reason why. It's because the start code that you've set up in Cura sets the active temperature for tool 0, but then changes to tool 2. Whereas the start code that you've set up with superslicer, sets the active temperature for tool 2.

Edit. To expand on that, unless you "tell" the firmware otherwise, the active and standby temperatures for all tools will be zero. So after you set the active temperature for tool 0, you then change to tool 2 so the active temperature will drop to zero. Then when you try to use that tool, you'll get a heater error (because it isn't being heated).

You might want to consider doing something similar to what I do, which is to set the active and standby temperatures for all tools apart from tool0 in config.g. Then whenever you select any tool other than tool0, the correct temperatures will be set automatically without relying on the slicer.

trobison

@deckingman How do you handle different materials (temperatures)? Thank you for explaining how cura is handling temperature commands.

deckingman

@trobison said in Spurious heater faults again:

@deckingman How do you handle different materials (temperatures)? Thank you for explaining how cura is handling temperature commands.

This is going to be long and complicated..............

Firstly, I don't have a tool changer. Instead I use my own hot end design which has 6 inputs and two heat zones and a single nozzle. So all 6 inputs are loaded with filaments at all times. By default, these filaments are PLA, ABS, TPU, PolySupport, ASA and PA6-CF (carbon fibre nylon). The hot end is designed with a second heat break such that when printing high temperature filaments such as PA6-CF at sya 290 deg C, none of the other loaded filaments will ever be heated above 210 deg C.

My tool definitions all use the same two heaters but each tool uses a different extruder. I call a separate macro from my config.g to set the active and standby temperatures for all filaments. This enables me to easily change one of more of the default filaments. The default "Set Tool Temperature" macro is as follows.

; Set tool temperatures

M568 P0 R0:0 S0:0; PLA - used for homing and as initial tool so set temperatures to zero
M568 P1 R255:210 S255:210; ABS
M568 P2 R210:210 S210:210; TPU95-HF
M568 P3 R230:210 S230:210; Support
M568 P4 R250:210 S250:210; ASA
M568 P5 R290:210 S290:210; PA6-CF

You'll note that the active and standby temperatures are the same for each tool (filament) because all tools share the same heaters. You'll also note that the second heat zone is set to 210 deg C and the secondary heat break ensures that it will never get above this temperature. So low temperature filaments will never get "cooked" when printing high temperature filaments.

You'll also note that I'm using the latest M568 command to set the tool temperatures because G10 is deprecated and will likely get removed at some time in the future.

I don't by default set the temperature for tool 0 when config.g is loaded. This is because I have "T0" in my config.g and I don't want that tool to start heating as soon as the printer is turned on. I use the nozzle as a probe so when I home Z, I heat the nozzle to around 140 deg C just to soften and plastic that may have oozed.

I did say it would be long and complicated but essentially, what I'm doing is setting all the active and standby temperatures, for all tools except tool 0, when the printer is turned on. So then whenever a different tool is activated, it will automatically get heated to the correct temperature.

This might help - from the Wiki..........https://docs.duet3d.com/en/User_manual/Tuning/Tool_changing

quote ...........

"
If Tn is used to select tool n but that tool is already active, the command does nothing. Otherwise, the sequence followed is:

If another tool is already selected, run macro tfree#.g where # is the number of that tool.
If another tool is already selected, deselect it and set its heaters to their standby temperatures (as defined by the R parameter in the most recent G10/M568 command for that tool)
Run macro tpre#.g where # is the number of the new tool
Set the new tool to its operating temperatures specified by the S parameter in the most recent G10/M568 command for that tool
Run macro tpost#.g where # is the number of the new tool. Typically this file would contain at least a M116 command to wait for its temperatures to stabilise.
Apply any X, Y, Z offset for the new tool specified by G10
Use the new tool.

"

trobison

Thank you very much for taking the time to explain that. This is very useful. I have set my initial temperatures in the config.g file. Once again, thank you for your time.

Phaedrux

@dc42 Related thread: https://forum.duet3d.com/topic/29113/pid-d-bed-keeps-failing-on-heat-up?_=1660537110945

Tinchus

Im @dc42 . My problem is with the heated chamber. after tunning and new values added, thes values eems to not work and I always get the "temp rising too slow"... even repeating the tunning, the values are the same but alter they fail.
Tunning doesnt fail, temperature is reched and tunning gives me the values. I add them to config.g.
Then these values fails

Notepad

I also appear to have started having this bug with the new firmware 3.4.0 and 3.4.1.
Bed type is a silicone heater slapped onto a 3mm plate, 400w heater.
Most common temperature for it to fail is 75°C when trying to heat to 100°C, and the bed is PID tuned.

It makes me think that the sensor is getting a momentary bad read, and the fault sensitivity is too high. Ill get a message saying something like expected temperature rate 0.9°C/s measured rate 0.2°C/s. However after looking at the temperature graph it shows the expected rate - this is why I believe the fault algorithm is slightly too sensitive.

Tinchus

Here I have the latest data from a tunning try today: it is my heated chamber

I ran M303 H0 P0.88 S120

The P0.88 is because I need to lower the power input to the resistor in order to not burn it.

The tunning finished OK:

8/17/2022, 2:39:15 PM Auto tuning heater 0 completed after 3 idle and 14 tuning cycles in 8036 seconds. This heater needs the following M307 command:
M307 H0 R0.125 K0.058:0.000 D44.76 E1.35 S0.88 B0
8/17/2022, 1:10:13 PM Auto tune starting phase 3, measuring
8/17/2022, 12:47:41 PM Auto tune starting phase 2, settling
8/17/2022, 12:25:23 PM Auto tune starting phase 1, heating up

I saved the values, I restarted the board, I checked new values are being used.

Now I try to heat the chamber and I get:

Error: Heater 0 fault: temperature rising too slowly: expected -0.02°C/sec measured -0.03°C/sec

This has happened with every try to tune PID.
The PID was working on this same chamber , same resistors, same PWM in version 3.3

Actual version is 3.4.1, board duet3 in SBC mode

ctilley79

@dc42 I'm still having this problem with 2.4.2 RC 2. When cold, the bed warms up fine. However, If I turn the heater off before the bed temp is reached and then turn the heater back on less then a minute later, the temp will rise about 10C before throwing the error.

One thing to note is I'm using a heating pad with a built in thermistor, and this type of setup results in the pad heating up well before the bed. So my guess is it has something to do with the bed being warm when the heater is turned back on and that's why the PID tune isn't seeing the values it expects. I'm not sure what changed in 3.4.2 that is causing this.