Spurious heater faults again

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.

deckingman

@ctilley79 If you have a reasonably thick bed (which you should have) then having the thermistor at the junction between the heater and the bottom of the bed is the worse place you can put it. When you turn the heater on, the temperature at that junction rises rapidly, so it turns off. Then when the temperature at the junction drops, the heater turns on but soon turns off again. Meanwhile, the temperature at the top of the plate is still cool. This constant one-off cycling plays havoc with the PID tuning and results in excessively long warm up time (for the top of the bed). What I did was drill a small hole in the edge of the bed, as deep as possible and as close to the top surface as possible, and put a thermistor in there. No more probs.....

deckingman

@tinchus This doesn't answer your question but using 88% pwm will not limit the power to your heater. It just means that it'll have full power for 88% of the time.

ctilley79

@deckingman said in Spurious heater faults again:

cycling

I had zero problem for 2 years. The pid tune seems to compensate well enough, until 3.4.2 RC2. Duet provided instructions for using these types of heaters with built in thermistors so I know the less than ideal placement of the thermistor isn't the issue. I do have to heat soak my chamber for a good 30 minutes to allow the heat to transfer to the entire bed. But it worked. Not ideal, but it worked until upgrading to RC2.

Regarding PWM. If I recall, depending on the PWM frequency, it will result in slowing down the heating process via pulsing from high/low 60% of the time.

deckingman

@ctilley79 said in Spurious heater faults again:

Regarding PWM. If I recall, depending on the PWM frequency, it will result in slowing down the heating process via pulsing from high/low 60% of the time.

The PWM value is the percentage of time spent "On" vs "Off". So if you used a value of 0.6, then it would indeed spend 60% of the time on (at full power) and 40% of the time off. The PWM frequency is how fast it cycles. So for example if you used a frequency of 100 Hz, that would be one cycle every 10 milliseconds. So within each 10ms period it would be on for 6ms and off for 4 ms.