Micro-controllers versus PLCs: Which one belongs in your plant?
The variety of micro-controllers emerging has been growing rapidly, with no signs of abating. These devices offer many capabilities, along with whole ecosystems of accessories that are also cost-effective (see Figure 1). Consequently, interest in these products has moved from automation clubs and basement robot builders, to the point where some are considering their use in manufacturing.
When an engineer is looking at solving a small industrial automation challenge, the traditional approach has been to use a programmable logic controller (PLC) (Figure 2), but some engineers now may consider a micro-controller; however, certain factors need to be considered before a decision is made.
For the purpose of this discussion, some generalizations will be made due to the number of possible open-source board-level products resulting from the do-it-yourself electronics industry (the maker world). Micro-controllers, field programmable gate array (FPGA) boards and single-board computers have varying capabilities and limits. However, for purposes of this discussion, we’ll lump them together under the heading of micro-controllers.
Similarly, the characteristic attributions of PLCs and other industrial controllers do not apply to every model and manufacturer, although there is a high degree of consistency across the range of companies within this space.
Industrial automation example
An engineer may be considering a small automated task involving two or three sensors, an actuator for the output, and a reporting function to the larger control system. It will require a basic program to make it operate.
This is simple for many small PLCs, with prices starting at a few hundred dollars, but there are factors that should be considered first. A small open-source board-level micro-controller might be tempting to try at a fraction of the cost.
The first obstacle the engineer is likely to hit is the input/output (I/O) compatibility: does the prospective micro-controller offer the required I/Os? It isn’t difficult to find a micro-controller with the correct number of discrete and analog I/Os, but they may not be the right type.
Some are relatively easy to convert, such as a 4-20 mA current loop to a 0-5 V voltage loop. Others are more difficult to convert to anything, such as an analog output using pulse-width modulation (PWM), common for micro-controllers. Some signal converters are available as standard products, but they add to the overall cost. An engineer insisting on a full do-it-yourself experience may try to create the converter internally, but such an undertaking can be complex and require extensive development time.
On the other hand, PLCs are designed to work with industrial sensors, and therefore offer a wide range of I/O choices, so there should be little or no need for external conversion. The ability to wire directly to a PLC or I/O module will be easier since it is designed for this purpose. A PLC also will ensure a high degree of protection for the devices and circuits by building in isolation for relevant I/O points. An end user may be able to do the same, but this requires additional knowledge and increases complexity.
There’s also the matter of mounting and housing a micro-controller, since it likely will be a naked board with pins for connections (Figure 3). The end user also must supply power and create terminals to attach external devices. These are manageable tasks, but take time.
These physical matching and mounting challenges may seem to be major elements of the discussion, but they only scratch the surface of the differences between the two major platform groups, with other less visible considerations being more important.
The OS supporting the application
Micro-controllers are bare-bones devices, and that includes the operating system. After all, a single-board computer selling for $40 is not going to have much in the way of built-in software routines, so the user is left to code everything except the most basic capabilities. This isn’t necessarily a problem since most micro-controllers use common programming environments such as Linux and C and are typically used for relatively simple applications.
Similarly, writing an application for a PLC also may be simple, but much happens below the surface that is not visible to the programmer or user. PLCs have many housekeeping functions watching the program and associated equipment.
Software watchdogs keep an eye on the program to make sure it is executing as it should. For example, say there is a problem with a for/next loop, and the program gets stuck. If it’s stuck, it can’t carry out its function, which could cause a harmful and potentially dangerous situation. The software watchdog times each scan of the program. If a given scan is not completed in the allowable time, the dog will bark, fault the PLC and put it into a safe mode while alerting the operator.
Hardware watchdogs keep an eye on the devices connected to the PLC, particularly I/O modules or individual devices such as switches, sensors, and actuators. The PLC always is exchanging handshakes with the devices, and counts each scan of the program as it operates. If the scan count for any individual device begins to lag, the PLC will assume something is wrong with the device or wiring. Depending on the level of sophistication and the program set up, it may fault and go into a safe mode, or it may continue to operate while informing operators of the problem.
Data from devices is verified using a cyclic redundancy check to ensure there are no communication errors. Again, if a problem develops, the PLC can go into a safe mode. All these functions are designed to warn users if the PLC is not functioning as expected, and therefore cannot control the machine or process as desired.
Theoretically, any of these capabilities could be added to a micro-controller’s programming, but the user would either have to write the routines from scratch, or find existing software modules to reuse. Naturally, these would have to be tested and verified for the application, which would be a major undertaking, at least the first time around. An engineer writing multiple programs for the same controller could probably reuse proven code blocks, but these capabilities are included with the operating system for virtually any PLC.
Designed for industrial environments
PLCs are designed to work in industrial environments. What this means differs with each manufacturer, but it involves additional protection for the hardware against a variety of potential threats. Examples include:
- Shock and vibration: Devices installed in factory environments likely will be subjected to rough treatment, and/or mounted on equipment that vibrates. Micro-controllers must be mounted securely with connections secured to withstand this kind of abuse.
- Noise: Industrial environments are full of equipment that are capable of creating magnetic fields and electronic noise. An inexpensive device can be sent into a fault mode or lose its program if subjected to enough interference. PLCs are better protected and can withstand the typical electrical noise problems that are encountered in most environments.
- Corrosion: Some environments subject equipment to vapors and fumes potentially corrosive to wiring and components. PLCs typically include various coatings to minimize any bare metal on the boards, and wiring devices use appropriate materials that can resist corrosion.
- Temperature range: A PLC may be installed outdoors in an enclosure subject to high and low temperatures. Choosing the right components able to stand up to these environments can extend the life of a PLC, whereas most micro-controllers require a more benign environment with respect to temperature.
The International Electrical Code (IEC), UL, and others have published standards describing how to test for these types of attributes, and the PLC documentation will indicate which tests have been performed and the methodology used. This kind of testing is complex and expensive, but it results in equipment able to operate reliably in industrial environments.
Micro-controllers rarely have such extensive testing, and will typically include only the basic requirements for specific markets such as control engineering. This also can be complicated by not knowing the manufacturer of the board. A generic board may not have been tested to the same extent as a branded product even if they seem to be identical (Figure 4).
Micro-controller longevity expectations
One of the realities of industrial applications is required longevity. If the solution works, few manufacturers would make an update without a compelling reason. As a result, many industrial users work with equipment often decades old, and they expect their suppliers to support products accordingly.
Original equipment manufacturers (OEMs or machine builders) must take a long-term view of the products they use in their machines, and need to be ready when a customer wants to buy parts for a system installed in the 1990s or earlier. Eventually, products do have to be discontinued, but those situations will be mapped out so the OEMs’ customers are offered a migration path to something more current. This typically includes mechanisms for reusing old PLC programs and retaining other intellectual property.
Companies manufacturing micro-controllers may not share this sense of history. If you need to replace a controller for a project from five years ago, finding the necessary parts might be a challenge. Over those years, multiple versions of the product could have come and gone, with various changes to the programming environment. Worst-case scenario, you might have to start over using something more current.
Technical support, micro-controllers
End users designing automation solutions using open-source micro-controllers become their own technical support group. Some outside help may be available through various discussion groups and forums, though these technical support communities may not have experience working with industrial automation.
PLC suppliers deal with industrial users trying to solve industrial problems on a daily basis. Most also have user communities and discussion forums focused on real-world manufacturing challenges. Some PLC suppliers provide this technical support for free, helping their customers solve hardware, software, and system problems.
Micro-controllers and other types of development boards are fantastic as teaching tools and for experiments. They’re cheap and make the difficult concepts of programming and automation much easier to learn.
On the other hand—if the task at hand is keeping manufacturing running effectively, efficiently and safely—PLCs deliver a wide variety of capabilities with reliability that has been tested and used for decades. When a plant must run and products must be manufactured, reliability and safety matter more than anything else.
Bill Dehner, technical marketing engineer; and Tim Wheeler, technical marketer and training developer, AutomationDirect. Edited by Emily Guenther, associate content manager, Control Engineering, CFE Media, email@example.com.
www.controleng.com KEYWORDS: automation reliability, programmable logic controller
- Comparing PLCs with micro-controllers
- Factors to consider when using a PLC for industrial automation applications.
- Reliability and broader cost issues working with micro-controllers.
Are end users commonly faced with a lot of technical support issues?
Learn more about open-source computing boards. From the authors: Open-source sourcing example: The Arduino Uno was developed by the Arduino company, which sells its "official" branded products. But since the product is open-source, other companies legally can manufacture the board claiming it is functionally equivalent (Figure 4). A generic "UNO R3" board may not have been tested to the same extent as a true Arduino product, even though they seem to be identical, save for the trademark, so buyer beware.
From Control Engineering: Use of industrial microcontrollers: webcast questions answered.
From microcontroller organizations: