Sensor Response Time Benchmarks: How to Measure and Compare Results

Which response-time number should you compare?

Compare the delay from a defined change at the sensing point to a specified transition at the loaded output. Keep target-entry and target-exit measurements separate. A sensor that detects a part quickly may take a different time to return to its original state.

The output LED, the electrical terminal and the PLC program are different observation points. A stopwatch or PLC timestamp may describe machine behavior, but it does not isolate the sensor’s own response. Likewise, switching frequency describes repeated operation under stated conditions; its reciprocal is not automatically a single-edge response time.

For an analog sensor, first agree whether the requirement is time to a stated percentage of the final value, 10–90% rise time, settling time or output update interval. Those are not interchangeable with a switching-output delay.

What do published benchmarks actually tell you?

Compare the configured mode, not the fastest headline

OMRON’s specification for the one-channel E3X-ZV11 fiber amplifier lists these operate/reset times. They are published specifications, not results measured for this article.

Configuration footnotes matter: in HS mode, four-unit interference prevention with Unit Number Priority changes the listed time to 700 µs. Check the selected fiber head’s sensing-distance table as well; the fastest mode is not automatically suitable for the required optical path. OMRON specifications and configuration footnotes.

Check whether a figure is a limit or an observation

The OMRON E3Z-G61 2M provides another useful reading example: its E3Z-G datasheet specifies 1 ms maximum for operate or reset. That wording is different from a mean, a typical value or the largest result seen in one bench run. It is also a different sensing arrangement, not a controlled head-to-head comparison with the fiber amplifier.

Before comparing suppliers, request the exact model, mode, test definition and applicable conditions. If one supplier quotes a typical value and another a maximum, ask for a common comparison basis instead of assigning a winner.

How do you build a meaningful two-channel test?

Use a controlled target or stimulus, a characterized reference and an oscilloscope that records the reference and sensor output together. Keep a dimensioned sketch of the setup. It should show where the event occurs, where each signal is measured and what is connected to the output.

Channel 1: what starts the clock?

For a moving target, a photogate or encoder-derived position can identify a defined crossing. For an optical stimulus, monitor the actual light change with a suitable reference detector. A motor command or emitter-drive signal occurs upstream of the physical event and may include its own delay.

A second sensor is not an instantaneous reference. Characterize its latency, switching location and uncertainty. If those are unknown, report the result as delay relative to that reference, not an absolute sensor response time.

Channel 2: measure the output under the intended load

Connect the specified load or representative PLC input, then measure at a stated point—such as the sensor connector or controller terminal. Record supply voltage, output type, cable length and load. An unloaded open-collector output is not equivalent to the installed circuit.

Use probes and inputs rated for the voltage and circuit conditions; do not connect a 24 V output directly to an unrated logic-analyzer input. Qualified personnel should make connections with power isolated and motion secured. Ground-referenced oscilloscope clips belong only on appropriate ground points. Use a suitably rated differential or isolated measurement arrangement where required; never defeat the instrument’s protective earth.

Before comparing channels, check the relative delay of the probes and channels with a suitable common signal. Record any deskew correction. This checks the instrument path; it does not calibrate the target geometry or reference detector.

How should you capture and repeat the measurement?

1. Freeze the baseline configuration.Record the exact model and firmware if applicable, speed mode, teach settings, filters, timers and interference-prevention settings. Keep power-up stabilization separate from steady-state response testing.
2. Define both physical events and electrical thresholds.Name target entry and target exit, and identify the corresponding output transitions. A 50% amplitude crossing can be a repeatable timing convention, but it is not proof that a PLC has recognized the signal. For interface acceptance, use the input module’s specified signal limits.
3. Resolve the transition and its timing uncertainty.Choose sample interval, bandwidth, record length and probe settings that resolve the claimed delay and edge shape. Inspect raw traces. Extra decimal places on an automatic measurement are not evidence of equivalent accuracy.
4. Trigger from the reference, not only from successful output edges.Otherwise a missing sensor response can disappear from the dataset. Capture both transitions and allow sufficient observation time to identify late or absent outputs.
5. Repeat without selecting only clean events.Save traces, event counts and acquisition settings. Check whether instrument dead time leaves target events unobserved; use a suitable continuous or segmented acquisition strategy and account for gaps. Record missing, extra and ambiguous transitions separately.
6. Vary the conditions the machine will actually encounter.After a stable baseline, test relevant changes in target position, material or optical return, speed, supply, temperature and neighboring sensors. Remain within equipment ratings. Repeat the limiting combinations rather than averaging unlike configurations together.

Report entry and exit distributions separately, with the number of measured events and tested units. Useful summaries include the median, spread and largest observed delay. Keep exclusions visible. A percentile from a small sample is weak evidence, and the largest observed value is not a guaranteed worst case.

Why might the measured delay be misleading?

First check whether the test is measuring a different event, a different electrical crossing or a different configuration. A surprisingly fast or slow number is a reason to inspect the trace and setup before changing the sensor.

Will a fast bench result work on the machine?

There are two separate acceptance questions: will the controller capture every required event, and will the machine act before its deadline? A sensor-only measurement answers neither one by itself.

First, prove that the input can capture the pulse

Measure the shortest valid HIGH and LOW intervals at the controller terminals under the limiting target conditions. Check voltage compatibility, the configured input filter and the acquisition method. A low average event rate can still contain a short pulse that the input never accepts.

Illustrative example: suppose an isolated, electrically valid output pulse lasts 4 ms after a stable LOW state. Siemens documents a 6.4 ms default digital-input filter for the S7-1200: a single pulse shorter than that filter interval is not detected. This failure can occur even when the sensor’s own edge delay is small. Verify the exact CPU and configuration; rapid pulse trains require attention to the documented filter behavior too. Siemens input-filter documentation.

Then, measure the time to the required action

For a reject mechanism, define when the actuator is actually effective—not just when the PLC issues a command. Measure the end-to-end delay where possible. If you build a budget from individual stages, include only non-overlapping intervals and account for controller scheduling and mechanical variation.

Illustrative example: at 0.8 m/s, a target travels 10.4 mm in 13 ms. If the required action point is 40 mm downstream of the detection event, nominal travel time is 50 ms. A 13 ms total delay leaves 37 ms before that point under these assumptions. That arithmetic is not approval: speed variation, timing spread and the actuator’s effective window still need testing.

The target’s length helps determine its detection window; the distance to the action point helps determine the action deadline. Do not compare the entire actuator delay with target dwell time unless the process specifically requires action within that dwell.

What should a useful benchmark report include?

A useful report lets another engineer reconstruct the test and identify what the result does—and does not—cover. Ask for these records rather than an unsupported “fast response” statement.

• Device and settings: exact part number, tested units, firmware where relevant, operating mode, thresholds, filters, timers and configuration file or screenshots.
• Physical setup: target properties, mounting dimensions, sensing gap, travel direction, speed, environmental conditions and the defined entry/exit events.
• Electrical and reference setup: supply, output load, cable, measurement point, reference characterization, probes, thresholds, channel correction and estimated timing uncertainty.
• Results and raw evidence: separate entry/exit summaries, sample and event counts, traces, spread, largest observed delays, missed/extra events, excluded records and acquisition gaps.
• Acceptance boundary: the limit agreed before testing, tested conditions, unresolved differences and any separate PLC-capture or machine-action validation still required.

Approve the claim only to the extent supported. A controlled bench run may support a timing comparison for a particular model and setup. It does not establish performance in untested modes, with a different target or in the completed machine. If the event definition, reference uncertainty or failure count is missing, request that evidence before relying on the number.