“The PLC scans every 10 ms” answers fewer timing questions than people think. When the question is when exactly did it happen, the toolkit is different.
The tools by precision class
Cyclic scan gives event resolution of one cycle — fine for sequence logic, useless for a registration mark at 2 m/s. Hardware interrupt OBs react to configured edges typically in the sub-millisecond class, independent of scan — the tool for capture, reject gates, and length measurement between edges. Time-based IO / input time stamping (with capable modules, e.g. TM Timer DIDQ or stamped ET200 inputs) records when the edge occurred against the module clock with microsecond-class resolution, and can switch outputs at scheduled times — this is the honest answer for sequence-of-events recording and precise actuation, because it removes both scan and interrupt latency from the story.
Clock synchronization is the neglected half: diagnostics across machines only correlate if clocks agree. NTP for the CPU clock against a plant time source is a checkbox that turns “roughly Tuesday” incident timelines into aligned ones; inside Profinet IRT domains, cycle-synchronous timing carries the high end.
Field examples
A cut-length complaint at high line speed traced to edge detection living in OB1 — moved to a hardware interrupt with time stamps, tolerance restored. A two-machine dispute (“who tripped first?”) settled in minutes because both CPUs held NTP-disciplined clocks and their diagnostic buffers aligned.
FAQ
How much latency does a hardware interrupt OB really have? Model-dependent but sub-millisecond class on 1500s — measure on your CPU with a scope if the application is marginal, then add margin.
Do I need IRT for time-stamped inputs? No — stamped I/O works over standard Profinet; IRT is for isochronous control, a stricter problem.
Zone Otomasyon designs measurement chains where timing claims are measured, not assumed. Precision problems welcome.