Common PLC Programming Mistakes and How to Fix Them

These are the most common mistakes found during PLC code reviews and migration projects. Each one has caused real production problems.

1. Forced I/O Left Permanently#

The mistake: During commissioning or troubleshooting, an I/O point is forced (TRUE/FALSE) to bypass a sensor or actuator. The force is never removed.

Consequence: The safety interlock or sensor check is permanently disabled. The machine operates without the protection. This is the #1 cause of hidden safety bypasses.

Fix: Check the force table after every commissioning session. Establish a policy: no permanent forces in production. In TIA Portal: Online → Force table. In STEP 7: PLC → Display Force Values.

2. Writing the Same Output from Multiple Locations#

The mistake: Output A 4.0 (Motor) is written in PB3 (automatic mode) and in PB7 (manual mode). Both blocks run every cycle.

Consequence: The last write wins. If PB7 runs after PB3, the automatic mode logic is overridden every cycle. The motor may not behave as expected.

Fix: Write each output in exactly one location. Use a marker as a "command" from each mode, then have a single output network that combines the commands:

// Single output location:
IF #Auto_Mode THEN Motor := Auto_Motor_Cmd;
ELSIF #Manual_Mode THEN Motor := Manual_Motor_Cmd;
END_IF;

3. Missing Initialization at Startup#

The mistake: Markers and DB values are not initialized when the PLC starts. They retain random values from the previous state (or zero if not remanent).

Consequence: Unpredictable behavior on first startup. A sequence starts at step 5 instead of step 0. A counter starts at 347 instead of 0.

Fix: Initialize all critical variables in OB100 (startup OB) or at the beginning of OB1 on first scan. Use OB100 start information to detect first cycle.

4. Timer Value Mismatch#

The mistake: A timer is set to 100 ms but the mechanical process needs 3 seconds. The timer was copied from another machine and never adjusted.

Consequence: The sequence advances before the hydraulic cylinder is fully extended. Collision, product damage, or machine damage.

Fix: Verify every timer value against the actual process requirements. Ask the machine operator: "How long does this movement take?" Add 20–50% safety margin.

5. BCD/Integer Confusion (S5)#

The mistake: An S5 program loads a counter value (L Z n → BCD format) and performs integer arithmetic (+F) on it.

Consequence: For values 0–9, BCD and binary are identical — no visible error. At 10, BCD is 0x10 (decimal 16), not 0x0A (decimal 10). Calculations produce wrong results intermittently.

Fix: Convert BCD to integer before arithmetic. In S7, use IEC counters (CTU/CTD) that return INT values directly.

6. The DW×2 Error (S5→S7 Migration)#

The mistake: During S5→S7 migration, data block word addresses are not multiplied by 2. S5 DW 5 is coded as S7 DBW 5 instead of DBW 10.

Consequence: The program reads the wrong data. It compiles without error. The data is shifted by half — setpoints, limits, and parameters are all wrong.

Fix: Apply the ×2 rule for every DW→DBW conversion. Use the PLCcheck Pro address converter or our reference table.

7. No Error Handling for Communication#

The mistake: Communication blocks (BSEND, TRCV_C, PUT/GET) are called without checking the DONE/ERROR/STATUS outputs.

Consequence: If communication fails, the program uses stale data without knowing it. A HMI setpoint change is never received, but the program keeps running with the old value.

Fix: Always check the STATUS output. Implement a timeout: if no successful transfer for N seconds, activate an alarm.

8. Overlapping Marker Memory#

The mistake: MW 10 is used in FB1 as a temperature setpoint. MB 10 is used in FB2 as a status byte. MW 10 includes MB 10 and MB 11 — writing MW 10 overwrites MB 10.

Consequence: Intermittent data corruption. The temperature setpoint changes the status byte. The bug is extremely difficult to find because it depends on execution order.

Fix: Use the cross-reference list to check for overlapping access. On S7-1500, use global data blocks instead of markers — each variable has its own memory.

9. Modifying Safety Logic Without Validation#

The mistake: A safety interlock is changed to "get the machine running faster." The change is not documented, not validated, and not reviewed.

Consequence: The next time the safety function is needed, it does not work as expected. Potential injury.

Fix: Every safety logic change requires: documentation of the change, review by a second person, validation testing, and management approval.

10. No Program Backup#

The mistake: The PLC program is only in the PLC. No backup exists on a PC, server, or removable media.

Consequence: If the CPU memory is corrupted (battery failure, firmware update error, hardware defect), the program is lost permanently.

Fix: Back up every PLC program. Store backups in at least two locations. Verify backups periodically by comparing online/offline.

How PLCcheck Pro Helps#

PLCcheck Pro detects many of these mistakes automatically:

• Identifies forced I/O references
• Finds multiple writes to the same output
• Detects overlapping marker/DB memory access
• Flags missing initialization
• Lists all timer values for review

Upload your code for analysis →

Maintained by PLCcheck.ai. Last update: March 2026. Not affiliated with Siemens AG.