Note: This post is part of our series titled Industrial Control is Ripe for Disruption
Last week, we talked about hardware, but that’s only one side of the coin. The software disparity between the automation and consumer sectors is arguably much larger. For decades, industrial programming in areas like PCs, servers, and smartphones, has focused on scalability, code reuse, and automated testing and debugging. During that same time, the automation industry has largely fought to keep things the same, sticking to relay ladder logic as the primary programming language. The topic deserves a lot more time than I’m going to give it right now, but here’s an oversimplified explanation.
Relay ladder logic (or just “ladder logic”) was originally developed to mimic the physical relays used for automation control before the PLC. This was a convenient way for the industry to transition from physical to virtual control without having to relearn how to design the control. It was also handy because maintenance technicians that already knew how to read electrical diagrams could also understand what was going on in the program. This is still cited as a benefit of ladder logic today, but in my opinion, it’s not really true anymore. PLC programs are a lot bigger and more complicated than they used to be, and it usually takes years to become proficient in ladder logic programming. Industry has invested heavily in training programmers and technicians for ladder logic programming, and while there are many advantages to having a “universal” skillset like that, it also makes industry resistant to considering alternatives.
Today’s automation systems are required to do a lot more than the systems of yesteryear. Datalogging, MES, quality calculations, and downtime tracking are all common occurrences, but PLCs and ladder logic aren’t well suited to those tasks. Usually a server or PC will be connected to the PLC to do those functions. That’s more hardware and more software adding complexity and expense to do relatively simple tasks. PLC manufacturers are starting to offer more integrated solutions for these functions, but without looking at a PC-based PLC, these usually still add hardware, software, complexity, and expense. In short, the status quo in PLCs doesn’t support expansion into these other areas very well, and there’s growing demand for it.
Do you have any thoughts on the future of PLC programming? What applications do you see PLCs struggling with? Are you using PCs in your automation? Leave me a comment and let me know.
About the Author
Jon is an engineer, entrepreneur, and teacher. His passion is creating and improving the systems that enhance human life, from automating repetitive tasks to empowering people in their careers. In his spare time, Jon enjoys engineering biological systems in his yard (gardening).
