Bed heating with RRF 3.0 erroneously trips slow heating error
-
-Ender 3 Pro printer with newly installed Duet2 WiFi running Reprap firmware version 3.0
-This printer was working perfectly running with a Maestro board and an older firmware version. No issues with bed heating
-When I try to heat up the bed I get the error: Heating fault on heater 0, temperature rising much more slowly than the expected 1.6°C/sec
-The bed is wired correctly with crimped ferrules going into the screw blocks, and the solder joints at the bed are flawless.
-I can get the bed up to temperature by babysitting it and manually increasing the temperature by 1° increments until the desired temp is achieved.
-The wires connecting the bed to the Duet are cool to the touch. Even when the bed is holding a temperature of 100°CI believe that my only issue is the firmware setting that decided my bed heats too slowly. How can I change this setting, or disable it entirely. I don't like being Nannied here. I know my hardware works. The manufacturer knows it works. Why is the Duet board telling me that it is unsafe?
-
The change is due to the way 3.0 has generalized more of the connections. In 2.x the bed heater was predefined and certain assumptions were made about how it would behave. In 3.0 that assumption about how a bed heater has been lost. In 3.01-r10 it's been re-introduced by flagging the heater as a bed in config.g
From the release notes:
Duet WiFi, Ethernet and Maestro: a default bed heater is no longer assigned, so you need to use M140 H0 in config.g if you want to replicate the previous behaviour. The online configurator already generates this command automatically when you configure a bed heater. Any M143 H0 command must come later in config.g than the M140 H0 command, because M140 resets the temperature limit for the heater to the default for bed heaters.
3.0 is quite old at this point, but 3.01 is still a release candidate, so you have the choice of either sticking with 3.0 which is mostly stable, but has quirks, or updating to the release candidate, which has more fixes and features, but also has it's own quirks.
If you want to stick with 3.0 I think you can get around the issue by getting it to successfully complete a PID tuning so that the firmwares internal model of how the heater behaves is in line with a bed heater. If you can't get it to tune successfully you may need to do some manual PID tuning (or copy the values from your old config)
@punamenon said in Bed heating with RRF 3.0 erroneously trips slow heating error:
Why is the Duet board telling me that it is unsafe?
Because based on the model it has of the heater it's expecting it to act like a hotend heater, and when it doesn't conform to that model the watch dog throws an error. If thermal runaway protection is nanying maybe you'd prefer an old version of marlin?
Just kidding. -
@Phaedrux Thanks! Helpful as always you.
maybe you'd prefer an old version of marlin?
Ha Ha. No thanks. I like the thermal runaway protection, I just don't like not being able to control what rise in temperature is determined unsafe. That's why I felt I was being Nannied. The issue as you explain it is more nuanced and I guess if it worked correctly (as it apparently does in 3.01) I wouldn't feel like I was being over protected.
-
You're not the first to be caught out by this one. Hence the change in 3.01.
Though the issue can still persist for chamber heaters which are also very slow to rise. I think you may have been caught by that one as well in the recent past?
-
@Phaedrux The Chamber heater problem was on an older version of the firmware. 2.01 maybe. I need to get back to that project.
-
@Phaedrux Well, apparently the problem is not fixed in version 3.01-RC12. Bummer. Now I need to downgrade to the previous 2.05.1 version of the firmware. Bummer.
-
That's even with an M140 H0 command in your config.g?
-
I have the same problem but 1.8 C/sec error. Running RC3.11. My config was created using the online program. With Phaedrux comments I check my config file. The M143 was right before the M140 H0 line. Per release note listed I moved the M143 after the M140 line, saved and rebooted. Same error code.
-
Gents,
I have an ender 5 pro and went through the same learning you are.
Phaedrux helped me to work through it. It is only fair I spread the knowledge.
Here is the section of my config.g file for your reference.
It may not be academically perfect, but copying the tuning values into the config and changing the D value helped.; Heaters
M308 S0 P"bedtemp" Y"thermistor" T98801 B4185 ; configure sensor 0 as thermistor on pin bedtemp
M950 H0 C"bedheat" T0 ; create bed heater output on bedheat and map it to sensor 0
M143 H0 S120 ; set temperature limit for heater 0 to 120C
M307 H0 A88.4 C265.5 D2.0 S1.00 V23.9 B0 ; disable bang-bang mode for the bed heater and set PWM limit (Values copied from auto tune D corrected from 0.9 to 2 by Phaedrux)
M140 H0 ; map heated bed to heater 0
M308 S1 P"e0temp" Y"thermistor" T98801 B4185 ; configure sensor 1 as thermistor on pin e0temp
M950 H1 C"e0heat" T1 ; create nozzle heater output on e0heat and map it to sensor 1
M143 H1 S300 ; set temperature limit for heater 1 to 300C
M307 H1 A390.6 C153.8 D3.5 S1.00 V23.9 B0 ; disable bang-bang mode for heater and set PWM limit (Values copied from auto tune) -
Been messing with this and got it fixed. I changed to PID in the config tool. By the way, it moves the M143 before M140 that I had changed above. Figure out tuning M code but no luck. I had a bench variable power supply for testing to the board mains and a switching PS to the bed power input. Tested PS supplies and it worked on a multimeter. I decide to test another PS I have and it is good. Took the PS on the Bed and moved it the board power input and connected the new PS to the bed power input. Changed to PID and fixed the M143 code issue (after M140). Sent M code to auto tune. Yea! it works. I have the bed temp. working selecting different bed temperatures and works great holding temperature as expected.
Next, I then went to PID the hot end but getting issues. Maybe the original PS has something going on with it; maybe not. I will work on that next.
Thanks for the input guys.
P.S.: Just saw Daniel M307 lines. My config file did not update. I guess you manually need to update these values.
-
Correct. The M307 goes directly to the config override. I copy it from there an placed it on the config.g
It is working, so I believe it does not hurt to have it twice...
Good printing!
