A timestamp is useful for locating a test in production history, while a duration describes how long an operation took. Using the same clock for both purposes can produce misleading cycle times when the computer clock changes. Define the quantity being measured before selecting the timing mechanism.

Python’s time documentation describes a monotonic clock that cannot move backward and is unaffected by system-clock updates. Its reference point is undefined, so differences between readings provide meaning rather than the absolute reading itself.

Separate the timing questions

Keep a calendar timestamp for event correlation and an appropriate elapsed-time measurement for duration. Do not subtract monotonic readings from unrelated computers or different timing domains. Their numeric values do not establish a shared reference.

Decide whether the reported cycle includes operator loading, queue time, instrument acquisition, analysis, storage, and unloading. A faster measurement routine may not improve the complete station cycle if the saved time is consumed by another stage.

Reported duration Boundary to define
Electrical acquisition Acquisition start through completed data availability
Automated sequence Program start through defined sequence completion
Station occupancy Position occupied through release for the next unit
Result delivery Result ready through confirmed storage

Measure the intended boundary

Place timing markers around the actual operation, not merely around a command that starts asynchronous work. If a driver returns immediately while acquisition continues, the command-call duration does not describe acquisition time. Record completion using the interface’s defined completion mechanism.

Retain waiting periods that belong to the chosen quantity. CPU execution time is not interchangeable with elapsed time when the program waits for instruments or operators. Label any deliberately excluded pauses so comparisons remain understandable. Preserve separate retry counts when additional attempts contribute to the reported occupied time.

Validate cycle-time records

Use a controlled delay to check that the reported duration follows the expected boundary. Exercise interruption and retry paths, including an operation that does not complete. An aborted attempt should not receive the same duration interpretation as a normally completed cycle.

Review impossible negative values and abrupt shifts as measurement-system issues before treating them as process improvements. Preserve the timer type, units, and relevant software revision with the calculation definition.

Compare stations only after their duration definitions agree. Two valid measurements can still answer different questions if one includes result storage and another ends at the final electrical reading. A useful cycle-time report makes those boundaries explicit and retains calendar information separately for production-event correlation.

Move from reading to a build-ready project

Use the fabrication and assembly checklists to prepare drawings, production files and test requirements.

Open the DFM checklist