In my last post, I thought that the blog would go quiet until the final results roll in … but then I got thinking one day and that led to a few things that deserved to be mentioned. As a result, I’ll take the time to use this blog post to talk about designing a latching fault circuit, weighing the thermal switches, improving the data analysis program and do more interim results – this time regarding contact resistance trends.
Table of Contents
Latching Fault Circuit Design – A Thought Experiment
In my previous hot-box experiment, I utilised an extra thermal switch of a higher temperature rating to provide protection against relay failure or thermal switch failure. While this did serve to cut out at the higher temperature threshold, preventing catastrophe, it instead created a hot-box which oscillated around the higher temperature which is probably not the best idea. Instead, a fault like that should probably create a latched response, meaning that the power will be cut off until some external intervention arrives.
I looked at some of the other challengers’ designs and there seems to be a mix of ideologies. I, personally, subscribe to the idea that such fail-safes should be as simple and robust as possible. They should not use microcontrollers, despite the temptation, as they are vulnerable to many failure modes – for example, due to a bug in the code, failure of the crystal oscillator, power supply noise or EMI from a switching relay or nearby spark. This could cause your protection to fail without knowing it. Similarly, the use of thermal switches which provide binary output to a microcontroller seems like a poor choice, especially when a microcontroller usually has ADC inputs meaning it is rather trivial to use a thermistor and get more granular temperature information. But I do understand – they’re pitching for a Design Challenge using thermal switches so they’re going to have to use it … while it may work, it’s perhaps not the most realistic design choice. On the contrary, using more simple, electromechanical systems may be vulnerable to physical shock, but they’re usually very insensitive to power and interference issues and are easily proven safe. Because such fail-safes should not actuate often, the switching life should be more than satisfactory.
As a result, I decided to embark on a thought experiment to design a suitable circuit but not actually build or test it. Such an exercise is good just to get the brain going, although perhaps the main reason I am not building it is one of cost and parts availability lead time.
The Scenario
It’s always good to design something with an application in mind and this time is no exception. I have an old broken soymilk maker which I salvaged the heated pot from. This is basically a stainless-steel jug with a heating element in the bottom designed to heat water. I often use it to heat chemicals or other solutions, but there is no switch whatsoever – plug it in and it heats forever. This poses a risk – what happens when the solution boils dry? The heating element could overheat and catch fire along with the outer plastic casing.
As a result, I would design a circuit where this jug could be plugged into that would cut the power when it boils dry. How might we detect this? Well, remember that water boils at about 100°C (depending on the atmospheric pressure) and the latent heat of vaporisation is needed to evaporate it into steam. This means that the boiling jug would be at about 100°C as long as water was still in it. Once everything has evaporated, then the jug can start to exceed 100°C, and we can detect that with an OHD1-110M thermal switch which is designed for 110°C. In fact, if you didn’t know, this is similar to how rice-cookers work.
Once this occurs, we need to trip the power to the jug and hold it off. This can be achieved with a latching relay. The two-coil variety has a set and reset coil. Pulsing or applying current to one coil causes the relay to move to one state and hold it continuously. Current needs to be applied to the opposite coil to move the output to the other state. It is like a mechanical power latch. This will form the memory of the circuit.
The schematic of what I came up with looks like the above. It does have quite a few more things added onto it, but the crux of the circuit works as described above, but with a few minor twists.
One is the addition of SW3 and SW4 which allows the operator to reset and set the relay manually. This is needed to undo a tripped condition, but also to verify that the relay is able to trip (or manually trip the circuit). There is also a second relay K2 that is always powered from the control plane and put in series with power to the load. This was put in for a specific reason – if power is lost to the control plane because the primary fuse (F1) blows, then the protection is lost but the latching relay will still provide power to the output. Having K2 means that a loss of control power will also cause the output to be switched off, maintaining safety. The customary back-EMF protection is added in the form of D2-D4. A main switch is added to allow manually turning off the control and output in one fell swoop – just in case the relays somehow failed, just as an additional convenience.
The circuit is not particularly power hungry nor sensitive to power quality, so a simple PCB-type control power transformer is used with a full-bridge rectifier and a small smoothing capacitor to produce roughly 12V DC to power the system. The actual voltage is not critical as long as it’s sufficient for the relays. To ensure the user knows the state of the output – in case there’s no power, I’ve added a neon-based tripped indicator. This could be substituted for an LED, diode and resistor instead if that is preferred.
I haven’t built it nor tested it, but it should work, at least in theory as everything is not very sensitive to the specific values. It also shows the use of a make-type switch in this case, which makes the circuit very straightforward. To do the same with a break-type switch would require a few more parts (at least, in the way that I’m thinking of it). Perhaps this is a circuit that could similarly apply to a number of other competitor’s applications as well.
Weighing the Switches
While my proposal to test the switches was all about the cycle experiment which has now evolved into many separate experiments, a simple parameter I neglected to measure was the weight of each switch. This could be important in some constrained applications, but can also tell us a bit about the consistency of manufacture and the differences in internals. As a result, for the remaining (unused) switches that were not leaded, I measured them to 0.01g resolution and 0.02g accuracy with a set of Multicomp D03407 Pocket Scales.
The results are as follows:
It seems that overall weights between switches are close to the scale’s accuracy limits with the exception of the large metal threaded TRS1-120BPR001. The two samples were still quite close (0.7%), indicating good quality control. Looking across different versions of the same casing type, such as the OHD1 switches, shows key differences in weight with break type (30B) lighter than make type (90M, 110M) which were similar in weight. The OHD5R-90B and -105B both measured similar weights as well, so it probably indicates the difference in type is more important than temperature when it comes to weight.
Upgrading the Analysis Program
I mentioned last time that the analysis program could probably be improved by examining the evolution of contact resistance over time. To do this will require summarising the maximum, minimum and average closed-state voltage measured across the switch. As we know the load current (to within 1%), we can then back-calculate the resistance.
In order to do this, I had to add a few lines to the original code which are pretty self-explanatory. The new version of the code is shown below.
# Data Log Analysis Program for Experimenting with Thermal Switches V2.0
# by Gough Lui - February 2022
# Intended only for use with CSV data files generated by my experiment!
# Very little in the way of error checking - use at own risk!
fn = input("File to Analyse? ")
for ch in range (0,2) : # Iterate through file twice!
f = open(fn,"r")
g = open("output-"+str(ch)+".csv","a") # Fixed output filenames!
cline = f.readline()
if len(cline) == 0 :
print("Zero Length File!") # In case wrong file selected
exit()
rdgt = [float(cline.split(",")[0])]
ch1t = [float(cline.split(",")[1])]
ch1v = [float(cline.split(",")[2])]
ch2t = [float(cline.split(",")[3])]
ch2v = [float(cline.split(",")[4])]
cphase = 0
scycles = 0
cyclet = 0
initt = float(cline.split(",")[0])
supt = 0
sdnt = 0
mupt = 0
mdnt = 0
avv = 0
maxv = 0
minv = 0
g.write("Cycle,CycleT,SwitchTUp,MaxTUp,SwitchTDown,MinTDown,AvSwCVolts,MaxSwCVolts,MinSwCVolts\n")
while True:
cline = f.readline()
if len(cline) == 0 :
break
crdgt = float(cline.split(",")[0])
cch1t = float(cline.split(",")[1])
cch1v = float(cline.split(",")[2])
cch2t = float(cline.split(",")[3])
cch2v = float(cline.split(",")[4])
# If no change of state has occurred, add the values onto the end of the list
if (cphase == 0 and cch1v < 2.5 and ch == 0) or (cphase ==1 and cch1v >= 2.5 and ch == 0) \
or (cphase == 0 and cch2v < 2.5 and ch == 1) or (cphase ==1 and cch2v >= 2.5 and ch == 1) :
rdgt.append(crdgt)
ch1t.append(cch1t)
ch1v.append(cch1v)
ch2t.append(cch2t)
ch2v.append(cch2v)
else : # Change of state has occurred, collect data and (if appropriate) print result to file
if cphase == 0 :
if ch == 0 :
supt = cch1t
mdnt = min(ch1t)
avv = sum(ch1v[5:-5])/len(ch1v[5:-5])
maxv = max(ch1v[5:-5])
minv = min(ch1v[5:-5])
else :
supt = cch2t
mdnt = min(ch2t)
avv = sum(ch2v[5:-5])/len(ch2v[5:-5])
maxv = max(ch2v[5:-5])
minv = min(ch2v[5:-5])
cphase = 1
if scycles > 0 :
g.write(str(scycles)+","+str(cyclet)+","+str(supt)+","+str(mupt)+","+str(sdnt)+","+str(mdnt)+","+str(avv)+","+str(maxv)+","+str(minv)+"\n")
scycles = scycles + 1
else :
if ch == 0 :
sdnt = cch1t
mupt = max(ch1t)
else :
sdnt = cch2t
mupt = max(ch2t)
cphase = 0
cyclet = crdgt-initt
initt = crdgt
# Clean-up lists to start a new cycle
rdgt=[crdgt]
ch1t=[cch1t]
ch1v=[cch1v]
ch2t=[cch2t]
ch2v=[cch2v]
f.close()
print("All Done!")
Interim Results – Contact Resistance Trends
The experiment still keeps running but there is not much change to report regarding temperatures. As a result, it’s probably more interesting to report on the newly-added parameter of contact resistance instead.
As of this morning, the test data was 1.34GiB in size, with the OHD1-50B achieving 54,215 cycles and the M-TRS5-60B achieving 20,834 cycles. Quite an achievement indeed! Because of the measurement resolution of the DAS240-BAT, we should be able to get indicative contact resistance but there may be some noise in the data, so averaging the closed-state voltage should help us reduce the noise.
Measurements from the OHD1-50B showed all readings within the 150mΩ rating. The voltage with the switch closed does have some peakiness, which could be externally induced noise or contact crackle. The minimum closed voltage is remarkably stable, with the average following closely behind. It seems the contact resistance initially reduces slightly and then it remains stable throughout, with small diurnal variations probably due to daily temperature impacts on the measuring equipment or slight shifts in contact point. The long-term average DC contact resistance is around 59mΩ.
The M-TRS5-60B was perhaps not so well-behaved, with the maximum reading spikes reaching 600mΩ in one case. Overall averages were mostly tame with less diurnal variation. There does not seem to be that much correlation regarding spikes thus external noise is not so likely, but perhaps contact crackle is the cause. The overall long-term average DC contact resistance is about 60mΩ - virtually identical to the OHD1-50B. The stability of both over time seems to suggest the contacts are holding up well to the torture and are not degrading in any measurable way.
Conclusion
This blog brings together a thought experiment to produce a latching temperature-threshold-based power controller to avoid overheating but without using any microcontrollers for higher robustness, a practical test to weigh the thermal switches themselves, an upgrade to the analysis code and an initial peek into the derived contact resistance trends which seem to indicate the switches are still very healthy despite having done 54,215 and 20,834 cycles each at this point in time.
That brings us to the end of yet another post – a little shorter than usual this time. This series of posts, taken together, is getting quite long especially since it was only two blogs required. Hope you enjoyed it … perhaps the next one will be the last in a month’s time with the final results.
[The Torturing Thermal Switches Blog Series Index]
- Blog #1: Torturing Thermal Switches – Cycle Testing Cut-in, Cut-out, Hysteresis & Contact Resistance
- Blog #2: Torturing Thermal Switches – Unboxing, Initial Characterisation & Experimental Refinements
- Blog #3: Torturing Thermal Switches – Magnetic Characteristics, Teardown, Overload Behaviour & Commencing the Cycle Experiment!
- Blog #4: Torturing Thermal Switches – Contact Bounce, Overvoltage & Building a Component/Filament Dryer
- Blog #5: Torturing Thermal Switches –Temperature Measurement Complexities, Switching Deviations, Data Analysis & Interim Results
- Blog #6: Torturing Thermal Switches – Latching Fault Circuit Design, Weighing In, and Checking Contact Resistance (this post)
- Blog #7: Torturing Thermal Switches – A Minor Glitch, *Final* Results & Conclusion
Top Comments