NTP vs PTP for Machine Vision Time and Traceability
Choose clock synchronisation from the required event alignment, traceability, network hardware, timestamp location, and failure behaviour.
A PLC event and camera frame both show 10:14:32, yet the image appears 18 ms after the part passes the sensor. Wall-clock timestamps identify the production window but cannot prove which frame belongs to a fast event. NTP and PTP solve different timing problems, and neither fixes a timestamp taken at the wrong layer.
This is a vendor-neutral engineering method. The worked example is hypothetical and must be replaced by measurements from the real product, line, and risk assessment.
What you will learn
Identify the physical, optical, data, or process limit behind ntp versus ptp.
Convert the inspection need into measurable acceptance criteria.
Compare practical architectures and their trade-offs.
Commission the method using repeatable evidence.
Validate the final system under representative production variation.
Technical foundation
Clock synchronisation and trigger synchronisation differ
Synchronized clocks provide a common time base. They do not make exposures simultaneous unless devices schedule or receive triggers accordingly. Hardware triggers can align events while clocks remain different; many systems use both.
NTP and PTP target different regimes
NTPv4 is broadly used for system-clock synchronisation and can reach tens of microseconds on suitable fast LAN workstations according to RFC 5905. IEEE 1588 PTP supports precise networked clocks and hardware timestamping, profiles, and network clock roles. Actual performance is architecture dependent.
Timestamp location defines meaning
A host receipt timestamp includes transport and queue delay. A camera exposure-start or sensor timestamp is closer to the physical event. Every timestamp must identify clock, event point, units, epoch, uncertainty or status, and synchronisation state.
Related guides on this publication: Machine Vision Traceability: Images, Results, Recipes, and MES and GigE vs USB3 vs CoaXPress: Camera Interface Guide and Machine Vision PLC Integration: A Robust Handshake.
Engineering workflow
1. Define the timing use case
Evaluate: audit wall time, frame-to-part association, stereo simultaneity, line-scan encoder relation, robot fusion, sequence ordering, and required error.
Why it matters: protocol choice follows the maximum permissible time error.
Measure or calculate: convert spatial or process tolerance into a time budget. Preserve settings, sample identity, operating state, and the calculation method so alternatives remain comparable.
Trade-off: tight timing improves association but raises hardware and validation cost. Common failure: choosing PTP because it sounds precise without a requirement.
2. Map clocks and timestamp points
Evaluate: camera sensor, camera clock, NIC, host OS, PLC, robot, database, MES, and UTC source.
Why it matters: several timestamps for one frame can differ legitimately.
Measure or calculate: draw the event path and name where each timestamp is generated. Preserve settings, sample identity, operating state, and the calculation method so alternatives remain comparable.
Trade-off: sensor-proximate hardware timestamps are meaningful but not always exposed. Common failure: comparing host arrival with PLC event time as if both mark exposure.
3. Choose architecture and protocol
Evaluate: NTP servers, PTP grandmaster, ordinary/boundary/transparent clocks, hardware timestamping, domain, profile, VLAN, and hardware trigger.
Why it matters: PTP performance depends on every relevant path and profile.
Measure or calculate: verify feature support and interoperability on actual devices. Preserve settings, sample identity, operating state, and the calculation method so alternatives remain comparable.
Trade-off: hardware PTP improves precision but increases component constraints. Common failure: mixing incompatible PTP profiles or domains.
4. Budget error and asymmetry
Evaluate: clock offset, timestamp resolution, network residence, path asymmetry, servo behaviour, trigger delay, exposure timing, drift, and holdover.
Why it matters: small clock offset does not remove fixed event-path delay.
Measure or calculate: measure offset and end-to-end event error independently. Preserve settings, sample identity, operating state, and the calculation method so alternatives remain comparable.
Trade-off: calibrating fixed delay improves accuracy but requires configuration control. Common failure: using protocol status as proof of physical event alignment.
5. Design status and failover
Evaluate: clock class, source identity, synchronised flag, offset threshold, grandmaster change, holdover, NTP stratum, leap handling, and invalid time.
Why it matters: timestamps may continue while the clock is unsynchronised.
Measure or calculate: alarm and annotate records during source loss or excessive offset. Preserve settings, sample identity, operating state, and the calculation method so alternatives remain comparable.
Trade-off: holdover preserves operation but uncertainty grows with oscillator drift. Common failure: accepting all timestamps after silent grandmaster loss.
6. Validate across load and faults
Evaluate: network traffic, switch roles, temperature, restart, cable change, asymmetry, clock failover, and long duration.
Why it matters: lab idle-network performance may not survive production.
Measure or calculate: compare devices against a common physical event and log offset percentiles. Preserve settings, sample identity, operating state, and the calculation method so alternatives remain comparable.
Trade-off: external timing instrumentation adds cost but proves the real chain. Common failure: checking only reported PTP offset on one camera.
Worked example
Hypothetical conveyor association: Belt speed is 1.5 m/s and maximum allowed timestamp-induced position ambiguity is 0.30 mm.
Allowed time error = 0.00030 m / 1.5 m/s = 0.00020 s = 200 µs
The complete budget includes sensor detection, trigger propagation, camera exposure timestamp, clock offset, and PLC event timestamp—not only network clock offset. If non-clock contributions consume 140 µs, only 60 µs remains for clocks and margin.
Practical decision aid
| Need | Likely approach | Validation focus |
|---|---|---|
| Human-readable audit time | managed NTP may be sufficient | UTC source, offset, outage annotation |
| Multi-device sub-millisecond correlation | PTP with suitable hardware | profile, switches, timestamp location |
| Exposure simultaneity | hardware trigger or scheduled action plus clocks | measured exposure-start difference |
| Host log ordering | NTP/PTP system clocks | queueing and timestamp point |
| Line-motion association | encoder/trigger identity plus time | spatial error at maximum speed |
| Traceable UTC plus precise local timing | disciplined PTP grandmaster | source, holdover, and record status |
Use the table to choose the next controlled experiment, not as a universal product recommendation. A component or algorithm is acceptable only when the complete inspection cell meets pre-agreed technical and operational criteria.
Common mistakes and how to prevent them
Comparing advertised best-case accuracy. real architecture differs. Prevent it by measuring complete event error.
Timestamping on host receipt. network delay is included. Prevent it by using camera or NIC event timestamps where needed.
Assuming PTP triggers cameras. clocks align but exposures need commands. Prevent it by designing scheduled action or hardware trigger.
Ignoring switch PTP role. residence and asymmetry degrade timing. Prevent it by verifying transparent or boundary behaviour.
No unsynchronised flag in records. bad time looks valid. Prevent it by storing clock status and source.
One-time offset test. temperature and failover drift appear later. Prevent it by running long and faulted validation.
Validate under production conditions
Generate a common physical or electrical event visible to every device and compare camera, PLC, host, and reference timestamps over long runs. Test maximum network and acquisition load, temperature, power-up, grandmaster loss and replacement, NTP source loss, cable and switch changes, asymmetric paths, clock steps, holdover, and restarts. Report offset and end-to-end event error percentiles, outliers, resynchronisation time, and invalid-time handling.
Use representative acceptable parts, confirmed defects, boundary samples, and nuisance variation. Repeat complete part presentations rather than processing one stored image many times. Include start-up, warm-up, maximum speed, changeover, maintenance, environmental limits, communication faults, and long-duration operation where relevant.
Define acceptance criteria before reviewing final results. Preserve raw counts and denominators for false accepts, false rejects, invalid acquisitions, timing overruns, and manually reviewed cases. After release, trend leading indicators and conduct labelled audits so deterioration is detected before a customer escape.
Key takeaways
Start with allowable event-time error and timestamp meaning.
NTP supports broad clock coordination; PTP supports more precise hardware-assisted timing.
Synchronized clocks do not automatically synchronize exposures.
Budget timestamp point, fixed delay, asymmetry, offset, and holdover.
Validate against a common event during load, failover, and environmental change.
Follow this Hashnode blog for more practical industrial machine-vision engineering, and connect with Kivanc Ekici on LinkedIn. For related machine-vision and automation information, visit ITAGE.
Frequently asked questions
Is PTP always more accurate than NTP?
PTP is designed for higher precision and hardware support, but actual performance depends on devices, switches, profiles, timestamping, topology, and configuration.
Does GigE Vision PTP make two cameras expose simultaneously?
It aligns supported device clocks. Simultaneous exposure additionally needs scheduled action commands or a shared hardware trigger and validated camera timing.
Where should an image timestamp be taken?
Prefer a documented camera event such as exposure start when physical timing matters; host receipt time is useful for software logs but includes transport delay.
What happens when the grandmaster fails?
Devices may select a replacement or enter holdover. Record clock source and status, alarm excessive offset, and validate transition behaviour.
Can NTP support production traceability?
Often yes for wall-clock record correlation when the required accuracy and outage behaviour are validated. It may be inadequate for tightly timed multi-device events.