Case study
PLC Scan Time Missed Pulse Case Study
Automation and control engineering case study on diagnosing PLC missed pulses from scan time, input filtering, sensor pulse width, asynchronous sampling, high-speed counters, reject timing, and validation evidence.
A programmable controller can miss a real event even when the sensor, wiring, and actuator are healthy. The usual cause is not mysterious software behaviour. It is a timing mismatch: a short input pulse appears and disappears between cyclic scans, or it is weakened by input filtering before the main logic ever sees it.
This case study follows a conveyor reject station that intermittently fails to eject defective cartons. Operators first suspect the pneumatic reject cylinder. Maintenance checks the valve, air pressure, and sensor alignment. The engineering evidence shows that the controlling fault is a PLC input-capture problem: the defect mark creates a pulse shorter than the worst-case scan interval, and the digital-input filter leaves too little visible pulse width for reliable detection.
The purpose is to show how an automation engineer connects sensor pulse width, scan time, input filtering, asynchronous sampling, reject timing, high-speed counter selection, and validation evidence before releasing a corrected machine.
Case Context
The machine is a packaging line with a conveyor, photoelectric defect-mark sensor, PLC, reject solenoid, and pneumatic pusher. A camera upstream prints or flags defective cartons. A small black mark on the carton edge passes the photoelectric sensor. When the mark is detected, the PLC schedules the reject pusher after the carton travels from the sensor to the reject gate.
The failure is intermittent. Some marked cartons are rejected correctly, while others pass through. Event logs show no PLC fault, no air-pressure alarm, and no solenoid diagnostic alarm.
| Item | Value or observation |
|---|---|
| Conveyor speed during fault | 1.40\ \text{m/s} |
| Defect mark length along travel | 15\ \text{mm} |
| Nominal PLC cyclic task period | 18\ \text{ms} |
| Worst observed task interval | 22\ \text{ms} |
| Digital input filter setting | 8\ \text{ms} |
| Sensor-to-reject distance | 0.95\ \text{m} |
| PLC output and solenoid latency | 25\ \text{ms} |
| Pneumatic pusher motion time to carton edge | 85\ \text{ms} |
| Reject gate useful position tolerance | \pm 12\ \text{mm} |
| Observed missed reject rate | approximately 70\% to 85\% of marked cartons |
The numbers are simplified for teaching. A real machine validation would use measured pulse traces, controller task diagnostics, input-module specifications, sensor response time, pneumatic timing at pressure extremes, product spacing, line-speed envelope, and the site safety requirements.
Why the Fault Is Plausibly a Capture Problem
The first useful distinction is between a real-world event and an event visible to the PLC task.
The sensor can produce a clean electrical pulse. The input module can receive that pulse. The main PLC program can still miss it if the pulse is not latched, stretched, or sampled while it is true. Cyclic logic usually reads an input image at task boundaries. If an input turns on and off between two task reads, the logic may never execute with that input true.
This failure mode is different from:
- a closed-loop tuning problem, where a process variable responds poorly to a controller command;
- a valve or cylinder fault, where the output command is correct but the actuator does not move;
- a safety interlock bypass problem, where a protection function is deliberately unavailable;
- a communication deadline miss, where a message arrives late over a bus.
Here the physical event exists, but the cyclic control task does not reliably observe it.
Sensor Pulse Width
The raw pulse width comes from the time required for the defect mark to pass through the sensor beam. With mark length L_m and conveyor speed v:
Using the measured values:
The raw sensor pulse is therefore about 10.7\ \text{ms} wide. That is shorter than the nominal scan period of 18\ \text{ms} and much shorter than the worst observed task interval of 22\ \text{ms}.
This alone is enough to make cyclic detection unreliable unless the input module or logic latches the event.
Scan-Time Capture Screen
For a simplified asynchronous pulse that is not latched and not stretched, the probability that at least one cyclic read occurs while the pulse is true is approximately:
where:
- t_{visible} is the time for which the PLC task can see the input as true;
- T_{scan} is the scan interval;
- the pulse phase relative to the scan is assumed approximately random.
If the raw sensor pulse were visible for its full width and the nominal scan period applied:
Only about 59\% of pulses would be expected to be captured by the cyclic task. At the worst observed scan interval:
Even without input filtering, the design would be marginal to failing. A reject station should not depend on a near-random phase relationship between a short mark and a cyclic scan.
Input-Filter Effect
The input filter is intended to reject electrical noise, contact bounce, and very short false pulses. It is useful for mechanical switches. It can be harmful when a real high-speed event is only slightly longer than the filter threshold.
Assume the input module does not present a true state to the PLC image until the input has remained high for the configured filter time. For a short pulse, a conservative visible-width screen is:
where negative values mean the pulse is rejected or too marginal to rely on.
With:
the visible interval is approximately:
Using the nominal scan period:
At the worst observed scan interval:
This is consistent with the reported miss rate. The exact percentage depends on the module implementation, task phasing, product speed variation, mark contrast, and sensor response time. The engineering conclusion does not depend on the exact probability: the available pulse width is not compatible with cyclic input polling.
Minimum Pulse-Stretch Requirement
If the machine used ordinary cyclic logic, the event should be visible for longer than the worst-case scan interval plus margin. A simple requirement is:
Use:
and choose:
Then:
The raw pulse is only 10.7\ \text{ms}. The filtered visible pulse is much smaller. Therefore, relying on ordinary cyclic logic is not acceptable. The design needs one of the following:
- a hardware high-speed counter or event-capture input;
- an input module with pulse-latching configured and verified;
- a sensor or interface that stretches the pulse beyond the worst-case scan interval;
- a faster deterministic task whose worst-case interval is shorter than the minimum real pulse width by a validated margin.
The preferred correction here is a high-speed counter or latched interrupt input because it preserves timing evidence and avoids hiding a design error with an arbitrary software timer.
Reject Timing Calculation
After detection, the carton must be rejected at the correct physical location. The travel time from sensor to reject gate is:
where:
and:
Therefore:
The output and solenoid latency is 25\ \text{ms}, and the pusher needs 85\ \text{ms} to reach the carton edge. The command should therefore be scheduled:
The reject command should be issued about 569\ \text{ms} after the captured mark event, assuming constant speed. If conveyor speed varies, the design should use an encoder-based distance counter rather than a fixed time delay.
Position Error from Scan Timestamping
Even when the cyclic task occasionally detects the pulse, the timestamp can be poor. If the event is timestamped only when the scan reads the input, timing uncertainty may approach one scan interval.
A conservative distance error screen is:
Using worst-case scan timing:
The reject gate useful tolerance is only:
So scan-based detection is not only unreliable; when it does detect the mark, the timing uncertainty can be too large for precise rejection.
If a high-speed counter or event-capture input timestamps the edge with 1\ \text{ms} resolution:
That is compatible with the reject tolerance, provided sensor placement, product slip, actuator repeatability, and conveyor speed measurement are also controlled.
High-Speed Counter Capacity Check
The corrected design routes the photoelectric mark sensor to a high-speed counter or event-capture input. The main PLC task reads an accumulated count and event timestamp. It no longer needs to see the input true during the scan.
First check the event rate. With minimum product pitch p=0.28\ \text{m} at the same conveyor speed:
The product mark event rate is only 5\ \text{Hz}. A high-speed input rated for 5\ \text{kHz} has enormous margin for this signal.
If the reject timing is converted to an encoder-distance basis, check the encoder edge rate. Suppose a measuring wheel has diameter D=80\ \text{mm} and the quadrature encoder has 1024 pulses per revolution. With four-edge decoding:
where:
Then:
For a counter rated at 100\ \text{kHz}:
That is acceptable as a first screen. The final design should still check input voltage levels, differential signalling, cable shielding, debounce/filter settings, interrupt load, counter rollover, reset behaviour, and diagnostics for impossible speed or count jumps.
Corrective Action
The engineering correction is not simply “make the PLC scan faster.” Faster scanning may reduce the miss rate, but it still leaves reliability dependent on workload, future program edits, communications, and asynchronous phase.
The corrective package is:
- Route the defect-mark sensor to a high-speed event-capture input.
- Disable the slow noise filter for that input or replace it with a filter setting validated against the shortest real pulse.
- Use shielded wiring, correct sensor thresholding, and an input module rated for the expected pulse width.
- Latch each rising edge with a count and timestamp.
- Have the main cyclic task consume captured events from a small queue, not from the raw input bit.
- Schedule reject actuation from event time or encoder distance.
- Alarm on queue overflow, impossible event spacing, missing heartbeat from the capture module, and speed outside the validated range.
- Document maximum line speed, minimum mark length, minimum product pitch, filter setting, task timing, and validation evidence.
This separates event capture from ordinary control sequencing. The cyclic task can still coordinate machine state, HMI, recipes, alarms, and output commands, but it no longer has to sample a short physical event directly.
Validation Test
A useful validation package must prove both detection and timing.
Pulse Measurement
Measure the sensor signal with an oscilloscope or validated high-speed logger at minimum and maximum line speeds.
At the worst expected speed, verify:
where t_{input,min} is the minimum pulse width required by the event-capture input after the selected filter setting.
For the measured case:
If the event-capture input requires only 0.1\ \text{ms}, the pulse-width margin is:
That is a strong margin, assuming the sensor waveform has clean edges and adequate voltage levels.
Count Agreement Test
Run a controlled trial with N=10{,}000 marked cartons. Compare three independent counts:
- camera or upstream mark-creation count;
- high-speed input captured-event count;
- downstream reject verification count.
Acceptance criteria:
If zero missed captures are observed in 10{,}000 trials, a common rough upper bound for the miss probability at about 95\% confidence is:
This does not prove zero risk. It gives a quantitative release screen and should be combined with speed, vibration, contamination, lighting, product-spacing, and fault-injection tests.
Timing Acceptance
Record event timestamp, scheduled reject command, solenoid output, pusher arrival, and downstream reject verification. The measured pusher contact timing should remain inside the reject window over the speed range.
For the case data:
If timestamp uncertainty is 1\ \text{ms} and speed uncertainty produces another 3\ \text{ms} equivalent timing uncertainty, the distance uncertainty is:
This is below the \pm 12\ \text{mm} reject tolerance. Remaining margin must cover pusher repeatability, product slip, sensor location error, and mechanical wear.
Engineering Decision
The original cyclic-input design should not be returned to production at the current line speed. The evidence shows three independent problems:
- the physical pulse is shorter than the worst-case PLC scan interval;
- the input filter reduces the effective visible pulse width;
- scan-based timestamping can exceed the reject-position tolerance even when a pulse is captured.
The corrected design can be released only after the high-speed event-capture path, filter setting, reject timing, count agreement, queue diagnostics, and downstream reject verification pass under the validated speed envelope.
The main lesson is that a PLC scan is not a universal event detector. Cyclic logic is reliable for states that persist long enough to be sampled. Short pulses, encoder edges, fast interlocks, registration marks, and motion events need hardware capture, latching, pulse stretching, or a formally bounded fast task with validation evidence.