Solved [3.4b7+7] Chamber Heater faults
-
We continue to experience Chamber heater faults when initially heating up our printers with any of the 3.4 betas. Our M307 is as follows. I don't think we can "dumb" it down much further. We never had issues with 3.3.
M307 H2 B1 C1800 D350 R0.02
@dc42 WIll this be addressed before 3.4 final? It's pretty critical that this is corrected. As explained in previous posts, the chamber temp can and does swing negative momentarily when initially heating - and the current algorithm is reading this as a fault. Thanks
-
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
-
-
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?
-
-
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.
-
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
-
@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
-
@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.
-
@dc42 Thank you. We'll definitely test it right away and report back with our findings.
-
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.
-
@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.
-
-
-
-
-
-
-