Scheduled Camera Actions: Verify Deadlines and Actual Image Capture
Basler scheduled actions specify execution against the camera timestamp. The documented zero or past-time case executes immediately like a regular action. That boundary makes clock readiness and scheduling margin part of the application contract, rather than details hidden behind a send call.
Establish membership and clock readiness
Record device and group keys, group mask and actual network scope. Confirm the required PTP state before issuing a scheduled action. Incorrect group membership and an unready clock are separate problems and need separate observable records.
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.
Account for scheduling margin
Separate clock sampling, host calculation, the send call and device reception. Form the target in the correct timestamp units and explain how the application accounts for elapsed time. The interval between reading a device clock and issuing an API call is not instantaneous.
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.
Test the expired-target boundary
In an isolated test, establish how the application handles zero, past-time and untrusted-clock inputs. Immediate execution must not be reported as successful execution at the intended future deadline. Retain the target and the capture-associated timing evidence together.
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.
Associate commands with captured frames
Give each request an application identity and retain the expected camera set beside received frames. Specify grouping rules for a missing camera, duplicate frame or receive timeout. Filling a result set with whichever image arrived most recently can conceal a failed acquisition.
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.
Separate execution from result availability
Action execution, exposure, transport, inference and result availability are distinct events. Define each measurement boundary and report whether the complete chain meets the application deadline. A correctly populated action-time parameter is only one piece of that evidence.
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.