Do not memorize this drawing as “the motor rung”. Say what each contact contributes. Moving supplies remembered purpose. DriveReady supplies permission. AtDrop removes the request when the destination is observed. Stop removes it when interruption is requested. If a reviewer points to a contact and you can only answer “it makes the rung work”, return to the contract.
Read a rung as a question followed by a result
Ladder diagrams borrow their appearance from relay circuits, but the controller executes instructions. A contact instruction asks about a stored Boolean value. A coil instruction writes a Boolean value according to the evaluated rung. The resemblance to electrical drawings is helpful until it makes you assume that every symbol is a physical device or that all rungs act simultaneously.
Start by reading a rung in plain language. “If a release is requested, and the discharge path is available, and the head is clear, command the conveyor.” That sentence translates directly into a series of true-testing contacts followed by a normal coil.
The text diagrams here show logical topology rather than a specific vendor editor's drawing syntax. [ A ] tests whether A is true, [/ A ] tests whether A is false, and ( Q ) is a normal output coil.
|----[ ReleaseRequest ]----[ DownstreamReady ]----[ HeadClear ]----( ConveyorCmd )----|If any series condition is false, the evaluated path is false. The normal coil writes false. The coil does not simply “do nothing” on a false rung.
Series means AND; parallel paths mean OR
Suppose either an automatic request or a manual jog may request the conveyor, but both require the downstream path to be available. Put the request paths in parallel and the shared permissive after their join.
|----+----[ AutoRequest ]----+----[ DownstreamReady ]----( ConveyorCmd )----|
| | |
| +----[ ManualJog ]-----+The corresponding expression is (AutoRequest OR ManualJog) AND DownstreamReady. If you put DownstreamReady only in the manual branch, the automatic branch bypasses it. The picture can make that mistake easier to see than a dense expression, but only if you inspect the actual branch boundaries.
Mode selection still matters. In a full design, the request signals should already express valid ownership, or the respective mode conditions should appear in their branches. The diagram is an excerpt about topology, not a complete conveyor controller.
A normally closed instruction is not a wiring instruction
The slash in [/ FaultActive ] means the logic passes when the Boolean FaultActive is false. It does not tell you how a field contact is wired. A physically normally closed device may produce a true input in its healthy condition, and you may use a true-testing instruction to ask whether that healthy condition exists.
Name the normalized signal first, then choose the instruction that asks the correct question. If PressureAdequate is true when operation is permitted, [ PressureAdequate ] reads directly. Choosing a slash because someone called the physical pressure contact “normally closed” confuses electrical topology with Boolean evaluation.
During diagnosis, inspect the raw input, the normalized meaning, and the rung separately. A green contact display indicates an instruction's evaluated condition according to that editor's convention; learn the convention before inferring voltage at a terminal.
A seal-in branch creates working memory
A classic run latch places a contact of its own run-request bit in parallel with Start, then keeps Stop in the shared series path:
|----[/ StopRequest ]----+----[ StartRequest ]----+----( RunRequest )----|
| | |
| +----[ RunRequest ]-----+On the first accepted Start, the coil becomes true. On later scans, its contact keeps the branch true after Start is released. Stop makes the shared path false and the normal coil clears the request.
This teaches a memory mechanism, but it also has a limitation: a held Start can reassert the latch after Stop is released. Use the request and restart rules from the behaviour contract. A familiar rung is not automatically the correct rung for every machine.
Set and reset coils offer another way to store a bit. They require an explicit priority and a clear owner. If set and reset instructions occur in different routines, understanding the final value may require inspecting execution order across the project. Keep the lifecycle together when possible.
One output should have one visible decision
Here is a troublesome pair of rungs:
Rung 1: [ AutoRequest ] ------------------------------ ( ConveyorCmd )
Rung 2: [ ManualRequest ] ---------------------------- ( ConveyorCmd )If both are normal coils evaluated in that order, rung 2 writes the final value. An automatic request can be true, yet a false manual request writes the output false afterward. The programmer may expect OR; the program performs two assignments.
Combine the requests before the output, or put them in parallel branches of the single owning rung. Use the cross-reference tool to find every write to an output. Include writes inside function blocks, indirect mappings, and supervisory interfaces where the platform permits them.
This is an example of a project rule that earns its place: a single command owner makes behaviour easier to prove. PLCopen's published coding guidelines are useful material when agreeing naming and language rules with a team; the exact project convention should be documented and reviewed.
Function blocks on rungs still have state
A timer box or counter box is not merely a longer contact. It has an instance, inputs, outputs, and internal state. Understand whether the rung controls a block's input or whether the vendor's execution-enable mechanism skips the call. Those are not necessarily equivalent.
A timer intended to reset when a condition is false must receive that condition under the block's documented calling rules. If the program stops calling the instance entirely, stored outputs may remain unchanged until another call. Drawings that look similar can therefore have different runtime behaviour.
Watch a timer's input, elapsed value, and done output together. If the elapsed value never resets, first investigate whether the block receives a false input; do not immediately increase its preset.
Try it
A learner draws two parallel paths. The top path contains AutoFillRequest; the bottom contains ManualFillRequest followed by CartonPresent. Both paths join at a normal DispenserCmd coil. The requirement says a carton must be present for either request.
Describe a failing input combination, redraw the topology in words, and state how many normal coils should write DispenserCmd.
Work through the answer
Set AutoFillRequest true, ManualFillRequest false, and CartonPresent false. The top path is true and bypasses the carton condition, so the dispenser command becomes true. The rung is expressing a different requirement than intended.
Place the two request contacts in parallel, join them, then place CartonPresent in series after the join. The equivalent expression is (AutoFillRequest OR ManualFillRequest) AND CartonPresent. One normal coil owns DispenserCmd.
The missing carton should also produce a useful reason when a request is refused. Keep that diagnostic decision visible rather than turning the permissive into an unexplained dark rung. In a real filling system, carton presence alone would not establish all conditions needed for dispensing; this exercise isolates the branch error.
Next, Structured Text expresses the same decisions with words and punctuation. The language changes; ownership, priority, and scan behaviour remain.