Skip to content
Case Study

Finding Unauthorized PLC Changes After Maintenance

After a weekend maintenance shutdown, a bottling line started faulting intermittently. The plant engineer compared the pre-maintenance backup against the current PLC program and found three unauthorized modifications -- including a bypassed interlock that was causing the faults.

Monday Morning: Line Down

Monday morning, Filler Line 2 started faulting intermittently. The line had been running perfectly on Friday before the weekend shutdown. Maintenance had access to the system over the weekend for a scheduled valve replacement on the filler station.

The faults were inconsistent -- the line would run for 15 to 20 minutes, then the overflow sensor would trip and halt production. The operator would clear the fault, the line would run again, and the cycle would repeat.

The plant engineer suspected someone had made changes to the PLC program during the maintenance window. She pulled the pre-maintenance backup ACD file from the server and uploaded both versions to PLC Company to compare them.

“The line was running fine Friday. After the weekend maintenance window, it started faulting every 20 minutes. Something changed.”

-- Plant Engineer, Filler Line 2

Comparing Backup vs. Current Program

The diff report immediately revealed three modifications in the Filler_Control routine that were not part of the authorized maintenance scope.

Files Compared

backup_2024-01-12.acd vs current program

Diff Summary

Comparison Report

3Rungs Modified
0Rungs Added
0Rungs Removed
47Routines Unchanged

All 3 modifications were found in the Filler_Control routine. The remaining 47 routines in the program were identical between the backup and current versions. Changes include a timer preset modification, a removed interlock condition, and a force bit applied to an output.

Detailed Changes

Modified Rungs in Filler_Control

Modified

Rung 14 -- Timer Preset Changed

- TON(FillCompleteTimer, 2000, 0)
+ TON(FillCompleteTimer, 500, 0)

The FillCompleteTimer preset was reduced from 2000ms to 500ms. This timer governs how long the filler waits before advancing to the next phase. At 500ms, the filler moves to the next bottle before the current one is fully filled, leading to inconsistent fill levels.

Interlock Bypassed

Rung 22 -- Level Sensor Interlock Removed

- XIC(FillLevelSensor) XIC(FillerReady) OTE(FillValveCmd)
+ XIC(FillerReady) OTE(FillValveCmd)

The FillLevelSensor condition was completely removed from the rung. Without this interlock, the fill valve opens based solely on the FillerReady signal, regardless of the actual fill level in the bottle.

This is the root cause of the intermittent faults. Without the level check, bottles overfill and liquid triggers the overflow sensor, which faults the line. The 15-20 minute interval between faults corresponds to how long it takes for the fill timing drift to cause an overflow condition.

Force Applied

Rung 31 -- Force ON Applied to Output

- XIC(CycleComplete) OTU(FillInProgress)
+ XIC(CycleComplete) OTU(FillInProgress) [Force ON on FillInProgress]

The FillInProgress bit has a force applied, holding it ON regardless of the rung logic. This means the OTU (unlatch) instruction on CycleComplete has no effect -- FillInProgress stays latched even after a cycle completes. Someone forced this bit during troubleshooting and never removed the force.

What the Comparison Revealed

3 Changes Found Instantly

Compared 47 routines and hundreds of rungs in seconds. The diff pinpointed exactly which rungs were modified and what changed in each one.

Root Cause Identified

The bypassed FillLevelSensor interlock in Rung 22 was causing bottles to overfill and trip the overflow sensor, producing the intermittent faults.

Unauthorized Modifications

The timer preset change and leftover force bit exposed undocumented changes made during the maintenance window that were outside the authorized work scope.

Audit Trail for Review

The before-and-after diff report provided visual proof of exactly what changed, suitable for management review and incident documentation.

Three Steps to Compare

1

Upload Both Versions

Upload your backup ACD file and the current ACD file. Both programs are parsed automatically, extracting every routine, rung, and instruction.

2

Compare Programs

The system performs a rung-by-rung diff across every routine in both programs, identifying additions, deletions, and modifications down to individual instruction parameters.

3

Review Changes

Get a structured report showing exactly what changed, with before-and-after views, severity indicators, and analysis of each modification's impact on machine operation.

Try It With Your PLC File

Upload an ACD, L5X, or RSS file and compare program versions to find what changed.

Common Questions

Can I compare two different versions of a PLC program?

Yes. Upload both the backup and current ACD files, and PLC Company will perform a rung-by-rung comparison across every routine. The diff report highlights exactly which rungs were added, removed, or modified, with before-and-after views so you can see precisely what changed.

What types of changes does the diff detect?

The comparison detects instruction modifications (changed parameters, added or removed conditions), timer and counter preset changes, force bits applied to I/O, rung additions and deletions, tag value changes, and structural changes like reordered instructions. Each change is categorized by severity so critical modifications like bypassed interlocks are flagged immediately.

Can I export the comparison report?

Yes. The full diff report can be exported as a PDF document suitable for management review, audit documentation, or incident reports. The export includes all before-and-after rung details, a summary of changes by routine, and timestamps showing when the comparison was performed.

Does it compare tag values and configurations too?

The comparison focuses on program logic -- the ladder logic rungs, instructions, and their parameters within each routine. This includes timer presets, counter values, and instruction operands. Tag database changes (added or renamed tags) and controller configuration differences (communication settings, module configurations) are also detected and reported separately.