Sensor Switching Frequency: Why High-Speed Machines Miss Signals

What does sensor switching frequency actually tell you?

Switching frequency describes repeated detection cycles per second under stated test conditions. A cycle includes detection and reset. A 1,000 Hz rating is not a promise that every target shape, output mode and PLC input will deliver 1,000 usable counts per second.

Check whether the published number is a guaranteed limit, a typical result or an average measurement. For example, OMRON’s E2E DC two-wire specification footnote identifies its response-frequency value as an average under a defined standard-target test at half the sensing distance. That footnote matters when comparing the catalog with a small, irregular production target.

Read frequency and response time together

Frequency answers “How often can detection repeat?” Response time answers “How long after a target change does the output change?” ON and OFF delays can differ. Neither the internal oscillator frequency nor an IO-Link communication cycle is automatically the sensor’s switching-frequency rating.

Do not turn a single response-time value into a frequency limit by taking its reciprocal unless the manufacturer defines that relationship. The response time vs switching frequency guide explains that distinction in more detail; here the task is to find where a production pulse is lost.

How short are the target and gap at full speed?

Calculate three quantities: event rate, target-present time and target-absent time. The same event rate can contain either broad, easy-to-observe states or very narrow pulses. The reset gap is as important as the target.

Use the effective detectable length along the direction of travel—not automatically the full part length. Beam size, sensing distance, target material, approach direction and geometry can change where detection starts and ends.

For a rotating target, count features—not only revolutions

With one detection cycle per tooth or slot, event rate in hertz equals RPM × features per revolution ÷ 60. At 3,000 RPM and 24 features, the rate is 1,200 Hz. That exceeds a hypothetical 1,000 Hz rating before any PLC limitation is considered. Unequal tooth and gap widths still require separate dwell checks; include runout and the actual sensing position.

Why can the sensor switch while the PLC misses the pulse?

A pulse must survive the electrical interface, any input filtering, and the controller’s acquisition method. A flashing sensor LED only tells you something about that device’s indicated state; it does not prove that a valid pulse reached the PLC terminal or was recorded by the program.

The input filter may reject the event

A stable-state digital filter can discard a pulse that is shorter than its qualification time. Beckhoff’s input-filter documentation illustrates both short HIGH pulses and short LOW pulses being rejected. Accepted edges are delayed. This is different from assuming that every input pulse simply appears a little later.

For a filter with that documented behavior, a 4 ms HIGH pulse cannot pass a 10 ms qualification requirement. Changing to a 3 ms setting may remove that particular rejection condition, but does not prove counting reliability. Check both polarities, electrical thresholds, timing tolerances and noise before changing the setting.

A valid pulse can fall between observations

Even after the input accepts a pulse, ordinary cyclic logic may never see its active state. Consider an idealized 4 ms HIGH / 6 ms LOW signal, already available for sampling, with observations exactly every 5 ms. At the phase shown below, every observation reads LOW.

That is why “the PLC scans twice per product cycle” is not a sufficient counting rule. Software edge counting must observe an active state and a reset state. Check the maximum interval between fresh observations at the counting logic, including input updates, remote I/O transfer and task scheduling—not only the typical program execution time.

Response delay does not automatically subtract from pulse width

For a simple active-HIGH output with fixed propagation delays and no pulse suppression, its rising edge occurs after the ON delay and its falling edge after the OFF delay. The resulting width is target time + OFF delay − ON delay. Equal 0.5 ms delays would shift an assumed 4 ms pulse without shortening it.

This is an illustrative edge-timing relationship, not a short-pulse guarantee. Separate maximum delay specifications do not establish fixed delays, a guaranteed minimum pulse width or the minimum detectable target time. Output inversion, timers and filtering can change the behavior. Use the model’s timing chart and actual terminal waveform.

Which capture method fits the job?

Choose by what must be preserved: a state, an event, every count, or an event’s time or position. These are different requirements. Faster cyclic logic, a latch and a high-speed counter are not interchangeable remedies.

Pulse catch is not a substitute for counting every event

Siemens’ S7-1200 pulse-catch description places capture after the input filter and says that, with multiple pulses in one scan, only the first is read. A latch therefore cannot restore an already filtered-out pulse, and it is not an unlimited event buffer. Its HSC function instead provides counting independently of cyclic counter instructions, once correctly configured.

Pulse extension has a similar boundary: it can make a short accepted event easier to observe, but may hide subsequent events or remove the reset gap. Beckhoff’s documented implementation filters first and extends second. Confirm the sequence before using extension as a fix.

A correct count is not necessarily a correctly timed action

For constant speed, travel during a delay equals speed × delay. In an illustrative case, 3 m/s × 1.5 ms is 4.5 mm of travel. A repeatable offset and changing event-to-event delay are different problems; speed changes also affect a time-based correction.

Timestamping helps identify when an edge occurred, but storage can still be limited. Beckhoff’s EL1252 documentation describes first/last-event selection within a fieldbus interrogation cycle. “Timestamp input” therefore does not, by itself, promise a record of every edge. Verify capture capacity before choosing it for a dense pulse train.

How do you find where the signal is being lost?

Compare evidence at successive points in the signal path. Start with the symptom—missed count, extra count, merged parts or late actuation—then look for the first point where the expected event disappears or changes.

1. Check the sensing event at the failing condition. Record speed, smallest target and gap, material, distance, alignment and active mode. If the sensor does not reliably resolve the target or reset, investigate geometry, sensing margin, teach settings and interference before blaming the PLC.
2. Measure the signal at the PLC terminal. Use a suitable oscilloscope or acquisition system to record HIGH/LOW duration, voltage levels, transitions and extra edges. Compare with the sensor output when necessary. A meter average or LED cannot establish the shortest pulse width. Do not attach an earth-referenced probe ground to an unverified circuit node.
3. Compare the terminal waveform with input acquisition. If the terminal signal is valid but the input path loses it, inspect receiver thresholds, channel filtering and capture configuration. A slowly refreshed watch table is not a reliable record of brief input states.
4. Compare acquired events with the application count. If hardware acquisition agrees with an independent reference but the application count does not, inspect edge logic, reset ownership, read consistency, overflow and restart behavior. If counts agree but the reject is late, investigate timing and motion rather than sensor frequency alone.

What should a full-speed trial confirm?

The trial should confirm both correct event capture and the required machine action over the agreed operating conditions. A successful bench pulse, a green LED or a higher catalog number is not enough.

• Freeze the configuration: exact sensor/order code, response mode, output logic, timers, input module/channel, filter, capture mode and relevant firmware or program revision.
• Exercise the shortest windows: maximum specified speed, smallest target and gap, relevant material variants, runout, starts/stops and the contamination or alignment limits expected in service.
• Record the evidence: terminal pulse widths and levels, missing/extra events against an independent reference, and any position or action-time error that matters.
• Agree acceptance before running: tested conditions, run length, allowable errors and restart/recovery checks. A test with no observed misses supports those tested conditions; it is not proof of unrestricted reliability.

If a supplier review is needed, send these timing windows and the controller configuration alongside the target details. Asking only for “a 1 kHz sensor” leaves the receiving path unresolved.

The practical rule: qualify the complete path from target to recorded event. Increase sensor speed when sensing is the limitation; change acquisition when a valid pulse is being lost downstream.