Illustrative scenario · Discrete manufacturing

The engineer who wrote this logic left three years ago. Rung explained it in six minutes.

A packaging line keeps faulting mid-changeover. Nobody on shift wrote the ladder logic — and with Rung, nobody has to, to understand it.

Packaging · case palletizing Rockwell Studio 5000 / L5X export Two controllers on one line

A composite scenario grounded in real ladder-logic and produced/consumed-tag failure modes — not a specific customer.

6 min
to root cause
0 live
controllers touched
1 engineer
no OEM site visit
Context

A changeover fault nobody currently on staff can explain.

Line 6 packages three SKUs on a rotating changeover schedule. Twice this week, the case palletizer has faulted mid-changeover — no safety event, but each fault costs a changeover cycle, and a growing shrug from whoever's on shift. The engineer who wrote the palletizer's ladder logic left the company three years ago; the comments in Studio 5000 are sparse, and the two controllers on the line — the palletizer and the case packer — talk to each other through produced/consumed tags nobody currently on staff has fully traced.

Instead of scheduling a two-day OEM site visit, an engineer exports both controllers' programs and asks Rung to explain what's actually happening.

09:14
Second changeover fault this week logged
09:20
Engineer exports both L5X programs, opens Rung
09:26
Root cause traced across both controllers
09:41
Changeover sequence corrected, verified next cycle
Actions

The engineer describes the symptom. Rung reads the program.

Every step here is a local, read-only file parse — nothing ever connects to a live controller. →

Ask

Plain language — no ladder-logic literacy required.

Read the program

Parses both L5X exports — tags, comments, rungs.

Trace the signal

Follows the handshake tag across both controllers.

Explain

Plain-English root cause, and exactly where to fix it.

rung — operator terminal
rung ❯
✻ Thought for 3.2s
╭─ ⚙ plc_read_program
│ path=PalletizerPLC.L5X routine=ChangeoverSeq
╰─
N12: XIC(SKU_Select_Done)XIC(Downstream_Ready)OTE(Changeover_Enable);
// Enable changeover once SKU selected and downstream confirms ready
╭─ ⚙ plc_trace_signal
│ tag=Downstream_Ready paths=[PalletizerPLC.L5X, CasePackerPLC.L5X]
╰─
PalletizerPLC.L5X — "Palletizer_PLC1": 1 reference
ChangeoverSeq/ChangeoverSeq N12: …XIC(Downstream_Ready)…
CasePackerPLC.L5X — "CasePacker_PLC2": 1 reference
MainProgram/ProduceTags N3: MOV(Local_Ready,Downstream_Ready);
// written on a 500ms produced-tag scan, not event-driven
Downstream_Ready is written by the case packer on a 500ms polled
produced-tag update, not an event. During changeover the palletizer
checks it inside a ~200ms window right after SKU_Select_Done — about
1 time in 8 it reads stale data and the enable never latches.
Nothing's wrong with either program alone — it's a race between them.
Latch Downstream_Ready with a one-shot after SKU_Select_Done, or move the
check into the packer's own handshake rung instead of polling it.
Result

A produced/consumed tag race, traced without an OEM callback.

The engineer never connected to a live controller, and never sent proprietary ladder logic anywhere it shouldn't go.

6 min
Total time to root cause
vs. 1–3 days waiting on an OEM visit or the original programmer
0
Live controllers connected to
diagnosis parsed exported program files only
1
Engineer needed
no OEM site visit, no departed-programmer callback

The trace and the explanation are sitting in the session transcript — the next engineer who hits a produced/consumed tag race on this line starts from an answer, not a blank Studio 5000 project and three-year-old comments.

Why this is better than without Rung

What the same fault usually costs, and what it cost here.

An engineering estimate, not a lab result — every line, program, and failure mode differs. It's the shape of the problem this capability is built to compress.

Without Rung
1–3 days
With Rung
6 min
CriteriaWithout RungWith Rung
First look at the logic ✕Hours reverse-engineering sparse-commented rungs by hand ✓Parsed and explained in under a minute
Who's needed ✕The programmer who left, or an OEM field visit ✓Whoever is on shift, on the terminal they already have
Escalation path ✕OEM support ticket or contractor site visit (days, per typical SLA) ✓None required for this fault
Program exposure ✕Sometimes — proprietary ladder logic pasted into a general AI chat tool ✓None — files parsed locally, read-only, never connects to a live controller
Root cause found ✕Trial-and-error changeover retries, sometimes "fixed" by luck ✓Traced to a specific produced/consumed tag race across both controllers

This is a composite scenario grounded in real ladder-logic and produced/consumed-tag failure modes, not a specific customer's numbers — every line and program differs. The value here is measured in time and OEM dependency avoided, not a fabricated dollar figure.

See it on your own program export

Bring this workflow to your line.

Install Rung today, or talk to us about a design partnership for your site.