Hello,
thank you for the data.
As I see in the trace there are 6 imageAcquisition requets but only 5 images taken. Is that right?
The image which was not taken was the first one.
As you can see with the acceptedAcquisitionCnt the camera is not accepting the the first imageAcquisition trigger.
If we look a little more closely, it is actually the case that the camera is ready at the time of the trigger (CameraStatus = 0),
but in the next cycle the CameraStatus = 128 (0x80) which means that the focus module is busy.
So it looks like a focus change is in progress and wos requested before or in the same time as the imageAcqusition trigger.
This is a little bit tricky with all the task and POWERLINK bus transmission times.
The camera is busy in case of a focus change an no image can be taken.
The way would be:
- change the focus (the command is processed asynchronously by the camera)
- to ensure that the camera has processed the command wait at least 5 PLK cycle + ca. 5ms
- check the CameraStatus
- if the cameraStatus is 0 you can trigger the image
Additional informations and recommendations from my side:
General Information
When operating the camera cyclically, special attention must be paid to task and bus cycle times.
On one hand, it takes some time for an action to be recognized, accepted, and displayed in the CameraStatus. On the other hand, some operations are processed so quickly that they may not appear in the CameraStatus or can be easily overlooked. The camera does not artificially extend the status display, as this would slow down the entire system from the perspective of trigger control.
Internal Processing
Only the trigger control (ImageAcquisition including the associated trigger parameters) is processed by the camera synchronously with guaranteed fixed jitter via POWERLINK. This is necessary to maintain overall camera performance.
Other commands from the cyclic frame (e.g., SearchAcquisitionSettings, IRFilter, SetFocus, or GainLevel) are processed by the camera during remaining time slots and may therefore take slightly longer to be processed and signaled in the CameraStatus, potentially with a jitter of a few milliseconds. This also applies to changes in the SDOs of the image acquisition configuration, which are asynchronous by nature.
Task Cycle and Bus Cycle Time
To avoid missing information in the CameraStatus, the task cycle should match the PLK cycle time and be synchronized with it.
For all requested camera actions, at least the bus cycle time must be considered before the action is recognized and signaled in the CameraStatus. For trigger control, this is guaranteed to be 5 PLK cycle times; for other actions, an additional ~5 ms may be required. Only after this time has elapsed following the issuance of a command is the CameraStatus and the camera’s Ready flag guaranteed to be valid.
Since some camera actions are processed so quickly internally that they may not appear in the CameraStatus (e.g., GainLevel), the following applies: if the corresponding flag in the CameraStatus is not set after the time period mentioned above, the action has been fully executed.
Actions with Feedback
For actions that provide cyclic feedback (SetFocus and ReadFocus, or GainLevel and ReadGainLevel), it is recommended to wait for the corresponding feedback after issuing the command.
Command Cascading
Commands are partially processed sequentially by the camera. Therefore, if commands are requested while other actions are still running, it may happen (due to bus cycle times and internal processing times) that the Ready flag briefly switches to TRUE before the next action is executed.
It is therefore recommended that users avoid requesting multiple actions before the previous ones are fully completed, or ensure that all actions are completely finished before a trigger is requested. Otherwise, the trigger will be ignored because the camera is not “Ready”.
I don’t have any information about the logbook entry at the moment, I’ll get back to you as soon as I have more information
Best regards,
Florian
