Dual thermistor bed PID not working in 3.4

pkos

Hi,

I've recently built a new Voron (Trident this time) and wanted to run a setup I already have working on my 2.4 - two thermistors - one on the silicone AC mat from Keenovo (built in), another one placed inside of the 8mm alu bed (small hole drilled in the side and thermistor placed inside to measure edge temps).

This is my config:

; Hotbed (Dual Thermistor)
M308 S0 P"temp1" Y"thermistor" T100000 B3950 A"Bed Heater"       	; Thermistor on the mat
M308 S2 P"temp0" Y"thermistor" T100000 B3950 A"Bed Plate"			; Thermistor inside the bed
M950 H0 C"out0" T2                                  	; Heater
M307 H0 B0 R0.166 C1554.8 D66.08 S0.60 V24.0		; Heater 0 model for 3.x
M140 H0                                            	; Map heated bed to heater 0
M143 H0 P1 T0 A2 S115 C0							; Regulate (A2) bed heater (H0) to have pad sensor (T0) below 115°C. Use Heater monitor 1 for it
M143 H0 P2 T0 A1 S120 C0                            ; Shut off (A1) bed heater (H0) if pad sensor (T0) exceeds 120°C. Use Heater monitor 2 for it
M143 H0 S115                                       	; Set temperature limit for heater 0 to 115C
M570 H0 T3											; Start screaming if temp falls 3C below set temp.

I'm running this on RRF 3.4 on a Duet 3 mini 5+ (as opposed to 2.4 which has a 6HC).

The command I was using to try to PID tune the bed was:

M303 H0 S85 P0.6

The behavior I am seeing is that once the mat thermistor reaches it's top value (here 115C)- it seems as if the heater is permanently turned off and the tuning algorithm never reengages it - even if the bed temp is waaaay below my set 85C. I made a test, where all I changed was the M143 line for the thermistor in the mat and dropped it down from 115C to 100C - same behavior. Once the mat reaches 100C, any future heating is stopped and the bed cools down (last bit of this can be seen in the screenshot below - ignore the hotend temps and the slight bump - this was around 60C after I restarted the board and did my bed to nozzle distance measurements).

I tried dropping down to 3.3 and here it also behaved the same. Once the temp was reached, even though the heater was marked as in tuning - heating was disengaged and would never reengage.

I know I had this working once, since my 2.4 with 6HC was PID tuned (but that was a long time ago, possibly before 3.3 - it's not operational at this time so I can't confirm).

Has anyone else seen this behavior?

pkos

An update.

Dropping to RRF 3.2 allowed me to pid tune, but only because it ignored the 115C limit and would actually go as high as 125C to reach the 85C on the bed. All done with the same settings.

After that, I went back to 3.4 and could no longer do a pid tune - once 115C is hit, any heating stops even if both heaters go below the target temperature.

I tried commenting out line 9 in my config (just in case, so the M143 H0 S115) - same behavior. Heating is disabled once 115C is reached.

Alex.cr

@pkos

If I remember correctly this is a known result of changes to the PID tuning software. I have a similar problem on my 2.4. I have a PID tune from an earlier version of RRF as well and just continue to use that.

I think there were concerns with de-coupling the heater and direct thermistor. This would allow more constant temperature control at the heater itself and prevent any overheating concerns. That being said, I wish it would still work because it's a great way to know the heated bed was ready. At this time your best bet is to just use the thermistor in the heater and monitor your secondary thermistor for heat up.

I am not sure what the long-term plan is for dual thermistor installations.

pkos

@alex-cr That would be a big shame, since the system works perfectly on the 2.4 as I am sure you see yourself on yours.

I won't give up this easily though, as to me - this is still incorrect behavior based on what is in the documentation for the M143 gcode.

Considering I am setting 115C to trigger an A2 (so temporary shut off) and not A1 (permanent shut off) - This to me is incorrect behavior or the documentation does not specify that A# is ignored during PID and always defaults to A1 (and not even the default A0).

Is there any chance I could trouble you @dc42 to help us here (especially on the A1 vs A2 behavior)?

pkos

Shameless bump to @dc42

Is there any chance anything could be done here? Or should I abandon all hope?