The question is whether or not I believe PC-based controls will replace PLCs, PACs or CNCs.
I’ve been around in the industry long enough to remember when both PCs and PLCs were in their infancy, and the “old-timers” still were designing their control systems around relay logic.
It still sends a shiver down my spine when I recall sitting in front of a multi-door control cabinet chock full of relays and motor contactors, trying to figure out which contact was bad, while I looked at a dog-eared, incomplete set of “as built” blueprints. Ah, those certainly were memorable days.
So, now that I’ve established my bona-fides, along with a few credentials in both age and senility, let’s address the question at hand: PC-based controls or PLCs?
[pullquote]This question has been around for a while, too, but it really got to be a hot topic in the ’90s. Prior to that, any process that required higher-order mathematics—trigonometry functions, for example—was handled by a PC because the PLCs at that time did not have the math co-processing chips. Also, PCs were networkable and could handle a lot of database applications.
However, PCs were notorious for failing in industrial conditions because their hardware wasn’t designed to handle heat, dust and vibration. Also, you were required to have specialized programming skills that the run-of-the-mill industrial electrician/technician did not possess, so if there was a breakdown that required troubleshooting beyond checking the I/O, it often required bringing in outside resources to fix the problem—good for OEMs and integrators; bad for production people.
PLCs were made specifically for industrial control applications. The hardware was ruggedly designed, and the programming wasn’t complicated as it was based on the electrical control wiring ladder diagram.
Joe the Maintenance Electrician easily could learn to program the PLC and then use it as a troubleshooting tool. Curiously, it was about this time that the maintenance mechanic’s life got a little harder. He no longer could just look at a machine for two seconds, declare it to be an electrical problem and walk away to drink coffee and play cards, while the electrician was left to prove that the solenoid valve or cylinder seals were bad.
In the past decade though, PLCs evolved such that they can perform the same functions as the PCs, and the PCs have become more rugged. The advent of soft logic-type programming for PCs virtually eliminated the need for specialized custom programming for most industrial control applications. Both the PC and the PLC CPU still require an I/O interface of some type, whether a PC chassis or PLC rack.
My company, M.C. Dean is a designer/builder and integrator, specializing in electronic and electrical systems. Its CIM Automation Systems division specializes in automation and drive systems for the pulp and paper industry, semiconductor industry and others.
At this time, our group currently uses a control architecture that specifies PCs for the SCADA overview networked to PLCs in the field. The PCs run the SCADA software that handles database tasks such as history collection, and the PLCs are often stand-alone units merrily running their tasks. The PLCs are monitored by the PCs, and the operators interact with the process via the SCADA hardware.
It could as easily be just the PCs and remote racks or PLCs with HMI monitors. The point is there’s more than one way to skin the cat now.
I believe it just boils down to one thing—the money. Most industries want to spend just enough capital to get the job done, so the application drives the engineering design, and competition or lack of funds dictates the type of control system.
PCs or PLCs? Look at what you have to spend and the application. Then decide on what meets your demands the best. Both PCs and PLCs are basically the same animal now.
Gregory Kempfer is a controls engineer at M.C. Dean/CIM Automation Systems (www.mcdean.com) in Harrisonburg, Va.
