Verifying Firmware Safety Features - Duet 3 Mini 5+

flobler

@phaedrux thanks, I will re-try the tests with an active print!

the "active" and "passive" heater temperatures are not being reset to 0C
if the hotend heater throws an error and switches to "fault", the bed heater keeps heating and vice versa if there is a bed heater "fault" the hotend keeps heating

That is expected. When a heater fault occurs, you are given some time (default 10 minutes, configurable using M570) to reset the heater fault and continue the print if it is spurious. If you do not respond during that time, all heaters are turned off.

I assume this means that heaters are only reset after a heater fault with the default time of 10 minutes if there is an ongoing print from SD card, right?

One more comment: If I disconnect the heater from the hotend and try to heat it, the heater fault is being triggered after a few seconds even without a print from the SD card and without having defined the fault detection via M570 in config.g. When I try to do the same with the bed the error is not being triggered. Is there a reason why hotend and bed are behaving differently?

I will do some tests this week and report back after.

Thanks!

dc42

@flobler said in Verifying Firmware Safety Features - Duet 3 Mini 5+:

One more comment: If I disconnect the heater from the hotend and try to heat it, the heater fault is being triggered after a few seconds even without a print from the SD card and without having defined the fault detection via M570 in config.g. When I try to do the same with the bed the error is not being triggered. Is there a reason why hotend and bed are behaving differently?

From my previous response:

A normal bed heater should go into the fault state with a "temperature rising more slowly than expected" error. It will take twice the dead time (as specified by M307) for the heater fault to be raised. However, if tuning has found the bed heater to have very low power so that the maximum temperature rise above ambient at full power is less than 34C, then the check is omitted.

Could that be the reason?

flobler

@dc42 thanks for your response. I am not sure what you would classify as "normal bed heater". I am using a stock Prusa MK3 bed.

https://shop.prusa3d.com/en/mk3mk3smk3s/198-magnetic-heatbed-mk52-24v-assembly.html

I doubt this would qualify as a "very low power" heater and the maximum temperature difference at full power should be significantly higher than 34C. Am I misunderstanding maybe? Is there a way for me to find out if the tuning procedure has found it to be a low powered heater?

Also to double check I am understanding everything correctly:

The heater fault (when no heater is connected but the printer is trying to heat) should be triggered anytime, even wihout an ongoing print for both hotend and bed heaters?
The timout which cuts off all temperatures after the fault was triggered only kicks in if there is an ongoing print from SD?

Thank you!

dc42

@flobler said in Verifying Firmware Safety Features - Duet 3 Mini 5+:

Is there a way for me to find out if the tuning procedure has found it to be a low powered heater?

Yes, send M307 H0 (assuming that heater 0 is the bed heater) and tell us what parameters it reports. The product of the R and first C value is the estimated maximum temperature rise above ambient.

Also to double check I am understanding everything correctly:

The heater fault (when no heater is connected but the printer is trying to heat) should be triggered anytime, even wihout an ongoing print for both hotend and bed heaters?

Yes, unless the expected rate of temperature rise is very small, either because the estimated maximum temperature rise above toom temperature is very low (<= 34C) or the heater is already hot.

The timout which cuts off all temperatures after the fault was triggered only kicks in if there is an ongoing print from SD?

Correct. When printing from SD card, after a heater fault is raised, if the user doesn't reset it within the timeout period then the system performs an emergency stop. It also tries to turn off power via the PS_ON pin, as if M81 had been commanded.

flobler

@dc42 thanks again for the quick reply!

Here is the output:

Heater 0 model: heating rate 0.302, cooling time constant 72.5, dead time 10.44, max PWM 1.00, calibration voltage 24.2, mode PID
Computed PID parameters: setpoint change: P56.6, I2.058, D413.7, load change: P56.6, I2.930, D413.7

That does indeed indicate it is considered to be a low powered heater if I understand you correctly.

What is interesting though is, that my other printer which I finished building later and which I have no tested the heater fault with (same bed is used there) has a significantly higher value for C

Heater 0 model: heating rate 0.279, cooling time constant 456.0, dead time 11.53, max PWM 1.00, calibration voltage 23.6, mode PID
Computed PID parameters: setpoint change: P55.5, I0.765, D447.8, load change: P55.5, I1.683, D447.8

It looks like I should re-run the PID routine and re-test. I will do that and report back.

dc42

@flobler said in Verifying Firmware Safety Features - Duet 3 Mini 5+:

Heater 0 model: heating rate 0.302, cooling time constant 72.5, dead time 10.44, max PWM 1.00, calibration voltage 24.2, mode PID

72.5 seconds would be a very low time constant for a heated bed.

flobler

@phaedrux said in Verifying Firmware Safety Features - Duet 3 Mini 5+:

@flobler Ok, this may explain the issue then. The timeout will only be active when the heater is running during a print from a file on the SD card.

@Phaedrux, @dc42 thank you both for the pointer, of course it worked once I triggered the heater fault during a print from SD card. I missed that bit which caused me to test the feature wrongly. Appreciate your help with this.

One thing I recognized: while both heaters shut off after 10 minutes the PanelDue still shows the set temperatures as "active" and does not reset to 0 there. This might seem a bit confusing first as I only was certain that both of the heaters have actually stopped heating when I saw the temperature measurement drop.

@dc42 said in Verifying Firmware Safety Features - Duet 3 Mini 5+:

@flobler said in Verifying Firmware Safety Features - Duet 3 Mini 5+:

Heater 0 model: heating rate 0.302, cooling time constant 72.5, dead time 10.44, max PWM 1.00, calibration voltage 24.2, mode PID

72.5 seconds would be a very low time constant for a heated bed.

I re-ran the PID routine and got the following results:

Heater 0 model: heating rate 0.264, cooling time constant 526.4, dead time 10.00, max PWM 1.00, calibration voltage 24.2, mode PID
Computed PID parameters: setpoint change: P67.6, I0.932, D473.3, load change: P67.6, I2.202, D473.3

The heater fault still does not trigger. I am disconnecting the bed heater and then set the bed temperature to 80C manually (the bed is at room temperature before I set it to 80C). From my understanding the fault should trigger with the values above. Probably I am still missing something.

dc42

@flobler I've just run two tests:

On my Tool changer, I disconnected the bed heater SSR, and commanded heating. A heater fault was generated after 35 seconds.
On my bench system I connected a 100K resistor in place of a thermistor and configured (non-existent) bed heater. I then set the M307 parameters that you gave in your post, and commanded heating. No heater fault was raised.

So I agree, something isn't right. I will investigate why no heater fault was raised.

dc42

The reason for the failure to detect a heater fault turned out to be a mechanism that allows for noise in the temperature readings. This mechanism allows for the measured heating rate to be as low as 0.25degC/sec below the expected rate without a fault being raised. When added to the tolerance that was already allowed, it means that lack of heating is not detected on slow bed heaters.

To fix this, I will increase the time over which the rate of temperature increase is measured, so that thermistor noise has less effect.

dc42

I have just implemented this fix, and using your parameters the heater faults after 30 seconds. I will include this fix in the next 3.4 beta release. We will need to see whether it increases the number of nuisance heater faults.

flobler

@dc42 Thank you very much! I will try it and report back when the next release is live

dc42

@flobler I can make a preview build available to you that includes the fix if you like.

flobler

@dc42 If it is not much of an effort I would be happy to try! Thank you

dc42

@flobler you can find it at https://www.dropbox.com/sh/cq7q3g8coymo9s3/AABtPYEzV1_unETpKEMPInSia?dl=0. Use it with care because we have more testing to do before we release the beta.

flobler

@dc42 Thank you very much!

I just tested the feature 3x with the preview build and each time the heater faults after ca. 20 seconds

I appreciate all the help you and everyone else provided to resolve this!

dc42

@flobler thanks for confirming this. I'm sorry it took a while to resolve.