Troubleshooting Pulse Generation Failures on Siemens S7-1200 PLCs

1. Problem Overview

A common engineering scenario on the SIMATIC S7-1200 involves generating two overlapping digital pulse trains to emulate a rotating shaft fitted with two reference sensors. Sensor 1 (S1) and Sensor 2 (S2) must produce short, deterministic pulses where S2 rises roughly halfway through the S1 pulse window, replicating the timing relationship found on a toothed wheel scanned by two offset inductive pickups.

The reported fault signature is consistent and reproducible: S1 pulses appear as expected, but S2 pulses are intermittently dropped. The S2 output occasionally remains low even though the rung logic evaluates to TRUE. This symptom is almost never a wiring defect or a defective transistor output — it is the classic scan-time / pulse-duration collision that every S7-1200 programmer encounters when migrating from relay logic to time-critical pulse generation.

This reference covers the root cause, four engineering solutions ranked from simplest to most deterministic, and a verification procedure you can run on a CPU 1214C or any current S7-1200 firmware (V4.2 through V4.7) in TIA Portal V17 or later.

2. Root Cause: Scan Time vs. Pulse Duration

An S7-1200 CPU does not execute logic continuously — it executes the OB1 (main program) cyclically. The cycle time T_cycle is the sum of:

• Process image update (PI update): up to ~150 µs per byte
• OB1 execution: dependent on code complexity
• Communication overhead (PG/HMI/OPC UA)
• System load (web server, trace, data logging)

For a moderate program, T_cycle typically lands between 1 ms and 10 ms. The reported figure of 1–2 ms places the controller in the upper-performance band, but it is still larger than half of the requested 30 ms S2 pulse width, and more importantly, it can occasionally spike above 15 ms under load.

The hard rule is:

In the failing program, an IEC TP timer (pulse) with PT = 30 ms works for S1 because the rung is TRUE for the entire interval. However, S2 is driven by a contact derived from S1's Q output half-way through the pulse. If the OB1 scan that evaluates this rung occurs at the rising edge of S2 with T_cycle ≈ 2 ms, the timer is started, the next scan 2 ms later sees Q = TRUE, and so does the scan 2 ms after that. The remaining 26 ms should be visible. The drop-out therefore usually points to one of three sub-causes:

1. Scan jitter: HMI tag polling or trace records lengthening T_cycle beyond the timer preset.
2. Process image discrepancy: Direct I/O access (%DB with :P) bypassing PI, combined with PI access — produces one-scan visibility.
3. Overlapping reset: The TP timer's reset input is being asserted by an upstream condition that toggles faster than the timer itself.

3. Prerequisites

• SIMATIC S7-1200 CPU (any variant from CPU 1211C through CPU 1217C with DC/DC/DC or DC/DC/Rly outputs)
• Firmware V4.2 or later (V4.5+ recommended for trace functionality)
• STEP 7 Basic / Professional in TIA Portal V15.1 or later (V17 recommended)
• One digital output module (SB or SM) for clean pulse emission, or use onboard outputs Q0.0 – Q0.7
• An oscilloscope or Siemens LOGO! 8 as a logic probe substitute
• Knowledge of the S7-1200 Programmable Controller System Manual

4. Engineering Solution 1: Activate System Clock Memory Bits

The Siemens S7-1200 provides eight fixed-frequency clock bits as part of the system memory. These are driven by the CPU's hardware timer, not by OB1, and therefore remain phase-locked to the configured frequency regardless of scan jitter. This is the fastest zero-code solution for steady-frequency pulse trains.

1. In the TIA Portal project tree, right-click the CPU and select Properties → System & Clock Memory.
2. Check Enable system clock memory byte.
3. Assign a clock memory byte (e.g., MB100) and confirm.
4. Download the hardware configuration to the CPU.

The activated byte provides the following fixed duty-cycle (50:50) outputs:

Limitations: only eight discrete frequencies are offered, duty cycle is fixed at 50%, and the phase relationship between any two bits is not controllable. Use this approach for periodic indicators, not for the rotating-shaft simulation described in the source case.

5. Engineering Solution 2: IEC Pulse Timer (TP) with Scan-Safe Preset

The IEC 61131-3 TP (pulse) timer generates a pulse of length PT on the rising edge of its IN input. It is more deterministic than the legacy S5 pulse timer because it is handled in a system-level priority class. Refer to the S7-1200 Instructions: Timer Operations reference for full semantics.

Implementation in Structured Text:

// S1 — base pulse train
TP_S1(IN := bStartS1, PT := t#30ms, Q => qS1, ET => etS1);

// S2 — derived from S1 rising edge to simulate offset sensor
IF qS1 AND NOT qS1_old THEN
    iOffsetCounter := 1; // delay 15 ms by counting scans
END_IF;
IF iOffsetCounter >= 8 THEN // 8 × 2 ms ≈ 15 ms
    TP_S2(IN := TRUE, PT := t#30ms, Q => qS2, ET => etS2);
    iOffsetCounter := 0;
ELSE
    iOffsetCounter := iOffsetCounter + 1;
END_IF;
qS1_old := qS1;

Key constraints:

• Always set PT ≥ 3 × T_cycle. With a 2 ms cycle, PT must be ≥ 6 ms. The 30 ms value in the source program already satisfies this — but verify by reading etS2 at the moment of drop-out.
• Use the same scan instance of the timer; never re-instantiate the TP block inside conditional code, as this resets ET.
• If you need an exact phase offset, drive a counter off a hardware timer (see Solution 4) rather than counting OB1 scans.

6. Engineering Solution 3: CTRL_PWM Pulse Generator

For deterministic hardware-timed pulses independent of OB1, the S7-1200 offers the PWM generator accessible via the CTRL_PWM instruction. Each CPU variant provides 2 to 6 PTO/PWM channels on outputs Q0.0 – Q0.5 (CPU-dependent). PWM is generated by the CPU's hardware, so the pulse continues even if OB1 is paused.

PTO/PWM channel availability:

Hardware configuration in TIA Portal:

1. Open Device Configuration for the CPU.
2. Select the onboard output channel (e.g., Q0.0).
3. In Properties → I/O Addresses / PTO/PWM, set Pulse Generator Selection to PWM.
4. Select a time base and the initial period / pulse width.

Runtime control in ladder logic:

// PWM_CTRL block — instance DB IDB_PWM1
CTRL_PWM_1(
    PWM       := "Pulse_1",          // HW identifier
    ENABLE    := bEnableS1,          // start pulse output
    BUSY      => bBusy,
    STATUS    => wStatus
);

// Update duty cycle
CTRL_PWM_2(
    PWM       := "Pulse_2",
    ENABLE    := bEnableS2,
    FREQUENCY := 33.0,                // Hz — adjust per test step
    DUTY      := 50.0,                // percent high
    BUSY      => bBusy2,
    STATUS    => wStatus2
);

For the dual-sensor simulation, run two PWM channels with the same frequency but different phases. PWM hardware does not natively support phase offset on the S7-1200 — phase offset must be achieved by gating one output with a delayed enable signal derived from a hardware counter.

7. Engineering Solution 4: High-Speed Counter (HSC) with Interrupt-Driven Output

When pulse accuracy must be sub-millisecond, route the generation through a high-speed counter with the built-in interrupt output control. The HSC can be clocked from the CPU's internal 30 MHz oscillator, providing a stable reference independent of OB1.

Configuration steps:

1. In the device configuration, enable the HSC channel on the desired input (I0.0 – I0.5 depending on CPU).
2. Set the count mode to Internal — single-phase with counting frequency = 1 kHz or 10 kHz.
3. Attach the CV = RV interrupt (OB 252 / hardware interrupt OB 40) to a fast output set/reset pair.
4. In the hardware-interrupt OB, write %Q0.0 := 1 (direct write, bypass PI) and schedule a delayed reset using a timed interrupt OB.

For the source problem — S1 pulse width 30 ms, S2 rising at +15 ms — a 1 kHz HSC gives 1 ms resolution per count, sufficient to hit the 15 ms offset with one count of error. The HSC interrupt fires inside hardware, so the OB1 scan time no longer affects the rising edge of S2.

Cross-reference the S7-1200 System Manual, Section on High-Speed Counters for the exact HSC input mapping per CPU variant.

8. Frequency-Sweep Generation (Rotating Shaft Acceleration)

The source requirement eventually expands into a frequency sweep that accelerates over time — emulating a spinning-up shaft. The TIA Portal CTRL_PWM instruction accepts a frequency update at runtime, so a linear ramp can be generated as follows:

// r is the current pulse frequency in Hz
IF iStep < 1000 THEN
    r := 1.0 + REAL#0.05 * INT_TO_REAL(iStep);  // 1 Hz → 51 Hz over 1000 steps
    iStep := iStep + 1;
ELSE
    r := 50.0;
END_IF;

CTRL_PWM_2(
    PWM       := "Pulse_2",
    ENABLE    := TRUE,
    FREQUENCY := r,
    DUTY      := 50.0
);

Update the PWM frequency at most every 10 × T_cycle to ensure that each new frequency is committed before the next change. Updating faster than this can cause the PWM engine to drop transitions during the parameter reconfiguration window.

For real-time trace recording of the ramp, open Online → Traces in TIA Portal and capture Q0.0 with a 1 ms sample period.

9. Verification Procedure

Run the following checks before declaring the pulse generator healthy:

1. Cycle time check: In TIA Portal, open Online & Diagnostics → Cycle Time. Record min / max / current OB1 time. Confirm max < PT / 3.
2. Output monitor: Place a watch table on the outputs and on the timer ET values. Confirm the ET of S2 actually reaches PT before Q drops.
3. Logic analyzer: Probe both outputs simultaneously. The S2 rising edge must occur within ±1 ms of the S1 +15 ms mark.
4. Long-duration soak: Run the frequency sweep for at least 5 minutes. Count S2 pulses with an HSC in the CPU; compare against expected count = ∫f(t)dt. A discrepancy > 0.1% indicates scan-time-induced drops.
5. Load stress test: Enable HMI polling at 100 ms, web server, and data logging simultaneously. Re-run the soak. If S2 drops appear only under load, the root cause is OB1 saturation.

10. Troubleshooting Matrix

11. Frequency vs. Cycle-Time Safe Operating Region

The relationship between requested pulse frequency and required minimum cycle time is:

P_min = 1 / f × 0.5 (for 50% duty cycle)

T_{cycle, max} = P_min / 3

For the source requirement (15 ms half-pulse), the absolute maximum sustainable OB1 scan time is 5 ms. If your program exceeds this, you must migrate to hardware-timed pulse generation.

12. Common Pitfalls and Field Notes

• Direct vs. process-image access. Mixing %I0.0 (PI) with %I0.0:P (direct) in the same OB1 produces inconsistent results because the PI is only refreshed at the start of OB1. For pulse-edge logic, commit to one access method per signal.
• Multiple TP instances of the same timer. Each IEC timer (TP, TON, TOF) must have exactly one instance DB. Duplicating the call creates two independent timers and corrupts the ET reading.
• Retriggering TP mid-pulse. The TP timer does not extend its output on re-trigger; the pulse ends at the original expiry. If the application needs retrigger behavior, use a TON with self-latching or migrate to PWM.
• HMI tag polling overload. A WinCC or HMI panel polling 50 tags at 100 ms each can add 5 ms to T_cycle. Reduce polling rate or move tags to on-change update.
• Trace recording impact. Enabling a 1 ms trace adds ~1–2 ms to each scan. Always disable traces after commissioning.
• Firmware mismatch. CTRL_PWM behavior changed subtly between V4.0 and V4.4. Always update to the latest firmware listed in the S7-1200 System Manual release notes.

13. FAQ