Dave Perkon is technical editor for Control Design. He has engineered and managed automation projects for Fortune 500 companies in the medical, automotive, semiconductor, defense and solar industries.
The PLC programming vs. computer programming debate has been around for at least 25 years; and, I hate to tell you, but the debate has not really changed over the decades. The final technology countdown of the PLC’s demise still has not occurred, nor has its reliability and deterministic capabilities set it apart from the ever-changing PC.
And, of course, the fabulous potential of the PC, with its Pentium and multi-core processors, and all of the add-on hardware and software, along with the ability to program in hundreds of languages, never really broke any barriers with real-time control. The debate just goes on and on, to the benefit of the control designer and programmer; fortunately, the hardware, whether PLC-based or PC-based, just keeps getting better.
I wonder if the selection of PLC programming vs. high-level computer programming really has to do with the number of identical units produced, job security for the programmer, inexperience, overconfidence or because of a "that’s what they taught me in college" mentality that pushes the choice of programming methods.
During my 27 years in control design and programming at an integrator and custom machine builder, I learned both PLC and high-level computer programming such as VB.Net and C# and even C, C++ and just about every text and script-based language in between. I can do both.
Also read: 4 must-read articles exploring the current state of the PLCÂ
What's strange to me is that the opinions of people who just learned PLC or high-level programming are at opposite ends of the scale. It certainly has a far left and far right political feel to it.
“I'm voting for PLC.”
[pullquote]
“Computer programming has my vote.”
There is no in between, in many cases.
Einstein once said everything should be made as simple as possible, but not simpler. I just wonder why this never is brought up in the PLC vs. computer programming debate. I'm sure the vendors know to keep it simple. Not only do both PLC and industrial PC vendors sell the hardware, they sell the software to go with it. It is PLC programming software, and, in many cases, the HMI programming/configuration is included in the same software platform.
If the programmer for an automated industrial machine is considering not using the software the vendor supplies with its PLC or PC controller, the programmer is definitely breaking the keep-it-simple rule. No doubt there are reasons to create custom code for some applications or even spend the time to write custom code for large OEM quantities of equipment—especially semiconductor equipment. However, you may want to consider the end user or integrator who will be using and supporting the machine. They will want it easy to troubleshoot, a quick learn and understandable, and many will not have high-level programmers on staff to support it.
If you want to select a computer and software and then lock the program down and build hundreds, or more likely thousands, of something, then consider the PC route and custom, high-level computer code. But remember, most end users will have no interest in it and probably wouldn't buy it on an industrial machine. So, I think, if you are considering using VB.Net, C++, C, C# or Java to control your assembly line, you have what is likely called the Dunning-Kruger effect and not an innovative approach to machine control.
With Dunning-Kruger, the inexperienced are the most confident in their abilities and knowledge. As their experience increases, their confidence reduces as they become aware of other options. Only with extensive experience and training does their confidence increase again. Put simply, it suggests that incompetent people will tend to overestimate their own levels of skill, while not recognizing the skills of others. They don't realize their inadequacies until they are trained and gain experience.
Writing custom code is so ’90s, dude. High-level programming means you have to worry about all the low-level stuff in many cases. There can be a lot of extra code to get certain things to work, and, for me, that is too many details to worry about. The program should limit exposure to low-level tasks, like C# and Java does. But we are not programming a game or business software; these are industrial control systems that can and often do change.
The trend is to reduce the programming needed. A simple program does that by design—PLC ladder diagram programming, for example, and other IEC 61131-3 languages. You are overestimating and ignoring the abilities or really just the interests of the guy who simply wants to get the machine running again, if you are using high-level programming on industrial machines.
Using PLC programming is a lot like using roundabouts when driving. The roundabouts work great for many, but there are always some who will never understand how to drive through one, much to my dismay. This brings up a discussion of the four stages of competency, which is a subject of another article.
Homepage image courtesy of mapichai at FreeDigitalPhotos.net
