Standard Features
Basler scout 235
9.16 Event Reporting
Event reporting is available on the camera. With event reporting, the camera can generate an
"event" and after some intermediate steps transmit a related event message to the PC whenever a
specific situation has occurred.
Currently, the camera can generate and transmit an event for two types of situations:
Overtriggering of the acquisition start trigger has occurred
(AcquisitionStartOvertriggerEventData)
Overtriggering of the frame start trigger has occurred (FrameStartOvertriggerEventData)
The end of an exposure has occurred (ExposureEndEventData)
An event overrun has occurred (EventOverrunEventData)
An Example of Event Reporting
An example related to the Exposure End event illustrates how event reporting works. The example
assumes that your system is set for event reporting (see below), and that an end of exposure has
just occurred in the camera. In this case:
1. An Exposure End event is generated. The event contains the event in the strict sense and sup-
plementary information:
An Event Type Identifier. In this case, the identifier would show that an exposure end type
event has occurred.
A Frame ID. This number indicates the frame count at the time that the event occurred.
A Stream Channel Identifier. Currently this identifier is always 0.
A Timestamp. This is a timestamp indicating when the event occurred.*
2. The event is placed in an internal queue in the camera.
3. As soon as bus transmission time is available, an event message will be sent to the PC. If only
one event is in the queue, the message will contain the single event. If more than one event is
in the queue, the message will contain multiple events.
4. Event Reporting involves some further software-related steps and settings to be made. For
more information, see the "Camera Events" code sample included with the pylon software
development kit.
* The timestamp is a 32 bit value. The structure of this timestamp is similar to the timestamp
described in Section 10.4 on page 254.
The Event Queue
As mentioned in the example above, the camera has an event queue. The intention of the queue is
to handle short term delays in the camera’s ability to access the bus and send event messages.
When event reporting is working "smoothly", a single event will be placed in the queue and this
event will be sent to the PC in an event message before the next event is placed in queue. If there
is an occasional short term delay in event message transmission, the queue can buffer several
events and can send them within a single event message as soon as transmission time is available.