HI Folks

This photo http://www.ambquality.co.uk/images/2020-08-27_2550.JPG shows
the switch-box that powers my home-built glass-fusing kiln (26 Amps @ 240v).

(yes - I know the wiring's terribly untidy - but it works!)

The commercial digital controller outputs 12v, which is used to switch
the small relays on the left, which, in turn, switch mains to the coils
of the contactors.
There's two of everything - because the long-term plan was to use one
contactor as a safety relay, and the other as the actual 'control' relay
- which is turned on & off by the controller, to regulate the
temperature in the kiln.

Power comes in on a 6mm2 cable top centre, and feeds to the heating
elements in the kiln via the two flexible cables top right.

I used the 40A contacts mostly because I had them to hand. They last
about 18 months in normal operation (somewhere around 200,000 switching
cycles) before the contacts fail. (As evidenced by the sooty dust in the
bottom of the enclosure!)

So - I'm looking to replace the main switching contactor with something
more suitable
- options are

- Potter & Brumfield 40A relay T92P11D22-12 (used in many commercial kilns)
- Crydom 50A SSR - D2450

Either option would allow me to dump the two interface relays, as the
P&B relay and the SSR will switch on a 12v signal.

The beauty of the contactors is that they have screw-clamp terminals
which makes the wiring simple.
The P&B relay uses 1/4" spades, the Crydom uses a screw/washer arrangement.

Are there any issues with using crimp connectors (either 1/4"
receptacles or ring-terminals) with solid core cables? - or would I be
better obtaining some heavy-duty multi-stranded cable...
I have a good ratchet crimp-tool.

I would probably terminate the incoming cable on a Klippon terminal, and
then run additional wiring to the relays - or I could retain one of the
contactors as a safety relay, (which only switches once per firing
rather than 750 times like the control relay) and run flexible leads
from the bottom of that contactor.

Also - for anybody experienced in using SSR's - is this 50A SSR going to
want significant heatsinking, when handling 26A or so? If so - what?

Thanks
Adrian

On Thu, 27 Aug 2020 22:41:46 +0100, Adrian Brentnall
wrote:

snip

Also - for anybody experienced in using SSR's - is this 50A SSR going to
want significant heatsinking, when handling 26A or so? If so - what?

No real use to you as I've only used (or tried to use) one on the
heated bed of my 3D printer and it draws around 10A at 12V (DC).

I think we used a 20A (or bigger) rated SSR on PWM and it got *very*
hot, very quickly (no h/s) so we left it with the relay on bang-bang.

Coincidentally it has been printing most the evening (and fairly
frequently) over the last ~5+ years and it's still going strong. ;-)

I think we used a 25A DC rated vehicle relay FWIW on (guess) a 50:50
duty cycle, switching every 20 seconds or so?

I think AC switching may be a different ball game (re SSR's)?

Cheers, T i m

On 27/08/2020 23:09, T i m wrote:
On Thu, 27 Aug 2020 22:41:46 +0100, Adrian Brentnall
wrote:

snip

Also - for anybody experienced in using SSR's - is this 50A SSR going to
want significant heatsinking, when handling 26A or so? If so - what?

No real use to you as I've only used (or tried to use) one on the
heated bed of my 3D printer and it draws around 10A at 12V (DC).

I think we used a 20A (or bigger) rated SSR on PWM and it got *very*
hot, very quickly (no h/s) so we left it with the relay on bang-bang.

Coincidentally it has been printing most the evening (and fairly
frequently) over the last ~5+ years and it's still going strong. ;-)

I think we used a 25A DC rated vehicle relay FWIW on (guess) a 50:50
duty cycle, switching every 20 seconds or so?

I think AC switching may be a different ball game (re SSR's)?

Cheers, T i m

Thanks Tim
There's a part of me that rather likes to hear that relay going
click-click while the kiln's firing - which you wouldn't get with a
solid-state relay, of course..

Maybe the answer is 'better relays' - the contactors are somewhat
agricultural, and probably aren't meant for frequent on/off cycles..
They're also unbranded - so probably Chinese Copies..

Was talking to a kiln manufacturer the other day and their latest 'Big
Idea' is to run a small SSR and a conventional relay in parallel - the
idea being that the SSR turns on, with its zero-voltage switching, and a
short time later the mechanical relay also pulls in, at which point the
ssr drops out. Reverse the sequence when turn-off is required.

Theory was that the relay only has to hold the current, rather than
switch it, and the ssr is only on for one or two seconds, so it doesn't
get a chance to overheat..

Sounded a bit over-complex to me!

Maybe I'll try the 'better relay' solution first....
Thanks

On 28/08/2020 07:36, Adrian Brentnall wrote:
There's a part of me that rather likes to hear that relay going
click-click while the kiln's firing - which you wouldn't get with a
solid-state relay, of course..

Unless you used it to drive a mechanical relay as well as the kiln...

Seriously, solid state is way more reliable than a relay. especially if
select up for reliability and not down to a price.




--
Climate Change: Socialism wearing a lab coat.

On 28/08/2020 08:29, The Natural Philosopher wrote:
On 28/08/2020 07:36, Adrian Brentnall wrote:
There's a part of me that rather likes to hear that relay going
click-click while the kiln's firing - which you wouldn't get with a
solid-state relay, of course..

Unless you used it to drive a mechanical relay as well as the kiln...

Ha! - I had toyed with the idea of adding some kind of 'sounder' to
replace the click!


Seriously, solid state is way more reliable than a relay. especially if
select up for reliability and not down to a price.


Yes - that's why I was looking at the 50A SSR...
The only thing I'm not sure about is what/how much heat-sinking it's
going to want...

On 27/08/2020 22:41, Adrian Brentnall wrote:
HI Folks

This photo http://www.ambquality.co.uk/images/2020-08-27_2550.JPG shows
the switch-box that powers my home-built glass-fusing kiln (26 Amps @
240v).

(yes - I know the wiring's terribly untidy - but it works!)

The commercial digital controller outputs 12v, which is used to switch
the small relays on the left, which, in turn, switch mains to the coils
of the contactors.
There's two of everything - because the long-term plan was to use one
contactor as a safety relay, and the other as the actual 'control' relay
- which is turned on & off by the controller, to regulate the
temperature in the kiln.

Power comes in on a 6mm2 cable top centre, and feeds to the heating
elements in the kiln via the two flexible cables top right.

I used the 40A contacts mostly because I had them to hand. They last
about 18 months in normal operation (somewhere around 200,000 switching
cycles) before the contacts fail. (As evidenced by the sooty dust in the
bottom of the enclosure!)

So - I'm looking to replace the main switching contactor with something
more suitable
- options are

- Potter & Brumfield 40A relay T92P11D22-12 (used in many commercial kilns)
- Crydom 50A SSR - D2450

Either option would allow me to dump the two interface relays, as the
P&B relay and the SSR will switch on a 12v signal.

The beauty of the contactors is that they have screw-clamp terminals
which makes the wiring simple.
The P&B relay uses 1/4" spades, the Crydom uses a screw/washer arrangement.

Are there any issues with using crimp connectors (either 1/4"
receptacles or ring-terminals) with solid core cables? - or would I be
better obtaining some heavy-duty multi-stranded cable...
I have a good ratchet crimp-tool.

No problem with solid core wire, so long as the crimp is well made.

I would probably terminate the incoming cable on a Klippon terminal, and
then run additional wiring to the relays - or I could retain one of the
contactors as a safety relay, (which only switches once per firing
rather than 750 times like the control relay) and run flexible leads
from the bottom of that contactor.

Also - for anybody experienced in using SSR's - is this 50A SSR going to
want significant heatsinking, when handling 26A or so? If so - what?

Yes you want a heatsink. Crydom make one designed for their SSRs:

https://uk.farnell.com/crydom/hs053/...75197?st=hs053



--
Cheers,

John.

/================================================== ===============\
| Internode Ltd - http://www.internode.co.uk |
|-----------------------------------------------------------------|
| John Rumm - john(at)internode(dot)co(dot)uk |
\================================================= ================/

Adrian Brentnall wrote :
Yes - that's why I was looking at the 50A SSR...
The only thing I'm not sure about is what/how much heat-sinking it's going to
want...


Dissipation will be minimal, but check the manufacturers spec for the
required heat sinking. I assume you will be mounting it away from any
kiln heat?

On Fri, 28 Aug 2020 07:36:27 +0100, Adrian Brentnall
wrote:

snip

I think AC switching may be a different ball game (re SSR's)?


Thanks Tim

Sorry it wasn't any use ...

There's a part of me that rather likes to hear that relay going
click-click while the kiln's firing - which you wouldn't get with a
solid-state relay, of course..

Agreed, some audio feedback that it's actually working. If you leave
the filament loaded in the printer the bit outside the extruder and
toward the roll goes brittle very quickly (even overnight) for some
as-yet unknown reason? So what I do when I've finished printing that
day / colour is cut the (PLA, 1.75mm OD) filament off a bout 30mm
above the extruder and put the roll back in it's plastic bag and in
it's box on the shelf (I have maybe 10 rolls). So, when starting the
next print I go into the printers own on-screen display (well, it's
actually an Arduino Mega g) and set it to 'Preheat PLA, Extruder and
bed' and (subconsciously now) listen out for the 'click' of the bed
heater relay, confirming I have indeed selected the preheat routine.

Once the extruder is up to 200 DegC (that's cold to you! g), I press
the spring loaded filament drive lever and pull the remains of the
filament out and thread the end of the new filament in.

I have often gone to walk away, not heard the click ... and gone back
and done it again (rotary encoder 'step' rate not quite right).

I used something like this:

https://preview.tinyurl.com/y2amfoy6

12vDC driving the input switching 12VDC on the output.

I can't say we wired it 100% correctly other than it did 'work' but
I'm not sure we were 100% sure from the markings on ours where the
relay should sit in the circuit (or if it mattered). The output
trigger for the heated bed of the 3D printer was pulled high (12V) on
active so we connected that to the input +Ve pin on the SSR and I
think we connected the output -Ve to PSU -Ve and SSR +Ve to the heated
bed (and then to +12V on the PSU). Being isolated between input and
output, I'm not sure it matters what 'leg' it's in, but that the
polarity is right?

Maybe the answer is 'better relays' - the contactors are somewhat
agricultural, and probably aren't meant for frequent on/off cycles..
They're also unbranded - so probably Chinese Copies..

Maybe.

Was talking to a kiln manufacturer the other day and their latest 'Big
Idea' is to run a small SSR and a conventional relay in parallel - the
idea being that the SSR turns on, with its zero-voltage switching, and a
short time later the mechanical relay also pulls in, at which point the
ssr drops out. Reverse the sequence when turn-off is required.

That makes loads of sense (from my experience of 'pushing'
semiconductors when switching heavy loads).

I designed zero-crossing into all the light units I designed and built
for my mobile disco but in most cases the switching devices were
handling far less power than they were rated for and in 8 years
regular use I never lost a single one. The lamps seemed to last well
as well, considering they were flashing most of the time, possibly
helped by the zero crossing.

Theory was that the relay only has to hold the current, rather than
switch it, and the ssr is only on for one or two seconds, so it doesn't
get a chance to overheat..

Yeah, good.

Sounded a bit over-complex to me!

I think it might be one of those things that when you have it
installed, you wonder why you didn't do it sooner? ;-)

Maybe I'll try the 'better relay' solution first....

I think the trick might be to find something that is *well* overrated
for the job. I think I also understand that if you want to uprate
things like relays, you join the contacts in series? The idea that the
contacts open faster (as in how quickly the gap forms) and so how much
time the contacts may be exposed to any back EMF?

But if the kiln people are pushing the SSR / relay combo I'm guessing
they have had good results from that?

In fact, if you go back 45 years when we were racing RC electric cars
in Ally Pally Palm Court Hall (normally £1000 / night to hire but we
knew someone .. g) a mate and I designed a hybrid speed controller
that used an 2N3033 power transistor driven by a pot (and some other
electronics) connected to a servo that then shorted the transistor out
with a micro switch when the servo was on full speed (to minimise
voltage drop). ;-)

I don't know if this would be any use:
https://uk.rs-online.com/web/generalDisplay.html?id=ideas-and-advice/solid-state-relays-guide

Cheers, T i m

On Fri, 28 Aug 2020 10:00:44 +0100, Harry Bloomfield wrote:

Yes - that's why I was looking at the 50A SSR...
The only thing I'm not sure about is what/how much heat-sinking
it's
going to want...

Dissipation will be minimal, but check the manufacturers spec for the
required heat sinking.

Well is 30 odd W is minimal...

Spec has forward voltage drop of 1.3 V at full rated current. The
forward drop won't be much less at 26 A so erring on the safe side
1.3 x 26 = 33.8 W.

The spec doesn't give a max case or junction operating temperature
only the thermal resitance junction to case of 0.45 C/W so the
junction at 26 A will be about 15 C above the case. Say 60 C max for
junction case is at 45 C ambient 25 C. Does that give a heatsink
thermal resitance of 0.6 C/W?

The makers sell a heatsink which one would assume is up to the job at
full rather than half the rated current.

I quite like the idea of the SSR doing the actual switching with a
relay/contactor shorting it out after the SSR has closed and opening
before the SSR opens. Even though the current being switched by the
relay contacts is still 26 A it's only at the forward voltage drop of
the SSR not full mains, much less arcing...

--
Cheers
Dave.

On 28/08/2020 11:26, T i m wrote:
On Fri, 28 Aug 2020 07:36:27 +0100, Adrian Brentnall
wrote:

snip

I think AC switching may be a different ball game (re SSR's)?


Thanks Tim

Sorry it wasn't any use ...

Not at all - all inputs are welcome!

snip

Maybe the answer is 'better relays' - the contactors are somewhat
agricultural, and probably aren't meant for frequent on/off cycles..
They're also unbranded - so probably Chinese Copies..

Maybe.

Was talking to a kiln manufacturer the other day and their latest 'Big
Idea' is to run a small SSR and a conventional relay in parallel - the
idea being that the SSR turns on, with its zero-voltage switching, and a
short time later the mechanical relay also pulls in, at which point the
ssr drops out. Reverse the sequence when turn-off is required.

That makes loads of sense (from my experience of 'pushing'
semiconductors when switching heavy loads).

Perhaps you're right. Their justification seemed to be that it would
save wear on the relay, and that they didn't have enough room in their
controller to fit a heatsink to the SSR.
Just sounded to me a bit like fitting two components where one would do....


I designed zero-crossing into all the light units I designed and built
for my mobile disco but in most cases the switching devices were
handling far less power than they were rated for and in 8 years
regular use I never lost a single one. The lamps seemed to last well
as well, considering they were flashing most of the time, possibly
helped by the zero crossing.

Theory was that the relay only has to hold the current, rather than
switch it, and the ssr is only on for one or two seconds, so it doesn't
get a chance to overheat..

Yeah, good.

Sounded a bit over-complex to me!

I think it might be one of those things that when you have it
installed, you wonder why you didn't do it sooner? ;-)

Maybe I'll try the 'better relay' solution first....

I think the trick might be to find something that is *well* overrated
for the job. I think I also understand that if you want to uprate
things like relays, you join the contacts in series? The idea that the
contacts open faster (as in how quickly the gap forms) and so how much
time the contacts may be exposed to any back EMF?

The heating elment is pretty-much a resistive load - so should'nt be any
back-emf to speak of - just the initial 'oomph' from switching 25A or so
at some random point in the mains cycle - about 1,000-times per firing
schedule.


But if the kiln people are pushing the SSR / relay combo I'm guessing
they have had good results from that?

So far - apparently... but early days.


In fact, if you go back 45 years when we were racing RC electric cars
in Ally Pally Palm Court Hall (normally £1000 / night to hire but we
knew someone .. g) a mate and I designed a hybrid speed controller
that used an 2N3033 power transistor driven by a pot (and some other
electronics) connected to a servo that then shorted the transistor out
with a micro switch when the servo was on full speed (to minimise
voltage drop). ;-)

I don't know if this would be any use:
https://uk.rs-online.com/web/generalDisplay.html?id=ideas-and-advice/solid-state-relays-guide

Thanks - I'll take a read.

The SSRs are often touted by the kiln-manufactures as being 'fail-safe'
- but the manufacturers warn that the SSRs can fail 'on' as well as
'off' - hence the need for a 'safety' relay that can kill power to the
kiln should the main switching device fail 'on'

Thanks
A

On 28/08/2020 12:30, Dave Liquorice wrote:
On Fri, 28 Aug 2020 10:00:44 +0100, Harry Bloomfield wrote:

Yes - that's why I was looking at the 50A SSR...
The only thing I'm not sure about is what/how much heat-sinking
it's
going to want...

Dissipation will be minimal, but check the manufacturers spec for the
required heat sinking.

Well is 30 odd W is minimal...

Spec has forward voltage drop of 1.3 V at full rated current. The
forward drop won't be much less at 26 A so erring on the safe side
1.3 x 26 = 33.8 W.

Thanks for that - I did do the maths but it's reassuring that you cam up
with a similar answer.
It's a small enclosure - but I could pop a small fan in there to vent
any hot air.

The spec doesn't give a max case or junction operating temperature
only the thermal resitance junction to case of 0.45 C/W so the
junction at 26 A will be about 15 C above the case. Say 60 C max for
junction case is at 45 C ambient 25 C. Does that give a heatsink
thermal resitance of 0.6 C/W?

The makers sell a heatsink which one would assume is up to the job at
full rather than half the rated current.

I think I was looking on the cpc site - couldn't find a heatsink there
(but the search facility is dire)
I've a box-full of handy 'spare' heatsinks upstairs - it'd be a matter
of finding something that would fit inside the case..


I quite like the idea of the SSR doing the actual switching with a
relay/contactor shorting it out after the SSR has closed and opening
before the SSR opens. Even though the current being switched by the
relay contacts is still 26 A it's only at the forward voltage drop of
the SSR not full mains, much less arcing...


Hmm - I see what you're saying.
Just the Luddite in me doesn't like fitting extra components that
increase the 'failure' potential of the circuit.

The big worry in this application is that a relay that fails 'on' will
result in a runaway kiln. This can be countered to some extent by
running a 'safety' relay in series - controlled by the main controller.
If the main relay fails 'on' then the controller will error out and drop
the 'safety' relay, thus isolating the heating element.

An alternative plan is an independent hardware circuit that monitors
kiln temperature and drops the 'safety' relay should it rise above a
preset temperature. There's a single IC that takes a thermocouple input
and does all the necessary...

All interesting info - thanks.

On Fri, 28 Aug 2020 14:57:27 +0100, Adrian Brentnall
wrote:

snip

Was talking to a kiln manufacturer the other day and their latest 'Big
Idea' is to run a small SSR and a conventional relay in parallel - the
idea being that the SSR turns on, with its zero-voltage switching, and a
short time later the mechanical relay also pulls in, at which point the
ssr drops out. Reverse the sequence when turn-off is required.

That makes loads of sense (from my experience of 'pushing'
semiconductors when switching heavy loads).

Perhaps you're right. Their justification seemed to be that it would
save wear on the relay,

It sounds like it would, where the 'wear and tear' is typically to the
contacts, rather than the general mechanics? I check because you
mention the '1000 times per cycle' and that is a far few times.

If I guessed my relay operates an on-off cycle every 30 seconds and
let's say the average print job lasts 1 hour (can be seconds or the
best part of a day) then that's 7200 times. As mentioned, it is only a
basic (it might have been a Lucas or some such) car type relay and I
feel it will carry on for ever. ;-)

and that they didn't have enough room in their
controller to fit a heatsink to the SSR.

Is their box metal and could you bolt it to that on the inside with a
heatsink on the outside (or wouldn't that help if it's near the
furnace)? Even a length of Ally angle cut to length and bolted to the
(presumed metal) case (with maybe a bit of thermal compound) would act
like a heat pipe?

Just sounded to me a bit like fitting two components where one would do....

Well, in this day and age you would think one should do but it seems
that it can't always, or at least not without other 'costs' (like
excess heat). ;-(

snip

Maybe I'll try the 'better relay' solution first....

I think the trick might be to find something that is *well* overrated
for the job. I think I also understand that if you want to uprate
things like relays, you join the contacts in series? The idea that the
contacts open faster (as in how quickly the gap forms) and so how much
time the contacts may be exposed to any back EMF?

The heating elment is pretty-much a resistive load - so should'nt be any
back-emf to speak of - just the initial 'oomph' from switching 25A or so
at some random point in the mains cycle

I think that's the thing that might make quite a difference,
especially in making the circuit (the SSR doing it). Is the idea that
the SSR would likely still hold in till after the relay had released
as well somehow, or are we assuming *zero* contact wear (arcing) when
breaking the circuit, even at peak voltage?

- about 1,000-times per firing
schedule.

I'm guessing it's quite a chunky device?


But if the kiln people are pushing the SSR / relay combo I'm guessing
they have had good results from that?

So far - apparently... but early days.

Ok.


snip

The SSRs are often touted by the kiln-manufactures as being 'fail-safe'
- but the manufacturers warn that the SSRs can fail 'on' as well as
'off' - hence the need for a 'safety' relay that can kill power to the
kiln should the main switching device fail 'on'


Understood, a good idea irrespective of the main switching gear.

Cheers, T i m

On Fri, 28 Aug 2020 15:06:32 +0100, Adrian Brentnall wrote:

Spec has forward voltage drop of 1.3 V at full rated current. The
forward drop won't be much less at 26 A so erring on the safe side
1.3 x 26 = 33.8 W.

Thanks for that - I did do the maths but it's reassuring that you cam up
with a similar answer.

B-)

The makers sell a heatsink which one would assume is up to the job at
full rather than half the rated current.

I think I was looking on the cpc site - couldn't find a heatsink there

There was a link further up the thread.

I quite like the idea of the SSR doing the actual switching with a
relay/contactor shorting it out after the SSR has closed and
opening
before the SSR opens. Even though the current being switched by
the
relay contacts is still 26 A it's only at the forward voltage drop
of
the SSR not full mains, much less arcing...

Hmm - I see what you're saying.
Just the Luddite in me doesn't like fitting extra components that
increase the 'failure' potential of the circuit.

Personally for the power switching I'd go for an SSR, PWM and PID
control circuit. Get the PID values right for the PWM the kiln will
heat up as fast as it can, with no or minimal overshoot (there is
some trade off between no overshoot and rate of change), hold at the
desired temperature(s), and cool naturally.

The big worry in this application is that a relay that fails 'on' will
result in a runaway kiln.

Link in the power circuit that melts a 100 degrees or so above the
maximum temperature expected? What temperatures are we tallking
about? Nickle melts at 1453 C, Palladium 1555, Stainless steel
1510...

Maybe a bimetal switch but that would self reset so would need to
latch off some how.

This can be countered to some extent by running a 'safety' relay in
series - controlled by the main controller. If the main relay fails 'on'
then the controller will error out and drop the 'safety' relay, thus
isolating the heating element.

Lots of additional bits to go wrong and shared with the main control
circuitry.

An alternative plan is an independent hardware circuit that monitors
kiln temperature and drops the 'safety' relay should it rise above a
preset temperature. There's a single IC that takes a thermocouple input
and does all the necessary...

Lots of additional bits to go wrong but independant of the main
control circutry.

--
Cheers
Dave.

On 28/08/2020 16:33, T i m wrote:
On Fri, 28 Aug 2020 14:57:27 +0100, Adrian Brentnall
wrote:

snip

Was talking to a kiln manufacturer the other day and their latest 'Big
Idea' is to run a small SSR and a conventional relay in parallel - the
idea being that the SSR turns on, with its zero-voltage switching, and a
short time later the mechanical relay also pulls in, at which point the
ssr drops out. Reverse the sequence when turn-off is required.

That makes loads of sense (from my experience of 'pushing'
semiconductors when switching heavy loads).

Perhaps you're right. Their justification seemed to be that it would
save wear on the relay,

It sounds like it would, where the 'wear and tear' is typically to the
contacts, rather than the general mechanics? I check because you
mention the '1000 times per cycle' and that is a far few times.

If I guessed my relay operates an on-off cycle every 30 seconds and
let's say the average print job lasts 1 hour (can be seconds or the
best part of a day) then that's 7200 times. As mentioned, it is only a
basic (it might have been a Lucas or some such) car type relay and I
feel it will carry on for ever. ;-)

and that they didn't have enough room in their
controller to fit a heatsink to the SSR.

Is their box metal and could you bolt it to that on the inside with a
heatsink on the outside (or wouldn't that help if it's near the
furnace)? Even a length of Ally angle cut to length and bolted to the
(presumed metal) case (with maybe a bit of thermal compound) would act
like a heat pipe?


My box is plastic - but I'm sure I have some suitable heatsinks upstairs
in a box..... if I can but find it!

Just sounded to me a bit like fitting two components where one would do....

Well, in this day and age you would think one should do but it seems
that it can't always, or at least not without other 'costs' (like
excess heat). ;-(

Yes


snip

Maybe I'll try the 'better relay' solution first....

I think the trick might be to find something that is *well* overrated
for the job. I think I also understand that if you want to uprate
things like relays, you join the contacts in series? The idea that the
contacts open faster (as in how quickly the gap forms) and so how much
time the contacts may be exposed to any back EMF?

The heating elment is pretty-much a resistive load - so should'nt be any
back-emf to speak of - just the initial 'oomph' from switching 25A or so
at some random point in the mains cycle

I think that's the thing that might make quite a difference,
especially in making the circuit (the SSR doing it). Is the idea that
the SSR would likely still hold in till after the relay had released
as well somehow, or are we assuming *zero* contact wear (arcing) when
breaking the circuit, even at peak voltage?

I presume that's the operating sequence they were planning...


- about 1,000-times per firing
schedule.

I'm guessing it's quite a chunky device?

The one I was looking at was rated 50A - which seemed suitably 'chunky'



But if the kiln people are pushing the SSR / relay combo I'm guessing
they have had good results from that?

So far - apparently... but early days.

Ok.


snip

The SSRs are often touted by the kiln-manufactures as being 'fail-safe'
- but the manufacturers warn that the SSRs can fail 'on' as well as
'off' - hence the need for a 'safety' relay that can kill power to the
kiln should the main switching device fail 'on'


Understood, a good idea irrespective of the main switching gear.

Yes - very necessary. Especially in a timber-built workshop!

On 28/08/2020 16:34, Dave Liquorice wrote:
On Fri, 28 Aug 2020 15:06:32 +0100, Adrian Brentnall wrote:



The makers sell a heatsink which one would assume is up to the job at
full rather than half the rated current.

I think I was looking on the cpc site - couldn't find a heatsink there

There was a link further up the thread.

Sorry - I'll backtrack and take a look.


I quite like the idea of the SSR doing the actual switching with a
relay/contactor shorting it out after the SSR has closed and
opening
before the SSR opens. Even though the current being switched by
the
relay contacts is still 26 A it's only at the forward voltage drop
of
the SSR not full mains, much less arcing...

Hmm - I see what you're saying.
Just the Luddite in me doesn't like fitting extra components that
increase the 'failure' potential of the circuit.

Personally for the power switching I'd go for an SSR, PWM and PID
control circuit. Get the PID values right for the PWM the kiln will
heat up as fast as it can, with no or minimal overshoot (there is
some trade off between no overshoot and rate of change), hold at the
desired temperature(s), and cool naturally.

The control bit is all taken care of with a very nice little touchscreen
controller https://www.bartinst.com/kilns/34

It's only the power-switching bit that's exercising me at the moment.


The big worry in this application is that a relay that fails 'on' will
result in a runaway kiln.

Link in the power circuit that melts a 100 degrees or so above the
maximum temperature expected? What temperatures are we tallking
about? Nickle melts at 1453 C, Palladium 1555, Stainless steel
1510...

There's the problem - don't go much higher than 820c with a glass-fusing
kiln. Last time I looked I couldn't see anything that would carry 30A
and fuse at that temperature.


Maybe a bimetal switch but that would self reset so would need to
latch off some how.

This can be countered to some extent by running a 'safety' relay in
series - controlled by the main controller. If the main relay fails 'on'
then the controller will error out and drop the 'safety' relay, thus
isolating the heating element.

Lots of additional bits to go wrong and shared with the main control
circuitry.

There is that - independance & all that


An alternative plan is an independent hardware circuit that monitors
kiln temperature and drops the 'safety' relay should it rise above a
preset temperature. There's a single IC that takes a thermocouple input
and does all the necessary...

Lots of additional bits to go wrong but independant of the main
control circutry.

'Lots'? - one IC, a couple of passives and a relay. A switch to ensure
that, once 'tripped' the over-temp lockout remains locked-out...

I may still do it that way - but, short-term, I can let the controller's
own 'safety' output do the work... as that'll be safer then nothing...

The 'safety' relay only switches once per firing schedule, and with no
load on the contacts - so it should be reasonably reliable.. - more
reliable than the 'main' relay, which switches 1,000 times per schedule.

On Fri, 28 Aug 2020 18:11:54 +0100, Adrian Brentnall
wrote:

snip


The control bit is all taken care of with a very nice little touchscreen
controller https://www.bartinst.com/kilns/34

It's only the power-switching bit that's exercising me at the moment.

snip

(Any reason, if you were to go for a more chunky relay / SSR it
couldn't be mounted outside the main controller box, say nearer the
heater terminals?)

Flicking though the instruction manual for your controller reminds me
very much of the Marlin software I use to drive my 3D printer or even
the programming / functional options on the two mobility scooter speed
controllers I've been playing with recently.

Needing a pod to take a couple of little digital voltmeters to allow
me to monitor the voltage on both batteries on either of the two
mobility scooters I'm currently playing with, (yesterday) I opened
Sketchup on my PC and designed the parts (bezel, body and rear).
After designing it and exporting it as an STL file, I opened it in
Repetier-Host and sliced it into .gcode using RH's built in Slic3r. I
then saved the file to my Open Media Vault NAS (running on a RPi) and
then opened Octoprint (running on another RPi connected to my 3D
printer by WiFi in a different room), uploaded the file to the
printers SD card (on a 3D printed case containing the display,
controller screen and input selector knob) and then selected it to
print using the Arduino Mega running Marlin.

https://marlinfw.org/

It probably took longer to type than to do! ;-)

What I was getting to is that I normally print either directly from
the PC (over USB) or save the print file to the SD and then select it
from the controller (locally). When printing remotely using Octoprint
....

https://octoprint.org/

I saw different things on the printers display, features that have
been sitting there all along but I've not used before.

The point is the huge respect I have for the patience, skills and
efforts of all the work the coders put into making this stuff work,
specifically (in my case) because all the software mentioned above is
free / shareware (donations normally made etc).

Marlin comes as a series of modules that you select via a config file
(to suit your particular hardware) and that it compiles when you
upload it into the (Arduino) controller.

The beauty of all the above for me is how nearly all of the hardware
is either generic and / or open source, as is much (all?) of the soft
/ firmware.

I recently *nearly* bought a small commercially made 3D printer off a
mate, till I realised I probably wouldn't be in full control of it as
I am with mine. ;-)

Cheers, T i m

p.s. It looks like you can get open source and even RPi based kiln
controllers. ;-)

https://github.com/jbruce12000/kiln-controller

https://www.instructables.com/id/Bui...Kiln-Controll/

The indestructible uses an SSR that might be of interest to you?

"Note: the SSR can get quite hot when in operation so you might want
to put it on a heat sink. I sit my plastic box on a tin can when
firing." ... ??

On 28/08/2020 21:17, T i m wrote:
On Fri, 28 Aug 2020 18:11:54 +0100, Adrian Brentnall
wrote:

snip


The control bit is all taken care of with a very nice little touchscreen
controller https://www.bartinst.com/kilns/34

It's only the power-switching bit that's exercising me at the moment.

snip

(Any reason, if you were to go for a more chunky relay / SSR it
couldn't be mounted outside the main controller box, say nearer the
heater terminals?)

It _could_ be mounted outside the box - just be neater of it was _inside_
- will depend on how much heatsink it wants/needs

Don't really want to mount it any nearer to the kiln, as the outside of
the kiln approaches 100c when it's running.


Flicking though the instruction manual for your controller reminds me
very much of the Marlin software I use to drive my 3D printer or even
the programming / functional options on the two mobility scooter speed
controllers I've been playing with recently.

Needing a pod to take a couple of little digital voltmeters to allow
me to monitor the voltage on both batteries on either of the two
mobility scooters I'm currently playing with, (yesterday) I opened
Sketchup on my PC and designed the parts (bezel, body and rear).
After designing it and exporting it as an STL file, I opened it in
Repetier-Host and sliced it into .gcode using RH's built in Slic3r. I
then saved the file to my Open Media Vault NAS (running on a RPi) and
then opened Octoprint (running on another RPi connected to my 3D
printer by WiFi in a different room), uploaded the file to the
printers SD card (on a 3D printed case containing the display,
controller screen and input selector knob) and then selected it to
print using the Arduino Mega running Marlin.

https://marlinfw.org/

It probably took longer to type than to do! ;-)

What I was getting to is that I normally print either directly from
the PC (over USB) or save the print file to the SD and then select it
from the controller (locally). When printing remotely using Octoprint
...

https://octoprint.org/

I saw different things on the printers display, features that have
been sitting there all along but I've not used before.

The point is the huge respect I have for the patience, skills and
efforts of all the work the coders put into making this stuff work,
specifically (in my case) because all the software mentioned above is
free / shareware (donations normally made etc).

Marlin comes as a series of modules that you select via a config file
(to suit your particular hardware) and that it compiles when you
upload it into the (Arduino) controller.

The beauty of all the above for me is how nearly all of the hardware
is either generic and / or open source, as is much (all?) of the soft
/ firmware.

I recently *nearly* bought a small commercially made 3D printer off a
mate, till I realised I probably wouldn't be in full control of it as
I am with mine. ;-)

Clever stuff - never got into 3-d printing....
but I can see the fascination.

Toyed with the idea of laser-etching (to 'engrave' on glass - but there
are easier / cheaper ways of achieving the same end)


Cheers, T i m

p.s. It looks like you can get open source and even RPi based kiln
controllers. ;-)

https://github.com/jbruce12000/kiln-controller

I'd not seen that one before.
The one I had seen, and this one, both require the schedule to be input
in a strange format..

They do

Target time : Target temperature : Hold time

while most glass-fusing schedules do

Ramp speed : Target temperature : Hold time

You can use a spreadsheet to calculate between them, but the earlier RPi
controller was driven by time (i.e. I'm at the target time) rather than
Temperature ( as in 'I'm at the target temperature') - which is a bit
different.
In glasswork, a difference of 5 - 10c can make a large difference to the
effect that you get - so temperature-driven is really a necessity...




https://www.instructables.com/id/Bui...Kiln-Controll/

The indestructible uses an SSR that might be of interest to you?

"Note: the SSR can get quite hot when in operation so you might want
to put it on a heat sink. I sit my plastic box on a tin can when
firing." ... ??


Yes - we I don't have a spare biscuit tin grin

Actually - I have a RPi hooked up to my kiln - it monitors the
temperature in the kiln through its own thermocouple and draws a
real-time graph that can be viewed over the LAN.

I must confess I'm not confident in the RPi's ability to run things like
kiln controllers, which need to run, unsupervised, for 8 - 10 hours at a
time, often overnight.

For me - the RPi is just too 'full-featured' - it's go too much going on
within the o/s for me to trust it to keep its mind on the
kiln-controlling job. But then my background is real-time,
safety-critical systems....

So - I did look at making a home-brew kiln controller - but, in the end,
I let the programmers in the USA do the hard work, although it does seem
that I've been helping them debug the thing over the past year or so...

The important part of the process is making things in the kiln - as
that's what brings in the cash - so I decided to concentrate on that...

On Fri, 28 Aug 2020 22:00:17 +0100, Adrian Brentnall
wrote:

snip

(Any reason, if you were to go for a more chunky relay / SSR it
couldn't be mounted outside the main controller box, say nearer the
heater terminals?)

It _could_ be mounted outside the box - just be neater of it was _inside_
- will depend on how much heatsink it wants/needs

Bigger box ... or I was thinking of another box fitted to the back /
side / bottom of that one with the extra stuff in?

Don't really want to mount it any nearer to the kiln, as the outside of
the kiln approaches 100c when it's running.

Ouch.

snip

Clever stuff -

It is indeed. 'Standing on the shoulders of giants' etc.

never got into 3-d printing....
but I can see the fascination.

Well it is fascinating (still to me, when I think about it or when I'm
holding the physical object I only thought of a while earlier) but for
me it's more the practicality. To be able to just think of some
'thing', design it (or download it if it's been done before, from the
likes of www.thingiverse.com) and then be able to use it soon after.
;-)

Be it something new or repairing or enhancing something you already
have. I look at it as an easy n/c variant of my lathe. ;-)

Toyed with the idea of laser-etching (to 'engrave' on glass - but there
are easier / cheaper ways of achieving the same end)

I don't think there is a cheaper / easier way of covering the range of
things you can with a 3D printer (even if you already own a lathe).
;-)

snip


https://github.com/jbruce12000/kiln-controller

I'd not seen that one before.
The one I had seen, and this one, both require the schedule to be input
in a strange format..

They do

Target time : Target temperature : Hold time

while most glass-fusing schedules do

Ramp speed : Target temperature : Hold time

Oh, I wonder why they did it that way when I would have thought that
you could do it any way you could imagine?

You can use a spreadsheet to calculate between them, but the earlier RPi
controller was driven by time (i.e. I'm at the target time) rather than
Temperature ( as in 'I'm at the target temperature') - which is a bit
different.
In glasswork, a difference of 5 - 10c can make a large difference to the
effect that you get - so temperature-driven is really a necessity...

I think there are automatic PID configuration routines you can run on
these diy 3D printers (and commercial ones I should imagine) and then
you can use the output / calculated values to set / tune the printer.


https://www.instructables.com/id/Bui...Kiln-Controll/

The indestructible uses an SSR that might be of interest to you?

"Note: the SSR can get quite hot when in operation so you might want
to put it on a heat sink. I sit my plastic box on a tin can when
firing." ... ??


Yes - we I don't have a spare biscuit tin grin

I would have thought you would want to put the SSR directly on the
tin, not the plastic box it was sitting in!

Actually - I have a RPi hooked up to my kiln - it monitors the
temperature in the kiln through its own thermocouple and draws a
real-time graph that can be viewed over the LAN.

Oh, neat.

I must confess I'm not confident in the RPi's ability to run things like
kiln controllers, which need to run, unsupervised, for 8 - 10 hours at a
time, often overnight.

Ok. FWIW, I've had a RPi3B running a NAS for a couple of years now and
touch it so rarely I've forgotten everything adminny about it. ;-(

It's similar with the one running a multi-TV tuner ... they just seem
to work (and work)?

For me - the RPi is just too 'full-featured' - it's go too much going on
within the o/s for me to trust it to keep its mind on the
kiln-controlling job.

How about the micro controllers, like the Arduino then? My 3D printer
runs on an Arduino Mega and as mentioned, runs print jobs that can be
a day long and where even a fractional error would stand out like a
sore thumb?

https://store.arduino.cc/arduino-mega-2560-rev3
And with a RAMPS controller board:
https://reprap.org/wiki/RAMPS_1.3
(that drives the steppers, the extruder and bed heaters).

But then my background is real-time,
safety-critical systems....

As you say, just as well with a kiln in a wooden shed. ;-)

So - I did look at making a home-brew kiln controller - but, in the end,
I let the programmers in the USA do the hard work, although it does seem
that I've been helping them debug the thing over the past year or so...

And that's the thing ... one thing I like about all this popular /
open source stuff is how many bodies are often working on stuff. It's
not always the case of course, you can sometimes pick something that
happens to then become obsolete or depreciated but if it was working
....

The important part of the process is making things in the kiln - as
that's what brings in the cash - so I decided to concentrate on that...

Oh, absolutely, I only got involved with the 3D printer because a mate
wanted one and didn't have the confidence to be able to cover all the
facets (not that I had ever built or even used one but I had done most
of the parts either myself or commercially). We built it together,
used to run it in his shop (handy to have somewhere to run it were you
could keep an eye on it for 8 hour print jobs) and he sold it to me
when he retired (with the proviso I still printed stuff for him as
required). ;-)

Initially we printed all sorts of stuff (because we could), spiral
vases, figures and personalised key fobs etc but now it's really only
used as an engineering production tool.

Brackets, equipment boxes, special jigs, templates and tools ... the
last serious thing I did before this voltmeter pod was spice rack ends
for my daughter. Oh, when the filament she ordered arrives, I'm due to
print 10 forked 'hooks' (for hanging big 4/ Stihl strimmers up on the
wall). Not for money though, just a returned favour. ;-)

What sort of glassware do you do in yer kiln?

Cheers, T i m

On Fri, 28 Aug 2020 22:00:17 +0100, Adrian Brentnall wrote:

I must confess I'm not confident in the RPi's ability to run things like
kiln controllers, which need to run, unsupervised, for 8 - 10 hours at a
time, often overnight.

Hum, have more confidence....

pi@PiZ-StoveB:/etc $ uptime
10:04:57 up 73 days, 9:38, 1 user, load average: 0.76, 0.63, 0.52

A Pi Zero (sans WiFi or Bluetooth) running a python script to control
the speed of the pump for the circulation between woodburner and
thermal store. The aim is to maintain a few degrees difference
between flow and return irespective of the actual temperature values
and if the woodburner is going flat out or dying down. Flat out it
boils rather too easyly...

Has half a dozen or so 1-wire devices connected that it monitors over
two 1-wire buses, an SSR using PWM to control the pump speed on a
GPIO, a small graphical LCD display SPI IIRC, (ex Nokia phones) to
show what it's up to and provide a menu system for set up controlled
by a rotary encoder on three GPIOs. Ethernet port via an ENC28J60
SPI(?) board.

It's also running nginx as web interface to the logged stove
temperatures pump speed etc (may also at some point, provide a
webinterface to the stove control script) and PiHole to block web
advertising crap for the LAN.

For me - the RPi is just too 'full-featured' - it's go too much going on
within the o/s for me to trust it to keep its mind on the
kiln-controlling job.

OS is Raspibian Lite (buster) so no GUI, completly headless, no
monitor, keyboard, mouse. Only way to talk to it is via the command
line from SSH over ethernet. The display/rotary controller is
confined to the menu system of the stove control script.

But then my background is real-time, safety-critical systems....

There is "real time" as in must react within 10 ns and and "real
time" as in must react within a minute... The stove system is slow to
react, pretty sure the period between each temperature measurment is
a minute. I suspect your kiln is also suitably "laggy".

--
Cheers
Dave.

On 28/08/2020 22:00, Adrian Brentnall wrote:

Actually - I have a RPi hooked up to my kiln - it monitors the
temperature in the kiln through its own thermocouple and draws a
real-time graph that can be viewed over the LAN.

I must confess I'm not confident in the RPi's ability to run things like
kiln controllers, which need to run, unsupervised, for 8 - 10 hours at a
time, often overnight.

I have had Pis running for years uninterrupted without any problem...
(normally only get a reset if there is a power cut!)

For me - the RPi is just too 'full-featured' - it's go too much going on
within the o/s for me to trust it to keep its mind on the
kiln-controlling job.Â* But then my background is real-time,
safety-critical systems....

It does not typically run a true real time os, however for kiln control
there are no hard real time requirements.

If you want a "simpler" option, look at an arduino - much less baggage
to worry about.

So - I did look at making a home-brew kiln controller - but, in the end,
I let the programmers in the USA do the hard work, although it does seem
that I've been helping them debug the thing over the past year or so...

The important part of the process is making things in the kiln - as
that's what brings in the cash - so I decided to concentrate on that...

Yup, often a good plan, it can be easy to get side tracked onto
something "interesting" but ultimately not rewarding (financially at least!)


--
Cheers,

John.

/================================================== ===============\
| Internode Ltd - http://www.internode.co.uk |
|-----------------------------------------------------------------|
| John Rumm - john(at)internode(dot)co(dot)uk |
\================================================= ================/

John Rumm wrote:
On 28/08/2020 22:00, Adrian Brentnall wrote:

Actually - I have a RPi hooked up to my kiln - it monitors the
temperature in the kiln through its own thermocouple and draws a
real-time graph that can be viewed over the LAN.

I must confess I'm not confident in the RPi's ability to run things like
kiln controllers, which need to run, unsupervised, for 8 - 10 hours at a
time, often overnight.

I have had Pis running for years uninterrupted without any problem...
(normally only get a reset if there is a power cut!)

For me - the RPi is just too 'full-featured' - it's go too much going on
within the o/s for me to trust it to keep its mind on the
kiln-controlling job.Â* But then my background is real-time,
safety-critical systems....

It does not typically run a true real time os, however for kiln control
there are no hard real time requirements.

If you want a "simpler" option, look at an arduino - much less baggage
to worry about.

Much harder to 'talk to' than a Pi though. The big advantage of the
Pi (and/or BeagleBoneBlack) is that they are 'proper' computers and
will join a home network just like any other and you can write
programs and such on them rather than downloading like you do with the
Arduino.

--
Chris Green
·

On Sat, 29 Aug 2020 12:39:22 +0100, Chris Green wrote:

snip

If you want a "simpler" option, look at an arduino - much less baggage
to worry about.

Much harder to 'talk to' than a Pi though.

But isn't that part of the point in that we are trying to make it
'KISS'?

The big advantage of the
Pi (and/or BeagleBoneBlack) is that they are 'proper' computers and
will join a home network just like any other and you can write
programs and such on them

True, but if the role is something that needs to be pretty routine and
efficient, wouldn't something like a micro-controller be better?

rather than downloading like you do with the
Arduino.

FWIW, I've had Arduino's / ESP32 etc talking to the Internet, running
as Web servers and connecting to Ethernet (Ethernet shield in my case)
and Bluetooth etc with no problem.

https://store.arduino.cc/arduino-eth...v3-without-poe

The ESP32 even had a SIM slot in it and so could send / receive (and
potentially respond to) tests (plus do WiFi directly etc).

https://www.espressif.com/en/products/socs/esp32

Given my 3D printer that is continuously (and often for many hours at
a time) doing several orders more processing than I suspect Adrian's
kiln controller (managing two heaters, a fan and 3 independent stepper
motors) on a 10 quid, 16 bit micro controller (Arduino Mega), I think
it would be more than up to the task. ;-)

And I quite like the 'fit and forget' aspect, nothing to get corrupted
by use (uSD cards) or upset because of how / when it was turned off.

I think Adrian (= most of us?) would prefer a simple / dedicated
'appliance' in this sort of role, not a 'GP computer'?

Not suggesting a RPi couldn't also do it, just that it may be
considered overkill?

Look at Dave L's usage load stats:

"pi@PiZ-StoveB:/etc $ uptime
10:04:57 up 73 days, 9:38, 1 user, load average: 0.76, 0.63, 0.52"

Cheers, T i m

On 29/08/2020 10:16, Dave Liquorice wrote:
On Fri, 28 Aug 2020 22:00:17 +0100, Adrian Brentnall wrote:

I must confess I'm not confident in the RPi's ability to run things like
kiln controllers, which need to run, unsupervised, for 8 - 10 hours at a
time, often overnight.

Hum, have more confidence....

grin
That's just me - ultra-cautious!

pi@PiZ-StoveB:/etc $ uptime
10:04:57 up 73 days, 9:38, 1 user, load average: 0.76, 0.63, 0.52

A Pi Zero (sans WiFi or Bluetooth) running a python script to control
the speed of the pump for the circulation between woodburner and
thermal store. The aim is to maintain a few degrees difference
between flow and return irespective of the actual temperature values
and if the woodburner is going flat out or dying down. Flat out it
boils rather too easyly...

Has half a dozen or so 1-wire devices connected that it monitors over
two 1-wire buses, an SSR using PWM to control the pump speed on a
GPIO, a small graphical LCD display SPI IIRC, (ex Nokia phones) to
show what it's up to and provide a menu system for set up controlled
by a rotary encoder on three GPIOs. Ethernet port via an ENC28J60
SPI(?) board.

It's also running nginx as web interface to the logged stove
temperatures pump speed etc (may also at some point, provide a
webinterface to the stove control script) and PiHole to block web
advertising crap for the LAN.

Sounds good....


For me - the RPi is just too 'full-featured' - it's go too much going on
within the o/s for me to trust it to keep its mind on the
kiln-controlling job.

OS is Raspibian Lite (buster) so no GUI, completly headless, no
monitor, keyboard, mouse. Only way to talk to it is via the command
line from SSH over ethernet. The display/rotary controller is
confined to the menu system of the stove control script.

I've not looked at Ras Lite - thanks - I'll take a look...


But then my background is real-time, safety-critical systems....

There is "real time" as in must react within 10 ns and and "real
time" as in must react within a minute... The stove system is slow to
react, pretty sure the period between each temperature measurment is
a minute. I suspect your kiln is also suitably "laggy".


I think the commercial controller I have samples temperature every
second - this particular kiln is 2ft x 4ft x 12", fibre-insulated, with
6 or 7kW of heating in the lid - so it can actually heat up quite fast.
It does adjust its PID parameters on-the-fly - so it adapts to the type
of kiln it's controlling - which is important because the controller
could be fitted to any type of glass or pottery kiln.

Older brick-built kilns are a bit like supertankers - they take a lot of
time to start & stop...

I'm sure that it would have been possible to use a Pi as a kiln
controller - but for me it was more cost-effective (or 'time-effective'
if you like) to buy one ready-built..

With 'realtime, safety-critical' I'm talking about things like the early
automatic guided vehicles, factory automation systems and petroleum
loading systems - all the kind of applications where you can't really
allow the possibility of the control software going walkabout while
'something' is left on and unsupervised..

I'm afraid this results in a certain amount of paranoia in my designing
- hardware watchdogs monitoring the health of the computerised control
system, and all that sort of thing....

Possibly the lesson that sticks most in my memory was having to manually
empty a 1 tonne weigh-hopper full of molasses - when the formulation
called for 50kg, but the control system turned on the screw feeder,
tried to print out the log record, but found that the dot-matrix printer
was out of fanfold paper - so it just sat, and waited, and waited....
while the molasses kept coming!

Happy to say that it wasn't my code - but you tend to remember these
lessons!

On 29/08/2020 12:39, Chris Green wrote:
John Rumm wrote:
On 28/08/2020 22:00, Adrian Brentnall wrote:

Actually - I have a RPi hooked up to my kiln - it monitors the
temperature in the kiln through its own thermocouple and draws a
real-time graph that can be viewed over the LAN.

I must confess I'm not confident in the RPi's ability to run things like
kiln controllers, which need to run, unsupervised, for 8 - 10 hours at a
time, often overnight.

I have had Pis running for years uninterrupted without any problem...
(normally only get a reset if there is a power cut!)

For me - the RPi is just too 'full-featured' - it's go too much going on
within the o/s for me to trust it to keep its mind on the
kiln-controlling job.Â* But then my background is real-time,
safety-critical systems....

It does not typically run a true real time os, however for kiln control
there are no hard real time requirements.

If you want a "simpler" option, look at an arduino - much less baggage
to worry about.

Much harder to 'talk to' than a Pi though. The big advantage of the
Pi (and/or BeagleBoneBlack) is that they are 'proper' computers and
will join a home network just like any other and you can write
programs and such on them rather than downloading like you do with the
Arduino.


And it's that very complexity (to my mind) that makes them less ideal
for safety-critical applications...

Don't get me wrong - they're great devices - and I've used them in
monitoring situations.

On Friday, 28 August 2020 09:41:42 UTC+1, Adrian Brentnall wrote:
On 28/08/2020 08:29, The Natural Philosopher wrote:
On 28/08/2020 07:36, Adrian Brentnall wrote:

There's a part of me that rather likes to hear that relay going
click-click while the kiln's firing - which you wouldn't get with a
solid-state relay, of course..

Unless you used it to drive a mechanical relay as well as the kiln...

Ha! - I had toyed with the idea of adding some kind of 'sounder' to
replace the click!

Put an R across an AWD, add R & C in series with those and you have a 240v clicker. Of course you could just use the old fried relay with its switch connections sealed off.


NT

On 29/08/2020 12:39, Chris Green wrote:
John Rumm wrote:
On 28/08/2020 22:00, Adrian Brentnall wrote:

Actually - I have a RPi hooked up to my kiln - it monitors the
temperature in the kiln through its own thermocouple and draws a
real-time graph that can be viewed over the LAN.

I must confess I'm not confident in the RPi's ability to run things like
kiln controllers, which need to run, unsupervised, for 8 - 10 hours at a
time, often overnight.

I have had Pis running for years uninterrupted without any problem...
(normally only get a reset if there is a power cut!)

For me - the RPi is just too 'full-featured' - it's go too much going on
within the o/s for me to trust it to keep its mind on the
kiln-controlling job.Â* But then my background is real-time,
safety-critical systems....

It does not typically run a true real time os, however for kiln control
there are no hard real time requirements.

If you want a "simpler" option, look at an arduino - much less baggage
to worry about.

Much harder to 'talk to' than a Pi though. The big advantage of the
Pi (and/or BeagleBoneBlack) is that they are 'proper' computers and
will join a home network just like any other and you can write
programs and such on them rather than downloading like you do with the
Arduino.

You can stick an ethernet "shield" on a arduino, then talk to it that way.


--
Cheers,

John.

/================================================== ===============\
| Internode Ltd - http://www.internode.co.uk |
|-----------------------------------------------------------------|
| John Rumm - john(at)internode(dot)co(dot)uk |
\================================================= ================/

John Rumm wrote:
On 29/08/2020 12:39, Chris Green wrote:
John Rumm wrote:
On 28/08/2020 22:00, Adrian Brentnall wrote:

Actually - I have a RPi hooked up to my kiln - it monitors the
temperature in the kiln through its own thermocouple and draws a
real-time graph that can be viewed over the LAN.

I must confess I'm not confident in the RPi's ability to run things like
kiln controllers, which need to run, unsupervised, for 8 - 10 hours at a
time, often overnight.

I have had Pis running for years uninterrupted without any problem...
(normally only get a reset if there is a power cut!)

For me - the RPi is just too 'full-featured' - it's go too much going on
within the o/s for me to trust it to keep its mind on the
kiln-controlling job.Â* But then my background is real-time,
safety-critical systems....

It does not typically run a true real time os, however for kiln control
there are no hard real time requirements.

If you want a "simpler" option, look at an arduino - much less baggage
to worry about.

Much harder to 'talk to' than a Pi though. The big advantage of the
Pi (and/or BeagleBoneBlack) is that they are 'proper' computers and
will join a home network just like any other and you can write
programs and such on them rather than downloading like you do with the
Arduino.

You can stick an ethernet "shield" on a arduino, then talk to it that way.

Yes, but it isn't possible, even with an ethernet shield, to simply
power it up and then run programs on it. You still have to fire up
the IDE on the 'host' and download a program of some sort to the
Arduino for it to 'do' anything.

An Arduino based solution is fine in many cases, and can be very
cheap, especially if you want/need more than one. Another (minor)
downside of Arduino is that you are mainly limited to using the
Arduino script language which is basically 'C', you can't write
Arduino software in Python or anything like tahts. However if
you want a minimal system then Arduino is probably the way to go.

A Pi or Beaglebone has the advantage of being usable standalone, you
can plug a keyboard and monitor in and it works.

--
Chris Green
·

On Sun, 30 Aug 2020 09:22:40 +0100, Chris Green wrote:

snip

You can stick an ethernet "shield" on a arduino, then talk to it that way.

Yes, but it isn't possible, even with an ethernet shield, to simply
power it up and then run programs on it. You still have to fire up
the IDE on the 'host' and download a program of some sort to the
Arduino for it to 'do' anything.

But the same applies to a RPi, you still have to program it to do
anything IO and that's most of the functionality of this sort of role?

An Arduino based solution is fine in many cases, and can be very
cheap, especially if you want/need more than one. Another (minor)
downside of Arduino is that you are mainly limited to using the
Arduino script language which is basically 'C', you can't write
Arduino software in Python or anything like tahts.

Not my area but that wouldn't bother most people who can code and
certainly would bother those who couldn't (RPi or Arduino). The
difference may be that with the Microcontrollers there are loads of
working examples out there for people to just download and install.

None of this 'If you are running Buster 8 to this and if 9 do that
..... ;-(

However if
you want a minimal system then Arduino is probably the way to go.

By 'Minimal system' you mean something that can manage a 3D printer
with two independent heaters, fan, two thermistors, screen, input
selector, SD card reader and 4 stepper motors. ;-)

A Pi or Beaglebone has the advantage of being usable standalone, you
can plug a keyboard and monitor in and it works.

I've not played with a Beagleboard but I think the point is having to
maintain an OS isn't an *advantage* in these scenarios.

Adrian was concerned about safety and we all know that the simpler a
solution the lower the chance of failure (MTBF).

So, with a RPi you *have* to first install an OS onto an SD card (that
have a finite lifespan). No need on an Arduino. However, you could
swap out the SD card with a spare on a RPi, whereas you would probably
swap out the entire Arduino.

With the RPi you have to program it to make it do what you want, that
process possibly being more complicated given the rage of IO available
(I've not tried but assume an Arduino may have a greater range of IO
available by default, analogue / digital inputs and outputs (PWM
etc), I2C etc).

Many appliance solutions may only have a basic display that could
easily allow you to (fully) manage the appliance but may not be good /
big enough to support a CLI OS. Arduino would need a support PC, RPi
just a screen and kbd (as you say).

I've probably got 10 RPi's here (some running 24/7 (NAS, TV, Weather,
CCTV)) and even more Arduino's, but only one used regularly (3D
printer). However, if I wanted some appliance like solution I'd first
look to the Arduinos for price and appliance like simplicity.

I have the basis for an Arduino based semi-automated model railway
controller, an electric outboard test tank and a battery capacity test
station (just not the time to hook it all up). ;-(

Cheers, T i m

On 30/08/2020 10:49, T i m wrote:

Adrian was concerned about safety and we all know that the simpler a
solution the lower the chance of failure (MTBF).


The way one normally deals with safety critical software systems, is by
working very hard to avoid any of the software being safety critical in
the first place. Typically this is done with hardware interlocks, since
they can usually be rigorously "proven" much more easily.

So for example with a kiln, you could have a max temperature sensors
that is hardwired into your safety relay/contactor, so should the temp
ever not be indicated as safe by all the sensors it trips out power to
the heaters. (software can obviously finesse that and log and report the
event etc)



--
Cheers,

John.

/================================================== ===============\
| Internode Ltd - http://www.internode.co.uk |
|-----------------------------------------------------------------|
| John Rumm - john(at)internode(dot)co(dot)uk |
\================================================= ================/

On Sun, 30 Aug 2020 13:22:20 +0100, John Rumm
wrote:

On 30/08/2020 10:49, T i m wrote:

Adrian was concerned about safety and we all know that the simpler a
solution the lower the chance of failure (MTBF).


The way one normally deals with safety critical software systems, is by
working very hard to avoid any of the software being safety critical in
the first place.

Oh, agreed, however, a simple firmware based system might be
inherently 'safer' than an OS / PC based system in the first place.

Typically this is done with hardware interlocks, since
they can usually be rigorously "proven" much more easily.

Yup, or like having thermal fuses in on the extruders and heated beds
of our 3D printers. ;-)

So for example with a kiln, you could have a max temperature sensors
that is hardwired into your safety relay/contactor, so should the temp
ever not be indicated as safe by all the sensors it trips out power to
the heaters. (software can obviously finesse that and log and report the
event etc)

Understood.

Given the code for an Arduino is held in NV RAM or prom/ whatever, I
would see it as less vulnerable to corruption than a fully 'live',
re/writeable OS sitting on any form of PC. I'm assuming it would be
easy to include an electronic watchdog timer on both an RPi and
Arduino but nothing (outside of external protection, as you highlight)
would work against a shorted heater driver / relay. [1]

Cheers, T i m

[1] Along those lines I've dug out a Playstation PSU I bought a while
ago (recommended by someone here, Theo possibly?) that I'm looking to
replace the current frame PSU I have in the 3D printer because it has
a built in ATX type low lever 'Enable' function that could be driven
by the controlling PC / RPi and so add *another* level of protection.

'If extruder / bed go over x or y DegC then cut power to printer'.

(Where the values are ideally below the levels of the thermal fuses
but above the peak printing temperatures). ;-)