S7-1200 TIA Portal Input Reads Zero: I0.4 Troubleshooting

Problem Overview

A field engineer reports the following symptom on a Siemens S7-1200 CPU programmed with TIA Portal:

• Digital input %I0.4 (label "prise de force") is wired to a permanent 24 V signal and is verified HIGH by both the physical LED indicator and 99 % of the program logic.
• In one specific network, monitoring the bit online shows %I0.4 = 0, breaking the rung.
• Inserting a memory bit (memento, e.g. %M10.0) assigned to %I0.4 in a previous network and using the flag instead of the input in the failing network restores correct behavior.
• All High-Speed Counters (HSC) on the CPU are confirmed disabled.

This article walks through the engineering diagnostic path, the actual root-cause families, the diagnostic steps to prove them, and a robust software pattern that prevents recurrence.

Why a Single Network Can Read I0.4 as 0

The S7-1200 stores digital inputs in two distinct areas that the user program can address:

The vast majority of user code reads %I0.4 from the PII. If the bit consistently reads 1 in those networks and only fails in one, the failure is not caused by a dead field wire, a missing 24 V supply, or a CPU hardware defect (those would corrupt the PII globally and the LED would also be off). The failure is one of the following four classes:

1. Conditional overwrite of the process image in the same scan (very rare, only via explicit SFC/POKE instructions).
2. HSC or PTO/PWM assignment of the input — when a function sub-module "owns" the terminal, certain TIA configurations can change the value the CPU writes back into the PII or the way the input is read.
3. Input filter time-out / hardware interrupt mis-configuration at the input channel — a configured rising-edge hardware interrupt can consume the signal in the cycle it occurs.
4. Edge / one-shot timing artefact — the network in question evaluates on a one-cycle pulse that has just been consumed by another rung (e.g. NEG / POS edge bit cleared by previous logic).

Step 1 — Verify the Failing Network Online

Open the affected FC/FB in TIA Portal, right-click the title bar and select Monitor On/Off. With the PLC in RUN, both %I0.4 and the surrounding tags must be visible at the same time. To compare the input against a memory copy side by side:

1. Insert a parallel contact %M10.0 next to %I0.4 in the failing network.
2. In a new network above, write: %M10.0 := %I0.4; (FBD) or equivalent ladder rung with a simple --| |--( )-- coil: A %I0.4, coil %M10.0.
3. Compile, download, go online, and observe both bits simultaneously for at least 60 seconds.

If the M bit is always 1 but the I bit momentarily shows 0, the input is being overwritten or read out of the PII at a different time than the M bit. If both go to 0, the issue is upstream (wiring, sensor, filter, or power supply).

Step 2 — Count the Number of 1→0 Transitions

Add a one-shot edge detector and a counter so you can quantify how often %I0.4 falls:

// FBD network - count falling edges of I0.4
      %I0.4   %M20.0        %MW100
--+--|/|-----(P)-----------(ADD 1)-----------(==)--
  |  (NEG edge)                          (target=%MW100)
  |
  +--[ %MW100 < 32767 ]

Run for an hour. Three outcomes:

• Counter increments every scan → the input is genuinely toggling or being overwritten every cycle. Investigate the channel assignment, HSC, or PTO/PWM.
• Counter increments only on power-up / STOP-RUN → the input was never reliably 1 at the moment the PII was sampled during the first scan. Add a power-on delay using %S_BSY / first-cycle flag.
• Counter never increments → the input is always 1; the failing network has a logic error (NOT contact, edge bit consumed elsewhere, or operand typo).

Step 3 — Check Hardware Configuration of the Input

In the project tree, open Devices & Networks → [CPU] → Properties → Digital inputs → Channel 4 and verify the following parameters:

Default filter for a 1212C/1214C/1215C digital input is typically 6.4 ms. If the field signal is a relay contact bouncing shorter than that window, the PII will read 0 between bounces. This is the single most common cause of "the LED is on but the bit is off."

Step 4 — Disable All HSC and Motion Functions

The S7-1200 shares terminals between standard digital inputs, HSC, PTO, PWM, and motion control. The CPU firmware rev 4.x and higher allows several of these to coexist, but firmware rev 2.x is stricter. Verify:

1. Open Device Configuration → CPU → Properties → Pulse generators (PTO/PWM): ensure the channel used by I0.4 is not assigned.
2. Open High-Speed Counters (HSC): confirm none of HSC1..HSC6 reference the input. Even when "disabled" in user code, a configured channel in the device view can still claim the terminal.
3. If you find an accidental assignment, unbind the channel, recompile, and re-download hardware configuration (not just the program block).

Step 5 — Use the Force Table to Validate the PII Path

The Force Table is a privileged tool — it overrides the PII from the field and is the only way to write to a physical input from TIA Portal.

1. Open Project tree → [CPU] → Watch and force tables → Force table.
2. Add row: %I0.4 → Force value 1.
3. Click Start force (the icon shows a padlock with a play symbol).
4. Go online and check the failing network. If the bit now reads 1 inside the network, the issue is the physical input path; if it still reads 0, the issue is downstream of the PII read (i.e. the network is overwriting or masking the bit).

Step 6 — Use a Watch Table to Toggle a Memory Bit

Watch tables are non-privileged. They let you change %M bits but not %I bits:

1. Open Watch and force tables → Watch table_1.
2. Add row: %M10.0 with "Modify value" = 1.
3. Click Modify (or Modify with trigger for scan-controlled writes).

This is the technique to test the rest of the logic independently from the input. If toggling %M10.0 drives the downstream actuator correctly, the failing network is logically sound and the original problem lies in the input path. If it still does not work, the failing network has its own bug (operand typo, wrong edge bit, hidden network above clearing a tag).

The Memory-Bit Workaround Explained

The field engineer's fix is to introduce a buffer flag:

// Network 1 - buffer the input
      %I0.4
--+--| |-----------( %M10.0 )--   // "memento" / memory bit

// Network N (failing) - use the flag instead
      %M10.0
--+--| |-----------( %Q0.0 )--   // works reliably

Why this works even when the original symptom persists:

• Decoupling of read timing. %M10.0 is written in the same scan and at the same PII refresh moment as every other input bit. If %I0.4 is being corrupted by an interrupt OB that runs between the PII write and the user-code read of the failing network, the M bit is read after that interrupt completes, so it reflects the corrected value.
• Decoupling of edge consumption. If a previous network uses a rising-edge (P) on %I0.4, the PII bit still shows 1 in the same scan (the edge marker is internal), but the user often mis-reads the edge flag and confuses it with the input state. Buffering removes the edge from the equation.
• Decoupling of group faults. On a 1215C, certain digital-input groups share a common ground. A high-impedance source can let the PII read a residual 0 only on the very first scan after STOP-RUN. A memory bit initialized with the first-cycle flag (%S0.1 via SFL/SFR) eliminates the artefact.

This pattern is also a best practice for signal conditioning: debounce, filter, and capture every field input once at the start of OB1, then use the conditioned flag everywhere else.

Alternative: Read the Periphery Directly

If the issue is proven to be in the PII itself, you can bypass the PII for that single input:

// Ladder - read periphery directly (immediate I/O access)
      %I0.4:P        %M10.0
--+--| |-------------( )--   // direct read at the moment of evaluation

The :P suffix forces the CPU to read the physical input on the same OB1 instruction, eliminating the PII from the equation. Use this only as a diagnostic step; the long-term fix should be a debounce/buffer network as in the previous section.

First-Cycle and Warm-Restart Considerations

On STOP→RUN, the S7-1200 default initializes all bit memories to 0 but leaves the PII at its last value. If your failing network uses %M10.0 directly, it will be 0 on the first scan, even if %I0.4 is already 1. Use a retentive tag, or initialize the flag with the first-cycle bit:

// First-cycle latch of I0.4
      %S0.1     %I0.4        %M10.0
--+--| |------| |-----------(S)--   // set M10.0 on first cycle if I0.4 is high

Mark %M10.0 as retentive in the PLC tag table (column "Retain") so the value survives a power cycle if required by the process.

Diagnostic Checklist

Best-Pattern Reference: Input Conditioning Block

Wrap every field input in a small FC that returns a debounced, buffered flag. The pattern below is reusable across the program and removes the symptom class entirely:

FUNCTION_BLOCK FB_InputCondition
VAR_INPUT
  iRaw       : BOOL;   // physical input %Ix.y
  iFilter_ms : UINT;   // debounce time, e.g. 10
  iFirstScan : BOOL;   // connect to %S0.1 in OB1
END_VAR
VAR_OUTPUT
  qStable    : BOOL;   // debounced flag
  qRising    : BOOL;   // one-cycle rising edge of qStable
END_VAR
VAR
  tStart     : TIME;   // IEC timer start timestamp
  tElapsed   : TIME;
END_VAR
BEGIN
  // Initialise on first scan
  IF iFirstScan THEN
    qStable := iRaw;
    tStart  := T#0ms;
  END_IF;

  // Restart the timer whenever the raw input changes
  IF iRaw <> qStable THEN
    tStart := TIME();  // system time
  END_IF;

  // Commit the new value only after filter has elapsed
  tElapsed := TIME() - tStart;
  IF tElapsed >= INT_TO_TIME(iFilter_ms) THEN
    qRising := iRaw AND NOT qStable;
    qStable := iRaw;
  END_IF;
END_FUNCTION_BLOCK

Call this block in OB1 with iRaw := %I0.4, route qStable to the rest of the program, and the failing network becomes both deterministic and self-documenting.

Verification Procedure

1. Apply the FB or the simple %I0.4 → %M10.0 buffer in a network above the failing one.
2. Replace all subsequent references to %I0.4 in user logic with %M10.0.
3. Compile, download hardware configuration, download software, and place the CPU in RUN.
4. Monitor the failing network online and confirm the bit reads 1 in every scan for 5 minutes.
5. Power-cycle the CPU three times. After each cycle, the bit must read 1 within the first two scans (cold-start, warm-restart, retentive-restart).
6. Disable the buffer momentarily to confirm the original symptom returns; this proves the workaround, not a coincidence.

FAQ