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.
But isn't that part of the point in that we are trying to make it 'KISS'?
True, but if the role is something that needs to be pretty routine and efficient, wouldn't something like a micro-controller be better?
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.
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
<grin>
That's just me - ultra-cautious!
Sounds good....
I've not looked at Ras Lite - thanks - I'll take a look...
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!
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.
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
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.
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?
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 .... ;-(
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. ;-)
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
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)
Oh, agreed, however, a simple firmware based system might be inherently 'safer' than an OS / PC based system in the first place.
Yup, or like having thermal fuses in on the extruders and heated beds of our 3D printers. ;-)
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). ;-)
HomeOwnersHub website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.