Camera PTP: Clock Alignment Is Only One Part of Exposure Synchronisation
Basler describes PTP clock synchronisation for supported GigE cameras and notes the influence of network hardware and setup. A network may also use an arbitrary timescale without an external absolute reference. Start by defining the event that the application actually needs to align.
Name the synchronised event
List exposure start, frame timestamps, image arrival and robot-state sampling separately. Give each value a source, unit and event definition. Similar numbers from two logs do not establish that they describe the same physical event or even the same clock domain.
For this review, identify the delivered device, software and configuration revisions first. Record unsupported, disabled and untested capabilities separately. Evidence from another model is useful context, but cannot establish what the delivered combination actually provides. Keep the original input beside the settings used to interpret it.
Record the master and timescale
Keep master-clock identity, role selection and network topology with the test. State whether the timeline has an absolute reference or is valid only within the synchronised network. Explain how host logs associate camera timestamps with their own recorded events.
Retain the original input and the reason for the decision, rather than a successful screenshot alone. Change only the variables agreed for the comparison, and keep the before-and-after configuration. List conditions that were not exercised explicitly; they should not silently become part of the accepted operating range.
Pair clock status with exposure evidence
Clock state and offset observations describe part of the timing chain. If simultaneous exposure is the requirement, obtain evidence tied to the actual trigger arrangement. Define the allowed difference and the measurement method before interpreting a successful clock-status display.
Use the three illustrated observations as starting questions, rather than as diagnoses of an installation that has not been inspected. Check record completeness, units and identity before selecting the next observation. An unresolved result is more informative than a confident explanation assembled from missing fields or unrelated test runs.
Cover restart and role changes
Observe convergence after an approved restart or master change. Specify how frames acquired before timing is trustworthy are marked and whether they may enter a combined result. Recovery should depend on an explicit readiness rule rather than a fixed optimistic delay.
Let the site owner choose an approved isolated way to exercise relevant exceptions. Record normal operation, the exceptional condition and recovery separately. The purpose is to establish how the application recognises and explains untrustworthy input, without requiring production equipment to act on deliberately invalid results.
Deliver a joined timing record
A useful sample links camera identity, clock state, trigger information, image and final result. Changes to switches, topology or triggering can affect the evidence boundary. Name the conditions under which the original synchronisation conclusion must be reviewed again.
Deliver the configuration, representative samples, result table and unresolved questions together. Agree who reviews subsequent changes. The receiving team should be able to select one conclusion and trace it back to its input and decision path without relying on the original author to reconstruct the missing steps.
Original documentation and further reading
Continue with related articles in this section, or use selection guides to prepare the next review. Apply the device-specific documentation and agreed operating conditions when implementing a test.