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.