PLC duplicate output warning: write each output in one place

What the duplicate output warning means

The checker compares instruction addresses across the whole project and flags any output written from more than one place. Vendor user manuals document this duplicate reference check, and on most packages it runs as part of the program check: the report shows warnings while the program still loads and runs.

The scan model explains why the warning matters. The controller solves rungs in order, top to bottom, writes results into an output image, and copies the image to the terminals at the end of the scan. A small machine PLC commonly completes that cycle in a few milliseconds; a 3 ms scan is a typical figure. When two instructions write one address in the same scan, the value left by the last write is the one that reaches the terminal.

Coil style decides what a false rung writes. A coil that follows its rung condition writes 0 when its contacts are false, so a later false rung erases an earlier true write in the same scan. A set-dominant style leaves the bit unchanged on a false rung, so two writes act like an OR on one CPU and like an override on another. The warning marks exactly that ambiguity, and one writer per output removes it on every controller.

Symptoms and what each points to

• Manual works, auto never starts the output. The routine's write lands after the main program's write in the scan, and its false condition clears the auto request before the image reaches the terminals.
• A panel button moves the output while the machine is in auto. The manual rung has no mode contact in series, so its write executes in auto too.
• The output drops whenever the panel returns to a certain screen. A screen-change routine is writing the address; that is the separate case covered in clearing a PLC coil range when the HMI returns to a screen.
• An unrelated edit changes machine behavior with no new warning. The edit moved a rung or a routine call, and order-dependent writes changed hands.
• Warnings on a machine that runs fine today. The result depends on scan order and instruction type, so today's behavior holds until something reorders the program.

Checks to run first

1. Read the whole program-check report and write down each flagged address. On a machine with 16 outputs and 6 warnings, this first pass takes about 5 minutes.
2. Search the project for each address and list every instruction that writes it: main program rungs, every subroutine, and any block move or clear whose target range covers the address.
3. Mark execution order. Your controller's manual documents the order in which the main program and routines execute; note which write runs last in auto and which runs last in manual.
4. Write the mode rules before you edit: a panel button commands an output in manual only, and the permissives that must hold in both modes belong on the final output rung.

The fix: one writer per output

1. Back up the project.
2. In the auto section, replace the write to the output with a write to Widget_On_Auto, keeping the sensing contacts on the rung: Auto_Mode AND Part_Present → Widget_On_Auto.
3. In the manual routine, end the rung on Widget_On_Manual with the mode contact in series: Manual_Mode AND HMI_Button → Widget_On_Manual. The series mode contact is what keeps the panel from commanding outputs in auto. The command-bit layout is the same one described in make an HMI button turn on a PLC output through a command bit.
4. Add one final rung, in one place, that drives the physical output: the two request bits in parallel, shared permissives in series. As a logic line: Y7 = (Widget_On_Auto OR Widget_On_Manual) AND Guard_OK. The contact names are illustrative; keep your own tag names.
5. Delete every other write to Y7, including the writes inside the subroutine. Some CPUs offer an instruction called OROUT that merges writes into an output address; availability and exact behavior vary by CPU, and a visible two-bit rung reads faster during a breakdown, so the plain rung is the default here.
6. Repeat for every flagged address, then run the program check again and confirm the warnings for those addresses are gone, 0 duplicate references left.

Worked example: one output through auto and manual

A filler machine has 16 outputs. 6 of them are also operable from the panel in manual, and the program check reports 6 duplicate coil warnings. Follow the conveyor output, Y7 in this example. Main program rung 18 reads Auto_Mode AND Part_Present AND Guard_OK → Y7. The manual routine executes after the main program, and its rung 4 reads Manual_Mode AND HMI_Button → Y7. Take the scan at 3 ms, in the ordinary few-millisecond range for a small machine PLC: 1 ÷ 0.003 s ≈ 333 scans each second, so both writes land on Y7 333 times every second.

Before the fix, with both rungs writing Y7 directly:

Auto: 1 then 0, last write wins, Y7 = 0. Manual: 0 then 1, Y7 = 1. The buttons work and the auto cycle does not, which matches what the floor sees.

After the fix, with Y7 = (Widget_On_Auto OR Widget_On_Manual) AND Guard_OK and Guard_OK healthy in every row:

All 6 warnings clear. The conveyor follows the auto cycle, a stray button press in auto moves nothing, and manual control passes through the same guard contact as auto.

Recommendation: whenever the program check names an output address more than once, give that address one writer. End each mode's rung on its own internal bit, OR the bits on a single final rung with the shared permissives in series, and gate the manual request with the manual-mode contact so the panel cannot move outputs in auto. On the example machine that is two request bits and one output rung for each of the 6 flagged addresses, and the warnings go away together with the order dependence.

Verify both modes before production

One boundary stays fixed: emergency stop and guard circuits stay in the safety layer, hardwired or safety-rated as your machine standard requires, and this rework only rearranges ordinary command writes.

1. Put the machine in a safe state for the first runs: movers disconnected or the drive in a commissioning state.
2. Run auto for at least 10 minutes and confirm each output follows its auto request. Tap a panel button during auto: Widget_On_Manual stays 0 because Manual_Mode is 0, and the output holds its auto state.
3. Switch to manual and confirm the button drives the output through the permissives. Release the button and the request drops, because a panel button is momentary; holding an output through a timed sequence is a timing design, covered in the timer-rung fix for an HMI button output that only stays on while pressed.
4. Watch the final rung solve live: put the request bits and the outputs on one monitor screen; displaying 16 PLC input and output bits on one screen shows the layout.
5. Run the program check once more and confirm 0 duplicate references on the 6 addresses, then return the machine to service.

When the same line also owes the crew a status board readable from the aisle, that is a separate screen doing a separate job; see shop-floor screens and andon-style boards.

Questions