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.
To be fair, is Automation Direct exactly what one would consider an unbiased source? They literally sell PLCs.
Exactly that, they’ve been pushing the “our PLCs better than rPi” without asking the real question.
They also ignore the fact that the RaspberryPi is currently being sold as a PLC… https://phytools.com/products/kunbus-revpi-core-3
I had to use the products from Kunbus.
They are seriously overpriced and full of bloatware. Would not recommend.
I don´t know about the others (https://www.industrialshields.com, https://www.pixtend.de, …) or ClickPLC, I can only talk about my experience with Kunbus.
Indeed – I did see them on the OpenPLC message board. I think most people were looking to take their hardware and strip out the OS and bloat.
Then this came on the market with some IO built in: https://www.sferalabs.cc/iono-pi/
About the same price as the Kunbus, but already ahead in the game on industrial IO.
I’m looking forward to what happens in a few months as companies start getting their hands on the CM4… IEEE 1588 for EtherCAT, easy RS-485 isolation with simple hardware on the baseboard, PCIe…
I would like to suggest Pro Pi, which is an industrial raspberry cheaper than Kunbus and at the same time with more featured sensor and interfaces.
http://www.propi.it
Don’t get me wrong, rpi, arduino, beaglebone etc are great platforms for the hobbyist and small r&d projects but standardized industrial platforms they are not. Yes. One could go through some serious mental gymnastics to make one of these function like a plc but a plc they are not. Plc’s have maintained their dominate hold on the industrial market for multiple reasons. Being able to build a sub $200 arduino system is not a reason to replace a plc.
I’m in the process of designing a system costing in excess of a million dollars. Why cobb something together that may do the job, require low level interrupt driven logic, copious amounts of validation work, i/o components that require custom builds each time a component fails and an end product that looks like a hokey rats nest of wires? What happens when a component fails on the custom IO board that you built at 2 AM on a Sunday when you’re on your 10th anniversary trip to the Bahamas or at your only kids wedding? Oh yeah and the company is losing $10k a minute while you’re trying to remember the pinout.
That kind of a platform on a production system will likely give your previous company nightmares for years to come until they finally pay through the nose to replace it.
Vendor lock-in and apathy is why PLCs persist as they do today. In so many ways, the automation industry is ailing and failing – and they’re happy to sell antiquated hardware and buggy software for premium prices, with the full support of many guys that haven’t had to learn anything new in decades… The apathy, the lack of technological progress in the industry, as a whole, is surreal. Those multimillion dollar projects, most of that cost is in? Those very same hardware and software solutions that haven’t truly evolved in decades.
From a Maintenance perspective, many of us are well versed with AB, siemens, GE and other PLCs, What manufacturing company is going to want to spend $$$ to train their mechanics to work wi Pi ?
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….
Say you are setting up a factory line that is costing tens or hundreds of thousands of dollars, you most definately want a controller that is proven and *predictable*.
As the author points out, a PLC is designed for industrial applications and reliability. A PC (raspberry or whatever) is made to a price point and there is usually no skin off someones nose if you have to reboot it a couple of times or the timing is off by a few milliseconds and a couple of frames are dropped.
Hardware : support (available interfaces) without having to roll your own.
Software : I *hate* ladder logic, but it has it’s place. Was that python 2 or pyton 3 that I need? And do I really need to talk about things breaking when a patch or update happens?
Each has its’ place, and it will remain that way for the forseeable future.
Not sure about the Beaglebone. Programming the PRUs is definitely doable but painful.
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 7c81
And you can run OpenPLC (openplc.org) on LinuxCNC to get your full ISO PLC editing and management suite…
With the CM4 RPi having an IEEE1588 NIC, we can now also guarantee network timing… Most new PLCs are looking at EtherCAT rather than a proprietary IO bus with vendor lock-in, and there’s no reason you couldn’t use OpenPLC as your head-end – the whole code path is auditable.
With LinuxCNC and OpenPLC on RPi 4B, I’m seeing loop reaction times in the steady 10-12uS area – which is IO limited.
Python, 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.
Yes the water will not be heated correctly if the timing is off by even a microsecond.
Write your Java so no object ever goes out of scope.
Put another way: ‘Write Fortran in Java’.
You can write Fortran in any language.
Viola! Garage collection becomes non-issue.
Java?? write C++ app optimized to raspi , and go faster even access gpio and without issues .
Raspi as plc will needs a fast boot option (until now i didnt know how to reset it in 1sec or 2sec max like a plc), probably with any kind of stripped operating system.
But is like comparing apples with oranges, both are fruits but …
Yes indeed the water heater requires sub nanosecond timing! We can’t be off by even a nanosecond in our timing or else the water will all boil away! Faster faster faster! Bust out the assembly language cuz heating water requires the utmost precision timing!
I like you :)
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.
Codesys has a hard realtime variant.
https://help.codesys.com/webapp/_cds_struct_rtev3;product=core_codesys_control
https://store.codesys.com/codesys-control-rte-sl.html?___store=en
Plc’s can run a POU much faster than a hundred times a second. 1ms execution times are pretty easy and you can even do hard real-time control. Plc’s execute like you’re talking about not to replicate relay logic but for safety reasons. Though ladder logic does replicate relay logic in appearance though if you’re going to assume that normal schematics can be replicated in ladder logic you’re going to end up running into some problems.
Check on the pie using code assess I can have programs that don’t exceed 3ms. The jitter isn’t super reliable regular unless I apply a real time patch though.
There are also plenty of hats that do have standardized plc input and outputs.
Ha, POU is not a term you see every day ..
Of course the cycle time can be arbitrary now – I was just saying that’s where it comes from.
All the thyristor/triac and relay controlled hardware had to switch with the AC power, so the control logic had to synchronize to a cycle time back in the day. Even earlier, when the control logic itself was also SCR/relay based, it could only change state once every zero crossing.
So far I haven’t seen a PLC programmed in “hard real time”, meaning that it’s running asynchronously without a fixed cycle. In my book, “hard real time” means a hardware interrupt with a deterministic cycle time, and “soft real time” means relying on the code to set the pace.
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 !!!
I love trains!
I think there is a huge difference between the guy who changes the toilet paper and the CSE.
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.
safety is critical, but it is up to the desigber/coder/engineer… https://hackaday.com/2015/10/26/killed-by-a-machine-the-therac-25/
+1 the programming is ****ing horrible though. Pretty sure uncle Edsger wouldn’t have had anything nice to say about PLCs
He’d have no problem – there’s no GOTOs to be considered harmful.;)
In fact, it’s fascinating – ladder logic is essentially simultaneous execution of all statements in the “program”. (and yes, most PLCs actually implement a variety of “sequencing functions” and it’s shoehorning that kind of thing into a relay logic system that makes is hard to work with)
What you mean with simultaneous execution? Ladder is executed sequentally from top to bottom, left to right.
The rung execution sequence may be ordered as implemented by various controllers. But the ladder diagram by itself has no ordering – all rungs are theoretically executed simultaneously. It’s much like languages like Prolog, with rules that fire when the conditions are met. Designing so there are no race conditions or dependency loops is important but difficult for non-trivial systems.
(Hence, mfrs specifying a particular run ordering, so it’s more like a sequence of rules, always executed in the same order, in a cyclical fashion – heck, that’s also easier for the mfr to code the microcontroller too)
If you implement logic that is “rung ordering dependent” then, you’re making assumptions about the execution platform. And that’s why it gets complex in real life.
To Jim:
Ok, so with “sequencing functions” you meant “run order rules”.
So if you made the same circuitry electrically, yes the run would be “simultaneous”, but in a PLCs there’s a run order (i mean practically, could be even IEC rule, i guess it could be like Labview, not familiar with Prolog).
I’m still unsure of the “complex”-thing? Are you saying that the difference in electrical and “PLC order rules” makes it hard?
Not when it is being executed by actual relays, as was originally done.
Real PLC’s can be programmed in Python or something called structured text. Ladder logic is becoming less and less common. Check out Codesys if you don’t believe me.
No argument there.. I would assume, though, that “real PLCs” intended for industrial applications have a “safe” version of Python with limited libraries, etc. – Sort of like “safe RTOS”es for the same applications that have limited file systems, well defined error handling, etc.
Only the truly deserving and most obscure overrun bugs make it into the “safe” version they use special voodoo magic to scare away the security issues
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:
https://www.youtube.com/watch?v=a0l29lgDf6k&feature=emb_logo
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.
lol.. like fail open or fail close alldepends on how you have the water heater relay setup… the plc doesnt care… you can only determine that if the plc has bad input or crashes what signal shall be sent out. last resort safety, thats what thermal relays, fuses, circuitbreakers, non integrated e-stops relays, overloads and torque limiting clutches/couplings are for.
Firsly, i was not talking specifically about a water heater.
Secondly, of course it depends how the water heater relay is setup, if there’s a safety requirement, the whole system needs to be designed in such a way, that the setup fails as safe as possible.
And using safety outputs the PLC for sure knows what the status of the output is. It tests the output at runtime all the time, you probably need to dual outputs (integrated or separate) anyway, so if one fails then the other can shut of the operation. Safety PLC for sure cares about outputs. What the hell do you thing safety relays do? Same principles apply.
And the discussion was about clarifying that standard PLCs do not have such features and are not even safety rated so the word “PLC” does not mean that it has any kind of approved safety functionality.
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 did pool filter and heating control with Pi+Arduino compatible (All the really important stuff like not running pumps dry was handled on the Arduino side) for years, till covid shut down the place I installed it.
I suspect a Pi hat with an Atmega328 on it (Yeah, ARM is better, but the 328 is almost *the* standard cheap 8 bit everyone understands) along with input protection and Phoenix connectors (Please can we all just agree not to use any more non pluggable screw terminals??) would be fine for most everything that isn’t safety of life or otherwise crazy expensive if it fails.
Verex (a corpo-grade pyhsical security system) uses an Atmega328 in the door controllers…does it stop the supplier from asking $350+ for one? Hell no!
I’d be seriously surprised if the BOM is more then $35 to make said door controller board.
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
At least in the US, I think any place that’s stocking RPi’s is probably stocking at least a few flavors of Arduino as well. Maybe some other stuff. (This is true of e.g., Microcenter, and probably your local computer or electronics hobbyist shop, for those lucky enough to have one with RS gone.)
Of course if the goal is to actually do something useful, automation wise, having the base RPi or a Arduino board is only half the battle anyway. You’re almost certainly going to need some extra components to do voltage level translation, high power outputs, etc. Even if you can get the basic board locally, the interface stuff is bound to be mail order — maybe even custom boards. You might as well just order it all together (and get a few extras in case you fry something — which is the real advantage of using a cheap board vs. pro-level PLCs).
If you’re brewing IPAs at home, I doubt you need hard real-time performance, but you probably do want logging and a nice UI.
At the very least, a pi for the central server makes sense, but if the setup is small enough to not need a distributed design, might as well just let the pi handle stuff.
>> I doubt you need hard real-time performance.
I mean, it depends, doesn’t it? Arguably it’s not necessary for a relatively slow-cycling thermostat loop on a wort boiler or something. But an automated bottle filler might need to be pretty spry — if your Raspbian install decides to spend a half million cycles syncing the disk cache, compiling a GPU shader or checking for a web browser upgrade just as the bottle’s reaching 98%, you’re going to have pale ale in places you probably didn’t want it.
And even stuff that seems pretty leisurely at a high level might still need to be more or less real time on the wire. Like if some of your equipment is controlled through triacs that need zero-cross switching, as in the video. Or if you’re doing, say, bit-banging to read a quadrature encoded position sensor at speed, or interact with some even weirder protocol on a downstream controller or sensor. Or doing manual pwm to precisely control steppers, pumps, fans, etc.
Don’t get me wrong. I’m sure you *can* do all of that with an RPi and a python interpreter, at least with enough tuning and twiddling. Maybe even all at once. It just doesn’t mean you should. Especially when someone else has probably already written the Arduino sketch(es) that does what you need, modulo cobbling them together and changing a couple of pin assignments.
And that’s just the programming side. I expect boot time, power consumption, always on reliability, etc. also all tend to come out better for micros.
RPis have a place running a fancy (high level) GUI, logging servers, etc. — if you need any of that — but I suspect anything but but the most trivial control stuff is best left to, well, controllers.
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.
Well, even having off-line PLCs controlling their centrifuges, the Iranians got stung. And you want to internet connect!?
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.
Yeah if it’s something simple it absolutely should be a smart relay. But if you’re doing anything even slightly advanced or if it requires a UI it’s so much easier to use a PLC. The Beagle bone has 2 industrial extended temperature range models, the beagle bone industrial and the newer beagle bone enhanced.
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.
Skull.
there is a heap of things like these advertised around teh place – allegedly ruggedizing the raspberry pi.
https://www.sferalabs.cc/strato-pi/
I shouldn’t be surprised that this point hasn’t been raised.
One key feature of industrial PLC’s is the ability to change programs on the fly, while the process is running. Try telling a manufacturer to completely stop their line for a few minutes so you can download a minor program change.
In my experience, speed is rarely an issue with PLC’s.
Much of the cost in in the physical wiring to external devices, which would be much harder and less reliable with a raspi or similar. DIN rail mounting, input and output protection circuitry, reverse voltage protection, robust terminals, stable programming environment – these are what is important for a industrial control systems. None of which are natively present in a pi.
Rolling upgrades are a standard feature on just about all enterprise software, shutting down for upgrades went out with punch cards.
Not being an enterprise software/server operator, does that mean an upgrade can be installed and the application flicked over to the new version without having to perform a reboot?
We(Not industrial) went with a custom visual scripting language on the Pi for that exact reason. Python is great, but visually creating if-then rules lets you really constrain things to avoid anything that might not work well with hot code changes.
Most of the comments are directed to the software aspect, but how do you get around the pi potentially (generally) leaving the file system in a state which needs repairing after a power loss?
You use OverlayFS
OverlayFS – best comment of the day – thank you Mijail!
I would not condiser a raspi for any even vaguely industrial type of application.
It’s made at the lowest price possible that gives it a chance of staying in one piece through the mail and nowhere near reliability or industrial temperature range to be condisered for such applications.
On top of that, add swapping uSD cards each year or so to keep them from wearing out.
But apart from that, the video is such a blatant advertisement for the other product, that there will be no doubt they’ve found some reasons why “their” product is “better”.
Addition:
Water heating usually need a control loop update rate of < 1Hz, If they've found a way to botch that with a 1GHz+ processor they really must have tried hard.
There is an industrialised Pi on offer,
https://www.netiot.com/netpi/industrial-raspberry-pi-3/
But at that point it costs more than a PLC.
Used that..it’s pretty unreliable and shoves some really immature docker integration down your throat
That is disappointing. You can replace the supplied OS etc but I would have hoped that it wouldn’t be necessary.
Why was it unreliable?
My spousal unit is a big fan of PLC’s and implemented them in many industrial situations and in everyone of them, safety was the primary concern. As noted earlier, eStops are separate from controller, but some devices need to be shut down in a specified order so that they don’t cause further damage. This means the ladder had an eStop input.
I, on the other hand, am a big fan of SBCs, primarily because it is easy to create a rational user interface. Yet we are happily married.
PLCs and SBCs can be married, too. PLCs in charge of the time sensitive functions and the SBCs doing the dishes. (user I/o, logging, etc.
In other words, instead of an “apples and oranges” discussion, we should be talking about fruit salad.
RaspberryPi compared to a PLC is like comparing a nice RV to a semi truck. Just because they are both big vehicles doesn’t mean they are comparable. The rPi is a whole ass credit card sized computer; we’ve had industrial PCs before there’s a reason they don’t run the entire operation.
I would much rather see a comparison to Arduino, which is much closer to what a PLC is.
The comparison would be fairer if it was done with a modern PLC.
For example, the PLCnext Control family from Phoenix Contact runs a Linux OS with the PREEMPT-RT patch, giving the real-time behaviour that the Pi is missing. And it can be programmed in IEC 61131 languages, if you want, like the toy PLC in this article.
There are similar modern PLCs from other vendors … it’s strange that this article chose an “old fashioned” PLC for this comparison.
I really hope these come down in price in the near future. I’d love to get one but the only supplier I found in my country sells the AXC F 2152 for about USD2500
Wow, that is some markup on an AXC F 2152. When you find a more reasonable supplier, ask them about the cheaper version, the AXC F 1152.
It’s all fun and games till it turns off the vacuum grippers and starts dropping things.
Joking aside, i quite like using bare c/cpp on single boards like the rpi in industrial control, but the one thing i hate about it is the reliability(or lack of) the SD cards…as for I/O, everything is Ethernet/IP, profinet, etc. these days so the PI is just a process controller and leaves the I/O to modules like wago blocks, turck, etc.
I think this article really shows the stark difference between a process automation controller (PAC) and a programmable logic controller (PLC).
A RaspberryPi looks like a great system for automation control (like a CNC) or, maybe, as supervisory control over a SCADA system; where several programmable controllers control a process line and need information pass off via SQL or something like that. It might be good for imaging systems too. Something that needs that kind of processing power, but does not control the immediate needs of the machine. I’m not sure it would be right for a safety application though, due to the speed needed for such applications.
Its not so much speed – PLCs from the 80’s coped just fine – it is more about *absolute* predictability, which you just can’t get with a multitasking OS. Stupid processing speeds can make up some slack, but not always, and not predictacbly.
You can get *good enough* predictability with a Pi and the realtime-patched preempt-rt kernel.
Servicing the control loop every 1000µs +/- 100µS is relatively easy. (latency in my tests peaks at 56µS so I am making a conservative claim)
This has its place in the world but you will be hard pressed to find something like this in any serious industrial operation. PLC gear is expensive for the hobbyist, but as a percentage of the cost of an entire factory its not that significant, especially when you consider what every hour of downtime is going to cost you.
I think people here are forgetting that there is a lot of demand for PLC’s outside of typical factory settings. Anywhere that can benefit from automation can benefit from a PLC. Agriculture for instance greatly benefits from low cost automation solutions. A livestock building benefits from a BMS system that controls all sorts of non-standard equipment and benefits from some customized features to tailor it to that specific buildings operation.
Also automation directs PLC software is not great. Codesys is much better and as a benefit you can use it for different PLC brands. For cheap customers who want to pay to replace and stock spare rPi’s to people willing to spend a little more for a real PLC
I like the idea of comparing but it is clear that there was not much effort given to make RPi runn better. I understand that common tools had to be used so bare metal Forth/microPython are not an issue here. But Raspbian+python are so far from any efficiency. Why not some more “industrial” distro (or at least TinyCore?) + C? Or even something with Real Time Kernel? I hope they will make more videos on that and dive deeper in the subject so they can show a real advantages of PLC and where is the place for SBC in control and automation. Maybe they could even convince people that there are much more options than RPi and some are even “more industrial” – begale bone have nice variety of their boards.
This reminds me that over 10 years ago I was doing some step motor control via LPT with Linux RTAI patch and Scilab+SciCos (now called Xcos). I wrote simple SciCos block that controls LPT, than generated C code from SciCos diagram, compiled it and it run in real time. Next I run some software (don’t remember name – some server type) that was returning some data from that compiled software as meters (semi HMI). I wonder – could I do the same now on a PC and compile that C code on RPi? Maybe even this quasi HMI?