[3.4b7+7] Chamber Heater faults

oozeBot

Here is the error logged when it faults:

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

oozeBot

As an additional test, we adjusted M307 to the following, but it resulted in the same fault.

M307 H2 B1 C3600 D350 R0.01

The documentation on the M307 parameters are a bit sparse - if anyone knows something we are missing that might resolve this, please speak up. Maybe our understanding of deadtime is inaccurate?

Stephen6309

@oozebot D is the dead time;
https://duet3d.dozuki.com/Wiki/Tuning_the_heater_temperature_control#Section_Setting_the_model_parameters_manually

oozeBot

When this was first discovered, our testing determined the maximum D value was around 350. On 3.4b7+1, it accepted D1000. I will test this change as soon as an available printer cools down.

Current M307 settings:

Heater 2: heating rate 0.010, cooling rate 0.028, dead time 1000.00, max PWM 1.00, mode bang-bang

edit - adjusting the dead time to 1000 appears to have been helpful. I have now adjusted all our printers to the new settings and will continue testing over the next few days.

oozeBot

Further testing with the following M307 still results in a chamber heater fault in the 3.4 betas. This was never an issue in 3.3. It appears the current algorithm simply won't let the temperature dip negative, which can and does happen when heating a chamber.

M307 H2 B1 C3600 D1000 R0.01
Heater 2: heating rate 0.010, cooling rate 0.028, dead time 1000.00, max PWM 1.00, mode bang-bang
Predicted max temperature rise 36°C

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

oozeBot

@dc42 - I just dug through the recent RRF code changes and see several (hopefully) related modifications that have been made. I am in hopes the information we've provided helped identify the issue. Can you confirm this was targeted in those changes? Thanks

dc42

@oozebot the problem was that prior to the 3.4beta series, if the M307 R parameter was low enough then the heater fault detection didn't work at all. So I've been trying to come up with a solution that works for slow heaters; but it's proving difficult. You may find RRF 3.4b7+4 better, and I hope to make that available later today.

oozeBot

@dc42 Thank you. We'll definitely test it right away and report back with our findings.

oozeBot

After spending the weekend on this, I believe we may have been able to stabilize the tuning to stop the heater faults by further raising the C value to 200x the actual time it takes to fully heat our chambers. As mentioned, this was never an issue prior to the 3.4 betas. We understand a defect was addressed to better protect against heater faults, but it feels way to restrictive for chamber heaters.

We will continue to test and provide results. If our current settings continue to provide success, I guess we'll consider this resolved, but it does not feel as if we are properly setting the values for how our heaters work. Instead, it feels as if we are working around a software issue.

oozeBot

@dc42 - After several more days of testing, we are going to mark this as solved, however something still feels wrong as the only way to reliably stop the heater faults was to raise the C value to 200x the actual time it takes to fully heat our chambers. That isn't how the documentation describes the C parameter, but we'll run with it unless we're told additional changes are made in the firmware.