Understanding the Program Without Being a Programmer

You do not have to write ladder logic to read it, and reading it is
often all you need. Ladder logic is drawn to resemble a relay control
schematic: two vertical ‘rails’ with horizontal ‘rungs’ between them.
Power is imagined to flow left to right across a rung when the
conditions on that rung are satisfied. The contacts on the left are the
conditions; the coil or instruction on the right is the result.

The three symbols that carry most of the meaning

• Examine-if-closed contact ( -| |- ): true when its bit is ON.
  Think ‘is this condition present?’

• Examine-if-open contact ( -|/|- ): true when its bit is OFF.
  Think ‘is this condition absent?’

• Output coil ( -( )- ): energizes its bit when the rung to its
  left is true.

To read a rung, ask: for the coil on the right to turn on, which
contacts on the left must be true? Each contact points at a bit — an
input, an internal flag, a timer done bit — that you can then go and
verify. This is the bridge between the program and the field: a rung
tells you exactly which conditions the machine is waiting for, and you
can measure each one.

Online tools that find the answer fast

When you are online, the software shows which contacts are true by
highlighting them. A rung that is almost fully highlighted except for
one contact tells you instantly what the machine is waiting on. Two
features make this even faster. Cross-reference lets you pick a bit and
see every place it is used — invaluable when an output will not turn on
and you need to find what controls it. Search or ‘find all’ locates a
tag by name. In Studio 5000 these live in the Logic menu and the tag
right-click menu; in TIA Portal, cross-references are generated per
block and project-wide.

Forcing: powerful and dangerous

A force overrides an input or output, holding it ON or OFF regardless
of the real world. Forcing is a legitimate diagnostic tool — forcing an
output briefly can confirm that the field wiring and load are healthy —
but it bypasses the safety logic your machine depends on. Force only
when you have confirmed no motion will cause harm, announce it, and
remove every force the moment you are done. Both platforms show a
prominent force indicator; never walk away from a controller with forces
active.

A worked example: reading a start rung

Imagine a simple motor start rung. From left to right it has: a
normally-open contact for the Start button, in parallel with a
normally-open contact for the motor’s own Run bit (the seal-in), then in
series a normally-closed contact for the Stop button, a normally-closed
contact for the Overload, and finally the Run output coil. To read it,
ask what makes the coil energize. The Start button or the seal-in must
be true, AND the Stop button must not be pressed, AND the Overload must
not be tripped. Press Start and, provided Stop and Overload are healthy,
the coil energizes; the seal-in then holds it on after you release
Start.

Now troubleshoot with this rung in mind. The motor will not start.
Online, you look at the rung: which condition is not satisfied? Perhaps
the Overload contact shows false — the overload has tripped, and the
rung can never complete. Perhaps the Start contact never goes true when
the button is pressed — the button, its wiring, or its input has failed.
The rung has told you precisely which of several possible causes is
present, and each one points at a specific device you can then verify in
the field. This is the everyday power of reading logic: it converts ‘the
motor will not start’ into ‘the overload contact is open,’ which is a
solvable, specific problem.

Timers, counters, and latches

Beyond simple contacts and coils, three instruction types appear
constantly and are worth recognizing. A timer delays an action — its
‘done’ bit turns on after a preset time — and a machine ‘waiting for no
reason’ is often waiting on a timer whose condition dropped out and
reset it. A counter tracks events and acts at a preset count. A latch
(or set/reset pair) holds a bit on until something explicitly turns it
off, which is how faults are often captured — a fault latches on so it
stays visible even after the momentary condition that caused it has
passed, and it must be explicitly reset. Recognizing a latched fault bit
explains why a fault persists after the cause is gone: it is waiting for
a reset.

Function blocks and structured text

Not all logic is ladder. Siemens programs frequently use function
block diagrams or structured text, and Logix supports these too. You do
not need to master them to troubleshoot, but recognize what you are
looking at: function block diagrams connect boxes with signal lines, and
you trace a signal from output back toward its source much as you trace
a ladder rung. Structured text reads like programming code; when you
meet it, the cross-reference tool becomes even more valuable, letting
you find where a tag is written without reading every line. The
underlying task is unchanged: find what the machine is waiting for, then
verify it in the field.

Following a signal backward with cross-reference

The cross-reference is arguably the most powerful single feature for
a non-programmer troubleshooting logic, because it lets you follow a
signal backward to its source without reading the whole program. Suppose
an output will not turn on. You cross-reference that output’s tag and
see every rung that writes to it — usually just one or a few. You go to
that rung and read what it is waiting for. One of its conditions is an
internal bit; you cross-reference that bit and find where it is set, and
read that rung. Step by step, you walk backward from the dead output
through the chain of conditions until you reach a physical input or a
fault bit you can verify in the field. You never had to understand the
whole program — only to follow one thread from symptom back to a
testable cause, and the cross-reference is what makes that thread
followable.

Permissives and interlocks: designed reasons to
stop

Machines are full of deliberate conditions that must be satisfied
before an action is allowed — permissives and interlocks that exist for
safety and for correct sequencing. A permissive is a condition that must
be true to permit an action: the guard must be closed, the previous
station must be clear, the pressure must be adequate. An interlock
prevents actions that would conflict or cause harm. When a machine
‘refuses’ to do something, it is very often not broken at all but
correctly withholding an action because a permissive is not met. Reading
the logic reveals which permissive is missing, and that is genuinely
useful information: the machine is telling you a real condition of the
process is not as it should be. Do not fight the interlock; find why its
condition is not met, because that condition usually points at the
actual problem the interlock is protecting against.

Reading a sequence: how machines step through
operations

Many machines operate as sequences — a series of steps executed in
order, each waiting for its conditions before advancing to the next.
Understanding this structure helps enormously when a machine stops
partway through its cycle, because it tells you the machine is stuck
waiting for a specific condition to advance from one step to the next,
and identifying that condition identifies the fault. When a machine
halts mid-cycle, the question becomes: which step is it on, and what is
that step waiting for to advance? Online, you can often see which step
is active and read the conditions required to move on. A step waiting
for a position sensor that never reports, a pressure that never builds,
or a timer that keeps resetting is a step whose advance condition is not
met, and that unmet condition is your fault, named precisely by the
machine’s own sequence logic. Machines that stop cleanly at a consistent
point in their cycle are almost always waiting on a specific step’s
advance condition rather than suffering a random failure.

Comments and documentation in the program

Well-written programs contain comments and descriptive tag names that
are a gift to the troubleshooter, and using them accelerates everything.
A tag named Infeed_Guard_Closed tells you exactly what it represents
without any detective work, and a rung comment explaining a section’s
purpose orients you instantly. Where a program is well documented,
reading it to find what a machine is waiting on becomes almost
conversational — the program tells you in plain terms what each
condition means. Where documentation is poor — cryptic tag names, no
comments — the same task is harder but not impossible; the
cross-reference and the structure still let you follow signals even when
their names are unhelpful. Either way, whatever documentation exists is
worth reading first, because the original programmer’s descriptions of
what conditions mean are often the fastest route to understanding what
the machine needs to proceed.

A case file: the machine waiting on a permissive

An operator reports that a machine ‘won’t do anything’ when they
press start, and the natural assumption is a failure — a dead start
button, a broken output, a fault. But going online reveals no fault at
all; the machine is simply not starting because a permissive is not met.
Reading the start logic, the technician sees that starting requires
several conditions, and one of them — a guard-closed permissive — is not
satisfied. The machine is behaving exactly as designed, correctly
refusing to start because it believes a guard is open. This turns the
investigation from ‘what is broken’ to ‘why does the machine think the
guard is open,’ which leads to the guard’s sensing chain, where a
drifted or failed guard switch is reporting open despite the guard being
closed. The machine was never broken in the sense the operator assumed;
it was withholding a start because a safety permissive was not met, and
the real fault lay in the sensing that made the permissive false. This
is an enormously common pattern — a machine that ‘won’t do anything’ is
very often not broken but correctly refusing to act because a permissive
or interlock condition is unmet, and reading the logic to find which
permissive is missing points straight at the real fault, which lies in
whatever is making that permissive condition false. Fighting the
machine’s refusal wastes effort; understanding what condition it is
waiting for, and why that condition is not met, solves it.