What is a PLC? What does it mean to be a PLC? These are interesting and open-ended questions indeed.
The Programmable Logic Controller (PLC) hearkens back to the days of control panels that used relay logic to define the electrical operation of control systems. Powered mechanical relays connected in series or parallel defined ANDs, ORs, and more complex logic was built on top of these basic elements. With the advent of cheap and accessible microcontrollers, hardwired logic was replaced with as many ones and zeroes, and power-handling was passed on to relays or transistors. Operational logic became more compact, inexpensive, and best of all, reconfigurable with a program change to the chip. The programming language typically used to this day for your average PLC reflects that they are, in fact, replacements for relay control logic. They use what is referred to as ‘ladder logic’, a series of virtual contacts and coils that if printed out and wired as it appears, would be a functional circuit. A bizarre abstraction for those of that grew up writing linear code, but an interesting one nonetheless.
These days, the PLC does so much more. Often, the most important function a PLC performs is as an air traffic controller of sorts. A content and data aggregator. In many or most control and/or monitoring systems, you’ve got a handful of devices that speak many different languages. They need to be read and written, and by something that knows how to talk to them. You have the interface transmission protocols and physical layer, such as RS-232, RS-485, RS-422, I2C, SPI, and communication formats such as MODBUS (which has three variants in itself), CAN, and many other standard and proprietary formats. The point is that the PLC talks to all the things, processes the data, and decides what to do about it. These days, most have some web functionality built in, and can operate as a data server on several different interfaces. With the addition of these higher-level functions, along with more memory, tags, and advanced data structures, they have in recent years also been called Programmable Automation Controllers (PACs). The lines are blurred, for sure, and the names are not really important.
Two other key features of a PLC – or a device that functions as one – are speed and reliability. Ideally, it should be as reliable and fast as the hardwired relay logic it replaces. How close depends on the application, of course, but at a minimum the speed should be consistent over time. This is what makes PLCs suitable for mission-critical processes and those that have safety considerations – they are bulletproof. Compare this to your average PC, which is susceptible to malicious attacks, corrupted operating system data and files, and insists upon updating itself daily, and it’s pretty clear why you would choose a PLC. It’s bad enough when you walk by a display monitor in a retail store and see a blue screen of death. Imagine one that risks others’ lives. No bueno.
So … no OS?
Until recently, the above two factors have ruled out anything that runs an operating system. Reliability and consistency just haven’t been possible at a level that makes them even a remote consideration. With the widespread use of linux servers to run the world, however, it may be time to reconsider. Even Windows Embedded is in widespread use in things like touchscreen HMIs.
So why use an operating system? On top of what a PLC does, an OS can do so much more. Established libraries and coding tools that greatly simplify putting control strategies into action are available. Databasing, email, advanced web services, and many many other facilities extend the controller far beyond your typical PLC. Hardware options and communications protocols are effectively limitless, another improvement over existing PLC platforms. Memory is no longer a consideration, which is a huge bonus. Even typical advanced PLCs work with as little as 256kb! With orders of magnitude more memory, trajectory data can be stored without concern, a killer feature for many applications. Data structures are not as strict and offer a higher level of abstraction, including object-oriented programming. All of these advantages justify a hard look at a better piece of hardware running something like Ubuntu for control needs.
Is it good enough?
As should be obvious from the discussion above, whether a control device is good enough is clearly a function of who you ask and which application you’re talking about. For a very simple but mission critical app, for example, you would gladly sacrifice some functionality for reliability. These days, we’d choose something like an ATTiny or ATMega microcontroller (what goes into Arduinos). If you want a rich user experience, databasing, and web/internet functionality, you could go with something like a CuPID, plain-jane Raspberry Pi, Beagle Bone, or other microcomputer. Or homebrew your own using combinations of them.
In any case, our point here is not to decide what is right for everybody, but to really explore what functionality we can bring to the Pi/CuPID to make it the best it can be, and evaluate it from the context of the key performance metrics above:
- Connectivity, communication, and interfacing
We’ll show some neat tricks and applications for Pi/CuPID/microcontrollers, and you may do with it what you like!