S7-1200 HSC Encoder Counting Failures: Input Filter and OB40 Fix

Problem Summary

An S7-1200 CPU is configured for High-Speed Counter (HSC) 1 with an A/B quadrature rotary encoder rated at 500 pulses per revolution (PPR). When the encoder is turned slowly by hand, the HSC count updates reliably on the engineering software and on the HMI. As soon as the operator increases the rotation speed — still well below the published 100 kHz / 200 kHz on-board input limit of the CPU — the HSC stops incrementing, the count freezes, or the comparator that should reset the counter never fires. A second symptom appears with an internal [==] comparator that should reset the HSC at a target value: the comparator never closes at high frequency, even after the OB1 cycle time was reduced to 30 ms.

The combined fault is a classic S7-1200 HSC configuration error caused by three independent root causes, not by a single bad setting:

1. The on-board digital input filter is left at the default 6.4 ms setting, which blocks most quadrature pulses above ~150 Hz before they ever reach the HSC hardware.
2. The user code compares the HSC current value (CV) to a constant with an [==] equality test inside OB1. The HSC changes faster than the scan, so the CV never equals the target value at the exact instant the comparison executes.
3. No hardware interrupt (OB40) is attached to the HSC event "CV = RV", so the application has no deterministic, scan-independent way to react to the HSC event.

Root Cause Analysis

Each of the three failure modes is independent and is discussed separately below so the engineer can isolate which one applies to the machine.

1. On-board input filter bandwidth

Every S7-1200 digital input has a configurable hardware filter that suppresses contact bounce and electrical noise. The filter is applied before the HSC hardware sees the edge, so a slow filter silently deletes the pulses that the encoder is generating. The default filter value is 6.4 ms, which corresponds to a maximum input frequency of:

f_max = 1 / (2 × filter_time) = 1 / (2 × 6.4 ms) ≈ 78 Hz

With A/B quadrature and x4 evaluation, the effective count rate is 4 × the input frequency. A 500 PPR encoder spinning at 60 RPM produces:

f_in = (500 × 60) / 60 = 500 Hz (per channel)
f_count = 500 × 4 = 2000 increments/s

Because 500 Hz per channel is already more than 78 Hz, the default filter blanks the signal and the HSC never advances. The first remediation step is therefore to change the filter of the HSC input pins to the lowest available value (typically 0.8 µs, 3.2 µs, or 0.1 ms depending on CPU firmware) inside the device configuration.

2. The HSC value compared with [==] inside OB1

The HSC hardware updates the current value (CV) in the background, on every valid edge. The application program in OB1 only samples the value once per scan. A standard [==] equality test against a constant target value (RV) will therefore only fire if the CV happens to equal the RV at the moment OB1 reads it. For a fast-changing count the probability of that coincidence approaches zero. Siemens explicitly recommends using the "CV = RV" hardware event of the HSC and assigning a hardware interrupt OB to it. The hardware event is edge-accurate: it triggers on the very cycle that drives CV to RV, regardless of the OB1 scan period.

3. No hardware interrupt OB bound to the HSC

If no OB40 (or OB40..OB47 on a CPU that supports multiple hardware interrupts) is bound to the HSC event "CV = RV" or "direction changed", the application can only poll the HSC inside OB1. The result is the missed-comparison symptom reported by the operator. The fix is to create an OB40 in the project, attach it to the HSC in the device configuration, and execute the response action inside OB40 instead of OB1.

Applicable S7-1200 CPUs and HSC Channels

The 100 kHz / 200 kHz figure differs by CPU. Always consult the system manual for the exact machine you have installed.

Source: S7-1200 Programmable Controller System Manual, 06/2023 and the S7-1200 Programmable Controller Technical Specifications page on the Siemens Industry Online Support portal.

Hardware Configuration in TIA Portal

The fix for the input-filter symptom is purely a device-configuration change. Open the project, select the S7-1200 CPU in the project tree, and switch to the "Properties" inspector.

1. Open Device configuration → CPU → Digital inputs.
2. Locate the channel used by HSC1. The default HSC1 assignment on CPU 1214C/1215C/1217C is Ia.0 (pulse), Ia.1 (direction), Ia.2 (home).
3. Set the Input filter of the pulse channel to the smallest value that still rejects the electrical noise expected on the machine. The typical sequence is: 6.4 ms (default) → 0.8 ms → 0.1 ms → 3.2 µs. Stop at the first value that gives reliable counting without spurious counts from EMI.
4. Repeat the filter adjustment for the direction and home channels so that all HSC channels use the same filter setting.
5. Compile and download the hardware configuration to the CPU.

HSC Operating Mode and Wiring for A/B Quadrature

HSC1 must be configured for "two-phase" operation, the Siemens term for A/B quadrature. The four possible counting modes for HSC1 on a CPU 1214C/1215C/1217C are summarised below.

For a 500 PPR A/B encoder, x4 evaluation produces 2000 increments per shaft revolution. Maximum recommended shaft speed for the 100 kHz A/B pin on a CPU 1214C is:

n_max = 100 000 edges/s / (4 × 500 PPR) = 50 rev/s = 3000 RPM

If the application rotates the encoder faster than 3000 RPM, x4 evaluation is the first thing to relax — drop to x2 or x1, or change the encoder for one with lower PPR.

Wiring must follow the shielded, twisted-pair rules in the S7-1200 System Manual, section "Wiring guidelines". Encoder cable shield is bonded to the encoder body and to the CPU ground terminal, not to any other metalwork.

Removing the [==] Comparator Miss with a Hardware Interrupt

The second symptom — "comparator doesn't react at high frequency" — is fixed by replacing the OB1 [==] test with a hardware interrupt that fires on the HSC event "CV = RV". The procedure in TIA Portal V13 (or newer) is as follows.

1. Right-click the CPU in the project tree and choose Properties → High-speed counters (HSC1).
2. Enable Counting mode: Two-phase and set the count direction behaviour.
3. Tick Enable hardware interrupt on CV = RV.
4. Choose the input filter values that you selected in the previous section.
5. Click Add new OB in the "Hardware interrupt" section. TIA Portal will create OB40 and bind it to the HSC event automatically.
6. Move the reset logic out of OB1 and into OB40. The body of OB40 should contain the actions that must happen deterministically when the count reaches the target: reset the HSC, set a marker, drive a fast output, or start a motion sequence.
7. If a normal program still needs to react, use a flag set inside OB40 and read in OB1; do not re-test the HSC value with [==] in OB1.

The HSC_CTRL Instruction

The application typically still needs to change the reference value (RV), the current value (CV), the counting direction, and the synchronisation behaviour at runtime. The standard tool is the CTRL_HSC instruction, which is automatically added to the project when an HSC is enabled.

The HSC is updated in the background by the CPU hardware. The program can read the live count from the process image (ID1000 in the legacy S7-200 example) or from the symbolic tag that TIA Portal generates (e.g. "HSC_1".CountValue or ID1000 in the I/O addresses). The process image value is the count at the start of the current OB1 scan. The hardware-internal value at the moment OB40 fires is read from the input word of the HSC (IW); this is the value to use inside the hardware interrupt OB.

If the program needs the latest possible value in OB1, use the immediate read instructions (e.g. PEEK on a 1500, or READ_DI on a 1200 with firmware 4.2+). Reading the process image alone is acceptable for slow-changing HMI displays but is not acceptable for real-time control.

How the Program Compares to a Reference Value

Three approaches are used in real S7-1200 applications, in order of preference.

The code in the original report used the third approach, which is the root cause of the missed comparator. A robust pattern is:

// OB1 — slow path: update RV and CV only when the operator changes them
IF "HMI.RV_Changed" THEN
   "HSC_1".NEW_RV := TRUE;     // edge on NEW_RV latches the new RV
   "HSC_1".RV := "HMI".RV_New;
   "HMI.RV_Changed" := FALSE;
END_IF;

IF "HMI.CV_Reset" THEN
   "HSC_1".NEW_CV := TRUE;     // edge on NEW_CV latches the new CV
   "HSC_1".CV    := 0;
   "HMI.CV_Reset" := FALSE;
END_IF;

// OB40 — fast path: deterministic reaction to CV = RV
IF "HSC_1".Status_HW = 16#0001 THEN   // event flag for CV = RV
   // reset the count, fire the gate, latch the index
   "HSC_1".NEW_CV := TRUE;
   "HSC_1".CV    := 0;
   "Process.Gate_Fire" := TRUE;
   "Process.Index_Mark" := TRUE;
END_IF;

The NEW_CV, NEW_RV, NEW_DIR, and NEW_PERIOD signals are edge-triggered. A rising edge on any of them tells the HSC to load the new value on the next counting cycle. Forgetting this edge is one of the most common S7-1200 HSC support cases — the value is updated in the tag list but the HSC never sees the change because the trigger edge is missing.

Physical Response Time Constraints

Even with a perfectly configured HSC and a perfectly timed hardware interrupt, the physical output chain introduces latency that the application must budget for. The original field report described a typical example: an object on a conveyor, a sensor 5 m before a pneumatic gate, and a 30 ms pneumatic valve plus 80 ms air/cylinder stroke. The total physical delay chain is:

1. Sensor or HSC event detection — typically 1 µs to 1 ms.
2. OB40 entry latency — typically 50 µs to 1 ms, depending on CPU load.
3. Program execution in OB40 — keep the OB small (< 100 µs for HSC + latch).
4. Output update from OB40 — the S7-1200 updates the process image output on the next system clock tick; the digital output is then physically driven after a few µs.
5. External actuator response — valve, pneumatic, hydraulic, motor, etc. This is usually the dominant delay.

For the conveyor example with the 5 m gap and a 30 ms valve + 80 ms cylinder stroke, the system has 110 ms to fire the gate after the HSC event. The HSC and the PLC contribute less than 2 ms of that 110 ms. The remainder is physics: it cannot be reduced by faster HSC, faster CPU firmware, or faster OB40. If the application needs a smaller actuator delay, the sensor must be moved closer to the gate, or the actuator must be replaced with a faster one (electric, servo, etc.).

Verification and Commissioning Procedure

1. Open the watch table for the HSC tag. Confirm that Status is 0 (no error) and that Status_HW reflects the expected event flags.
2. With the encoder disconnected, monitor the HSC count in online mode. It must remain constant at the value last loaded. If the count drifts without the encoder moving, the filter is too short, the wiring picks up noise, or the encoder cable shield is not properly grounded.
3. Turn the encoder by hand at 60 RPM. Confirm the count increments by 2000 per revolution with x4 evaluation, 1000 per revolution with x2, and 500 with x1.
4. Drive the encoder with a small motor at the application's nominal speed. Confirm the count remains accurate over at least 100 revolutions. Compare the count with an external reference (hand tally, second HSC, or stroboscope).
5. Force a CV = RV event by setting RV to the current CV. OB40 must fire once. If OB40 does not fire, check that the OB is bound to the HSC in the device configuration and that the event is enabled.
6. For an event-driven output, drive a fast digital output from inside OB40 and confirm with an oscilloscope that the latency from the HSC event to the output edge is < 1 ms.
7. Long-duration stability test: run the application for 1 hour at nominal speed, log the count, and confirm zero drift.

Troubleshooting Matrix

Common STATUS Word Codes

The STATUS output of CTRL_HSC follows the error codes listed in the S7-1200 System Manual, appendix "STATUS word for CTRL_HSC". The most common codes in HSC support cases are:

Edge-Case Notes and Field-Proven Caveats

• On CPU 1211C and CPU 1212C, HSC1..HSC6 share the on-board inputs. Enabling a high-speed counter on one channel may re-assign the digital input addresses that user code expects. Always re-check the address assignment in the device configuration after enabling an HSC.
• Adding a Signal Board (SB) gives four additional high-speed inputs at 200 kHz. The SB inputs are HSC7..HSC10 and are independent of the on-board HSCs. If the application needs to count two encoders at the same time and the on-board HSC6 is already used, the SB is the only path.
• CPU firmware 4.2 introduced 200 kHz on-board inputs for CPU 1211C DC/DC/DC and CPU 1212C DC/DC/DC. Older firmware is capped at 100 kHz. The HSC behaviour is unchanged, but the ceiling is different.
• Counting in "Frequency" mode rather than "Count" mode is selected by accident in many first-time projects. Frequency mode resets the count on every measurement period and never retains a value to compare against RV; the CV in frequency mode is the measured frequency in Hz, not a position.
• If the encoder is differential (RS-422), connect the A, /A, B, /B pairs to the differential-capable inputs of the CPU. The S7-1200 on-board inputs Ia.0..Ia.5 are single-ended by default; differential input requires the SB 1221 DI 4×5 V DC differential or a third-party converter.
• The HSC input channel allocation is shown in the "Input filter" table inside the device configuration. The table in the S7-1200 System Manual reflects the CPU's hardware revision. If the input filter dropdown does not list 0.8 µs or 3.2 µs, the CPU is the older hardware revision that supports only the 0.1 ms minimum filter.

FAQ