Duplicate Coils and Output Conflicts in PLC Programming

Duplicate coils are among the most common—and most confusing—PLC programming mistakes.

They occur when two or more parts of the program write to the same output, command bit or internal variable.

For example:

Rung 1:
Start_Request ─────────────( Motor_Output )

Rung 8:
Fault_Reset ───────────────( Motor_Output )

Both rungs control the same destination. Each may look reasonable when viewed separately, but the PLC cannot preserve both results.

In a typical cyclic program, the later instruction overwrites the value written earlier in the scan. The final output depends on execution order, not on what the operator expects.

This creates machines that appear inconsistent even though the PLC is executing the program exactly as written.

How a Duplicate Coil Behaves

A standard PLC output coil does not usually energize the physical terminal immediately when the rung becomes true.

Instead, the instruction writes a value into an internal output image or memory location. If another instruction later writes to the same address, that second value replaces the first one.

Consider this simplified example:

Rung 1:
Start_Request = TRUE
Motor_Output := TRUE

Later in the program:

Rung 8:
Automatic_Mode = FALSE
Motor_Output := FALSE

When the scan finishes, Motor_Output is false because the second assignment occurred later.

Online monitoring may show the first rung as true. A technician sees power flowing to the coil and assumes the motor should run.

However, another rung has already overwritten the result.

This is why duplicate-coil problems can waste hours during commissioning.

“Last Rung Wins” Is Only a Simplification

For ordinary coils executing sequentially in one cyclic task, the final write usually determines the resulting state.

However, real PLC programs may also contain:

• Set and reset instructions
• Multiple cyclic or interrupt tasks
• Function blocks writing through shared data
• HMI commands writing directly to tags
• Communication blocks modifying the same variable
• Safety and standard programs exchanging signals

In these situations, the behaviour may be more complicated than simply “the last rung wins.”

The important rule is broader:

A command should have one clearly defined owner.

When several program sections can write to the same value, the result becomes dependent on task timing, execution priority and scan order.

Common Duplicate-Coil Symptoms

The output behaves inconsistently

The output works in manual mode but not in automatic mode—or the opposite—because one section of the program overwrites the other.

Startup logic appears to be ignored

The start rung becomes true, but a later initialization or interlock rung writes false to the same command.

A fault will not reset

One network clears the fault bit while another immediately sets it again during the same scan.

Sometimes that behaviour is correct because the original fault remains active. In other cases, it is an unintended conflict between separate fault routines.

The machine starts unexpectedly

A maintenance, recovery or automatic section writes true after the normal stop logic has already written false.

Restart behaviour changes between attempts

The final state depends on which asynchronous input or task writes to the command last.

Online monitoring looks correct

The monitored rung appears energized, but it is not the final location writing to the output.

Duplicate Physical Output Coils

The most obvious problem is using the same physical output address more than once.

For example:

Manual_Start ──────────────( Q0.0 )

Automatic_Start ───────────( Q0.0 )

This does not create an OR function.

If Manual_Start is true but Automatic_Start is false, the later automatic rung may write false to Q0.0. The motor remains off.

The programmer expected either condition to run the motor, but the PLC processed two separate assignments.

The correct structure is:

Manual_Run_Request OR Automatic_Run_Request
────────────────────────────────────( Q0.0 )

Even better, apply stop, fault and permissive conditions before the single final assignment.

Duplicate Internal Commands

Duplicate physical coils are usually easy to find. Duplicate internal commands can be more dangerous because they are hidden behind symbolic names and function blocks.

A tag such as Motor_Run_Command may be written by:

• Manual-control logic
• Automatic sequence logic
• Fault-recovery logic
• Maintenance controls
• Startup initialization
• Communication processing

The physical output may only have one coil, but its internal command still has multiple owners.

Cross-reference tools should therefore be used for both physical addresses and symbolic tags.

Look for every instruction that writes to the command, including:

• Normal coils
• Set and reset coils
• Move instructions
• Function-block outputs
• Structured Text assignments
• HMI write access
• Communication data transfers

Set and Reset Conflicts

Set-reset instructions intentionally allow a value to be controlled from separate conditions.

For example:

Start_Request ─────────────(S Motor_Run)

Stop_Request ──────────────(R Motor_Run)

This can be valid, but the priority must be clear.

What happens when START and STOP are true during the same scan?

The result may depend on which instruction executes later. Reversing the network order can reverse the priority.

For most motor commands, STOP should override START.

A clearer structure is:

IF Stop_Request OR Fault_Active THEN
    Motor_Run := FALSE;

ELSIF Start_Request AND Start_Permissive THEN
    Motor_Run := TRUE;
END_IF;

Now the priority is visible rather than hidden in ladder placement.

The same approach is useful for fault latches:

IF Fault_Condition THEN
    Fault_Latched := TRUE;

ELSIF Reset_Request AND Reset_Conditions_Valid THEN
    Fault_Latched := FALSE;
END_IF;

An active fault takes priority over reset.

Multiple Tasks Can Create Timing Conflicts

Modern PLCs may execute several program tasks:

• Main cyclic task
• Timed interrupt task
• Hardware interrupt
• Communication task
• Startup routine

If more than one task writes to the same tag, the result can change according to task priority and timing.

For example:

1. The main task sets a run request.
2. A higher-priority interrupt begins.
3. The interrupt resets the same command.
4. The main task resumes.
5. Another network sets the command again.

This type of conflict may appear only under specific production conditions, making it extremely difficult to reproduce.

Shared variables should have a defined owner. Other tasks should provide requests or status information rather than writing directly to the final command.

HMI Writes Can Conflict With PLC Logic

An HMI button should not normally write directly to a physical output or final motor command.

Suppose the HMI writes:

Motor_Run := TRUE

The PLC program later evaluates its start-stop logic and writes:

Motor_Run := FALSE

The HMI button appears to do nothing.

In another timing condition, the HMI write may occur after the PLC program and temporarily make the command true until the following scan.

This can create flickering or momentary commands.

The HMI should write to a request tag such as:

HMI_Start_Request

The PLC then decides whether that request may become an actual output command.

One Authoritative Output Owner

Professional PLC logic should give each physical output one authoritative owner.

Different program sections may create requests, but only one section should decide the final output state.

For a motor, the structure might include:

Manual_Run_Request
Automatic_Run_Request
Maintenance_Run_Request
Stop_Required
Fault_Active
Motor_Permissive
Safety_Healthy

The final command is then calculated once:

Motor_Output_Command :=
    Safety_Healthy
    AND Motor_Permissive
    AND NOT Fault_Active
    AND NOT Stop_Required
    AND
    (
        Manual_Run_Request
        OR Automatic_Run_Request
        OR Maintenance_Run_Request
    );

The physical output is assigned from that command in one location:

Q0.0 := Motor_Output_Command;

This makes the output behaviour easier to understand and verify.

Separate Requests From Feedback

A frequent design mistake is using one bit to represent several different states.

For example, Motor_Run may be used for:

• Operator request
• PLC output command
• Contactor status
• Motor-running confirmation

These meanings should be separated:

Motor_Start_Request
Motor_Output_Command
Motor_Contactor_Feedback
Motor_Running_Confirmed

This prevents feedback logic from accidentally overwriting a command and makes HMI diagnostics much clearer.

The operator can then see:

• Start requested
• Start permitted
• Output commanded
• Contactor energized
• Motor running

How to Find Duplicate Writes

Use the PLC programming software’s cross-reference or reference-data function.

Search for every write access to the affected tag.

Do not look only for visible output coils. Check for:

• Assignment coils
• Set/reset instructions
• Move instructions
• Block outputs
• InOut parameters
• Structured Text assignments
• Initialization routines
• HMI write permissions
• Communication mappings

Also inspect whether the same physical output is addressed symbolically in one location and absolutely in another.

For example:

Motor_Contactor

may point to %Q0.0, while another network writes directly to %Q0.0. They are duplicate writes even though the displayed names differ.

Troubleshooting an Output Conflict

When an output behaves incorrectly, trace the complete command path.

Monitor:

• Manual request
• Automatic request
• Stop request
• Fault state
• Permissive result
• Final internal command
• Physical output address
• Output feedback
• Current operating mode
• Sequence step

Use a PLC trace when the problem is intermittent.

A trace can reveal that the command turns on early in the scan and is overwritten several milliseconds later.

The HMI may never display this brief transition because its polling rate is much slower.

Why Duplicate Coils Are Dangerous

Duplicate output control does more than make troubleshooting inconvenient.

It can cause:

• Unexpected machine movement
• Outputs that cannot be stopped reliably
• Fault logic that is overridden
• Bypasses that remain active
• Commands that survive mode changes
• Restart instability
• Interlocks that appear ineffective

The danger increases when one programmer adds logic without realizing that another section already controls the same tag.

A program may operate normally for years until a small modification changes execution order or introduces one additional write.

Recommended Programming Rules

Use one final assignment for each physical output.

Allow multiple logic sections to generate requests, not direct output commands.

Define start, stop, fault and safety priorities explicitly.

Avoid scattered set and reset instructions.

Separate operator requests, PLC commands and physical feedback.

Use cross-reference tools before modifying an existing command.

Record why an output was activated or removed.

Review HMI and communication access to ensure external systems cannot write directly to final outputs.

Final Thoughts

Duplicate coils create output conflicts because several program sections attempt to control one state independently.

The PLC does not combine those assignments according to operator intent. It executes them in order, and later instructions can overwrite earlier results.

This can make startup logic appear ignored, prevent fault resets or even allow unexpected machine movement.

The professional solution is simple:

One output, one authoritative owner.

Manual logic, automatic sequences and maintenance functions may request operation. Faults and interlocks may block it. But the final command should be calculated and written in one clearly defined location.

The fewer places that control an output, the easier the system is to understand, test and commission safely.