Evaluating Raspberry Pi As A Programmable Logic Controller
It should be no surprise to many that one can use a Raspbery Pi SBC as an industrial controller, but is it any good at that? That was the question which [Dough Reneker] and [William Shaffer] built a test rig to see how a Raspberry Pi performs in head to head tests. They compared a Python-based control loop on a Raspberry Pi 3B against an C0-12DD1E-2-D AutomationDirect CLICK Programmable Logic Controller (PLC) using a simple water heating example.
A major snag with using the Raspberry Pi as a PLC is the lack of industrial I/O capacity. This requires additional hardware, in this case adding a four-channel ADC board as well as a custom board to condition the signals. The Raspberry Pi looks for 0-3 V inputs where industrial control applications are usually in the -10 to 10 V range and often use a 4-20 mA current loop.
Using a PLC leverages so-called ladder logic, where each action depends on conditions. With each update scan, the PLC ensures that all input conditions are translated into the appropriate output conditions in real-time. It’s only job is to monitor the process at hand and it does this very well.
Here the flexibility and generic nature of the Raspberry Pi running Linux was a disadvantage. Unlike the PLC, the lack of a hard real-time OS means you can’t guarantee the Pi will be as responsive to changing inputs.
The behavior of the two systems showed that while both did the task they were programmed for, the Raspberry Pi was decidedly more erratic. Although one could program around a lot of these issues (presumably using Linux in stripped-down, soft real-time configuration with interrupt-driven native code), the effort needed to make a Raspberry Pi system suitable for an industrial environment shows why single-board computers haven’t seen adoption as replacements for PLCs.
36 thoughts on “Evaluating Raspberry Pi As A Programmable Logic Controller”
To be fair, is Automation Direct exactly what one would consider an unbiased source? They literally sell PLCs.
This is where the beaglebone would have an advanage due to the programmable realtime units. but the pi’s price is awesome, perhaps arduino or teensy as the controller, programmed thru wireless pi zero running a plc web based interface to update the arduino? price could still be pretty low, getting the 4-20 currrent loops is a bit of an issue tho. I like the industrual application.. you could buy a lot of these for the price of an allenbradley plc… and the ab software for programming is horrible, looks the same as it might have been in 1990. real bad hmi software….
LinuxCNC comes with a built-in classic-ladder PLC and a realtime kernel.
(Beta-release) SD-card image for the Pi4 here: https://www.linuxcnc.org/iso/
LinuxCNC also has drivers for both the built-in GPIO and some fairly competent external IO options, Google 7c80 and 7c81Python, for a PLC “emulator”, really?
Why not use Java?
Java would be at least 100X faster, and would get faster on each function iteration!
It would get so fast, it would heat the water before the inputs registered!
The Pi-4 would be great for java, but i’d recommend the 8GB model, since Java requires it, 16Gb would be even better.
4 cores is the sweet spot for java, although 8 cores or 8C/16T would be even better.
It would put sloooow python, and very slow C/C++ and even ASSembly to shame!
(Says the man whose company poisoned Java)
B^)The idea of “Bill Gates” pushing *Java* is the real troll here.
He could have loaded Codesys into the raspberry pi and run it as a PLC…
Wrong place, sorry…
Garbage collection is non-determinate. You can’t guarantee the execution time of your code as the result.
Also worth looking at the OpenPLC project https://www.openplcproject.com/runtime/raspberry-pi/. However, these implementations are clearly not suitable for an even mildly safety critical application.
PLC programming is its own can of worms, like trying to wrap your head around the idea that your program has to execute in the allotted cycle time (e.g. 40 ms) or it just gets rudely interrupted, OR, the I/O variables change while the program is executing and the program doesn’t know that just happened. Depends entirely on the system whether you’re even allowed to do a “main” loop that never exists.
I once asked a PLC programmed what would happen if I made a loop that iterates a hundred times, the answer “It would use a lot of CPU”. Then I asked what would happen if I made it run a thousand times, “It would use a lot of CPU”, a million times? “A lot more CPU”. To this day I don’t know whether he meant it would need a faster CPU, or whether the PLC would somehow assign more resources to complete the code within the cycle time.
It just runs the loop. If the whole program completes within the cycle time there is no problem, but the more times your loop runs the bigger part of the computations per cycle it will use. If you don’t meet the cycle time you need to increase it, get a better CPU or, if you fail only sporadically, increase the acceptable miss rate
That’s what makes it weird. It’s like living in a “Memento” world where you have to start over every few milliseconds. Save state, then continue the next cycle.
I mean, I get where the whole PLC logic is coming from. The Ladder Logic programming style replicates relay logic, which changes state ever 1/100th or 1/120th of a second when the AC voltage goes to zero and relays can switch without arcing their contacts, so all the logic has to find its state before the next zero-crossing comes.
Or thyristors/triacs which can only switch off when the current reaches zero, so they latch on until the next zero-crossing.
Probably the biggest problem with a Pi (or Beagle, or Arduino, the latter less so) is the unsuitability of the platform for life critical applications out of the box. Would you control an elevator hoist motor controller and the elevator car brakes with a Pi? Even the cheap little PLCs are designed to fail in predictable ways, have extremely constrained programming (viz the ladder logic) so the effect of a failure of a sensor or output circuit is knowable. I don’t know that PLC ladder logic is “provably correct” in a formal sense, but certainly, one can pretty easily write out the ENTIRE fault tree, given the ladder logic. And it’s easy for the mfr of the PLC to write and test the software that runs the ladder to verify that it is correct.
This is not true of someone writing Python, Java, C, or what have-you on a complex computer with a variety of i/o devices with non-deterministic behavior. Garbage collection and similar things are really a second order concern – there are much bigger ones.
Look at the cases where the Nest thermostat accidentally turned off the heat in people’s houses leading to frozen pipes, etc.
That said, things like the Beagle, Arduino, etc. do provide great value for a lot of applications, particularly for home hackery.
It’s the difference between “simple programmers” aka “code monkeys” and real engineers.
if the elevator controller fails, I’d hate to be the engineer on the project.
If the java crapplet fails, and deletes the files on the users computer, boo hoo, sucks to be you.
Remember, “NO WARRANTY”, or “FITNESS FOR PURPOSE” and “KNOWN DEFECTS”.
Then again, remember in the good old USA, everyone is an engineer , the guy who changes the TP rolls is the building engineer.
> Then again, remember in the good old USA, everyone is an engineer , the guy who changes the TP rolls is the building engineer.
As is the random dude claiming to be a “Real Engineer” in the comments of a HaD post.
What he said!!!
I mean, what Real Engineer said !!!
It is not a problem, if you use the correct tool for the job. In a lot of machines the safety side is simple enough, that you can use e-stop buttons and safety relays to stop the machine and you don’t even need to incorporate it to the machines actual programmable functionality.
Most of the industrial PLCs have no verified safety functionality at all.
As for languages, wether you use the IEC languages (which ladder is one of), python, C, visual basic or some language of your own, might really be a problem to the people if at some point the machine has to be enhanced, or if it’s a badly made program and you need to dig in the code to see when a sensor fails then maintenance folks aswell. Otherwise, whatever suits the developer the best and whatever the client allows, use that.
Safety languages are usually Ladder and FBD. To verify them at runtime, the safety program compiler makes a mirror program and compares that the result is the same in both programs plus there are other things the safety runtime monitors. Plus there are other concepts like multiple channels etc. that are used in safety.
The Nest problem is not really a safety issue, it failed in the correct direction atleast. It’d be a bigger problem if it failed the other way and managed to get the house on fire, although i doubt it’s possible.
As you said a bit differently, there are a lot of places where you can use small embedded systems and soft PLCs without having the industrial features. It really comes down to what kind of environment it is to be run in, if it really needs to be updateable/upgradable and what the developper is familiar with and what client wants. PLCs are used, because they are not only industrial grade hardware, but have a full development environment. They have quarantees and standardized interfaces etc.
+1 the programming is ****ing horrible though. Pretty sure uncle Edsger wouldn’t have had anything nice to say about PLCs
Here’s a great talk from PyCon 2019 on using Python (via raspberry pi) to talk to PLCs and a demonstration with a stop light:
The one thing comes to my mind when I hear PLC is “always fail safe”. That when there is a breakdown or a fault, that no one is injured, looses a limb or dies.
A RPi in an industrial setting, I do not know. Like for example after a number of writes the SD cards will fail read only, if this happened at a critical time, will it fail safe ? You could spent a lot of time trying to shoehorn it to mostly fail safe, but getting it to “always fail safe” I do not know.
Thats not really what PLC means. Even though the PLC manufacturers have a real knowledge of the hardware (unlike people using RPis) and have tried to make them functional and trustable (within the limits of economy), regular PLCs can fail “unsafely” and usually it’s the I/O electronics that fail and it is not uncommon for them to fail “unsafe”. Unsafe in quotes, because regular stuff is not meant to be used in safety functions.
Obviously it’s wise to try to make system as failsafe as possible even if it doesn’t have a safety requirement in itself. A machine failing too often or destroying itself within a safe environment really eats the trust in you anyway.
That’s why there are safety PLCs and other safety components, which are use for the safety parts of the machine.
We use these: https://www.ccontrols.com/basautomation/baspi.php
They have all the standard industrial inputs: 0-10V except current loop, use NTP for clock, support Ethernet or Wi-Fi, and support BACNet.
Even with PoE the 1Gb rpi4 and the BASpi baord is still cheaper than the PLC you referenced.
I can respect a company for doing a writeup about how industrial PLC are better suited for their specific app than a pi. My industrial plant running friends talk to me regularly about how horrible it is to wait for industrial control parts to come while their plant is functionally impaired and they ask about using a Pi on a regular basis. The writeup is absolutely correct that the purpose built PLC is better suited. The biggest issue is cost. Right up front, It seems like the industry supporting industrial automation was built on the assumption that downtime is so expensive they can justify any cost. They are not wrong, but it burns every time they order a replacement thingy. I like that he makes this video we could take as a sales pitch for how to disrupt the PLC industry.
1. RTOS – don’t bother getting all fancy until you stop interrupting me
2. Native voltages – -10 +10 and industrial power is really dirty, handle it.
3. Form factor – Din rails, cabinet mounting
4. Load up on high quality ADCs
5. Modularize – Brilliant people run these systems, but save their brain space for the hard stuff, make this easy.
6. UI – GnuRadio seems like it would work. Interface with 50/60hz um… radio signal coming down the mains.I think an esp32 may have been a better camparison.
When the part costs 800 dollars you don’t necessarily have live spares onsite. When the part costs a buck as a chip and 10-20 as a module, you would have a dozen just in case. Make it so it works with the industrial components, as far as WIPO/DMCA will allow and see if kickstarter isn’t fully funded right off the bat.
Same thing with hot tub controllers. Massive racket, shouldn’t be a pi, but shouldnt be 800 a board for measurements and relays with safety checks.
I guess this is sort of the point of the video, but a RPi seems like a particularly weird thing to even consider as a PLC replacement.
Obviously a stock kernel is partly to blame for the erratic behavior they got. A realtime linux kernel and some other tweaks might make the solution at least kinda sorta work. But the bottom line is that a full-fledged Linux-based RPi is really just the wrong fit. You’re churning along at a gigahertz or more to unreliably fiddle a couple of pins and interrupts. Something the lowliest 5 cent Chinese micro could just about do in it’s sleep.
An apt comparison, really, since AFAIK, the core of most PLCs are themselves fairly simple 16 or 32 bit microcontrollers. The units cost an arm and a leg, sure, but what you’re paying for isn’t CPU horsepower or advanced hardware. The price-premium is for the overall industrial bulletproofness, plus ultra long term product line support (the ability to buy a replacement part or compatible module to plug into your 30 year old potato chip production line or whatever).
If you just want to add some automation to your basement IPA home brewing operation, a DIY approach is totally feasible, but I would think the place to start is probably just a simple Arduino, Cortex, ESP32, etc. You can get dev boards or shields with ethernet, if that’s your wont, and you can probably even find off-the-shelf add-on boards for whatever input level translation or relay driving you need to do.
You can probably even do ladder logic programming. The google suggests there’re already at least a few projects out there that can compile ladder logic diagrams straight into AVR or PIC code.
One reason to consider a Pi is that you might be able to go to a shop and just buy one.
(Until Maplin closed down you could buy them even on a Sunday in the UK)You can typically buy the smaller PLCs over the counter at an electrical supply place catering to the trade. Probably not on Sunday, but Monday through Saturday for sure.
And of course, for mail order, you can easily get one in a couple days
https://www.standardelectricsupply.com/brand-siemens/siemens-6ed10521fb080ba0-programmable-logic-controller-module/sku-V4319-6ed10521fb080ba0
https://www.factorymation.com/SG2-12HT-D
The task chosen for the comparison is a joke and the implementation on the RPi was made by someone who had no clue how to do it properly.
The task is to sample inputs once per second and to update outputs 60 times per second. Basically they are implementing a PWM in software. They could have used the I2S interface to queue the output values for a whole second in advance.
They also say that the 1 Hz input acquisition is not synchronized to the 60 Hz output generation. Why didn’t they use only a 60 Hz timer that fetches inputs every 60th time?Good point as it would be easy connect an Arduino to the rPi over hard wired Aux(Tx/Rx) ports and have it handling 5V signaling with both digital and analog IO and some simple development GUI like Scratch creating the configuration and notifications. But I think the author had a motive to show a less than optimal solution so the PLC market keeps spending big bucks for simple micro-controller type functionality. What’s also missing is how the rPi can provide both local and remote UI capabilities where as the PLC setup requires more $$ for monitoring and remote control capabilities.
The main problem with the RPi in a PLC role is that the components are not industrial temperature related. This role really calls for an industrial rated SOM (Variscite, etc.) The other challenge would be supply chain – aka EOL management.
There are also some Arduino solutions out there such as Rugged Circuits https://www.rugged-circuits.com/ which also has an industrial rated ecosystem as well (i/o boards).
(I’ve no fiduciary interested in them, just a happy customer)
One thing that I hardly ever see anyone talk about when it comes to RPI for industrial applications.
This is temp. RPI does NOT have the temp range for industrial applications. PERIOD!
The second major hurdle is that they dont even sell them with locking uSD card holders anymore. I don’t know about you, but I am not going to have my company run from a device that could have its main storage media be able to fall out due to vibration, or fail with extreme temps. No thanks.Beagle Boards have soldered on eMMC, no SD card required. Your comments about temperatures are well taken – and as someone else pointed out, the DC power is pretty ratty in industrial applications. So now you need a suitable DC power supply for your Pi, and then you need appropriate peripherals to give opto-isolated in/out or relays. Pretty soon, you’ve got a $30 Pi, plus $50 in other stuff (a box to hold it all) – The $90 industrial “smart relay” looks pretty attractive in that context.
As neat as a raspberry Pi is, there is no way it is a suitable replacement for a PLC. PLCs are meant to be highly reliable, that is not something that can be said about a consumer device like a Raspberry Pi.
Rebooting your home made media centre or garden sprinkler that is controlled by a Pi is no big deal. Something crashing that is controlling heavy machinery is a whole different kettle of fish.
This is a classic case of person with hammer, sees every problem as a nail.
Leave a Reply
This site uses Akismet to reduce spam. Learn how your comment data is processed.
Search
Never miss a hack
Follow on facebook Follow on twitter Follow on youtube Follow on rss Contact us
Subscribe
If you missed it
Our Columns
