Use PLC programming, not custom code

I cannot help mentioning that PLC programming is the industrial way of doing things and using high level computer programming is not the right way to control an assembly line.

By Dave Perkon, technical editor

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.”

With Dunning-Kruger, the inexperienced are the most confident in their abilities and knowledge.

“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

Show Comments
Hide Comments

Join the discussion

We welcome your thoughtful comments.
All comments will display your user name.

Want to participate in the discussion?

Register for free

Log in for complete access.


  • Great article. Like so many things they seem so simple on the surface but when you evaluate the options through the life cycle of the product the PLC is clearly the better choice.


  • I totally agree with this author in this article. The KISS system really produces sustainable results (Keep It Simple Stupid!). It allows the customer's local support technicians to resolve most issues on their own. Also, even though PC based control is tempting, several years down the road the hardware will fail. Because of changes in operating systems and in the hardware, the original application MOST LIKELY may not run in the newer PC environment, thus requiring a complete redesign. I know- been there, suffered that, and what was worse, I had to fly my butt across the Atlantic TWICE because of it, at my cost. (Are you all aware that the PCI bus has at least five different designs? And where is the ISA bus?) But how are the PLCs doing? Still running strong even after many decades. Some of my customers are still running A-B PLC2 systems even. The hard part is finding PC environments where my old PLCs that require "serial access" with DOS-based programming tools can still be accessed, considering that several years ago unscrupulous laptop designers decided that serial ports weren't needed any more (I DO hope you know the difference between RS232 and USB ports, yes?). PLCs, programmed in ladder logic, rule in industrial control, for everyone. Period. (FYI- my first escape from hard wired relay logic was in 1977 when I had to work with Modicon 084 and Texas Instruments 5TI PLCs. The TI didn't even have a processor core- it was entirely operated by logic chips and clocked off the AC power, but it was programmable. The Modicon had "core memory" and we had to save the programs onto punched paper tape via a DEC PDP-8 and a telephone modem.) I love the roundabout comment too.


  • Could you build a house with just 1 type of saw? What about using 1 type of hammer? Sure. But that is NOT the simplest solution. I'm sorry, but Occam’s Razor is a vestigial remnant of medieval science. I do agree that machine control should always be done in a PLC. Sadly the same vendor's HMI package which comes with an "industry standard PLC" often come up short. Extending the HMI's functionality through a ladder logic programming is like using a rip saw to cope crown molding. After all is said and done, it doesn't look pretty, but your chest fills with pride that you got the job done through sheer force of will. Although, your boss didn't budget the time it actually took you to do it. The right tool, for the right job. Where the focus controls programming should be (and especially in robot programming) is not in "simple programming", but in fault tolerant programming. Is it extra work? Yes, but it is aimed specifically towards "the guy who simply wants to get the machine running again." As for HMI programming, the focus should be in hierarchical and scenerio-based layout that emphases situation awareness and operator response... But that is wholly another topic.


  • Another great article. Since my livelihood depends on controls engineers selecting the controls hardware and software I sell, this is a topic I think about frequently. I think the unknown quantity here is the confluence of two slowly but steadily increasing factors: extremely capable cheap hardware and the growing population of people who have actually coded things. I totally agree with your comment that the platform needs to be supportable by the end customer's team. Ladder does that. What happens when those teams reach a tipping point where the plant engineers and electricians are fluent in text based languages because of exposure to app programming and hardware like RazPi and similar? In other words, when the digital natives enter the workforce and the cheap SBC platforms have become even more capable... There is one possibiltiy, however, that runs contrary to my theory. Just because the digital natives are always connected does not mean the subset of that population with an interest in programming will grow enough to put folks with those skill sets into plant maintenance rolls. I don't know what will happen in the future. I just want to make sure I don't miss it.


  • My vote is for the PLC, it is people friendlier, with a little code on the side. I have to agree with Robert Couture to a small degree when it comes to the HMIs and to a lesser degree the PLC . With the variety of PLCs on the market, all offering different options for tag size, languages, Client/Server architectures, remote access, C++ configured add-ons, etc., there is no one-size-fits all solution. They are all weapons (hammers) of various attributes using a common language, namely IEC 61131-3. This commonality cannot be overstated and is the greatest advantage of PLC programming. Thank you IEC and IEEE. The 'Programming' solution is common among most, if not all HMIs since it is often a necessary part of any HMI configuration modification. The 'Programming' solution is not used as much with the PLC, but is often a feature. In either case the biggest problem with 'Computer Programming' (e.g., C++, VB,) is the code can be extremely difficult to debug. Programmers don't always leave 'comments and they have a tendency to show off with some convoluted code that can be very difficult to figure out even if you can get the programmer to sit next to you (Good luck with that 2 years down the road). It can be a nightmare to locate and figure out, and often I have seen the programmer not remember what he did two years ago. I am sure we have all seen this first hand. Programming does have its place, but should be limited, not expanded in scope. It should only be used when there is no other PLC solution and is absolutely necessary. Many PLC providers offer programming features, an Add-On or an SDK, by which programming code can be added in the form of a function block and often requires the programmer to document his code. These can be easily found and removed or modified when troubleshooting. All in all a good article with great comments. KISS off everyone :)


  • I'm surprised that you consider Ladder code to be a low-level language, and C a high-level language. Ladder code is high-level because it is very abstracted from the computer's instruction set. That's why its so easy for non-programmer plant operators to figure it out, as you pointed out in your article.


  • I agree with Dave. The oft-maligned ladder-logic language is sometimes spoken of as an infantile language that no professional would use, because it's just here to help the lowly (uneducated, unintelligent?) technician. A language isn't better because it's harder to understand. Chess moves are simple, but chess is not simple to do well. Something I don't see mentioned is that in the U.S. at least, ladder logic is actually a combination of Ladder and Function would take a LOT of relays to implement a Compute instruction! Yes, you can make something work with an Arduino or a Raspberry Pi, but you'll quickly run into issues with RTOS, compatibility of connected devices (things you actually need, like sensors, I->P transducers, and the like), the different flavors of the aforementioned devices, language selection, device ruggedness, code documentation, etc. And by the way, PLCs are run by microprocessors - just like your favorite controller du jour, but optimized for industrial use, ready to deal with Modbus/TCP, ethernet, USB, etc.


RSS feed for comments on this page | RSS feed for all comments