How To Read Ladder Logic in PLC and Relay Controls, Part 2

Ladder logic is a tricky thing. At the heart of this industrial programming language lies a brilliantly simple structure (see Part 1 here), each line acting as a simple comparison to drive signals on or off. But beyond that simplicity are many layers of complexity: branching line structures, function blocks, global and local variables, interlacing subroutines, and many other factors that can bring troubleshooting to a screeching halt.

In order to read and understand ladder logic, each professional has established a unique mental flowchart process built from years of on-the-job experience. To continue revising and improving your own methods, we have compiled some of the most common recommendations and tricks for analyzing ladder projects from simple to moderate complexity.

Understand the Origin of Ladder Logic

It’s called "ladder" because there are many horizontal lines, each one broken with both contacts (input signals) and coils (output signals) that are each measured one at a time. They come from the interlocking electromechanical control relay systems that existed before computers. Each relay circuit was powered by a power supply, some systems by AC and some by DC.

Figure 1. Massive banks of control relays were the precursor to ladder logic programming. Image used courtesy of Adobe Stock

Due to the nature of electronics, when you have multiple parallel circuits, they all permit the flow of electricity simultaneously–at least as long as the circuit is complete.

Likewise, the first step in ladder diagram interpretation is to understand that the program does not execute in a sequential order. That is, something at the very end of the program may become true even if the first line is false.

In structured text codes, we often find that the code ceases to progress after a certain line, halting and waiting for a condition to become true before the next line(s) can execute. Therefore, we "debug" these codes starting from line 1.

In contrast, PLC programs allow the user to search throughout the code for a certain key variable. The reason for a certain problematic action is often buried in a sub-routine. Learn to use the search function. For example, if an output is stuck "ON," search for that output and reverse engineer the input conditions that caused the failure. Working backward is usually much faster than starting from the top of the code.

Learn the Sub-Routine Structure

Just like in structured text code, the program always has a "Main" routine that executes continuously while the PLC is in run mode. If line conditions are met, the program may jump into a subroutine at any time.

However, the program will always return to the main routine once complete. As before, in a text-based program, we may find a while loop that causes the code to stick inside a sub-routine, but this is not the case in ladder logic. We may be locked out of a sub-routine for various conditional reasons but never stuck inside one.

Figure 2. A good technician should learn how to read both the ladder diagrams and the electrical schematics. Image used courtesy of Adobe Stock

Now, that broad statement above may be generally true, but there are cases in which jump and label instructions can cause a code to perform a smaller loop inside of the main program loop. Be careful of these loops because they can cause the code to become stuck in a single area.

Default State of Coils is Often Unknown

In a typical programming language, declaring the variables sets an initial value for everything when the power is cycled or the program reset. However, turning off a relay or resetting a motor drive may be dangerous unless the specific program conditions are deemed safe. Therefore, when the power is cycled, most I/O points will retain the same status they were last assigned.

When an output is stuck "ON," we may initially think that a conditional line somewhere is also stuck "ON." However, the true fault may be that the line was inadvertently deleted or a sub-routine is no longer running. If the ladder rung is not being executed, do not be fooled into thinking the variable will automatically turn "OFF" by default.

That being said, there are ways to set initial values for variables under certain conditions, but the hardware input conditions usually dictate the output state, not the software.

What if I Only Have Drawings of the Ladder Diagrams?

Many of the previous tips assume access to the software environment so that you can monitor the rungs and cross-reference the variables, but what if you only have printed or digital files of the ladder drawings?

If digital, I once again encourage the liberal use of the search function (ctrl-f or cmd-f), which can be used in PDF, text, and most other file types.

Figure 3. Line diagrams explain the logic, but they can’t replace the physical wiring diagram for any electrical system. Image used courtesy of Adobe Stock

For physical prints, this is by far the most difficult challenge of all, but not impossible. For large programs, you can’t search lists of variables, and simply flipping pages back and forth to reverse engineer a problem leads to an unsolvable maze of cross-referencing. For this task, I have used colored sticky notes (like Post-It notes) more than once. When the actual suspect variable is located, that page is tagged with a color, then the input condition variable(s) are noted. Working in reverse, once that input condition is found on the output end of another rung elsewhere, that page is marked in color similarly, giving you an easy way to flip between related pages. Usually, an entire chain of input-to-output events will not be more than a few layers deep.

For this manual paper-trail method, finding each variable still takes an agonizingly long time. Still, it is absolutely essential to carefully track the logic flow path in an organized manner.

Can you Practice Troubleshooting?

You can and should practice troubleshooting as much as possible.

Try this: while the program is running successfully in operation, go to the variables (or tag) list and pick an output variable.

First, imagine what symptoms you would see if this output was faulty—stuck on or off. This step prepares you for a "root cause analysis" mindset. Don’t just fix the problem; fix the reason for the problem.

Next, find the program's output variable as quickly as possible. If it exists in multiple locations, figure out why and how each location differs. You may find an output as a momentary coil or as a set/reset (latch/unlatch) matching pair.

Then, reverse engineer. Try to explain several possible reasons that an output may be hypothetically stuck on/off. Trace the problem back through several layers if necessary. What I mean by layers might be, for example, a relay coil is energized by a timer Q bit. But the timer is energized by a memory coil. That memory coil is energized by two sensors being ON simultaneously. If you wanted to trace back to the sensors, you’d need to locate three different rungs, not just one.

Some Additional Notes

There are a few additional items that are worth mentioning.

A ladder diagram does NOT replace an electrical schematic or vice versa. The ladder logic only explains how the system works; it does not define how the field and control devices are physically wired. Don’t ignore either one.

If, due to security or user privilege reasons, you don’t have access to the PLC programming software, don’t worry. Ask the operations manager for an export of the project as a pdf or similar. You can search and view every variable, description, and ladder line, but you will not need to connect to the system.

There are Many Methods

Reading ladder logic is not a standardized process; everyone does it differently. Practice as much as you can to figure out your best practices, and share them with others to better grasp your process.

If you have certain ladder troubleshooting strategies, please share them below. I’d love to learn more!