Heaters turn ON when powering ON or restarting Duet 3

HeidiH

Hi, I have found out that when I power ON my Duet 3 Mainboard 6HC or restart the firmware with emergency stop my heaters turn on for a very short time period (1s or so),

I have connected the heaters to OUT1 and OUT3 of the board and have set-up a BtnCmd testing panel, in which I monitor also the heater PWM outputs with the temperature. At least based on that panel I don't see any activation of the OUT1 and OUT3 PWM outputs simultaneously, but of course I can't monitor this during the restart.

I have aimed to avoid this by specifying in the config. file that tools are not ON, by default but this does not help, but still occurs. Below is the code that I have used:

M568 P0 R0 S0 A0

What could cause this issue? Does there occur some other electric spike on my heaters that isn't caused by Duet 6HC board turning ON, or is this still some configuration problem?

BR, Heidi

Phaedrux

@HeidiH said in Heaters turn ON when powering ON or restarting Duet 3:

I have found out that when I power ON my Duet 3 Mainboard 6HC or restart the firmware with emergency stop my heaters turn on for a very short time period (1s or so),

How did you identify this?

Please share your config.g and the results of sending M122 and M98 P"config.g" in teh gcode console.

HeidiH

@Phaedrux I identified this as the temperature increases (Heater 1: 1.8C Heater 2: 2.1C), which appeared in response to the restart of firmware. These heaters are not similar with each other and the another of my heater gave me a sound that I now for sure that its temperature has increased. Unfortunately, I can't open further details of these on this forum.

The result of M122 code:

M122 T37:39
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.5.0-rc.4 (2024-04-09 09:46:27) running on Duet 3 MB6HC v1.01 (standalone mode)
Board ID: 08DJM-956BA-NA3TJ-6J1DJ-3SD6S-199YS
Used output buffers: 2 of 40 (29 max)
=== RTOS ===
Static ram: 155208
Dynamic ram: 121056 of which 208 recycled
Never used RAM 66664, free system stack 200 words
Tasks: NETWORK(1,ready,39.9%,176) ETHERNET(5,nWait 7,0.1%,317) HEAT(3,nWait 1,0.0%,323) Move(4,nWait 6,0.0%,336) CanReceiv(6,nWait 1,0.0%,940) CanSender(5,nWait 7,0.0%,334) CanClock(7,delaying,0.0%,334) TMC(4,nWait 6,9.3%,54) MAIN(1,running,50.7%,444) IDLE(0,ready,0.0%,30), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:29:42 ago, cause: software
Last software reset at 2024-05-27 09:25, reason: User, Gcodes spinning, available RAM 66872, slot 2
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
MCU temperature: min 38.5, current 38.9, max 39.5
Supply voltage: min 23.7, current 23.7, max 23.8, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.1, current 12.2, max 12.2, under voltage events: 0
Heap OK, handles allocated/used 99/4, heap memory allocated/used/recyclable 2048/68/12, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, SG min n/a, mspos 0, reads 39138, writes 14 timeouts 0
Driver 1: standstill, SG min n/a, mspos 0, reads 39138, writes 14 timeouts 0
Driver 2: standstill, SG min n/a, mspos 0, reads 39138, writes 14 timeouts 0
Driver 3: standstill, SG min n/a, mspos 8, reads 39138, writes 14 timeouts 0
Driver 4: standstill, SG min n/a, mspos 8, reads 39139, writes 14 timeouts 0
Driver 5: standstill, SG min n/a, mspos 8, reads 39142, writes 11 timeouts 0
Date/time: 2024-05-27 09:55:31
Slowest loop: 999.30ms; fastest: 0.07ms
=== Storage ===
Free file entries: 20
SD card 0 detected, interface speed: 25.0MBytes/sec
SD card longest read time 3.3ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, segments created 0, maxWait 0ms, bed compensation in use: none, height map offset 0.000, max steps late 0, min interval 0, bad calcs 0, ebfmin 0.00, ebfmax 0.00
no step interrupt scheduled
Moves shaped first try 0, on retry 0, too short 0, wrong shape 0, maybepossible 0
=== DDARing 0 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== DDARing 1 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
=== GCodes ===
Movement locks held by null, null
HTTP is ready with "M122  T37:39" in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
File2 is idle in state(s) 0
Queue2 is idle in state(s) 0
Q0 segments left 0, axes/extruders owned 0x0000000
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== CAN ===
Messages queued 16039, received 0, lost 0, errs 8435795, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 50 (min 49), ts 8911/0/0
Tx timeouts 0,0,8910,0,0,7126 last cancelled message type 30 dest 127
=== Network ===
Slowest loop: 32.36ms; fastest: 0.03ms
Responder states: MQTT(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
= Ethernet =
Interface state: active
Error counts: 0 0 0 1 0 0
Socket states: 5 2 2 2 2 0 0 0
=== Multicast handler ===
Responder is inactive, messages received 0, responses 0

Here is the result of M98 code:

M98 P"config.g"
Error: in file macro line 9 column 18: meta command: variable 'logTemps' already exists

Here are the parts from config. file that are related to my heaters, hopefully they are sufficient?

; Pt100 sensors for heaters 1 and 2
M308 S1 P"spi.cs1" Y"rtd-max31865" A"First Heater" 
M308 S2 P"spi.cs3" Y"rtd-max31865" A"Second Heater"

; Heaters 1 and 2
M950 H1 C"!out1" Q10 T1
M950 H2 C"!out3" Q10 T2

; Restricting maximum temperature 
M143 H1 S300 A0
M143 H2 S180 A0

; PID parameters for heaters
; Heater 1
M570 H1 P2 T10 R2
M307 H1 R2.921 K0.455:0.000 D2.48 E1.35 S0.55 B0

; Heater 2
M570 H2 P2 T10 R2
M307 H2 A550 C303.1 S0.3 D15.0 B0

;Tools 0 and 1
; Tool 0
M563 P0 S"Tool 1" D0 H1
G10 P0 X0 Y0 ; Set tool 0 axis offsets
M568 P0 R0 S0 A0

; Tool 1
M563 P1 S"Tool 2" H2 
G10 P1 X0 Y0
M568 P1 R0 S0 A0

;Tools of in the start up
T-1

Best regards, Heidi

Phaedrux

@HeidiH said in Heaters turn ON when powering ON or restarting Duet 3:

3.5.0-rc.4

Please update to 3.5.1 now that it is available and see if you still get the same behaviour? Upload this zip file to DWC. https://github.com/Duet3D/RepRapFirmware/releases/download/3.5.1/Duet2and3Firmware-3.5.1.zip

Do the LEDs on the heater outputs light up on the board?

HeidiH

@Phaedrux Hi, thanks for your help.

I upgraded my firmware and web interface to 3.5.1. and it didn't help with this problem. Also, at start-up each led of those high current outputs (OUT 1 to OUT 3) are turned on. OUT 2 is connected with a servo, and OUT 1 and OUT 3 with by above mentioned heaters 1 and 2. Actually, I noticed from my Panel Due that it gives a warning that my heater 2 is expected to experience overheating problem.

I was thinking, if this problem could require some electrical isolation for example with relays?

I would have also another question related to configuring heaters: As my sensor could detach from the board and initiate error or wrong temperature reading for the heater and trigger unwanted excess heating, I would like to prevent this by determining the minimum temperature that I allow for the heater. Can I program it using M143 command? Like here:

M143 H1 P1 S0 A0 C1 ; Minimum allowed temperature for heater is is 0C degrees, which initiates heater fault and heater truning off

BR; Heidi

gloomyandy

@HeidiH You have the output pins for your heaters set to be inverted:

M950 H1 C"!out1" Q10 T1
M950 H2 C"!out3" Q10 T2

Is that correct? What sort of heaters are you using?

HeidiH

@gloomyandy Thank you for your reply and notification. Yes, we have configured inverted our cartridge and pressurized air heaters, powered with DC-AC solid state relays (IN: 3-32VDC or 5-24VDC OUT: 24-280VAC), because if they were non-inverted then they would turn ON at start-up when powering ON the Duet 3 6HC board. We have connected the positive wires of the heaters to the out1 and out3, and the negative wires to the GND of board.

When I measured also with a multimeter and saw a short-term -0.040VDC voltage at the start-up of the board, which then dropped.

BR, Heidi

gloomyandy

@HeidiH That sounds like a very unusual way to connect a heater. I think it would help if you post a picture showing how you have things wired up.

HeidiH

@gloomyandy thank you for your help, I appreciate it. I tried to draw a connection diagram of another of the heaters, and both are connected similarly. Hopefully it is ok, and please, ask further questions if that is unclear and I try to specify it better.

I am not so familiar with electric connection drawings after my school, and my colleague who did the connections is now on vacation.

Incubation heater connections.jpg

gloomyandy

@HeidiH That is not the normal way to wire a SSR to a Duet board. The usual way would be to have OUT1 to "SSR-" and to have "SSR+" connected to the adjacent V_FUSED connection on the same header. On the Duet boards the high power outputs switch the negative supply. With this wiring it should not be necessary to invert the out1 pin in your configuration. If you are not familiar with the reason for your current wiring perhaps you should wait and consult with your colleague before making any changes. You may also want to wait for @dc42 or one of the other Duet folks to confirm this @Phaedrux @droftarts information.

HeidiH

@gloomyandy Hi, great! Thank you for your excellent reply, I think we will correct our wiring accordingly, but first I will wait my colleague to come back from holiday. When we have tested this, I will let you know if we managed to get rid of the problem.

With best wishes, Heidi

droftarts

@HeidiH @gloomyandy is correct, your SSR wiring is wrong. As he says, the OUT headers are switched on the ground side, because MOSFETs (that do the switching) need to be after the load (ie the heater). So the out1 pin switches to GND, not positive voltage. I'm somewhat surprised it worked at all, as you effectively had GND on both inputs of the SSR. Maybe there was enough residual current to trigger the SSR.

Make sure your SSR can cope with the V_FUSED voltage, ie the VIN voltage, probably 24V. If it can't, you can either wire +5V to the SSR+ input, and still use out1 for the SSR- input, or use an IO header to switch the SSR.

Ian

HeidiH

@droftarts @gloomyandy @Phaedrux Hi, now we have made your instructed corrections and the above problem with heaters were solved. Thank you for these excellent guidance and support.

I still got one question in mind, related to my earlier problem with my heaters, when I had them wired in an old way and when wiring like now. I had a few cases with the old wiring, when I either did not have the Pt100 temperature sensor connected to the board or my firmware crashed because of my written lines on the configuration file related to the global variables at that time. With the first case I got a heater fault warning and a comment on n/a as the temperature on the web interface, while with the latter case the firmware was not responsive. In both cases, both of my heaters turned on (even without setting-up any input for them), which is not desired.

Was these above events because I had my heaters wired and configured in a wrong manner, and does the above change avoid this risk? I had also my heater fault detection set with M143 as described below but it wasn't able to avoid this unwanted heating:

M143 H1 P0 S300 A0
M143 H2 P0 S180 A0

Also, should I have my allowed lowest temperatures be configured with M143, and not only the maxima? Unfortunately I don't figure it out what does the monitor number mean (P in above commands)? Is it somewhat related to the H term?

I also tried to read about these issues from: https://docs.duet3d.com/en/User_manual/Troubleshooting/Heater_faults, but based on that I assume the firmware should automatically detect at least bad wiring issues?

My firmware is: 3.5.1.

BR, Heidi

HeidiH

@droftarts Hi, I am sorry, but I edited my above post after you had marked it solved, based on my comment. However, I noticed another questions related to heater fault detection. Could you answer those still? Thanks in advance. BR, Heidi

droftarts

@HeidiH said in Heaters turn ON when powering ON or restarting Duet 3:

I think these are the questions you want answering?

With the first case I got a heater fault warning and a comment on n/a as the temperature on the web interface

This was probably a configuration error, and the heater has been defined with no temperature sensor.

while with the latter case the firmware was not responsive. In both cases, both of my heaters turned on (even without setting-up any input for them), which is not desired.

I think the configuration with the output pins inverted, along with the wiring issue with the SSR, caused this.

Was these above events because I had my heaters wired and configured in a wrong manner, and does the above change avoid this risk?

Yes, I think so. The default state of the heater should now be off.

I had also my heater fault detection set with M143 as described below but it wasn't able to avoid this unwanted heating:
M143 H1 P0 S300 A0
M143 H2 P0 S180 A0

If the logic to turn on and off the heater is reversed, when the firmware tries to turn off the heater (either because it reaches temperature, or there is a fault) it will actually turn the heater on! It doesn't 'know' what is happening or why, just that the temperature is not what is expected.

By 'what is expected', the firmware has a model of how the heater responds, which is created by running M303 heater tuning, and configured by M307 in config.g.

Also, should I have my allowed lowest temperatures be configured with M143, and not only the maxima? Unfortunately I don't figure it out what does the monitor number mean (P in above commands)? Is it somewhat related to the H term?

Generally, you set basic maximum temperature limits with M143. It is possible to set minimum temperatures too, just it is usually not very useful. The H term is used to define which heater has this limit. You can set up to three M143 commands per heater using the P command, and use the A and C parameters to define different actions at different temperatures. For example:

M143 P0 H2 S180 C0 A0 ; Heater 2 temperature too high, generate heater fault
M143 P1 H2 S200 C0 A3 ; Heater 2 temperature too high, shut down printer
M143 P2 H2 P2 S10 C1 A0 ; Heater 2 temperature too low (below 10C), generate heater fault

Use M570 to configure how accurately you want to maintain the set temperature.

I also tried to read about these issues from: https://docs.duet3d.com/en/User_manual/Troubleshooting/Heater_faults, but based on that I assume the firmware should automatically detect at least bad wiring issues?

It can't automatically detect bad wiring issues, it just tells you when the input (ie turning the heater on and off) doesn't match the predicted output (temperature increase/decrease). This may be because of bad wiring, but it can't tell that is the issue, just that there is something unexpected.

Ian