Xtium2-CL MX4 User's Manual
Xtium2-CL MX4 Reference
•
67
Trigger Signal Validity
The ACU ignores external trigger signal noise with its programmable debounce control. Program
the debounce parameter for the minimum pulse duration considered as a valid external trigger
pulse. For more information see Note 1: General Inputs / External Trigger Inputs Specifications.
Supported Transfer Cycling Methods
The Xtium2-CL MX4 supports the following transfer modes, which are either synchronous or
asynchronous. Images are accumulated in on-board memory in a FIFO type manner. On-board
memory can get filled up if the rate at which the images are acquired is greater than the rate at
which the DMA engine can write them to host buffer memory. On-board memory can also get
filled-up if there are no more empty buffers available to transfer the on-board images.
When no memory is available for a new image to be stored in on-board memory, the image is
discarded and a CORACQ_VAL_EVENT_TYPE_FRAME_LOST or trash buffer callback is generated. If
a CORACQ_VAL_EVENT_TYPE_FRAME_LOST occurs when host buffers are available, it can indicate
a problem with the MX4 bus bandwidth.
If image buffers are constructed using a trash buffer (SapBufferWithTrash using a transfer cycle
mode with trash), when no host buffers are available and no memory is available for a new image
to be stored in on-board memory, the SapXferCallBackInfo::IsTrash (C++) function or
SaxXferNotifyEventsArgs.Trash (.NET) property returns true. If a trash callback function has been
registered during construction of the SapTransfer object, it will be executed when a trash event
occurs.
When stopping the image acquisition, the event CORXFER_VAL_EVENT_TYPE_END_OF_TRANSFER
will occur once all images currently in the on-board memory are transferred to host buffer memory.
Note that if the application does not provide enough empty buffers, the Xtium2 event will not occur
and an acquisition abort will be required.
•
CORXFER_VAL_CYCLE_MODE_SYNCHRONOUS_WITH_TRASH
Before cycling to the next buffer in the list, the transfer device will check the next buffer's
state. If its state is full, the transfer will keep the image in on-board memory until the next
buffer’s state changes to empty. If the on
-board memory gets filled, trash callbacks will be
generated.
•
CORXFER_VAL_CYCLE_MODE_SYNCHRONOUS_NEXT_EMPTY_WITH_TRASH
When starting an acquisition, the buffer list is put in an empty buffer queue list in the exact
order they were added to the transfer. Whenever a user sets a buffer to empty, it is added
to the empty buffer queue list, so that after cycling once through the original buffer list, the
buffers acquired into will follow the order in which they are put empty by the user. So in this
mode, the on-board images will be transferred to host buffer memory as long as there are
buffers in the empty buffer queue list. If no buffers are available on the host and the on-
board memory gets filled, trash callbacks will be generated.
•
CORXFER_VAL_CYCLE_MODE_ASYNCHRONOUS
The transfer device cycles through all buffers in the list without concern about the buffer
state.
