Ladder Logic: Can't we do Better?

Introduction

It's an argument that is sure to draw out a lot of passionate opinions. Much like politics, religion, part numbering standards, the best CAD system, and the designated hitter rule, people are very passionate about certain subjects and Ladder Logic is one of them. But this very capable and pervasive language is due for an upgrade, no... replacement, as the dominate programming language in the automation world.

Let me first state that while I've been in the automation industry for 25+ years and have?programmed?in many, many languages I am NOT a PLC expert. I know enough to be dangerous and get by. However I am?cognizant?of the fact that there are a lot of you out there who are MCUH more experienced than me. So take my opinions with that in mind.

A History Lesson with Dick Morley

A brief history lesson first. Modern Ladder Logic (LL) is based upon the electrical schematics representation of relay racks that we used to control automation systems before the invention of the Programmable Logic Controller (PLC). These relay systems were often very simple control systems that typically consisted of some pumps, motors, a few inputs such as sensors or flow meters, etc. It is a visual/text language combined with symbols to describe the states of output and inputs (NO, NC), timers, variables, as well as motors, pumps and more.

Enter Dick Morley, the "father of the modern PLC". Dick and several others (he is the first to share the credit) invented the modern PLC as a way to replace these racks of physical relays. In 1968 while at Bedford Associates, Mr. Morley and his team devise a device with a number of transistors that would allow one to program a relay based system without the internal wiring required (and many less relays). The device went on to be know as a Modular Digital Controller or Modicon, the quintessential name we all know.

As indicated in the title of this article I am one who feels we have outgrown LL as the primary programming language and this stems from my experience as a young engineer and meeting Mr. Morley on multiple occasions. Early in my career I attended a conference called COFES (Congress on the Future of Engineering Software). It was a who's who of motion control, robotic, CAD and embedded systems leaders (and me?) who discussed engineering software and what the future would hold.

I was at dinner at my first COFES and we all introduced ourselves. My seatmate said, "Sean have you met Mr. Morley? You know, you owe your career to him". Gob smacked I shook the hand of the man who invented the device that made my job possible. Over the subsequent years I would meet Dick at COFES or other industry functions and we'd discuss automation and control systems. As the years passed at one of the last conferences before he passed in 2017 he spoke to me about the advances in controllers and how LL was now an antiquated language.

I told Dick he needed to work on a replacement language to which he said "that's in your generations' hands now".

When Dick invented the PLC and LL he never envisioned that we'd have complex devices such as servos, analog feedback devices, robots and more trying to be controlled by a system that was designed to replace relays. He once said something to the effect (paraphrasing) "We're trying to paint the Mona Lisa with crayons".

It's not often we get to meet people who fundamentally affect our lives. My interactions with Dick have had me thinking about this for years. So I have often posed the question "Can't We Do Better?"

PLC Programming Languages

Currently there are 5 major programming "styles" used in PLCs (in general order of popularity)

1. Ladder Logic (LL) or Ladder Diagram (LD) - by FAR the most popular
2. Structured Text (ST)
3. Function Block Diagrams (FBD)
4. Sequential Function Chart (SFC)
5. Instruction List (IL)

While they look different all can be used and in many situations you can even mix and match (LL can call a ST script). A great explanation of the differences can be found at INSTBLOG

To a layman with little to no PLC programming experience, LL can be quite intimidating. It involves using a series of symbols and gates to decide if a rung is complete or not. It flows from right to left and with complex function can have multiple branching rungs that need to be evaluated before determining the state of the rung. Even when shown to experienced text programmers (Python, C# etc.) there is often a lot of scratching of the head and puzzled looks. While it's perfectly "logical" I have found that LL requires you to think in terms of 1s and 0s vs a flowing pattern of logic can can be described in words.

Enter the Era of Low Code Robots

In the last 3-5 years there have been advances by multiple companies who want to make programming easier. Most of these advances have been in the field of robotics vs machines control however.

Universal Robots was one of the pioneers in making programming robots simpler. Their URCaps environment was simple to learn and use even for non-programmers. Add in their opensource environment allowing component manufacturers to make their accessories work with the robot easily and you have a very powerful ecosystem.

READY Robotics has introduced Forge/OS that allows you to program several different robot manufacturers all from one simple flowchart based programming language. This allows a manufacturer who may have a variety of robots to train their staff on one language vs "all of them". It also provides a method of standardization so that any technician can work on any robot knowing that they will be familiar with the programming structure and methodology.

Realtime Robotics, Inc. has pioneered the motion planning aspects of robotics by automatically preventing collisions and prioritizing movements automatically. This was a cumbersome and often dangerous manual task, ensuring robots did not enter the same workspace simultaneously.

The introduction of the tablet based teach pendant by FANUC America Corporation (first used to program their CRX cobot) has been extended to be able to communicate with all of their industrial robots, making programming much simpler. Other traditional robot manufacturers have adopted a similar approach to simplifying their pendants.

Finally, Epson America Inc. recently introduce RC+ Express Edition. This is a drag and drop based programming interface that allows for rapid development of simple applications. While I have extensive experience with their traditional SPEL+ language, I had never used this particular application. After downloading a trial I had a simple palletizing program fully written and documented in less than an hour.

There are others working in this field (apologies that I can't mention you all) and the advances are quite amazing.

But What about Machine Control?

While the industry has no shortage of companies working on the simplification of robot programming, why is one one working on the same advances in machine control?

Arguably this is a much larger and more complex market. While small manufacturers (and distribugrators) are often pretty good at mechanical design and even perhaps some vison and robot programming they often lack the skillset and experience to do the PLC programming required for a robust system. This requires them to hire outside contractors or an integrator to help them be successful. While not a bad thing (remember I owned an integrator for 18 years) there are many reasons while an integrator may NOT be the right answer.

Imagine a world where we could have a small machine programmed and debugged in a matter of days or weeks? By using simple language and graphical interfaces it opens the ability to program these machines by even non technical individuals.

While this is NOT an example of what the final outcome should look like consider this simple example of a flashing light. Experienced PLC programmers are going to laugh considering this is indeed a simple example but hear me out...

On the left is an example using two timers to flash a light on and off every half second. Show this to a non programmer and they *may* be able to determine what's going on here. The issue with LL is that it requires you to look at a rung and then determine the state and then go back to previous (or subsequent rungs) and see how that rungs changes depending on the changed state of the other rungs. Is Timer1 on or off? Timer2?

On the right you will find a simple example I wrote using Epson's RC+ Express. In this example ignore the LOOP function (as PLC naturally loop their code). In it I simply turn on an output, wait for a period of time, then turn it off, wait again, and repeat. I can, and have, shown this code to children and other non programmers and they easily understand what is going on.

Epson's RC+ Express is a tool I had available and while NOT the ultimate answer it's a good illustration of?what a solution might look like. This is not an endorsement of their product and I have not been compensated by Epson in any way. #EndLegalDisclaimer

Side note: You LL experts are going to tell me I could have done this with one timer. And you are right. But while simpler, the rung actually looks more confusing.

By having a library of simple command blocks such as:

• If..Then
• Input State Check
• Output State Set
• Do..While
• Wait
• Goto Function
• Script Function (call a complex math formula or string manipulation script)

...and many many more, one could build a very powerful and simple to use machine control system. Opening up the architecture to suppliers (much like URCaps) one could create an environment where programming a 罗克韦尔自动化 servo or a SMC valve bank could be achieve by simple filling in the blank variables for each component.

Furthermore such a graphical interface lends itself to a much more connected and simple HMI design as both of these are graphical forms of communication.

Resistance to Change

The biggest argument against leaving LL is that an entire generation of maintenance technicians have been brought up with the language. Proponents will claim that they don't want to change and that we should keep using this language because "it's the way we've always done it".

I was taught FORTRAN in college, because that was the predominant language used by mechanical engineers at the time. Meanwhile the electrical engineers were taught C. I begged my college to allow me to take C (the growing, more popular language) but they refused. The next semester they changed the ME programming curriculum to be C instead of the "now dying" (their words) FORTRAN.

How many FORTRAN programmers do you see anymore (if they have giant long grey beads we're not going to count them).

If all those FORTRAN veterans would have had their way, we'd still be programming in that language. In almost every other industry (electrical, web, finance etc..) we have adopted newer and new languages as their advantages are show. Notepad based HTML gave way to Cold Fusion which gave way to PHP, Java, JavaScript, Python, RubyOnRails and more.

I also feel that experienced PLC progamemrs feel threatened by tools that make their jobs easier. (That's human nature across all aspects). However there will always been the need for these experts and the fear of innovation is not a valid excuse to not move forward,

We cannot dismiss new technologies just because we're used to the old ones. Advances are made by disruption. The #GenZ and younger #millennial generations want a simpler to use programming language that can be used on phones, iPads or tablets. Soon these younger technicians will be replacing the older guard who grew up only knowing Ladder Logic. We can either help create new tools or they will find way to do it themselves.

Conclusions

Will Ladder Logic every go away? Probably not for a very long time. It's far too pervasive and quite honestly, powerful. There are complex systems that would be very difficult to program using a graphical interface.

With the advances of low code, graphical drag and drop programming languages we are lowering the bar to entry however. (I refuse to use the word democratization as it's an annoying buzzword, but it holds true.) By introducing programing languages that even novices can use, it opens up the world of automation to everyone.

If we want our industry to continue to grow then how can that be a bad thing?

PS: If you're a VC and want to fund this development, give me a ring. I know some people who can help make this a reality.