Table of Contents

1. Introduction
1.1. Features of Applet Acq_QuadCXP6x1AreaGray
1.1.1. Parameterization Order
1.2. Bandwidth
1.3. Requirements
1.3.1. Software Requirements
1.3.2. Hardware Requirements
1.3.3. License
1.4. Camera Interface
1.5. Image Transfer to PC Memory
2. Software Interface
3. CoaXPress
3.1. FG_PIXELFORMAT
3.2. FG_CXP_TRIGGER_PACKET_MODE
4. Camera
4.1. Events
4.1.1. FG_START_OF_FRAME_CAM_PORT_0 et al.
4.1.2. FG_END_OF_FRAME_CAM_PORT_0 et al.
5. Sensor Geometry
5.1. FG_VANTAGEPOINT
5.2. FG_SENSORWIDTH
5.3. FG_SENSORHEIGHT
6. ROI
6.1. FG_WIDTH
6.2. FG_HEIGHT
6.3. FG_XOFFSET
6.4. FG_YOFFSET
7. Trigger
7.1. Features and Functional Blocks of Area Trigger
7.2. Digital Input/Output Mapping
7.3. Event Overview
7.4. Trigger Scenarios
7.4.1. Internal Frequency Generator / Grabber Controlled
7.4.2. External Trigger Signals / IO Triggered
7.4.3. Control of Three Flash Lights
7.4.4. Software Trigger
7.4.5. Software Trigger with Trigger Queue
7.4.6. External Trigger with Trigger Queue
7.4.7. Bypass External Trigger Signals
7.4.8. Multi Camera Applications / Synchronized Cameras
7.4.9. Hardware System Analysis and Error Detection / Trigger Debugging
7.5. Parameters
7.5.1. FG_AREATRIGGERMODE
7.5.2. FG_TRIGGERSTATE
7.5.3. FG_TRIGGER_FRAMESPERSECOND
7.5.4. Trigger Input
7.5.4.1. External
7.5.4.1.1. FG_TRIGGERIN_DEBOUNCE
7.5.4.1.2. FG_GPI
7.5.4.1.3. FG_FRONT_GPI
7.5.4.1.4. FG_TRIGGERIN_SRC
7.5.4.1.5. FG_TRIGGERIN_POLARITY
7.5.4.1.6. FG_TRIGGERIN_DOWNSCALE
7.5.4.1.7. FG_TRIGGERIN_DOWNSCALE_PHASE
7.5.4.2. Software Trigger
7.5.4.2.1. FG_SENDSOFTWARETRIGGER
7.5.4.2.2. FG_SOFTWARETRIGGER_IS_BUSY
7.5.4.2.3. FG_SOFTWARETRIGGER_QUEUE_FILLLEVEL
7.5.4.3. Statistics
7.5.4.3.1. FG_TRIGGERIN_STATS_SOURCE
7.5.4.3.2. FG_TRIGGERIN_STATS_POLARITY
7.5.4.3.3. FG_TRIGGERIN_STATS_PULSECOUNT
7.5.4.3.4. FG_TRIGGERIN_STATS_PULSECOUNT_CLEAR
7.5.4.3.5. FG_TRIGGERIN_STATS_FREQUENCY
7.5.4.3.6. FG_TRIGGERIN_STATS_MINFREQUENCY
7.5.4.3.7. FG_TRIGGERIN_STATS_MAXFREQUENCY
7.5.4.3.8. FG_TRIGGERIN_STATS_MINMAXFREQUENCY_CLEAR
7.5.4.3.9. FG_TRIGGER_INPUT0_RISING et al.
7.5.4.3.10. FG_TRIGGER_INPUT0_FALLING et al.
7.5.5. Sequencer
7.5.5.1. FG_TRIGGER_MULTIPLY_PULSES
7.5.6. Queue
7.5.6.1. FG_TRIGGERQUEUE_MODE
7.5.6.2. FG_TRIGGERQUEUE_FILLLEVEL
7.5.6.3. FG_TRIGGER_QUEUE_FILLLEVEL_EVENT_ON_THRESHOLD
7.5.6.4. FG_TRIGGER_QUEUE_FILLLEVEL_EVENT_OFF_THRESHOLD
7.5.6.5. FG_TRIGGER_QUEUE_FILLLEVEL_THRESHOLD_CAM0_ON et al.
7.5.6.6. FG_TRIGGER_QUEUE_FILLLEVEL_THRESHOLD_CAM0_OFF et al.
7.5.7. Pulse Form Generator 0
7.5.7.1. FG_TRIGGER_PULSEFORMGEN0_DOWNSCALE et al.
7.5.7.2. FG_TRIGGER_PULSEFORMGEN0_DOWNSCALE_PHASE et al.
7.5.7.3. FG_TRIGGER_PULSEFORMGEN0_DELAY et al.
7.5.7.4. FG_TRIGGER_PULSEFORMGEN0_WIDTH et al.
7.5.8. Pulse Form Generator 1
7.5.9. Pulse Form Generator 2
7.5.10. Pulse Form Generator 3
7.5.11. Camera Out Signal Mapping
7.5.11.1. FG_TRIGGERCAMERA_OUT_SELECT
7.5.11.2. FG_TRIGGERCAMERA_GPO0 et al.
7.5.12. Digital Output
7.5.12.1. FG_TRIGGEROUT_SELECT_GPO_0 et al.
7.5.12.2. FG_TRIGGEROUT_SELECT_FRONT_GPO_0 et al.
7.5.12.3. Statistics
7.5.12.3.1. FG_TRIGGER_EXCEEDED_PERIOD_LIMITS
7.5.12.3.2. FG_TRIGGER_EXCEEDED_PERIOD_LIMITS_CLEAR
7.5.12.3.3. FG_TRIGGEROUT_STATS_SOURCE
7.5.12.3.4. FG_TRIGGEROUT_STATS_PULSECOUNT
7.5.12.3.5. FG_TRIGGEROUT_STATS_PULSECOUNT_CLEAR
7.5.12.3.6. FG_MISSING_CAMERA_FRAME_RESPONSE
7.5.12.3.7. FG_MISSING_CAMERA_FRAME_RESPONSE_CLEAR
7.5.12.3.8. FG_TRIGGER_EXCEEDED_PERIOD_LIMITS_CAM0 et al.
7.5.12.3.9. FG_MISSING_CAM0_FRAME_RESPONSE et al.
7.5.13. Output Event
7.5.13.1. FG_TRIGGER_OUTPUT_EVENT_SELECT
7.5.13.2. FG_TRIGGER_OUTPUT_CAM0 et al.
8. Overflow
8.1. FG_FILLLEVEL
8.2. FG_OVERFLOW
8.3. Events
8.3.1. FG_OVERFLOW_CAM0 et al.
9. Image Selector
9.1. FG_IMG_SELECT_PERIOD
9.2. FG_IMG_SELECT
10. Lookup Table
10.1. FG_LUT_ENABLE
10.2. FG_LUT_TYPE
10.3. FG_LUT_VALUE
10.4. FG_LUT_CUSTOM_FILE
10.5. FG_LUT_SAVE_FILE
10.6. Applet Properties
10.6.1. FG_LUT_IMPLEMENTATION_TYPE
10.6.2. FG_LUT_IN_BITS
10.6.3. FG_LUT_OUT_BITS
11. Processing
11.1. FG_PROCESSING_OFFSET
11.2. FG_PROCESSING_GAIN
11.3. FG_PROCESSING_GAMMA
11.4. FG_PROCESSING_INVERT
12. Output Format
12.1. FG_FORMAT
12.2. FG_BITALIGNMENT
12.3. FG_PIXELDEPTH
12.4. FG_CUSTOM_BIT_SHIFT_RIGHT
13. Camera Simulator
13.1. FG_CAMERASIMULATOR_ENABLE
13.2. FG_CAMERASIMULATOR_WIDTH
13.3. FG_CAMERASIMULATOR_LINE_GAP
13.4. FG_CAMERASIMULATOR_HEIGHT
13.5. FG_CAMERASIMULATOR_FRAME_GAP
13.6. FG_CAMERASIMULATOR_PATTERN
13.7. FG_CAMERASIMULATOR_PATTERN_OFFSET
13.8. FG_CAMERASIMULATOR_ROLL
13.9. FG_CAMERASIMULATOR_SELECT_MODE
13.10. FG_CAMERASIMULATOR_PIXEL_FREQUENCY
13.11. FG_CAMERASIMULATOR_LINERATE
13.12. FG_CAMERASIMULATOR_FRAMERATE
13.13. FG_CAMERASIMULATOR_TRIGGER_MODE
13.14. FG_CAMERASIMULATOR_ACTIVE
13.15. FG_CAMERASIMULATOR_PASSIVE
14. Miscellaneous
14.1. FG_TIMEOUT
14.2. FG_APPLET_VERSION
14.3. FG_APPLET_REVISION
14.4. FG_APPLET_ID
14.5. FG_APPLET_BUILD_TIME
14.6. FG_HAP_FILE
14.7. FG_DMASTATUS
14.8. FG_CAMSTATUS
14.9. FG_CAMSTATUS_EXTENDED
14.10. FG_SYSTEMMONITOR_FPGA_TEMPERATURE
14.11. FG_SYSTEMMONITOR_FPGA_VCC_INT
14.12. FG_SYSTEMMONITOR_FPGA_VCC_AUX
14.13. FG_SYSTEMMONITOR_FPGA_VCC_BRAM
14.14. FG_SYSTEMMONITOR_CURRENT_LINK_WIDTH
14.15. FG_SYSTEMMONITOR_CURRENT_LINK_SPEED
14.16. FG_SYSTEMMONITOR_PCIE_LINK_GEN2_CAPABLE
14.17. FG_SYSTEMMONITOR_PCIE_LINK_PARTNER_GEN2_CAPABLE
14.18. FG_SYSTEMMONITOR_PCIE_TRAINED_PAYLOAD_SIZE
14.19. FG_SYSTEMMONITOR_EXTENSION_CONNECTOR_PRESENT
14.20. FG_ALTERNATIVE_BOARD_DETECTION
14.21. FG_SYSTEMMONITOR_FPGA_DNA
14.22. FG_SYSTEMMONITOR_CHANNEL_CURRENT
14.23. FG_SYSTEMMONITOR_CHANNEL_VOLTAGE
14.24. FG_SYSTEMMONITOR_CHANNEL_STATE
14.25. Debug
14.25.1. FG_DEBUGSOURCE
14.25.2. FG_DEBUGSOURCENAME
14.25.3. FG_DEBUGSAVECONFIG
14.25.4. Input
14.25.4.1. FG_DEBUGINENABLE
14.25.4.2. FG_DEBUGFILE
14.25.4.3. FG_DEBUGINSERT
14.25.4.4. FG_DEBUGWRITEPIXEL
14.25.4.5. FG_DEBUGWRITEFLAG
14.25.4.6. FG_DEBUGREADY
14.25.5. Output
14.25.5.1. FG_DEBUGOUTENABLE
14.25.5.2. FG_DEBUGOUTXPOS
14.25.5.3. FG_DEBUGOUTYPOS
14.25.5.4. FG_DEBUGOUTPIXEL
Glossary
Index

This document provides detailed information on the Silicon Software AcquisitionApplets "Acq_QuadCXP6x1AreaGray" for microEnable 5 marathon ACX QP frame grabbers.

This document will outline the features and benefits of this AcquisitionApplets. Furthermore, the output formats and the software interface is explained. The main part of this document includes the detailed description of all applet modules and their parameters which make the AcquisitionApplets adaptable for numerous applications.

The AcquisitionApplets "Acq_QuadCXP6x1AreaGray" is a quad camera applet. Up to four individual cameras can be used. The features of this applet are fully available for all camera ports. The CoaxPress camera interface can be configured for CoaxPress cameras transferring grayscale pixels. Allowed pixel formats are Mono8, Mono10, Mono12, Mono14 and Mono16. Only single link CoaxPress cameras can be used with this applet. The maximum link speed is CXP-6. A multi-functional area trigger is included to control the camera or external devices using grabber generated, external or software generated trigger pulses. Area scan cameras transferring images with a resolution of up to 65536 by 65535 pixels are supported. The applet is processing data at a bit depth of 16 bits. An image selector at the camera port facilitates the selection of one image out of a parameterizable sequence of images. This enables the distribution of the images to multiple frame grabbers and PCs. For reverse operation, the Image can be mirrored in x-direction and y-direction before cutting the ROI. Acquired images are buffered in frame grabber memory. A region of interest (ROI) can be selected for further processing. The stepsize of the ROI width is 8 pixel and the ROI stepsize for the image height is 1 line. The 14 bit full resolution lookup table can either be configured by using a user defined table or by using a processor. The processor gives the opportunity to use pre-defined functions such as offset, gain, invert to enhance the image quality.

Processed image data are output via high speed DMA channels. Pixel format can either be 8 bit, 10 bit packed, 12 bit packed, 14 bit packed or 16 bits per pixel.

The applet can easily be included into user applications using the Silicon Software runtime.


The maximum bandwidths of applet Acq_QuadCXP6x1AreaGray are listed in the following table.


The peak bandwidth defines the maximum allowed bandwidth for each camera at the camera interface. If the camera's peak bandwidth is higher than the mean bandwidth the frame grabber on-board buffer will fill up as the data can be buffered, but not being processed at that speed.

The mean bandwidth per camera describes the maximum allowed mean bandwidth for each camera at the camera interface. It is the product of the framerate and the image pixels. For example, a 1 Megapixel image at a framerate of 100 frames per second, the mean bandwidth will be 100 MPixel/s. In case of 8bit per pixel as output format this would be equal to 100 MB per second.

The required output bandwidth of an applet can differ from the input bandwidth. A region of interest (ROI) and the output format can change the required output bandwidth and the maximum mean bandwidth. Mind that the DMA bandwidth is the total bandwidth. The sum of all camera channel bandwidths has to be less than the maximum DMA bandwidth to avoid overflows.

Regard the relation between MPixel/s and MByte/s. The MByte/s depends on the applet and its parameterization concerning the pixel format. It is possible to acquire more than 8 bit per pixel or convert from one bit depth to another. 1 MByte is 1,000,000 Byte.

[Note]Bandwidth Varies

The exact maximum DMA bandwidth depends on the used PC system and its chipset. The camera bandwidth depends on the image size and the selected frame rate. The given values of 1800 MByte/s for the possible DMA bandwidth might be lower due to the chipset and its configuration. Additionally some PCIe slots do not support the required number of lanes to transfer the requested or expected bandwidth. In these cases have a look at the mainboard specification. A behaviour like multiplexing between several PCIe slots can be seen in rare cases. Some mainboard manufacturers provide a BIOS feature where you can select the PCIe payload size: Always try to set this to its maximum value or simply automatic. This can help in specific cases.

The software interface is fully compatible to the Silicon Software runtime. Please read the SDK manual of the Silicon Software runtime software to understand how to include the microEnable frame grabbers and their applets into own applications.

The runtime includes functional SDK examples which use the features of the runtime. Most of these examples can be used with this AcquisitionApplets. These examples are very useful to learn on how to acquire images, set parameters and use events.

This document is focused on the explanation of the functionality and parameterization of the applet. The next chapters will list all parameters of this applet. Keep in mind that for multi-camera applets, parameters can be set for all cameras individually. The sample source codes parameterize the processing components of the first camera. The index in the source code examples has to be changed for the other cameras.

Amongst others, parameters of the applet are set and read using functions

  • int Fg_setParameter(Fg_Struct *Fg, const int Parameter, const void *Value, const unsigned int index)
  • int Fg_setParameterWithType(Fg_Struct *Fg, const int Parameter, const void *Value, const unsigned int index, const enum FgParamTypes type)
  • int Fg_getParameter(Fg_Struct *Fg, int Parameter, void *Value, const unsigned int index)
  • int Fg_getParameterWithType(Fg_Struct *Fg, const int Parameter, void *Value, const unsigned int index, const enum FgParamTypes type)

The index is used to address a DMA channel, a camera index or a processing logic index. It is important to understand the relations between cameras, processes, parameters and DMA channels.

For applets having multiple DMA channels for each camera, the relation between the indices is more complex. Please check the respective documentation of these applets for more details.

This AcquisitionApplets can be used with up to 4 area scan cameras. To receive correct image data from your camera, it is crucial that the camera output format matches the selected frame grabber input format. The following parameter configure the grabber's camera interface to match with the individual camera pixel format. Most cameras support different operation modes. Please, consult the manual of your camera to obtain the necessary information, how to configure the camera to the desired pixel format.

Ensure that the images transferred by the camera do not exceed the maximum allowed image dimensions for this applet (65536 x 65535).

A second parameter defines the way trigger packets are sent from the grabber to the camera on the CXP link.

This AcquisitionApplets Acq_QuadCXP6x1AreaGray for the microEnable 5 marathon ACX QP acquires the sensor data of an area scan camera. When this is performed some sensor dimension depending information can be used to register an event based callback function.

In programming or runtime environments, a callback function is a piece of executable code that is passed as an argument, which is expected to call back (execute) exactly that time an event is triggered. This applet can generate some software callback events based on applet-events as explained in the following section. These events are not related to a special camera functionality. Other event sources are described in additional sections of this document.

Our Runtime/SDK enables an application to get these event notifications about certain state changes at the data flow from camera to RAM and the image and trigger processing as well. Please consult our Runtime/SDK documentation for more details concerning the implementation of this functionality.

Some operations, for example mirroring or tap sorting, require knowledge on the sensor Dimension and orientation of the camera. The following parameters supply this kind of information.

This module allows the definition of a region of interest (ROI), also called area of interest (AOI). A ROI allows the selection of a smaller subset pixel area from the input image. It is defined by using parameters FG_XOFFSET, FG_WIDTH, FG_YOFFSET and FG_HEIGHT. The following figure illustrates the parameters.


As can be seen, the region of interest lies within the input image dimensions. Thus, if the image dimension provided by the camera is greater or equal to the specified ROI parameters, the applet will fully cut-out the ROI subset pixel area. However, if the image provided by the camera is smaller than the specified ROI, lines will be filled with random pixel content and the image height might be cut or filled with random image lines as illustrated in the following.


Furthermore, mind that the image sent by the camera must not exceed the maximum allowed image dimensions. This applet allows a maximum image width of 65536 pixels and a maximum image height of 65535 lines. The chosen ROI settings can have a direct influence on the maximum bandwidth of the applet as they define the image size and thus, define the amount of data.

The parameters have dynamic value ranges. For example an x-offset cannot be set if the sum of the offset and the image width will exceed the maximum image width. To set a high x-offset, the image width has to be reduced, first. Hence, the order of setting the parameters for this module is important. The return values of the function calls in the SDK should always be evaluated to check if changes were accepted.

Mind the minimum step size of the parameters. This applet has a minimum step size of 8 pixel for the width and the x-offset, while the step size for the height and the y-offset is 1.

The settings made in this module will define the display size and buffer size if the applet is used in microDisplay. If you use the applet in your own programs, ensure to define a sufficient buffer size for the DMA transfers in your PC memory.

All ROI parameters can only be changed if the acquisition is not started i.e. stopped.

[Note]Camera ROI

Most cameras allow the setting of a ROI inside the camera. The ROI settings described in this section are independent from the camera settings.

[Note]Influence on Bandwidth

A ROI might cause a strong reduction of the required bandwidth. If possible, the camera frame dimension should be reduced directly in the camera to the desired size instead of reducing the size in the applet. This will reduce the required bandwidth between the camera and the frame grabber.

The parameter specifies the width of the ROI. The values of parameters FG_WIDTH + FG_XOFFSET must not exceed the maximum image width of 65536 pixels. If a horizontal mirroring is active SensorWidth limits the maximum Width (Width + XOffset). If furthermore vertical Mirroring is active the maximum Width is limited by the DRAM and SensorHeight (Sensor dimension need to fit into the DRAM).

[Note] Maximum image width is reduced for horizontal mirrored Images

Limitations of the available BRAM in the FPGA allow only to store smaller lines and there for the images that can be mirrored needs to be smaller. A mirrored Image can only have width of 32768, the not mirrored image can have the full width of 65536.



The area trigger system enables the control of the image acquisition process of the frame grabber and the connected cameras. In detail it controls the exact exposure time of the camera and controls external devices. The trigger source can be external devices, internal frequency generators or the user's software application.

The marathon frame grabber has eight input IOs available on its extension port plus 4 inputs on the front IO connector. The extension port can be connected through a Silicon Software IO module board to external devices. In contrast the marathon has 4 inputs on its extension port and another four inputs on the front IO connector. Check the hardware documentation for more information. The microEnable 5 marathon ACX QP generates the desired trigger outputs and control signals from the input events according to the trigger system's parameterization. The trigger system outputs can be routed to the camera via the CoaXPress link. Additionally, outputs can be routed to the digital outputs for control of external devices such as flash lights, for synchronizing or for debugging.


In the following an introduction into the Silicon Software microEnable 5 marathon ACX QP trigger system is presented. Several trigger scenarios will show the possibilities and functionalities and will help to understand the trigger system. The documentation includes the parameter reference where all parameters of the trigger system are listed and their functionality is explained in detail.

The Silicon Software trigger system was designed to fulfill the requirements of various applications. Powerful features for trigger generation, controlling and monitoring were included in the implementation. This includes:

  • Trigger signal generation for cameras and external devices.

  • External devices such as encoders and light barriers can be used to source the trigger system and control the trigger signal generation.

  • In alternative an internal frequency generator can be used to generate trigger pulses.

  • The trigger signal generation can be fully controlled by software . Single pulses or sequences of pulses can be generated. The trigger system will automatically control and limit the output frequency.

  • Input signal monitoring .

  • Input signal frequency analysis and pulse counting .

  • Input signal debouncing

  • Input signal downscaling

  • Pulse multiplication using a sequencer and controllable maximum output frequency. Make up to 65,000 output pulses out of a single input pulse.

  • Trigger pulse queue for buffering up to 2000 pulses and control the output using a maximum frequency valve.

  • Four pulse form generators for individual controlling of pulse widths, delays and output downscaling.

  • Up to 10 outputs depending on the grabber type plus the CoaXPress trigger outputs.

  • A bypass option to keep the pulse forms of the input signals and forward them to outputs and cameras.

  • Event generation for input and output monitoring by application software.

  • Trigger state events for fill level monitoring, trigger busy states and lost trigger signals give full control of the system.

  • Camera frame loss notification .

  • Full trigger signal reliability and easy error detections.

The trigger system is controlled and configured using parameters. Several read only parameters return status information on the current trigger state. Moreover, the trigger system is capable of generating events for efficient monitoring and controlling of the trigger system, the software, the frame grabber and external hardware.

The complex trigger system can be easily used and parameterized. The following block diagram figure shows an overview of the trigger system. As can be seen, the trigger system consists of four different main functional blocks.


  1. Trigger Input:

    Trigger inputs can be external signals, as well as software generated inputs and the frequency generator. An input monitoring and input statistics module allows analysis if the input signals.

    External input signals are debounced and split into several paths for monitoring, and further processing.


  2. Input Pulse Processing:

    The second main block of the trigger system is the Input Pulse Processing. External inputs as well as software trigger generated pulses can be queued and multiplied in a sequencer if desired. All external trigger pulses are processed in a maximum frequency valve. Pulses are only processed by this valve if their frequency is higher than the previously parameterized limit. If a higher frequency is present at the input, pulses will be rejected or the trigger pulse queue is filled if activated. The maximum frequency valve ensures that the output-pulses will not exceed the maximum possible frequency which can be processed by the camera.


  3. Output Pulse Form Generators:

    After the input pulses have been processed, they are feed into four optional pulse form generators. These pulse form generators define the signal width, a delay and a possible downscale. The four pulse form generators can arbitrarily allocated to the outputs which makes the trigger system capable for numerous applications such as muliple flash light control, varying camera exposure times etc.


  4. Trigger Output:

    The last block is related to the trigger outputs. The pulse form generator signals can be output at the digital outputs and directly to the camera. Moreover, they can be monitored using registers and events.


In programming or runtime environments, a callback function is a piece of executable code that is passed as an argument, which is expected to call back (execute) exactly that time an event is triggered.

For a general explanation on events see Event.

In the following, a list of all events of the trigger system is presented. Detailed explanations can be found in the respective module descriptions. The events are available for all cameras. Replace CAM0 by the respective camera index if necessary.

In the following, trigger sample scenarios are presented. These scenarios will help you to use the trigger system and facilitate easy adaptation to own requirements.

The scenarios show real life configurations. They explain the requirements, illustrate the inputs and outputs and list the required parameters and their values.

Let's start the trigger system examples with a simple scenario. In this case we simply want to control the frequency of the camera's image output and the exposure time with the frame grabber. Assume that there is no additional external source for trigger events and we do not need to control any flash lights. Thus the frame grabber's trigger system has to control the frequency of the trigger pulses and the exposure time.

Figure 7.7 shows the hardware setup. Only the camera connected to the frame grabber is required.


To put this scenario into practice, you will need to set your camera into an external trigger mode. Consult the vendor's user manual for more information. CXP cameras are configured using GenICam. Use the Silicon Software GenICam explorer to set the camera into external trigger mode.

After the camera is set to an external trigger mode, the exposure period and the exposure time can be controlled by one of the camera control inputs. Use the CXP cable as trigger source. The names of the camera trigger modes vary. You will need to use an external trigger mode, where the exposure period is programmable. If you also want to define the exposure time using the frame grabber, the respective trigger mode needs to support this, too.

In the following, a waveform is shown which illustrates the frame grabber trigger output. Most cameras will start the acquisition on the rising or falling edge of the signal. The exposure time is defined by the length of the signal. Note that some cameras use inverted inputs. In this case, the signal has to be 'low active' instead of being 'high active'. Thus the frame grabber output has to be inverted which is explained later on.


After hardware setup and camera configuration we can start parameterizing the frame grabber's trigger system. Parameters can be changed in your own application, in microDisplay or by editing a microEnable Configuration File (mcf). For more information on how to parameterize applets, please consult the Silicon Software runtime documentation.

In the following, all required parameters and their values are listed.

Now, the trigger is fully configured. However the trigger signal generation is not started yet. Set parameter FG_TRIGGERSTATE to TS_ACTIVE to start the system. Of course, you will also need to start your image acquisition. It is up to you if you like to start the trigger generation prior or after the acquisition has been started. If the trigger system is started first, the camera will already send images to the frame grabber. These images are discarded as no acquisition is started.

You will now receive images from your camera. Change the frequency and the signal width to see the influence of these parameters. A higher frequency will give you a higher frame rater. A shorter exposure time will make the images 'darker'. You will realize, that it is not possible to set an exposure time which is longer than the exposure period. In this case, writing to the parameter will result in an error. Therefore, the order of changing parameter values might be of importance. Also be careful to not select a frequency or exposure time which exceeds the camera's specifications. In this cases you will loose trigger pulses, as the camera cannot progress them. Get the maximum ranges from the camera's specification sheets.

To stop the trigger pulse generation, set parameter FG_TRIGGERSTATE to TS_SYNC_STOP. The trigger system will then finalize the current pulse and stop any further output until the system is activated again. The asynchronous stop mode is not required in this scenario.

In the previous example we used an internal frequency generator to control the camera's exposure. In this scenario, an external source will define the exact moment of exposure. This can be, for example, a light barrier as illustrated in the following figure. Objects move in front of the camera, a light barrier will define the moment, when an object is located directly under the camera. In practice, it might not be possible to locate the light barrier and the camera at the exact position. Therefore, a delay is required which delays the pulses from the light barrier before using them to trigger the camera. Moreover, in our scenario, we assume that a flash light has to be controlled by the trigger system, too.


An exemplary waveform (Figure 7.10) provides information on the input signal and shows the desired output signals. The input is shown on top. As you can see, the falling edge of the signal defines the moment which is used for trigger generation. Thus, the signal is 'low active'. Mind that the pulse length of any external input is ignored (second row), only falling edges are considered.

The output to the camera is shown in the third row. Here we can see an inserted delay. This delay will compensate the positions of the light barrier and the camera. The signal width at the trigger camera output defines the exposure time, if the camera is configured to the respective trigger mode. Control of the flash light is done using trigger output 0. Again, a delay is added. Depending on the requirements of the flash light, this delay has to be shorter or longer than the trigger camera output delay. Similarly, the required pulse length varies for different hardware.


Before parameterizing the applet, ensure that your camera has been set to an external trigger mode. Check the previous trigger scenario for more explanations.

In this example, we have to parameterize the trigger mode, the input source and we have to configure two trigger outputs.

The trigger is now fully configured. Just as described in the previous scenario, you can now start the acquisition and activate the trigger system using parameter FG_TRIGGERSTATE.

You will now receive images from the camera for each external trigger pulse. Compare the number of external pulses with the generated trigger signals and the received images for verification. Use parameter FG_TRIGGERIN_STATS_PULSECOUNT of category Trigger Input -> Input Statistics and parameter FG_TRIGGEROUT_STATS_PULSECOUNT of the output statistics parameters to get the number of input pulses and generated pulses. You can compare these values with the received image numbers.

This scenario is similar to the previous one. We use an external trigger to control the camera and a flash light. But in difference, we want to get three images from one external trigger pulse. Each image out of the sequence of three images has to use a different light source. Thus, in this scenario we will learn on how to use a trigger pulse multiplication and on how to control three lights connected to the grabber.

The application idea behind this scenario is that an object is acquired using different light sources. This could result in a HDR image or switching between normal and infrared illumination. The following figure illustrates the hardware setup. As you can see, we have three light sources this time. The objects move in front of the camera. The light barrier will provide the information on when to trigger the camera. Let's suppose that the objects stop in front of the camera or the movement is slow enough to generate three images with the different illuminations.


Before looking at the waveform, let's have a look at our fictitious hardware specifications.


The object speed is 100 objects per second. The minimum camera exposure time is 50Ás at a minimum camera frame period of 70Ás. Thus we only need 210Ás to acquire the three images. The following waveform shows the input and output signals, as well as the multiplied input signals. The first row shows the input. Each falling edge represents the light barrier event as marked in the second row. The third row shows the multiplied input pulses with a gap of 70Ás between the pulses. The trigger signal is generated for each of these pulses, however the trigger flash outputs 0, 1 and 2 are downscaled by three and a delay is added.


Parameterization is similar to the previous example. In contrast, this time, we have to set the trigger pulse sequencer using a multiplication factor and we have to use all four pulse form generators.

Start the trigger system using parameter FG_TRIGGERSTATE as usual. You will notice that you get thrice the number of images from the frame grabber than external trigger pulses have been generated by the light barrier. Equally to the previous example, check for exceeding line periods at the input when you run your application or ensure that your external hardware will not generate the input pulses with an exceeding frequency.

Keep in mind to start the acquisition before activating the trigger system. This is because you will receive three images for one external trigger pulse. If you start the acquisition after the trigger system, you cannot ensure that the first transfered image is the first image out of a sequence.

The previous examples showed the use of the internal frequency generator and the use of external trigger pulses to trigger your camera and generate digital output signals. Another trigger mode is the software trigger. In this mode, you can control the generation of each trigger pulse using your software application. To use the software triggered mode, set parameter FG_AREATRIGGERMODE to ATM_SOFTWARE. Next, configure the pulse form generators and the outputs as usual and start the trigger system (set FG_TRIGGERSTATE to TS_ACTIVE) and the acquisition. Now, you can generate a trigger pulse by writing value '1' to parameter FG_SENDSOFTWARETRIGGER i.e. each time you write to this parameter, a trigger pulse is generated. The relevant blocks of the trigger system are illustrated in the following figure.

Keep in mind that the time between two pulses has to be larger than 1 / FG_TRIGGER_FRAMESPERSECOND as this will limit the maximum trigger frequency. The trigger system offers the possibility to check if a new software trigger pulse can be accepted i.e. the trigger system is not busy anymore. Read parameter FG_SOFTWARETRIGGER_IS_BUSY to check it's state. While the parameter has value IS_BUSY, writing to parameter FG_SENDSOFTWARETRIGGER is not allowed and will be ignored. You should always check if the system is not busy before writing a pulse. To check if you lost a pulse, read parameter FG_TRIGGER_EXCEEDED_PERIOD_LIMITS.

In some cases, you might want to generate a sequence of pulses for each software trigger. To do this, simply set parameter FG_TRIGGER_MULTIPLY_PULSES to the desired sequence length. Now, for every software trigger pulse written to the trigger system, a sequence of the define length with a frequency defined by parameter FG_TRIGGER_FRAMESPERSECOND is generated. Again, the system cannot accept further inputs while a sequence is being processed.

Let's have a look at some flow chart examples on how to use the trigger system in software triggered mode. The flow charts visualize the steps of a fictitious user software implementation. In the first example, we simply generate single software trigger pulses using parameter FG_SENDSOFTWARETRIGGER. When the applet receives this pulse, it will trigger the camera. The camera will send an image to the frame grabber which will be processed there and will be output to the PC via DMA transfer. In the meantime, the users software application will wait for any DMA transfers. After the application got the notification that a new image has been fully tranferred to the PC it will send a new software trigger pulse and the frame grabber and camera will start again generating an image. Our software application will now have the time to process the previously received image until it is waiting for a new transfer. Thus, the software can process images while image generation is in progress. Of course, you can first process your images and afterwards generate a new trigger pulse, as well. So the steps for a repeating sequence are: Generate a SW trigger pulse, wait for image, generate a SW trigger pulse, wait for image. The flowchart of this example can be found in the following figure.


In the sample application shown above, it is ensured that the trigger system is not busy after you received the image. Therefore, we do not need to check for the software trigger busy flag in this example. One drawback of the example is that we might not acquire the frames at the maximum speed. This is because we have to wait for the full transfer of images before generating a new trigger pulse. Cameras can accept new trigger pulses while they transfer image data. The next example will therefore use the trigger sequencer.

The next example uses two threads. One thread for trigger generation and one thread for image acquisition and processing. In comparison to the previous example, we use the trigger sequencer for pulse multiplication and we will have to use the busy flag. This will allow an acquisition at a higher frame rate.


The main thread will configure and start the trigger system and the acquisition. For each software trigger pulse we send to the frame grabber, 1000 pulses are generated and send to the camera at the framerate specified by FG_TRIGGER_FRAMESPERSECOND. After sending a software trigger pulse to the frame grabber we wait until the software is not busy anymore by polling on register FG_SOFTWARETRIGGER_IS_BUSY. To control the number of generated trigger pulses we count each successful sequence generation. If more images are required we can send another software trigger pulse to the frame grabber to start a new sequence.

The second thread is used for image acquisition and image data processing. Here, the software will wait for new incoming images (Use function Fg_getLastPicNumberBlockingEx() for example) and process the received images. The thread can exit if the desired number of images have been acquired and processed.

To understand the following scenario you should have read the previous scenario first. In the following we will have a look at the software trigger once again. This time, we use the trigger queue. The trigger queue enables the buffering of trigger pulses from external sources or from the software trigger and will output these pulses at the maximum allowed frequency specified by FG_TRIGGER_FRAMESPERSECOND. Therefore, we can write to FG_SENDSOFTWARETRIGGER multiple times even if the trigger system is still busy. Parameter FG_SOFTWARETRIGGER_IS_BUSY will only have value IS_BUSY if the queue is full. Instead of writing multiple times to FG_SENDSOFTWARETRIGGER you can directly write the number of required pulses to the parameter.

The trigger queue can buffer 2040 sequence pulses. Thus if you have a certain sequence length of N pulses and currently 200 pulses in the queue, the trigger system can store additional 1840 remaining pulses. You can check the fill level by reading parameter FG_TRIGGERQUEUE_FILLLEVEL.

In the following flow chart you can see a queue fill level minimum limit of 10 pulses. In our supposed application we will check the queue fill level and compare it with our limit. If less pulses are in the queue, we generate a new software trigger pulse. Thus, on startup, the queue will fill-up until it contains 10 pulses. We count the software trigger pulses send to the trigger system. Multiplied with our sequence length, we can obtain the number of pulses which will be send to the camera. If enough pulses have been generated, we can stop the trigger pulse generation.


When having a look at the waveform (Figure 7.16) we can see the initialization phase where the queue is filled. After fill level value 10 has been reached, no more software trigger pulses are written to the applet. The system will now continue the output of trigger pulses. As our sequence length is 1000 pulses we have to wait for 1000 pulses to be generated until a change in the fill level will occur. After the 1000th pulse has been completely generated, the fill level will change to 9. This will cause the generation of another software trigger pulse by our sample application which will cause a fill level of 10 again.


When using the trigger queue, the stopping of the trigger system is of interest. If you set parameter FG_TRIGGERSTATE to TS_SYNC_STOP, the trigger system will stop accepting inputs such as software trigger pulses, but it will complete the trigger pulse generation until the queue is empty and all pulses are fully output. You can immediately cancel the pulse generation by setting the FG_TRIGGERSTATE to TS_ASYNC_STOP.

Of course, we can use the trigger queue with external triggers, too. This will give us a possibility to buffer 'jumpy' external encoders or any other external trigger signal generators. Let's suppose an external encoder which is configured to generate trigger pulses with a frequency of 50Hz and a camera which can be run at a maximum frequency of 52Hz. Thus, we set parameter FG_TRIGGER_FRAMESPERSECOND to 52Hz. Now assume that the external hardware is a little 'jumpy' and the 50Hz is just an average. So if we have inputs with a frequency higher than 52Hz we will loose at least one pulse. You can check this using the trigger lost events or by reading parameter FG_TRIGGER_EXCEEDED_PERIOD_LIMITS.

Now let's have a look at the same scenario if the queue is enabled. If it is enabled, we can buffer trigger pulses. Thus, we can buffer the exceeding input frequency and output the pulses at the maximum camera trigger frequency which is 52Hz in our example. After the input frequency is reduced, the queue will get empty and the pulse output is synchronous to the input again. Note that the delay might result in images with wrong content such as 'shifted' object positions.

To enable the queue, just write value FG_ON to FG_TRIGGERQUEUE_MODE.

The following waveform illustrates the input signal, the queue fill level and the output signal. At the beginning, the gap between the first two input signals is 20ms i.e. the frequency is less than 52Hz. Thus, the queue will not fill with pulses and the trigger system will directly output the second pulse. Now, the gap between the second and the third as well as the fourth pulse is less than 19.2ms and therefore, the trigger system will delay the output of these pulses to have a minimum gap of 19.2ms. During this period, the queue fill level will increment to value 1 for short periods. The gap between the fourth and the following input pulses is sufficiently long enough, however, the system will have to delay these pulses, too.


Note that the trigger lost event and FG_TRIGGER_EXCEEDED_PERIOD_LIMITS will only be set if the queue is full i.e. in overflow condition.

A basic application is that multiple cameras at one or more frame grabbers are connected to the same trigger source. If all cameras have to acquire images for every trigger pulse. Simply connect the trigger source to all frame grabbers and set the same trigger configuration for all cameras. This applets supports up to 4 cameras. Set the same parameters for all cameras. Multiple trigger systems are allowed to share the same trigger input, so you do not have to connect your trigger source to 4 inputs.

If you do not have an external trigger source, but use the generator or the software trigger you can synchronize the triggers to ensure camera exposures at the same moment. Simply output the camera control signal on a digital trigger output and connect this output to a digital input of other frame grabbers which have to be synchronized with the master. In the slave applets bypass the input to the camera control (CC) outputs. In addition to that, this applet supports up to 4 cameras and includes a special trigger mode called SYNCHRONIZED. This mode can be chosen for all camera ports except the first one. The "slave" cameras use trigger pulses at the output of the first camera as input source. However, users will still have to configure the pulse form generators in the trigger system of the slave cameras and will still have to allocate them to the trigger outputs.

[Tip]Arbitrary Output Allocation

In multiple camera applets you can also select another camera trigger module source. For example, CXP trigger source for camera 1 can use CAM_A_PULSEGEN0.

The Silicon Software trigger system includes powerful monitoring possibilities. They allow a convenient and efficient system analysis and will help you to detect errors in your hardware setup and wrong parameterizations.

Let's have a look at the simple external trigger example once again. Assume that you have set up all devices and have fully configured the applet. You start the system and receive images. Unfortunately, the number of acquired images or the framerate is not as expected. This means, at some point trigger signals or frames got lost. To analyze the error, let's have a look at the monitoring applet registers.

  • Trigger Input Statistics

    The parameters of the trigger input statistics category allow an analysis of the external trigger pulses. Parameter FG_TRIGGERIN_STATS_FREQUENCY performs a continuous frequency measurement of the input signals. Compare this value with the expected trigger input frequency. If the measured frequency is much higher or lower than the expected frequency, check your external hardware. Also check if the correct trigger input has been chosen by parameter FG_TRIGGERIN_SRC and if the pulse width of the input is long enough to be detected by the hardware.

    To validate a constant input frequency, the trigger system will also show the maximum and minimum detected frequencies using parameters FG_TRIGGERIN_STATS_MAXFREQUENCY and FG_TRIGGERIN_STATS_MINFREQUENCY. On startup, you will have a very low frequency as no external pulses might have been detected so far. Therefore, you have to clear the measurement using parameter FG_TRIGGERIN_STATS_MINMAXFREQUENCY_CLEAR first. If you detect an unwanted deviation from the expected values or the difference between the minimum and maximum frequency is comparably high, your external trigger generating hardware might be 'jumpy', skips pulses or is 'bouncing' which causes pulse multiplication. In this case, you might be able to compensate the problem using a higher debouncing value, set a lower maximum allowed frequency (see Section 7.4.2, 'External Trigger Signals / IO Triggered') or use the trigger queue (see Section 7.4.6, 'External Trigger with Trigger Queue').

    Another feature of the input statistics module is the pulse counting. This feature can be used to compare the number of input pulses with the output pulses and acquired images. Read the pulse count value from parameter FG_TRIGGERIN_STATS_PULSECOUNT. To ensure a synchronized counting of the input and any output pulses and images you should clear the pulse counter before generating external trigger inputs.

  • Trigger Output Statistics

    A pulse counter is connected to the trigger output, too. Here you can select one of the pulse form generators using parameter FG_TRIGGEROUT_STATS_SOURCE and read the value with parameter FG_TRIGGEROUT_STATS_PULSECOUNT. Reset the pulse counter using FG_TRIGGEROUT_STATS_PULSECOUNT_CLEAR.

    Use the pulse count value to compare it with the input pulse counter. If the values vary, pulses in the frame grabber have been discarded. This can happen if the input frequency is higher than the maximum allowed frequency specified by parameter FG_TRIGGER_FRAMESPERSECOND. If this happens, flag FG_TRIGGER_EXCEEDED_PERIOD_LIMITS will be set. Moreover, if the pulse counter values dramatically differ, ensure that no trigger multiplication and/or downscaling has been set. Check parameters FG_TRIGGERIN_DOWNSCALE, FG_TRIGGER_MULTIPLY_PULSES and the downscale parameters of the pulse form generators.

    It is also possible to count the input and output pulses with the input events and the output event FG_TRIGGER_OUTPUT_CAM0.

  • Camera Response Check

    Trigger pulses might get lost in the link to the camera or the trigger frequency is to high to be processed by the camera. In this case, the number of frames received by the frame grabber differs from the trigger pulses sent. For this error, the trigger system includes the missing camera frame response detection module. The module can detect missing frames and generate an event for each lost frame or set a register. Check Section 7.5.12.3, 'Statistics' for more information and usage.

  • Acquired Image Compare

    Of course, it is also possible to count the number of acquired images i.e. the number of DMA transfers and compare them with the generated trigger pulses. If the values differ, you might have lost trigger pulses in the camera. In this case, check that the trigger frequency is not to high for the camera. Ensure that you do not run the applet in overflow state, where images can get lost in the applet. If the applet is run in overflow, check the maximum bandwidths of the applet. A smaller region of interest might solve the problems.

For every monitoring values, check the maximum and minimum ranges of the parameters. If pulse counters reached their maximum value, they will reset and start from zero.

The area trigger system of this AcquisitionApplets applet can be run in three different operation modes.

[Important]Free-Run Mode

If you like to use your camera in free run mode you can use any of the modes described above. The camera will ignore all trigger pulses or, if required, you can disable the output or deactivate the trigger using parameter FG_TRIGGERSTATE.

[Important]Allowed Frequencies

Mind the influence of parameter FG_TRIGGER_FRAMESPERSECOND in external and software triggered mode. Always set this parameter for these modes.



The area trigger system is operating in three trigger states. In the 'Active' state, the module is fully enabled. Trigger sources are used, pulses are queued, downscaled, multiplied and the output signals get their parameterized pulse forms. If the trigger is set into the 'Sync Stop' mode, the module will ignore further input pulses or stop the generation of pulses. However, the module will still process the pulses in the system. This means, a filled queue and the sequencer will continue processing the pulses and furthermore, the pulse form generators will output the signals according to the parameterized parameters. Finally, the 'Async Stop' mode asynchronously and immediately stops the full trigger system for the respective camera process. Note that this stop might result in output signals of undefined signal length as a current signal generation could be interrupted. Also note that a restart of a previously stopped trigger i.e. switching to the 'Active' state will clear the queue and the sequencer.



This is a very important parameter of the trigger system. It is used for multiple functionalities.

If you run the trigger system in 'Generator' mode, this parameter will define the frequency of the generator. If you run the trigger system in 'External' or 'Software Trigger' operation mode, this parameter will specify the maximum allowed input frequency. Input frequencies which exceed this limit will cause the loss of the input pulse. To notify the user of this error, a read register contains an error flag or an event is generated. However, if the trigger queue is enabled, the exceeding pulses will be buffered and output at the maximum frequency which is defined by FG_TRIGGER_FRAMESPERSECOND. Thus, the parameter also defines the maximum queue output frequency. Moreover, it defines the maximum sequencer frequency. The maximum valid value of FG_TRIGGER_FRAMESPERSECOND is limited by FG_CAMERASIMULATOR_FRAMERATE in camera simulator mode.

Note that the range of this parameter depends on the settings in the pulse form generators. If you want to increase the frequency you might need to decrease the width or delay of one of the pulse form generators.


Read the general trigger system explanations and the respective parameter explanations for more information.



The parameters of category Trigger Input are used to configure the input source of the trigger system. The category is divided into sub categories. All external sources are configured in category external. Category software trigger allows the configuration, monitoring and controlling of software trigger pulses. In category statistics the parameters for input statistics are present.

In general, a perfect and steady trigger input signal can not be guaranteed in practice. A transfer using long cable connections and the operation in bad shielded environments might have a distinct influence on the signal quality. Typical problems are strong flattening of the digital's signal edges, occurring interferences during toggling and inducing of short jamming pulses (spikes). In the following figure, some of the influences are illustrated.


The trigger system has been designed to work highly reliable even under problematic signal conditions. An internal debouncing of the inputs will eliminate unwanted trigger pulses. It is comparable to a hysteresis. Only signal changes which are constant for a specified time (marked 'L' in the figure) are accepted which makes the input insensitive to jamming pulses. Also multiple triggering will be effectively disabled, which occurs by slow signal transfers and bouncing. Set the debounce time according to your requirements in Ás. Note that the debounce time will also be the delay time before the trigger signal can be processed. The settings made for this parameter affect all digital inputs. The parameter is camera process independent i.e. the latest settings will apply for all camera inputs.



If the trigger system is run in software triggered mode (see parameter FG_AREATRIGGERMODE), this parameter is activated. Write value '1' to this parameter to input a software trigger. If the trigger queue is activated multiple software trigger pulses can be written to the frame grabber. They will fill the queue and being processed with the maximum allowed frequency parameterized by FG_TRIGGER_FRAMESPERSECOND.

Note that software trigger pulses can only be written if the trigger system has been activated using parameter FG_TRIGGERSTATE. Moreover, if the queue has not been activated, new software trigger pulses can only be written if the trigger system is not busy. Therefore, writing to the parameter can cause an FG_SOFTWARE_TRIGGER_BUSY error.



The trigger input statistics module will offer you frequency analysis and pulse counting of the selected input. The digital input for the statistics is selected by FG_TRIGGERIN_POLARITY. Measurements are performed after debouncing and polarity selection but before downscaling.

The statistics section also includes a list of digital input events.

The sequencer is a powerful feature to generate multiple pulses out of one input pulse. It is available in external and software trigger mode, but not in generator mode. The sequencer multiplies an input pulse using the factor set by FG_TRIGGER_MULTIPLY_PULSES. The inserted pulses will have a time delay to the original signal according to the setting made for parameter FG_TRIGGER_FRAMESPERSECOND. Thus, the inserted pulses are not evenly distributed between the input pulses, they will be inserted with a delay specified by FG_TRIGGER_FRAMESPERSECOND. Hence, it is very important, that the multiplicate pulses with a parameterized delay will not cause a loss of input signals.

Let's have a look at an example. Suppose you have an external trigger source generating a pulse once every second. Your input frequency will then be 1Hz. Assume that the sequencer is set to a multiplication factor of 2 and the maximum frequency defined by FG_TRIGGER_FRAMESPERSECOND is set to 2.1Hz.

The trigger system will forward each external pulse into the trigger system and will also generate a second pulse 0.48 seconds later. As you can see, the multiplication frequency is chosen to be slightly higher than the doubled input frequency. This will allow the compensation of varying input frequencies. If the time between two pulses at the input will be less than 0.96 seconds, you will loose the second pulse. Silicon Software recommends the multiplication frequency to be fast enough to not loose pulses or recommends the activation of the trigger queue for compensation. You can check for lost pulses with parameter FG_TRIGGER_EXCEEDED_PERIOD_LIMITS.

The maximum trigger output frequency is limited to the the setting of parameter FG_TRIGGER_FRAMESPERSECOND. This can avoid the loss of trigger pulses in the camera which is hard to detect. In some cases it is possible, that the frequency of your external trigger source varies. To prevent the loose of trigger pulses, you can activate the trigger queue to buffer these pulses. Furthermore, the queue can be used to buffer trigger input pulses if you use the sequencer and the software trigger.

Activate the trigger queue using parameter FG_TRIGGERQUEUE_MODE.

The queue fill level can be monitored by parameter FG_TRIGGERQUEUE_FILLLEVEL. Moreover, two events allow the monitoring of the fill level. Using parameters FG_TRIGGER_QUEUE_FILLLEVEL_EVENT_ON_THRESHOLD and FG_TRIGGER_QUEUE_FILLLEVEL_EVENT_OFF_THRESHOLD it is possible to set two threshold. If the fill level exceeds the ON-threshold the respective event FG_TRIGGER_QUEUE_FILLLEVEL_THRESHOLD_CAM0_ON is generated. If the fill level gets less or equal than the OFF-threshold the event FG_TRIGGER_QUEUE_FILLLEVEL_THRESHOLD_CAM0_OFF is generated.

Note that a fill level value n indicates that between n and ná+á1 trigger pulses have to be processed by the system. Therefore, a fill level value zero means that no more values are in the queue, but there might be still a pulse (or multiple pulses if the sequencer is used) to be processed. There exists one exception for value zero obtained with FG_TRIGGERQUEUE_FILLLEVEL i.e. the parameter and not the events. This value at this parameter truly indicates that no more pulses are in the queue and all pulses have been full processed.

The parameters explained previously were used to generate the trigger pulses. Next, we will need to prepare the pulses for the outputs. The area trigger system includes four individual pulse form generators. These generators define the width and delay of the output signals and also support downscaling of pulses which can be useful if different light sources are used successively. After parameterizing the pulse form generators you can arbitrarily allocate the pulse form generators to the outputs.

The following figure illustrates the output of the pulse form generators and the parameters.


Once again, note that the ranges of the parameters depend on the other settings in the pulse form generators and on paramerter FG_TRIGGER_FRAMESPERSECOND. If you want to increase the frequency you might need to decrease the width or delay of one of the pulse form generators.


[Note]Note

This description applies also to the following parameters: FG_TRIGGER_PULSEFORMGEN1_DOWNSCALE_PHASE, FG_TRIGGER_PULSEFORMGEN2_DOWNSCALE_PHASE, FG_TRIGGER_PULSEFORMGEN3_DOWNSCALE_PHASE

The parameter FG_TRIGGER_PULSEFORMGEN[0..3]_DOWNSCALE defines the number of phases and parameter FG_TRIGGER_PULSEFORMGEN[0..3]_DOWNSCALE_PHASE selects the one being used. The downscale value represents the factor. For example value three will remove two out of three successive trigger pulses. The phase is used to make the selection of the pulse in the sequence. For the given example, a phase set to value zero will forward the first pulse and will remove pulses two and three of a sequence of three pulses. Check Section 7.5.7, 'Pulse Form Generator 0' for more information.

Take care of the dependency between the downscale factor and the phase. The factor has to be greater than the phase.



The camera interface of the microEnable 5 marathon ACX QP is equipped with a trigger output channel to trigger the camera. Moreover, 8 general purpose outputs to the camera exist. Please, consult the vendor's manual of your camera to identify the required signals and their mapping.

The trigger system of this AcquisitionApplets provides several possibilities of mapping pulse sources to the camera channels:

  • Pulse form generators 0 to 3

    The pulse form generators are the main output sources of the trigger system. You can either directly connect one of the four sources to a camera signal channel or invert the signal if you need low active signals.

  • Ground or Vcc if a CC line is not used or you want to temporarily deactivate or activate the line.

  • The input bypass

    The trigger system will ignore the signal length of the input signals. If you want to directly bypass one of the inputs to a camera signal channel, you can set the respective channel to bypass or the inverted bypass.

Table 7.32. Parameter properties of FG_TRIGGERCAMERA_OUT_SELECT

PropertyValue
NameFG_TRIGGERCAMERA_OUT_SELECT
TypeEnumeration
Access policyRead/Write/Change
Storage policyPersistent
Allowed values
VCC
Vcc
GND
Gnd
CAM_A_PULSEGEN0
Cam A Pulse Generator 0
CAM_A_PULSEGEN1
Cam A Pulse Generator 1
CAM_A_PULSEGEN2
Cam A Pulse Generator 2
CAM_A_PULSEGEN3
Cam A Pulse Generator 3
CAM_A_NOT_PULSEGEN0
Not Cam A Pulse Generator 0
CAM_A_NOT_PULSEGEN1
Not Cam A Pulse Generator 1
CAM_A_NOT_PULSEGEN2
Not Cam A Pulse Generator 2
CAM_A_NOT_PULSEGEN3
Not Cam A Pulse Generator 3
CAM_B_PULSEGEN0
Cam B Pulse Generator 0
CAM_B_PULSEGEN1
Cam B Pulse Generator 1
CAM_B_PULSEGEN2
Cam B Pulse Generator 2
CAM_B_PULSEGEN3
Cam B Pulse Generator 3
CAM_B_NOT_PULSEGEN0
Not Cam B Pulse Generator 0
CAM_B_NOT_PULSEGEN1
Not Cam B Pulse Generator 1
CAM_B_NOT_PULSEGEN2
Not Cam B Pulse Generator 2
CAM_B_NOT_PULSEGEN3
Not Cam B Pulse Generator 3
CAM_C_PULSEGEN0
Cam C Pulse Generator 0
CAM_C_PULSEGEN1
Cam C Pulse Generator 1
CAM_C_PULSEGEN2
Cam C Pulse Generator 2
CAM_C_PULSEGEN3
Cam C Pulse Generator 3
CAM_C_NOT_PULSEGEN0
Not Cam C Pulse Generator 0
CAM_C_NOT_PULSEGEN1
Not Cam C Pulse Generator 1
CAM_C_NOT_PULSEGEN2
Not Cam C Pulse Generator 2
CAM_C_NOT_PULSEGEN3
Not Cam C Pulse Generator 3
CAM_D_PULSEGEN0
Cam D Pulse Generator 0
CAM_D_PULSEGEN1
Cam D Pulse Generator 1
CAM_D_PULSEGEN2
Cam D Pulse Generator 2
CAM_D_PULSEGEN3
Cam D Pulse Generator 3
CAM_D_NOT_PULSEGEN0
Not Cam D Pulse Generator 0
CAM_D_NOT_PULSEGEN1
Not Cam D Pulse Generator 1
CAM_D_NOT_PULSEGEN2
Not Cam D Pulse Generator 2
CAM_D_NOT_PULSEGEN3
Not Cam D Pulse Generator 3
BYPASS_GPI_0
Bypass GPI 0
NOT_BYPASS_GPI_0
Not Bypass GPI 0
BYPASS_GPI_1
Bypass GPI 1
NOT_BYPASS_GPI_1
Not Bypass GPI 1
BYPASS_GPI_2
Bypass GPI 2
NOT_BYPASS_GPI_2
Not Bypass GPI 2
BYPASS_GPI_3
Bypass GPI 3
NOT_BYPASS_GPI_3
Not Bypass GPI 3
BYPASS_GPI_4
Bypass GPI 4 (not available on LightBridge)
NOT_BYPASS_GPI_4
Not Bypass GPI 4 (not available on LightBridge)
BYPASS_GPI_5
Bypass GPI 5 (not available on LightBridge)
NOT_BYPASS_GPI_5
Not Bypass GPI 5 (not available on LightBridge)
BYPASS_GPI_6
Bypass GPI 6 (not available on LightBridge)
NOT_BYPASS_GPI_6
Not Bypass GPI 6 (not available on LightBridge)
BYPASS_GPI_7
Bypass GPI 7 (not available on LightBridge)
NOT_BYPASS_GPI_7
Not Bypass GPI 7 (not available on LightBridge)
BYPASS_FRONT_GPI_0
Bypass Front-GPI 0
NOT_BYPASS_FRONT_GPI_0
Not Bypass Front-GPI 0
BYPASS_FRONT_GPI_1
Bypass Front-GPI 1
NOT_BYPASS_FRONT_GPI_1
Not Bypass Front-GPI 1
BYPASS_FRONT_GPI_2
Bypass Front-GPI 2
NOT_BYPASS_FRONT_GPI_2
Not Bypass Front-GPI 2
BYPASS_FRONT_GPI_3
Bypass Front-GPI 3
NOT_BYPASS_FRONT_GPI_3
Not Bypass Front-GPI 3
PULSEGEN0
Pulse Generator 0
PULSEGEN1
Pulse Generator 1
PULSEGEN2
Pulse Generator 2
PULSEGEN3
Pulse Generator 3
NOT_PULSEGEN0
Not Pulse Generator 0
NOT_PULSEGEN1
Not Pulse Generator 1
NOT_PULSEGEN2
Not Pulse Generator 2
NOT_PULSEGEN3
Not Pulse Generator 3
Default valuePULSEGEN0


[Note]Note

This description applies also to the following parameters: FG_TRIGGERCAMERA_GPO1, FG_TRIGGERCAMERA_GPO2, FG_TRIGGERCAMERA_GPO3, FG_TRIGGERCAMERA_GPO4, FG_TRIGGERCAMERA_GPO5, FG_TRIGGERCAMERA_GPO6, FG_TRIGGERCAMERA_GPO7

Table 7.33. Parameter properties of FG_TRIGGERCAMERA_GPO0

PropertyValue
NameFG_TRIGGERCAMERA_GPO0
TypeEnumeration
Access policyRead/Write/Change
Storage policyPersistent
Allowed values
VCC
Vcc
GND
Gnd
CAM_A_PULSEGEN0
Cam A Pulse Generator 0
CAM_A_PULSEGEN1
Cam A Pulse Generator 1
CAM_A_PULSEGEN2
Cam A Pulse Generator 2
CAM_A_PULSEGEN3
Cam A Pulse Generator 3
CAM_A_NOT_PULSEGEN0
Not Cam A Pulse Generator 0
CAM_A_NOT_PULSEGEN1
Not Cam A Pulse Generator 1
CAM_A_NOT_PULSEGEN2
Not Cam A Pulse Generator 2
CAM_A_NOT_PULSEGEN3
Not Cam A Pulse Generator 3
CAM_B_PULSEGEN0
Cam B Pulse Generator 0
CAM_B_PULSEGEN1
Cam B Pulse Generator 1
CAM_B_PULSEGEN2
Cam B Pulse Generator 2
CAM_B_PULSEGEN3
Cam B Pulse Generator 3
CAM_B_NOT_PULSEGEN0
Not Cam B Pulse Generator 0
CAM_B_NOT_PULSEGEN1
Not Cam B Pulse Generator 1
CAM_B_NOT_PULSEGEN2
Not Cam B Pulse Generator 2
CAM_B_NOT_PULSEGEN3
Not Cam B Pulse Generator 3
CAM_C_PULSEGEN0
Cam C Pulse Generator 0
CAM_C_PULSEGEN1
Cam C Pulse Generator 1
CAM_C_PULSEGEN2
Cam C Pulse Generator 2
CAM_C_PULSEGEN3
Cam C Pulse Generator 3
CAM_C_NOT_PULSEGEN0
Not Cam C Pulse Generator 0
CAM_C_NOT_PULSEGEN1
Not Cam C Pulse Generator 1
CAM_C_NOT_PULSEGEN2
Not Cam C Pulse Generator 2
CAM_C_NOT_PULSEGEN3
Not Cam C Pulse Generator 3
CAM_D_PULSEGEN0
Cam D Pulse Generator 0
CAM_D_PULSEGEN1
Cam D Pulse Generator 1
CAM_D_PULSEGEN2
Cam D Pulse Generator 2
CAM_D_PULSEGEN3
Cam D Pulse Generator 3
CAM_D_NOT_PULSEGEN0
Not Cam D Pulse Generator 0
CAM_D_NOT_PULSEGEN1
Not Cam D Pulse Generator 1
CAM_D_NOT_PULSEGEN2
Not Cam D Pulse Generator 2
CAM_D_NOT_PULSEGEN3
Not Cam D Pulse Generator 3
BYPASS_GPI_0
Bypass GPI 0
NOT_BYPASS_GPI_0
Not Bypass GPI 0
BYPASS_GPI_1
Bypass GPI 1
NOT_BYPASS_GPI_1
Not Bypass GPI 1
BYPASS_GPI_2
Bypass GPI 2
NOT_BYPASS_GPI_2
Not Bypass GPI 2
BYPASS_GPI_3
Bypass GPI 3
NOT_BYPASS_GPI_3
Not Bypass GPI 3
BYPASS_GPI_4
Bypass GPI 4 (not available on LightBridge)
NOT_BYPASS_GPI_4
Not Bypass GPI 4 (not available on LightBridge)
BYPASS_GPI_5
Bypass GPI 5 (not available on LightBridge)
NOT_BYPASS_GPI_5
Not Bypass GPI 5 (not available on LightBridge)
BYPASS_GPI_6
Bypass GPI 6 (not available on LightBridge)
NOT_BYPASS_GPI_6
Not Bypass GPI 6 (not available on LightBridge)
BYPASS_GPI_7
Bypass GPI 7 (not available on LightBridge)
NOT_BYPASS_GPI_7
Not Bypass GPI 7 (not available on LightBridge)
BYPASS_FRONT_GPI_0
Bypass Front-GPI 0
NOT_BYPASS_FRONT_GPI_0
Not Bypass Front-GPI 0
BYPASS_FRONT_GPI_1
Bypass Front-GPI 1
NOT_BYPASS_FRONT_GPI_1
Not Bypass Front-GPI 1
BYPASS_FRONT_GPI_2
Bypass Front-GPI 2
NOT_BYPASS_FRONT_GPI_2
Not Bypass Front-GPI 2
BYPASS_FRONT_GPI_3
Bypass Front-GPI 3
NOT_BYPASS_FRONT_GPI_3
Not Bypass Front-GPI 3
PULSEGEN0
Pulse Generator 0
PULSEGEN1
Pulse Generator 1
PULSEGEN2
Pulse Generator 2
PULSEGEN3
Pulse Generator 3
NOT_PULSEGEN0
Not Pulse Generator 0
NOT_PULSEGEN1
Not Pulse Generator 1
NOT_PULSEGEN2
Not Pulse Generator 2
NOT_PULSEGEN3
Not Pulse Generator 3
Default valueGND


The microEnable 5 marathon frame grabbers have eight general purpose outputs (GPOs) and in addition 2 Front GPOs.

The trigger system of this AcquisitionApplets provides several possibilities of mapping sources to the digital output signals:

  • Pulse form generators

    The pulse form generators are the main output sources of the trigger system. You can either directly bypass one of the four sources to a digital output or invert its signal. As this is a multi camera applet you can choose any of the trigger modules for each output. For example you can select Cam A pulse form generator 0 for all outputs.

  • Ground or Vcc if a digital output is not used or you want to manually set the signal level.

  • The input bypass

    The trigger system will ignore the signal length of the input signals. If you want to bypass an input directly to the output you can select the specific input or its inverted version.

[Note]Note

This description applies also to the following parameters: FG_TRIGGEROUT_SELECT_GPO_1, FG_TRIGGEROUT_SELECT_GPO_2, FG_TRIGGEROUT_SELECT_GPO_3, FG_TRIGGEROUT_SELECT_GPO_4, FG_TRIGGEROUT_SELECT_GPO_5, FG_TRIGGEROUT_SELECT_GPO_6, FG_TRIGGEROUT_SELECT_GPO_7

Select the source for the output on the respective GPO.

[Note] Using legacy values "PULSEGEN_0 to PULSEGEN_3" and "NOT_PULSEGEN_0 to NOT_PULSEGEN_3".

Note that values "PULSEGEN_0 to PULSEGEN_3" and "NOT_PULSEGEN_0 to NOT_PULSEGEN_3" are legacy parameters. If you set the parameter to one of these values the respective trigger module will be used. Reading the parameter will always include the camera index.

For example if you set FG_TRIGGEROUT_SELECT_GPO_0 for DMA index 1 to PULSEGEN_0 on a multi-cam applet you will use the trigger module of camera B. Reading the parameter results in returning CAM_B_PULSEGEN0.

Table 7.34. Parameter properties of FG_TRIGGEROUT_SELECT_GPO_0

PropertyValue
NameFG_TRIGGEROUT_SELECT_GPO_0
TypeEnumeration
Access policyRead/Write/Change
Storage policyPersistent
Allowed values
VCC
Vcc
GND
Gnd
CAM_A_PULSEGEN0
Cam A Pulse Generator 0
CAM_A_PULSEGEN1
Cam A Pulse Generator 1
CAM_A_PULSEGEN2
Cam A Pulse Generator 2
CAM_A_PULSEGEN3
Cam A Pulse Generator 3
CAM_A_NOT_PULSEGEN0
Not Cam A Pulse Generator 0
CAM_A_NOT_PULSEGEN1
Not Cam A Pulse Generator 1
CAM_A_NOT_PULSEGEN2
Not Cam A Pulse Generator 2
CAM_A_NOT_PULSEGEN3
Not Cam A Pulse Generator 3
CAM_B_PULSEGEN0
Cam B Pulse Generator 0
CAM_B_PULSEGEN1
Cam B Pulse Generator 1
CAM_B_PULSEGEN2
Cam B Pulse Generator 2
CAM_B_PULSEGEN3
Cam B Pulse Generator 3
CAM_B_NOT_PULSEGEN0
Not Cam B Pulse Generator 0
CAM_B_NOT_PULSEGEN1
Not Cam B Pulse Generator 1
CAM_B_NOT_PULSEGEN2
Not Cam B Pulse Generator 2
CAM_B_NOT_PULSEGEN3
Not Cam B Pulse Generator 3
CAM_C_PULSEGEN0
Cam C Pulse Generator 0
CAM_C_PULSEGEN1
Cam C Pulse Generator 1
CAM_C_PULSEGEN2
Cam C Pulse Generator 2
CAM_C_PULSEGEN3
Cam C Pulse Generator 3
CAM_C_NOT_PULSEGEN0
Not Cam C Pulse Generator 0
CAM_C_NOT_PULSEGEN1
Not Cam C Pulse Generator 1
CAM_C_NOT_PULSEGEN2
Not Cam C Pulse Generator 2
CAM_C_NOT_PULSEGEN3
Not Cam C Pulse Generator 3
CAM_D_PULSEGEN0
Cam D Pulse Generator 0
CAM_D_PULSEGEN1
Cam D Pulse Generator 1
CAM_D_PULSEGEN2
Cam D Pulse Generator 2
CAM_D_PULSEGEN3
Cam D Pulse Generator 3
CAM_D_NOT_PULSEGEN0
Not Cam D Pulse Generator 0
CAM_D_NOT_PULSEGEN1
Not Cam D Pulse Generator 1
CAM_D_NOT_PULSEGEN2
Not Cam D Pulse Generator 2
CAM_D_NOT_PULSEGEN3
Not Cam D Pulse Generator 3
BYPASS_GPI_0
Bypass GPI 0
NOT_BYPASS_GPI_0
Not Bypass GPI 0
BYPASS_GPI_1
Bypass GPI 1
NOT_BYPASS_GPI_1
Not Bypass GPI 1
BYPASS_GPI_2
Bypass GPI 2
NOT_BYPASS_GPI_2
Not Bypass GPI 2
BYPASS_GPI_3
Bypass GPI 3
NOT_BYPASS_GPI_3
Not Bypass GPI 3
BYPASS_GPI_4
Bypass GPI 4 (not available on LightBridge)
NOT_BYPASS_GPI_4
Not Bypass GPI 4 (not available on LightBridge)
BYPASS_GPI_5
Bypass GPI 5 (not available on LightBridge)
NOT_BYPASS_GPI_5
Not Bypass GPI 5 (not available on LightBridge)
BYPASS_GPI_6
Bypass GPI 6 (not available on LightBridge)
NOT_BYPASS_GPI_6
Not Bypass GPI 6 (not available on LightBridge)
BYPASS_GPI_7
Bypass GPI 7 (not available on LightBridge)
NOT_BYPASS_GPI_7
Not Bypass GPI 7 (not available on LightBridge)
BYPASS_FRONT_GPI_0
Bypass Front-GPI 0
NOT_BYPASS_FRONT_GPI_0
Not Bypass Front-GPI 0
BYPASS_FRONT_GPI_1
Bypass Front-GPI 1
NOT_BYPASS_FRONT_GPI_1
Not Bypass Front-GPI 1
BYPASS_FRONT_GPI_2
Bypass Front-GPI 2
NOT_BYPASS_FRONT_GPI_2
Not Bypass Front-GPI 2
BYPASS_FRONT_GPI_3
Bypass Front-GPI 3
NOT_BYPASS_FRONT_GPI_3
Not Bypass Front-GPI 3
PULSEGEN0
Pulse Generator 0
PULSEGEN1
Pulse Generator 1
PULSEGEN2
Pulse Generator 2
PULSEGEN3
Pulse Generator 3
NOT_PULSEGEN0
Not Pulse Generator 0
NOT_PULSEGEN1
Not Pulse Generator 1
NOT_PULSEGEN2
Not Pulse Generator 2
NOT_PULSEGEN3
Not Pulse Generator 3
Default valueCAM_A_NOT_PULSEGEN0


[Note]Note

This description applies also to the following parameters: FG_TRIGGEROUT_SELECT_FRONT_GPO_1

Select the source for the output on the repsective Front GPO.

[Note] Using legacy values "PULSEGEN_0 to PULSEGEN_3" and "NOT_PULSEGEN_0 to NOT_PULSEGEN_3".

Note that values "PULSEGEN_0 to PULSEGEN_3" and "NOT_PULSEGEN_0 to NOT_PULSEGEN_3" are legacy parameters. If you set the parameter to one of these values the respective trigger module will be used. Reading the parameter will always include the camera index.

For example if you set FG_TRIGGEROUT_SELECT_GPO_0 for DMA index 1 to PULSEGEN_0 on a multi-cam applet you will use the trigger module of camera B. Reading the parameter results in returning CAM_B_PULSEGEN0.

Table 7.35. Parameter properties of FG_TRIGGEROUT_SELECT_FRONT_GPO_0

PropertyValue
NameFG_TRIGGEROUT_SELECT_FRONT_GPO_0
TypeEnumeration
Access policyRead/Write/Change
Storage policyPersistent
Allowed values
VCC
Vcc
GND
Gnd
CAM_A_PULSEGEN0
Cam A Pulse Generator 0
CAM_A_PULSEGEN1
Cam A Pulse Generator 1
CAM_A_PULSEGEN2
Cam A Pulse Generator 2
CAM_A_PULSEGEN3
Cam A Pulse Generator 3
CAM_A_NOT_PULSEGEN0
Not Cam A Pulse Generator 0
CAM_A_NOT_PULSEGEN1
Not Cam A Pulse Generator 1
CAM_A_NOT_PULSEGEN2
Not Cam A Pulse Generator 2
CAM_A_NOT_PULSEGEN3
Not Cam A Pulse Generator 3
CAM_B_PULSEGEN0
Cam B Pulse Generator 0
CAM_B_PULSEGEN1
Cam B Pulse Generator 1
CAM_B_PULSEGEN2
Cam B Pulse Generator 2
CAM_B_PULSEGEN3
Cam B Pulse Generator 3
CAM_B_NOT_PULSEGEN0
Not Cam B Pulse Generator 0
CAM_B_NOT_PULSEGEN1
Not Cam B Pulse Generator 1
CAM_B_NOT_PULSEGEN2
Not Cam B Pulse Generator 2
CAM_B_NOT_PULSEGEN3
Not Cam B Pulse Generator 3
CAM_C_PULSEGEN0
Cam C Pulse Generator 0
CAM_C_PULSEGEN1
Cam C Pulse Generator 1
CAM_C_PULSEGEN2
Cam C Pulse Generator 2
CAM_C_PULSEGEN3
Cam C Pulse Generator 3
CAM_C_NOT_PULSEGEN0
Not Cam C Pulse Generator 0
CAM_C_NOT_PULSEGEN1
Not Cam C Pulse Generator 1
CAM_C_NOT_PULSEGEN2
Not Cam C Pulse Generator 2
CAM_C_NOT_PULSEGEN3
Not Cam C Pulse Generator 3
CAM_D_PULSEGEN0
Cam D Pulse Generator 0
CAM_D_PULSEGEN1
Cam D Pulse Generator 1
CAM_D_PULSEGEN2
Cam D Pulse Generator 2
CAM_D_PULSEGEN3
Cam D Pulse Generator 3
CAM_D_NOT_PULSEGEN0
Not Cam D Pulse Generator 0
CAM_D_NOT_PULSEGEN1
Not Cam D Pulse Generator 1
CAM_D_NOT_PULSEGEN2
Not Cam D Pulse Generator 2
CAM_D_NOT_PULSEGEN3
Not Cam D Pulse Generator 3
BYPASS_GPI_0
Bypass GPI 0
NOT_BYPASS_GPI_0
Not Bypass GPI 0
BYPASS_GPI_1
Bypass GPI 1
NOT_BYPASS_GPI_1
Not Bypass GPI 1
BYPASS_GPI_2
Bypass GPI 2
NOT_BYPASS_GPI_2
Not Bypass GPI 2
BYPASS_GPI_3
Bypass GPI 3
NOT_BYPASS_GPI_3
Not Bypass GPI 3
BYPASS_GPI_4
Bypass GPI 4 (not available on LightBridge)
NOT_BYPASS_GPI_4
Not Bypass GPI 4 (not available on LightBridge)
BYPASS_GPI_5
Bypass GPI 5 (not available on LightBridge)
NOT_BYPASS_GPI_5
Not Bypass GPI 5 (not available on LightBridge)
BYPASS_GPI_6
Bypass GPI 6 (not available on LightBridge)
NOT_BYPASS_GPI_6
Not Bypass GPI 6 (not available on LightBridge)
BYPASS_GPI_7
Bypass GPI 7 (not available on LightBridge)
NOT_BYPASS_GPI_7
Not Bypass GPI 7 (not available on LightBridge)
BYPASS_FRONT_GPI_0
Bypass Front-GPI 0
NOT_BYPASS_FRONT_GPI_0
Not Bypass Front-GPI 0
BYPASS_FRONT_GPI_1
Bypass Front-GPI 1
NOT_BYPASS_FRONT_GPI_1
Not Bypass Front-GPI 1
BYPASS_FRONT_GPI_2
Bypass Front-GPI 2
NOT_BYPASS_FRONT_GPI_2
Not Bypass Front-GPI 2
BYPASS_FRONT_GPI_3
Bypass Front-GPI 3
NOT_BYPASS_FRONT_GPI_3
Not Bypass Front-GPI 3
PULSEGEN0
Pulse Generator 0
PULSEGEN1
Pulse Generator 1
PULSEGEN2
Pulse Generator 2
PULSEGEN3
Pulse Generator 3
NOT_PULSEGEN0
Not Pulse Generator 0
NOT_PULSEGEN1
Not Pulse Generator 1
NOT_PULSEGEN2
Not Pulse Generator 2
NOT_PULSEGEN3
Not Pulse Generator 3
Default valueCAM_A_NOT_PULSEGEN0


The output statistics module counts the number of output pulses. The source can be selected by parameter FG_TRIGGEROUT_STATS_SOURCE. The count value can be read from parameter FG_TRIGGEROUT_STATS_PULSECOUNT. Parameter FG_TRIGGEROUT_STATS_SOURCE also selects the source for the missing frame detection functionality.

This applet is equipped with a detection of missing camera frame responses to trigger pulses. If the camera will not send a frame for each output trigger pulse, the register is set to FG_YES until cleared by writing to parameter FG_MISSING_CAMERA_FRAME_RESPONSE_CLEAR.

The idea of the frame loss detection is that for every trigger pulse generated by the trigger system, the camera will send a frame to the frame grabber. If a trigger pulse gets lost, or the camera cannot send a frame, this register will be set to FG_YES. Technically, between two output signal edges, a incoming image has to exist. Or in other words: There must not be two or more successive trigger start edges without a valid frame in between. The following figure illustrates the behavior.


The pulse form generator allocated to the camera trigger signal line carrying the image trigger pulses has to be selected by FG_TRIGGEROUT_STATS_SOURCE. The missing frame response system might not work correct for all camera models due to different timings.

[Note]Select Camera Control/Trigger Signal Line

Take care to select the pulse form generator feeding the camera trigger signal line which carries the image trigger pulses by setting parameter FG_TRIGGEROUT_STATS_SOURCE to the respective source.

[Warning]Acquisition Start Before Trigger Activation

Keep in mind to start the acquisition before activating the trigger. Otherwise, the trigger pulses sent will get lost. Also keep in mind, that any changes of the camera configuration might result in invalid data transfers.

[Tip]Events for Missing Frame Response

If you want to monitor the exact moment of a missing frame responses, and the exact number of missing frames use event FG_MISSING_CAM0_FRAME_RESPONSE. Analog this approach exists for all 4 cameras connected to the applet addressed by its index.



[Note]Note

This description applies also to the following events: FG_TRIGGER_EXCEEDED_PERIOD_LIMITS_CAM1, FG_TRIGGER_EXCEEDED_PERIOD_LIMITS_CAM2, FG_TRIGGER_EXCEEDED_PERIOD_LIMITS_CAM3

The event is generated for each lost input trigger pulse. A trigger loss can occur if the input frequency is higher than the maximum allowed frequency set by parameter FG_TRIGGER_FRAMESPERSECOND (see Chapter 7.5.3). If the trigger queue is enabled, the events will only be generated if the queue is full i.e. for overflows. In generator and synchronized trigger modes, the events will not be generated. Except for the timestamp, the event has no additional data included.

For a general explanation on events see Event.

You can select one of the trigger outputs to generate a software event. i.e. a software callback function. Use parameter FG_TRIGGER_OUTPUT_EVENT_SELECT to specified the source pulse form generator for the event. The events name itself is FG_TRIGGER_OUTPUT_CAM0.

For a general explanation on events check Event.

The applet processes image data as fast as possible. Any image data sent by the camera is immediately processed and sent to the PC. The latency is minimal. In general, only one concurrent image line is stored and processed in the frame grabber. However, the transfer bandwidth to the PC via DMA channel can vary caused by interrupts, other hardware and the current CPU load. Also, the camera frame rate can vary due to an fluctuating trigger. For these cases, the applet is equipped with a memory to buffer the input frames. This buffer can store up to 32,000 image lines. The fill level of the buffer can be obtained by reading from parameter FG_FILLLEVEL.

In normal operation conditions the buffer will always remain almost empty. For fluctuating camera bandwidths or for short and fast acquisitions, the buffer can easily fill up quickly. Of course, the input bandwidth must not exceed the maximum bandwidth of the applet. Check Section 1.2, 'Bandwidth' for more information.

If the buffer's fill level reaches 100%, the applet is in overflow condition, as no more data can be buffered and camera data will be discarded. This can result in two different behaviors:

  • Corrupted Frames:

    The transfer of a current frame is interrupted by an overflow. This means, the first pixels or lines of the frame were transfered into the buffer, but not the full frame. The output of the applet i.e. the DMA transfer will be shorter. The output image will not have it's full height.

  • Lost Frames:

    A full camera frame was discarded due to a full buffer memory. No DMA transfer will exist for the discarded frame. This means the number of applet output images can differ from the number of applet input images.

A way to detect the overflows is to read parameter FG_OVERFLOW or check for event FG_OVERFLOW_CAM0. Reading from the parameter will provide information about an overflow condition. As soon as the parameter is read, it will reset. Using the parameter an overflow condition can be detect, but it is not possible to obtain the exact image number and the moment. For this, the overflow event can be used.

In programming or runtime environments, a callback function is a piece of executable code that is passed as an argument, which is expected to call back (execute) exactly that time an event is triggered. This applet can generate some software callback events based on the memory overflow condition as explained in the following section. These events are not related to a special camera functionality. Other event sources are described in additional sections of this document.

Our Runtime/SDK enables an application to get these event notifications about certain state changes at the data flow from camera to RAM and the image and trigger processing as well. Please consult our Runtime/SDK documentation for more details concerning the implementation of this functionality.

[Note]Note

This description applies also to the following events: FG_OVERFLOW_CAM1, FG_OVERFLOW_CAM2, FG_OVERFLOW_CAM3

Overflow events are generated for each corrupted or lost frame. In contrast to the other events presented in this document, the overflow event transports data, namely the type of overflow, the image number and the timestamp. The following figure illustrates the event data. Data is included in a 64 Bit data packet. The first 32 Bit include the frame number. Bits 32 to 47 include an overflow mask.


Note that the frame number is reset on acquisition start. Also note that the first frame will have frame number zero, while a DMA transfer starts with frame number one. The frame number is a 32 Bit value. If it's maximum is reached, it will start from zero again. Keep in mind that on a 64 Bit runtime, the DMA transfer number will be a 64 Bit value. If the frame corrupted flag is set, the frame with the frame number in the event is corrupted i.e. it will not have it's full length but is still transfered via DMA channel. If the frame lost flag is set, the frame with the frame number in the event was fully discarded. No DMA transfer will exist for this frame. The corrupted frame flag and the frame lost flag will never occur for the same event. The flag "event loss occured before" is an additional security mechanism. It means that an event has been lost. This can only happen at very high event rates and should not happen under normal conditions.

The analysis of the overflow events depends on the user requirements. In the following, an example is shown on how to ensure the integrity if the DMA data by analyzing the events and DMA transfers.


In the example, two frames got lost and one is marked as corrupted. As the events are not synchronous with the DMA transfers, for analysis a software queue (push and pull) is required to allocate the events to the DMA transfers.

The Image Selector allows the user to cut out a period of p images from the image stream and select a particular image n from it.

The following example will explain the settings of p and n which represent the frame grabber parameters FG_IMG_SELECT_PERIOD and FG_IMG_SELECT. Suppose two frame grabbers being connected to a camera signal multiplexer, providing all camera images to both devices. Grabber 0 is required to process all even frames, while grabber 1 is required to process all odd frames. The settings will then be:

Ensure that both grabbers are used synchronously. This is possible with a triggered camera. To do so, initialize and configure both frame grabbers. Configure the camera for external trigger and the trigger system of master grabber which is directly connected to the camera. Next, the acquisitions of both grabbers have to be started and finally, the trigger generation has to be enabled, generally by setting FG_TRIGGERSTATE to active. Now the camera will start sending image data and the grabbers acquire those synchronously. More information can be found in the trigger chapter Chapter 7, 'Trigger'.

This AcquisitionApplets includes a full resolution lookup table (LUT). Settings are applied to the acquired images just before transferring them to the host PC. Thus, it is the last pre-processing step on the frame grabber.

A lookup table includes one entry for every allowed input pixel value. The pixel value will be replaced by the value of the lookup table element. In other words, a new value is assigned to each pixel value. This can be used for image quality enhancements such as an added offset, a gain factor or gamma correction which can be performed by use of the processing module of this applet in a convenient way (see Module Chapter 11, 'Processing'). The lookup table can also be loaded with custom values. Application areas are custom image enhancements or correct pixel classifications.

This applet is processing data with an internal resolution of 16 bits. But the lookup table has 14 input bits i.e. pixel values can be in the range For each of these elements, a table entry exists containing a new output value. The new values are in the range from 0 to 65536. Since this applet uses 16 bit internally, consider that all values need to represent this value range. This LUT is applied to all pixel values before FG_FORMAT is applied. The input values for the LUT are aligned to the most significant bit (MSB).

In the following the parameters to use the lookup table are explained. Parameter FG_LUT_TYPE is important to be set correctly as it defines the lookup table operation mode.

There exist two basic possibilities to use and configure the lookup table. One possibility is to use the internal processor which allows a convenient way to improve the image quality using parameters such as offset, gain and gamma. Check category Chapter 11, 'Processing' for more detailed documentation. Set this parameter to LUT_TYPE_PROCESSING to use the processor.

The second possibility to use the lookup table is to load a file containing custom values to the lookup table. Set the parameter to LUT_TYPE_CUSTOM to enable the possibility to load a custom file with lookup table entries.

Beside these two possibilities it is always possible to directly write to the lookup table entries using the field parameter FG_LUT_VALUE. The use of these parameters will overwrite the settings made with the processor or the custom input file. Vice versa, changing a processing parameter or loading a custom lookup table file, will overwrite the settings made by the field parameters.



If parameter FG_LUT_TYPE is set to LUT_TYPE_CUSTOM, the according path and filename to the file containing the custom lookup table entries can be set here. If the file is valid, the file values will be loaded to the lookup table. If the file is invalid, the call to this parameter will return an error.

A convenient way of getting a draft file, is to save the current lookup table settings to file using parameter FG_LUT_SAVE_FILE.

Please make sure to activate the Type of LUT FG_LUT_TYPE to "UserFile"/LUT_TYPE_CUSTOM in order to make the changes and file names taking effect.

This section describes the file formats which are in use to fill the so called look-up tables (LUT). The purpose of a LUT is a transformation of pixel values from a input (source) image to the pixel values of an output image. This transformation is done by a kind of table, which contains the assignment between these pixel values (input pixel values - output pixel values). Basically the LUT is defined for gray format and color formats as well. When defining a LUT for color formats, the definition of tables has to be done for each color component. The LUT file format consists of 2 parts:

  • Header section containing control and description information.

  • Main section containing the assignment table for transforming pixel values form a source (input) image to a destination (output) image.

The following example shows how a grey scale lookup table description could look like:

# Lut data file v1.1
id=3;
nrOfElements=4096;
format=0;
number=0;
0,0;
1,1;
2,2;
3,3;
4,4;
5,5;
6,6;
…
4095,4095;
        

General Properties:

  • File format extension should be ".lut"

  • LUT file format is an ASCII file format consisting of multiple lines of data.

  • Lines are defined by a line separator a <CR> <LF> line feed (0x3D 0x0D 0x0A).

  • Lines consist of key / value pairs. Key and value are separated by "=". The value has to be followed by a semicolon ; (0x3B)

  • Formats consist of header data, containing control information and the assignment table for a specific color component (gray / red, green, blue).

  • Basically the LUT file color format follows the same rules as the gray image format. In addition, due to the fact, that each color component can has its own transformation, the definitions are repeated for each color component.

The following example shows how a color scale lookup table description could look like:

# Lut data file v1.1
[red]
id=0;
nrOfElements=256;
format=0;
number=0;
0,0;
1,1;
..
255,255;
[green]
id=1;
nrOfElements=256;
format=0;
number=0;
0,0;
1,1;
..
255,255;
[blue]
id=2;
nrOfElements=256;
format=0;
number=0;
0,0;
1,1;
..
255,255;
        

A more detailed explanation of the lookup table file format can be found in our runtime's SDK manual.



In the following, some properties of the lookup table implementation are listed.

A convenient way to improve the image quality are the processing parameters. Using these parameters an offset, gain and gamma correction can be performed. Moreover, the image can be inverted.

[Important]Processor Activation

The processing parameters use the lookup table for determination of the correction values. For activation of the processing parameters, set FG_LUT_TYPE of category lookup table to LUT_TYPE_PROCESSING . Otherwise, parameter changes will have no effect.

All transformations apply in the following order:

  1. Offset Correction, range [-1.0, +1.0], identity = 0

  2. Gain Correction, range [0, 2^14[, identity = 1.0

  3. Gamma Correction, range ]0, inf], identity = 1.0

  4. Invert, identity = 'off'

In this applet, a full lookup table with m = 14 input bits and n = 16 outputs bits is used to perform the corrections. Values are determined by


If the inversion is used, output values are determined by


where x represents the input pixel value i.e. is in the range from 0 to 2^14 - 1. If the determined output value is less than 0, it will be set to 0. If the determined output value is greater than 2^16 - 1 it is set to 2^16 - 1.

Color applets process each color component separately using the same processing parameters for each component.

If no parameters are changed, i.e. they are set to identity, the output values will be equal to the input values as shown in the figure below. In the following, you will find detailed explanations for all processing parameters.


The following parameter can be used to configure the applet's image output format i.e. the format and bit alignment.

Parameter FG_FORMAT is used to set and determine the output formats of the DMA channels. An output format value specifies the number of bits and the color format of the output.

This applet has an internal processing bit width of 16 bits. Any selected camera pixel format is mapped to this internal bit width. Check the camera parameter section to learn about the mapping of the camera bits to the internal bit width. For a definition on how to map the internal bits to the ouput bits, check parameter FG_BITALIGNMENT.

This applet supports the following output formats:

  • FG_GRAY: 8 bit grayscale format

  • FG_GRAY10: 10 bit grayscale format

    [Note]10 Bit Output Format

    Note that in the 10 bit output format 1 pixel is distributed over more than one byte. Also, two successive pixel share one byte. The pixel are directly aligned in memory. Thus 8 successive pixel are stored in 10 byte. The DMA transfer might be filled with random content for the last bytes.

  • FG_GRAY12: 12 bit grayscale format

    [Note]12 Bit Output Format

    Note that in the 12 bit output format 1 pixel is distributed over more than one byte. Also, two successive pixel share the same byte. The pixel are directly aligned in memory. Thus 2 successive pixel are stored in 3 byte. The DMA transfer might be filled with random content for the last bytes.

  • FG_GRAY14: 14 bit grayscale format

    [Note]14 Bit Output Format

    Note that in the 14 bit output format 1 pixel is distributed over more than one byte. Also, two successive pixel share the same byte. The pixel are directly aligned in memory. Thus 12 successive pixel are stored in 21 byte. The DMA transfer might be filled with random content for the last bytes.

  • FG_GRAY16: 16 bit grayscale format

    [Warning]DMA Bandwidth

    Keep in mind that for the 16 bit output mode, the DMA bandwidth might not be sufficient to process the camera input data. Check Section 1.2, 'Bandwidth' for more information.



The bit alignment is used to map the pixel bits of the internal processing with a depth of 16 bit to the configured DMA output bit depth defined by parameter FG_FORMAT.

You can select three different modes: Left aligned, right aligned and a custom shift mode. If you select left aligned, the applet will map the upper bits of the internal processing bit width to the available output bits. If you select right aligned, the applet will map the lower bits of the internal processing bit width to the available output bits. If you want to define a custom bit shift, you'll need to set the parameter to FG_CUSTOM_SHIFT_MODE and use parameter FG_CUSTOM_BIT_SHIFT_RIGHT to define the bit shift.

Keep in mind that the internal processing bit width has nothing to do with the camera pixel format. Check the camera parameter section to learn about the mapping of the camera bits to the internal bit width.



This parameter can only be used if parameter FG_BITALIGNMENT is set to FG_CUSTOM_BIT_SHIFT_MODE. If it is enabled, you can define a custom right bit shift value for the DMA output of the frame grabber. A shift of 0 means that the most significant bits (MSB) of the internal processing bit width are mapped to the output MSB. For example, if the applet has an internal processing bit width of 12 bit and you select a 10 bit output, the upper 10 bits are mapped to the output. If you select however a bit width of two, the lower 10 bits are mapped to the output. Note that this applet has an internal bit width of 16 bits.



The camera simulator is a convenient way to simulate cameras for first time applet tests. If the simulator is enabled it generates pattern frames of specified size and speed. The image data is replaced at the position of the camera i.e. all applet processing functionalities are applied to the generated images. Note that camera specific settings of the applet will not have any functionality.

The generated images are horizontal, diagonal or vertical grayscale patterns, such as the one shown in the following figure.


[Note]No Sub-Sensor sorting in Generated Images

The camera simulator will generate a simple grayscale pattern. If the camera or this applet uses sub sensor pixel sorting (sensor correction), the simulator will not generate images which represent the camera sensor.

You can either use the camera simulator in free run mode or the simulator can be triggered by the output of the trigger module of this applet. As this applet uses a CoaxPress camera interface, the CXP trigger output of the respective camera port is used as camera simulator trigger input. The rising edge of the trigger will be used.

You can choose between line trigger and frame trigger mode. In line trigger mode, a rising edge at the input will output a line from the camera simulator. For frame trigger mode, the input will trigger the output of a frame.

[Warning]Trigger frequency must not exceed the speed of the camera simulator

Same as for real cameras, it is very important that the frequency of the trigger pulses do not exceed the maximum speed of the camera simulator. Set the camera simulator to a sufficiently large speed to avoid line or frame lost.



The miscellaneous module category summarizes other read and write parameters such as the camera status, buffer fill levels, DMA transfer lengths, time stamps and buffer fill-levels.

Area of Interest (AOI)

See Region of Interest.

Board

A Silicon Software hardware. Usually, a board is represented by a frame grabber. Boards might comprise multiple devices.

Board ID Number

An identification number of a Silicon Software board in a PC system. The number is not fixed to a specific hardware but has to be unique in a PC system.

Camera Index

The index of a camera connected to a frame grabber. The first camera will have index zero. Mind the difference between the camera index and the frame grabber camera port.

See also Camera Port.

Camera Port

The Silicon Software frame grabber connectors for cameras are called camera ports. They are numbered {0, 1, 2, ...} or enumerated {A, B, C, ... }. Depending on the interface one camera could be connected to multiple camera ports. Also, multiple cameras could be connected to one camera port.

Camera Tap

See Tap.

Device

A board can consist of multiple devices. Devices are numbered. The first device usually has number one.

Direct Memory Access (DMA)

A DMA transfer allows hardware subsystems within the computer to access the system memory independently of the central processing unit (CPU).

SiliconSoftware uses DMAs for data transfer such as image data between a board e.g. a frame grabber and a PC. Data transfers can be established in multiple directions i.e. from a frame grabber to the PC (download) and from the PC to a frame grabber (upload). Multiple DMA channels may exist for one board. Control and configuration data usually do not use DMA channels.

DMA Channel

See DMA Index.

DMA Index

The index of a DMA transfer channel.

See also Direct Memory Access.

Event

In programming or runtime environments, a callback function is a piece of executable code that is passed as an argument, which is expected to call back (execute) exactly that time an event is triggered. These events are not related to a special camera functionality and based on frame grabber internal functionality.

SiliconSoftware uses hardware interrupts for the event transfer and processing is absolutely optimized for low latency. These interrupts are only produced by the grabber if an event is registered and activated by software. If an event is fired at a very high frequency this may influence the system performance.

For example these events can be used to check the reliability between a frame trigger input and the resulting and expected camera frame.

Our Runtime/SDK enables an application to get these event notifications about certain state changes at the data flow from camera to RAM and the image and trigger processing as well. Please consult our Runtime/SDK documentation for more details concerning the implementation of this functionality. Some events are enabled to produce additional data, which is described for the event itself.

Port

See Camera Port.

Process

An image or signal data processing block. A process can include one or more cameras, one or more DMA channels and modules.

Region of Interest (ROI)

Represents a part of a frame. Mostly rectangular and within the original image boundaries. Defined by source coordinates and its dimension. The frame grabber cuts the region of interest from the camera image. A region of interest might reduce or increase the required bandwidth and the corresponding image dimension.

Sensor Tap

See Tap.

Software Callback

See Event.

Tap

Some cameras have multiple taps. This means, they can acquire or transfer more than one pixel at a time which increses the camera's acquisition speed. The camera sensor tap readout order varies. Some cameras read the pixels interlaced using multiple taps, while some cameras read the pixel simultaneously from different locations on the sensor. The reconstruction of the frame is called sensor readout correction.

The CameraáLink interface is also using multiple taps for image transfer to increase the bandwidth. These taps are independent from the sensor taps.

Trigger

In machine vision and image processing, a trigger is an event which causes an action. This can be for example the initiation of a new line or frame acquisition, the control of external hardware such as flash lights or actions by a software applications. Trigger events can be initiated by external sources, an internal frequency generator (timer) or software applications. The event itself is mostly based on a rising or falling edge of a electrical signal.

Trigger Input

A logic input of a trigger IO. The first input has index 0. Check mapping of input pins to logic inputs in the hardware documentation.

Trigger Output

A logic output of a trigger IO. The first output has index 1. Please check the mapping of output pins to logic outputs in the hardware documentation. The electrical characteristics and specification can be found related to the selected or used trigger board/connector.

Trigger Reliability

See Event.

User Interrupt

See Event.

B

Bandwidth, Bandwidth

C

Camera, Camera
Events, Events
Format, CoaXPress
Interface, Camera Interface, Camera
Camera Simulator, Camera Simulator
Camera::Events, Events
CoaXPress, CoaXPress

E

Events
Camera, Events
Digital Inputs, Event Overview, Statistics
Overflow, Events
Trigger, Event Overview
Trigger Lost Detection, Statistics
Trigger Output, Output Event
Trigger Queue, Queue

F

Features, Features of Applet Acq_QuadCXP6x1AreaGray
FG_ALTERNATIVE_BOARD_DETECTION, FG_ALTERNATIVE_BOARD_DETECTION
FG_APPLET_BUILD_TIME, FG_APPLET_BUILD_TIME
FG_APPLET_ID, FG_APPLET_ID
FG_APPLET_REVISION, FG_APPLET_REVISION
FG_APPLET_VERSION, FG_APPLET_VERSION
FG_AREATRIGGERMODE, FG_AREATRIGGERMODE
FG_BITALIGNMENT, FG_BITALIGNMENT
FG_CAMERASIMULATOR_ACTIVE, FG_CAMERASIMULATOR_ACTIVE
FG_CAMERASIMULATOR_ENABLE, FG_CAMERASIMULATOR_ENABLE
FG_CAMERASIMULATOR_FRAMERATE, FG_CAMERASIMULATOR_FRAMERATE
FG_CAMERASIMULATOR_FRAME_GAP, FG_CAMERASIMULATOR_FRAME_GAP
FG_CAMERASIMULATOR_HEIGHT, FG_CAMERASIMULATOR_HEIGHT
FG_CAMERASIMULATOR_LINERATE, FG_CAMERASIMULATOR_LINERATE
FG_CAMERASIMULATOR_LINE_GAP, FG_CAMERASIMULATOR_LINE_GAP
FG_CAMERASIMULATOR_PASSIVE, FG_CAMERASIMULATOR_PASSIVE
FG_CAMERASIMULATOR_PATTERN, FG_CAMERASIMULATOR_PATTERN
FG_CAMERASIMULATOR_PATTERN_OFFSET, FG_CAMERASIMULATOR_PATTERN_OFFSET
FG_CAMERASIMULATOR_PIXEL_FREQUENCY, FG_CAMERASIMULATOR_PIXEL_FREQUENCY
FG_CAMERASIMULATOR_ROLL, FG_CAMERASIMULATOR_ROLL
FG_CAMERASIMULATOR_SELECT_MODE, FG_CAMERASIMULATOR_SELECT_MODE
FG_CAMERASIMULATOR_TRIGGER_MODE, FG_CAMERASIMULATOR_TRIGGER_MODE
FG_CAMERASIMULATOR_WIDTH, FG_CAMERASIMULATOR_WIDTH
FG_CAMSTATUS, FG_CAMSTATUS
FG_CAMSTATUS_EXTENDED, FG_CAMSTATUS_EXTENDED
FG_CUSTOM_BIT_SHIFT_RIGHT, FG_CUSTOM_BIT_SHIFT_RIGHT
FG_CXP_TRIGGER_PACKET_MODE, FG_CXP_TRIGGER_PACKET_MODE
FG_DEBUGFILE, FG_DEBUGFILE
FG_DEBUGINENABLE, FG_DEBUGINENABLE
FG_DEBUGINSERT, FG_DEBUGINSERT
FG_DEBUGOUTENABLE, FG_DEBUGOUTENABLE
FG_DEBUGOUTPIXEL, FG_DEBUGOUTPIXEL
FG_DEBUGOUTXPOS, FG_DEBUGOUTXPOS
FG_DEBUGOUTYPOS, FG_DEBUGOUTYPOS
FG_DEBUGREADY, FG_DEBUGREADY
FG_DEBUGSAVECONFIG, FG_DEBUGSAVECONFIG
FG_DEBUGSOURCE, FG_DEBUGSOURCE
FG_DEBUGSOURCENAME, FG_DEBUGSOURCENAME
FG_DEBUGWRITEFLAG, FG_DEBUGWRITEFLAG
FG_DEBUGWRITEPIXEL, FG_DEBUGWRITEPIXEL
FG_DMASTATUS, FG_DMASTATUS
FG_END_OF_FRAME_CAM_PORT_0, FG_END_OF_FRAME_CAM_PORT_0 et al.
FG_END_OF_FRAME_CAM_PORT_1, FG_END_OF_FRAME_CAM_PORT_0 et al.
FG_END_OF_FRAME_CAM_PORT_2, FG_END_OF_FRAME_CAM_PORT_0 et al.
FG_END_OF_FRAME_CAM_PORT_3, FG_END_OF_FRAME_CAM_PORT_0 et al.
FG_FILLLEVEL, FG_FILLLEVEL
FG_FORMAT, FG_FORMAT
FG_FRONT_GPI, FG_FRONT_GPI
FG_GPI, FG_GPI
FG_HAP_FILE, FG_HAP_FILE
FG_HEIGHT, FG_HEIGHT
FG_IMG_SELECT, FG_IMG_SELECT
FG_IMG_SELECT_PERIOD, FG_IMG_SELECT_PERIOD
FG_LUT_CUSTOM_FILE, FG_LUT_CUSTOM_FILE
FG_LUT_ENABLE, FG_LUT_ENABLE
FG_LUT_IMPLEMENTATION_TYPE, FG_LUT_IMPLEMENTATION_TYPE
FG_LUT_IN_BITS, FG_LUT_IN_BITS
FG_LUT_OUT_BITS, FG_LUT_OUT_BITS
FG_LUT_SAVE_FILE, FG_LUT_SAVE_FILE
FG_LUT_TYPE, FG_LUT_TYPE
FG_LUT_VALUE, FG_LUT_VALUE
FG_MISSING_CAM0_FRAME_RESPONSE, FG_MISSING_CAM0_FRAME_RESPONSE et al.
FG_MISSING_CAM1_FRAME_RESPONSE, FG_MISSING_CAM0_FRAME_RESPONSE et al.
FG_MISSING_CAM2_FRAME_RESPONSE, FG_MISSING_CAM0_FRAME_RESPONSE et al.
FG_MISSING_CAM3_FRAME_RESPONSE, FG_MISSING_CAM0_FRAME_RESPONSE et al.
FG_MISSING_CAMERA_FRAME_RESPONSE, FG_MISSING_CAMERA_FRAME_RESPONSE
FG_MISSING_CAMERA_FRAME_RESPONSE_CLEAR, FG_MISSING_CAMERA_FRAME_RESPONSE_CLEAR
FG_OVERFLOW, FG_OVERFLOW
FG_OVERFLOW_CAM0, FG_OVERFLOW_CAM0 et al.
FG_OVERFLOW_CAM1, FG_OVERFLOW_CAM0 et al.
FG_OVERFLOW_CAM2, FG_OVERFLOW_CAM0 et al.
FG_OVERFLOW_CAM3, FG_OVERFLOW_CAM0 et al.
FG_PIXELDEPTH, FG_PIXELDEPTH
FG_PIXELFORMAT, FG_PIXELFORMAT
FG_PROCESSING_GAIN, FG_PROCESSING_GAIN
FG_PROCESSING_GAMMA, FG_PROCESSING_GAMMA
FG_PROCESSING_INVERT, FG_PROCESSING_INVERT
FG_PROCESSING_OFFSET, FG_PROCESSING_OFFSET
FG_SENDSOFTWARETRIGGER, FG_SENDSOFTWARETRIGGER
FG_SENSORHEIGHT, FG_SENSORHEIGHT
FG_SENSORWIDTH, FG_SENSORWIDTH
FG_SOFTWARETRIGGER_IS_BUSY, FG_SOFTWARETRIGGER_IS_BUSY
FG_SOFTWARETRIGGER_QUEUE_FILLLEVEL, FG_SOFTWARETRIGGER_QUEUE_FILLLEVEL
FG_START_OF_FRAME_CAM_PORT_0, FG_START_OF_FRAME_CAM_PORT_0 et al.
FG_START_OF_FRAME_CAM_PORT_1, FG_START_OF_FRAME_CAM_PORT_0 et al.
FG_START_OF_FRAME_CAM_PORT_2, FG_START_OF_FRAME_CAM_PORT_0 et al.
FG_START_OF_FRAME_CAM_PORT_3, FG_START_OF_FRAME_CAM_PORT_0 et al.
FG_SYSTEMMONITOR_CHANNEL_CURRENT, FG_SYSTEMMONITOR_CHANNEL_CURRENT
FG_SYSTEMMONITOR_CHANNEL_STATE, FG_SYSTEMMONITOR_CHANNEL_STATE
FG_SYSTEMMONITOR_CHANNEL_VOLTAGE, FG_SYSTEMMONITOR_CHANNEL_VOLTAGE
FG_SYSTEMMONITOR_CURRENT_LINK_SPEED, FG_SYSTEMMONITOR_CURRENT_LINK_SPEED
FG_SYSTEMMONITOR_CURRENT_LINK_WIDTH, FG_SYSTEMMONITOR_CURRENT_LINK_WIDTH
FG_SYSTEMMONITOR_EXTENSION_CONNECTOR_PRESENT, FG_SYSTEMMONITOR_EXTENSION_CONNECTOR_PRESENT
FG_SYSTEMMONITOR_FPGA_DNA, FG_SYSTEMMONITOR_FPGA_DNA
FG_SYSTEMMONITOR_FPGA_TEMPERATURE, FG_SYSTEMMONITOR_FPGA_TEMPERATURE
FG_SYSTEMMONITOR_FPGA_VCC_AUX, FG_SYSTEMMONITOR_FPGA_VCC_AUX
FG_SYSTEMMONITOR_FPGA_VCC_BRAM, FG_SYSTEMMONITOR_FPGA_VCC_BRAM
FG_SYSTEMMONITOR_FPGA_VCC_INT, FG_SYSTEMMONITOR_FPGA_VCC_INT
FG_SYSTEMMONITOR_PCIE_LINK_GEN2_CAPABLE, FG_SYSTEMMONITOR_PCIE_LINK_GEN2_CAPABLE
FG_SYSTEMMONITOR_PCIE_LINK_PARTNER_GEN2_CAPABLE, FG_SYSTEMMONITOR_PCIE_LINK_PARTNER_GEN2_CAPABLE
FG_SYSTEMMONITOR_PCIE_TRAINED_PAYLOAD_SIZE, FG_SYSTEMMONITOR_PCIE_TRAINED_PAYLOAD_SIZE
FG_TIMEOUT, FG_TIMEOUT
FG_TRIGGERCAMERA_GPO0, FG_TRIGGERCAMERA_GPO0 et al.
FG_TRIGGERCAMERA_GPO1, FG_TRIGGERCAMERA_GPO0 et al.
FG_TRIGGERCAMERA_GPO2, FG_TRIGGERCAMERA_GPO0 et al.
FG_TRIGGERCAMERA_GPO3, FG_TRIGGERCAMERA_GPO0 et al.
FG_TRIGGERCAMERA_GPO4, FG_TRIGGERCAMERA_GPO0 et al.
FG_TRIGGERCAMERA_GPO5, FG_TRIGGERCAMERA_GPO0 et al.
FG_TRIGGERCAMERA_GPO6, FG_TRIGGERCAMERA_GPO0 et al.
FG_TRIGGERCAMERA_GPO7, FG_TRIGGERCAMERA_GPO0 et al.
FG_TRIGGERCAMERA_OUT_SELECT, FG_TRIGGERCAMERA_OUT_SELECT
FG_TRIGGERIN_DEBOUNCE, FG_TRIGGERIN_DEBOUNCE
FG_TRIGGERIN_DOWNSCALE, FG_TRIGGERIN_DOWNSCALE
FG_TRIGGERIN_DOWNSCALE_PHASE, FG_TRIGGERIN_DOWNSCALE_PHASE
FG_TRIGGERIN_POLARITY, FG_TRIGGERIN_POLARITY
FG_TRIGGERIN_SRC, FG_TRIGGERIN_SRC
FG_TRIGGERIN_STATS_FREQUENCY, FG_TRIGGERIN_STATS_FREQUENCY
FG_TRIGGERIN_STATS_MAXFREQUENCY, FG_TRIGGERIN_STATS_MAXFREQUENCY
FG_TRIGGERIN_STATS_MINFREQUENCY, FG_TRIGGERIN_STATS_MINFREQUENCY
FG_TRIGGERIN_STATS_MINMAXFREQUENCY_CLEAR, FG_TRIGGERIN_STATS_MINMAXFREQUENCY_CLEAR
FG_TRIGGERIN_STATS_POLARITY, FG_TRIGGERIN_STATS_POLARITY
FG_TRIGGERIN_STATS_PULSECOUNT, FG_TRIGGERIN_STATS_PULSECOUNT
FG_TRIGGERIN_STATS_PULSECOUNT_CLEAR, FG_TRIGGERIN_STATS_PULSECOUNT_CLEAR
FG_TRIGGERIN_STATS_SOURCE, FG_TRIGGERIN_STATS_SOURCE
FG_TRIGGEROUT_SELECT_FRONT_GPO_0, FG_TRIGGEROUT_SELECT_FRONT_GPO_0 et al.
FG_TRIGGEROUT_SELECT_FRONT_GPO_1, FG_TRIGGEROUT_SELECT_FRONT_GPO_0 et al.
FG_TRIGGEROUT_SELECT_GPO_0, FG_TRIGGEROUT_SELECT_GPO_0 et al.
FG_TRIGGEROUT_SELECT_GPO_1, FG_TRIGGEROUT_SELECT_GPO_0 et al.
FG_TRIGGEROUT_SELECT_GPO_2, FG_TRIGGEROUT_SELECT_GPO_0 et al.
FG_TRIGGEROUT_SELECT_GPO_3, FG_TRIGGEROUT_SELECT_GPO_0 et al.
FG_TRIGGEROUT_SELECT_GPO_4, FG_TRIGGEROUT_SELECT_GPO_0 et al.
FG_TRIGGEROUT_SELECT_GPO_5, FG_TRIGGEROUT_SELECT_GPO_0 et al.
FG_TRIGGEROUT_SELECT_GPO_6, FG_TRIGGEROUT_SELECT_GPO_0 et al.
FG_TRIGGEROUT_SELECT_GPO_7, FG_TRIGGEROUT_SELECT_GPO_0 et al.
FG_TRIGGEROUT_STATS_PULSECOUNT, FG_TRIGGEROUT_STATS_PULSECOUNT
FG_TRIGGEROUT_STATS_PULSECOUNT_CLEAR, FG_TRIGGEROUT_STATS_PULSECOUNT_CLEAR
FG_TRIGGEROUT_STATS_SOURCE, FG_TRIGGEROUT_STATS_SOURCE
FG_TRIGGERQUEUE_FILLLEVEL, FG_TRIGGERQUEUE_FILLLEVEL
FG_TRIGGERQUEUE_MODE, FG_TRIGGERQUEUE_MODE
FG_TRIGGERSTATE, FG_TRIGGERSTATE
FG_TRIGGER_EXCEEDED_PERIOD_LIMITS, FG_TRIGGER_EXCEEDED_PERIOD_LIMITS
FG_TRIGGER_EXCEEDED_PERIOD_LIMITS_CAM0, FG_TRIGGER_EXCEEDED_PERIOD_LIMITS_CAM0 et al.
FG_TRIGGER_EXCEEDED_PERIOD_LIMITS_CAM1, FG_TRIGGER_EXCEEDED_PERIOD_LIMITS_CAM0 et al.
FG_TRIGGER_EXCEEDED_PERIOD_LIMITS_CAM2, FG_TRIGGER_EXCEEDED_PERIOD_LIMITS_CAM0 et al.
FG_TRIGGER_EXCEEDED_PERIOD_LIMITS_CAM3, FG_TRIGGER_EXCEEDED_PERIOD_LIMITS_CAM0 et al.
FG_TRIGGER_EXCEEDED_PERIOD_LIMITS_CLEAR, FG_TRIGGER_EXCEEDED_PERIOD_LIMITS_CLEAR
FG_TRIGGER_FRAMESPERSECOND, External Trigger Signals / IO Triggered, FG_TRIGGER_FRAMESPERSECOND
FG_TRIGGER_FRONT_GPI0_FALLING, FG_TRIGGER_INPUT0_FALLING et al.
FG_TRIGGER_FRONT_GPI0_RISING, FG_TRIGGER_INPUT0_FALLING et al.
FG_TRIGGER_FRONT_GPI1_FALLING, FG_TRIGGER_INPUT0_FALLING et al.
FG_TRIGGER_FRONT_GPI1_RISING, FG_TRIGGER_INPUT0_RISING et al.
FG_TRIGGER_FRONT_GPI2_FALLING, FG_TRIGGER_INPUT0_FALLING et al.
FG_TRIGGER_FRONT_GPI2_RISING, FG_TRIGGER_INPUT0_RISING et al.
FG_TRIGGER_FRONT_GPI3_FALLING, FG_TRIGGER_INPUT0_FALLING et al.
FG_TRIGGER_FRONT_GPI3_RISING, FG_TRIGGER_INPUT0_RISING et al.
FG_TRIGGER_INPUT0_FALLING, FG_TRIGGER_INPUT0_FALLING et al.
FG_TRIGGER_INPUT0_RISING, FG_TRIGGER_INPUT0_RISING et al.
FG_TRIGGER_INPUT1_FALLING, FG_TRIGGER_INPUT0_FALLING et al.
FG_TRIGGER_INPUT1_RISING, FG_TRIGGER_INPUT0_RISING et al.
FG_TRIGGER_INPUT2_FALLING, FG_TRIGGER_INPUT0_FALLING et al.
FG_TRIGGER_INPUT2_RISING, FG_TRIGGER_INPUT0_RISING et al.
FG_TRIGGER_INPUT3_FALLING, FG_TRIGGER_INPUT0_FALLING et al.
FG_TRIGGER_INPUT3_RISING, FG_TRIGGER_INPUT0_RISING et al.
FG_TRIGGER_INPUT4_FALLING, FG_TRIGGER_INPUT0_FALLING et al.
FG_TRIGGER_INPUT4_RISING, FG_TRIGGER_INPUT0_RISING et al.
FG_TRIGGER_INPUT5_FALLING, FG_TRIGGER_INPUT0_FALLING et al.
FG_TRIGGER_INPUT5_RISING, FG_TRIGGER_INPUT0_RISING et al.
FG_TRIGGER_INPUT6_FALLING, FG_TRIGGER_INPUT0_FALLING et al.
FG_TRIGGER_INPUT6_RISING, FG_TRIGGER_INPUT0_RISING et al.
FG_TRIGGER_INPUT7_FALLING, FG_TRIGGER_INPUT0_FALLING et al.
FG_TRIGGER_INPUT7_RISING, FG_TRIGGER_INPUT0_RISING et al.
FG_TRIGGER_MULTIPLY_PULSES, Control of Three Flash Lights, FG_TRIGGER_MULTIPLY_PULSES
FG_TRIGGER_OUTPUT_CAM0, FG_TRIGGER_OUTPUT_CAM0 et al.
FG_TRIGGER_OUTPUT_CAM1, FG_TRIGGER_OUTPUT_CAM0 et al.
FG_TRIGGER_OUTPUT_CAM2, FG_TRIGGER_OUTPUT_CAM0 et al.
FG_TRIGGER_OUTPUT_CAM3, FG_TRIGGER_OUTPUT_CAM0 et al.
FG_TRIGGER_OUTPUT_EVENT_SELECT, FG_TRIGGER_OUTPUT_EVENT_SELECT
FG_TRIGGER_PULSEFORMGEN0_DELAY, FG_TRIGGER_PULSEFORMGEN0_DELAY et al.
FG_TRIGGER_PULSEFORMGEN0_DOWNSCALE, FG_TRIGGER_PULSEFORMGEN0_DOWNSCALE et al.
FG_TRIGGER_PULSEFORMGEN0_DOWNSCALE_PHASE, FG_TRIGGER_PULSEFORMGEN0_DOWNSCALE_PHASE et al.
FG_TRIGGER_PULSEFORMGEN0_WIDTH, FG_TRIGGER_PULSEFORMGEN0_WIDTH et al.
FG_TRIGGER_PULSEFORMGEN1_DELAY, FG_TRIGGER_PULSEFORMGEN0_DELAY et al.
FG_TRIGGER_PULSEFORMGEN1_DOWNSCALE, FG_TRIGGER_PULSEFORMGEN0_DOWNSCALE et al.
FG_TRIGGER_PULSEFORMGEN1_DOWNSCALE_PHASE, FG_TRIGGER_PULSEFORMGEN0_DOWNSCALE_PHASE et al.
FG_TRIGGER_PULSEFORMGEN1_WIDTH, FG_TRIGGER_PULSEFORMGEN0_WIDTH et al.
FG_TRIGGER_PULSEFORMGEN2_DELAY, FG_TRIGGER_PULSEFORMGEN0_DELAY et al.
FG_TRIGGER_PULSEFORMGEN2_DOWNSCALE, FG_TRIGGER_PULSEFORMGEN0_DOWNSCALE et al.
FG_TRIGGER_PULSEFORMGEN2_DOWNSCALE_PHASE, FG_TRIGGER_PULSEFORMGEN0_DOWNSCALE_PHASE et al.
FG_TRIGGER_PULSEFORMGEN2_WIDTH, FG_TRIGGER_PULSEFORMGEN0_WIDTH et al.
FG_TRIGGER_PULSEFORMGEN3_DELAY, FG_TRIGGER_PULSEFORMGEN0_DELAY et al.
FG_TRIGGER_PULSEFORMGEN3_DOWNSCALE, FG_TRIGGER_PULSEFORMGEN0_DOWNSCALE et al.
FG_TRIGGER_PULSEFORMGEN3_DOWNSCALE_PHASE, FG_TRIGGER_PULSEFORMGEN0_DOWNSCALE_PHASE et al.
FG_TRIGGER_PULSEFORMGEN3_WIDTH, FG_TRIGGER_PULSEFORMGEN0_WIDTH et al.
FG_TRIGGER_QUEUE_FILLLEVEL_EVENT_OFF_THRESHOLD, FG_TRIGGER_QUEUE_FILLLEVEL_EVENT_OFF_THRESHOLD
FG_TRIGGER_QUEUE_FILLLEVEL_EVENT_ON_THRESHOLD, FG_TRIGGER_QUEUE_FILLLEVEL_EVENT_ON_THRESHOLD
FG_TRIGGER_QUEUE_FILLLEVEL_THRESHOLD_CAM0_OFF, FG_TRIGGER_QUEUE_FILLLEVEL_THRESHOLD_CAM0_OFF et al.
FG_TRIGGER_QUEUE_FILLLEVEL_THRESHOLD_CAM0_ON, FG_TRIGGER_QUEUE_FILLLEVEL_THRESHOLD_CAM0_ON et al.
FG_TRIGGER_QUEUE_FILLLEVEL_THRESHOLD_CAM1_OFF, FG_TRIGGER_QUEUE_FILLLEVEL_THRESHOLD_CAM0_OFF et al.
FG_TRIGGER_QUEUE_FILLLEVEL_THRESHOLD_CAM1_ON, FG_TRIGGER_QUEUE_FILLLEVEL_THRESHOLD_CAM0_ON et al.
FG_TRIGGER_QUEUE_FILLLEVEL_THRESHOLD_CAM2_OFF, FG_TRIGGER_QUEUE_FILLLEVEL_THRESHOLD_CAM0_OFF et al.
FG_TRIGGER_QUEUE_FILLLEVEL_THRESHOLD_CAM2_ON, FG_TRIGGER_QUEUE_FILLLEVEL_THRESHOLD_CAM0_ON et al.
FG_TRIGGER_QUEUE_FILLLEVEL_THRESHOLD_CAM3_OFF, FG_TRIGGER_QUEUE_FILLLEVEL_THRESHOLD_CAM0_OFF et al.
FG_TRIGGER_QUEUE_FILLLEVEL_THRESHOLD_CAM3_ON, FG_TRIGGER_QUEUE_FILLLEVEL_THRESHOLD_CAM0_ON et al.
FG_VANTAGEPOINT, FG_VANTAGEPOINT
FG_WIDTH, FG_WIDTH
FG_XOFFSET, FG_XOFFSET
FG_YOFFSET, FG_YOFFSET
Format, Output Format

I

Image Select, Image Selector
Image Selector, Image Selector
Image Transfer, Image Transfer to PC Memory

L

Lookup Table, Lookup Table
Lookup Table::Applet Properties, Applet Properties

M

Miscellaneous, Miscellaneous
Miscellaneous::Debug, Debug
Miscellaneous::Debug::Input, Input
Miscellaneous::Debug::Output, Output

O

Output Format, Output Format
Overflow, Overflow
Events, Events
Overflow::Events, Events

P

PC Interface, Image Transfer to PC Memory
Pixel Format, CoaXPress
Processing, Processing
Processor, Processing

R

Region of Interest, ROI
ROI, ROI

S

Sensor Geometry, Sensor Geometry
Software Interface, Software Interface
Specifications, Features of Applet Acq_QuadCXP6x1AreaGray

T

Trigger, Trigger
Activate, FG_TRIGGERSTATE
Busy, FG_SOFTWARETRIGGER_IS_BUSY
Bypass, Bypass External Trigger Signals
Camera Signal Mapping, Camera Out Signal Mapping
Debounce, FG_TRIGGERIN_DEBOUNCE
Debugging, Hardware System Analysis and Error Detection / Trigger Debugging
Digital Input, Digital Input/Output Mapping, FG_GPI, FG_FRONT_GPI
Digital Input Output Mapping, Digital Input/Output Mapping
Digital Output, Digital Input/Output Mapping, External Trigger Signals / IO Triggered, Digital Output
Downscale Input, FG_TRIGGERIN_DOWNSCALE
Encoder, External Trigger Signals / IO Triggered
Error Detection, Hardware System Analysis and Error Detection / Trigger Debugging
Events, Event Overview
Exceeded Period Limits, FG_TRIGGER_EXCEEDED_PERIOD_LIMITS
Exsync, External Trigger Signals / IO Triggered
External, External Trigger Signals / IO Triggered, FG_AREATRIGGERMODE, External
Flash, External Trigger Signals / IO Triggered, Control of Three Flash Lights
Frame Rate, Internal Frequency Generator / Grabber Controlled
Framerate, FG_TRIGGER_FRAMESPERSECOND
Generator, Internal Frequency Generator / Grabber Controlled, FG_AREATRIGGERMODE
GPI, FG_GPI, FG_FRONT_GPI
Grabber Controlled, Internal Frequency Generator / Grabber Controlled
Image Trigger, External Trigger Signals / IO Triggered
Input, Trigger Input, FG_GPI, FG_FRONT_GPI
Input Statistics, Statistics
IO Triggered, External Trigger Signals / IO Triggered
Length, Internal Frequency Generator / Grabber Controlled
Lost Trigger, Hardware System Analysis and Error Detection / Trigger Debugging, FG_TRIGGER_EXCEEDED_PERIOD_LIMITS
Missing Frame Response, FG_MISSING_CAMERA_FRAME_RESPONSE
Mode, FG_AREATRIGGERMODE
Multi Camera, Multi Camera Applications / Synchronized Cameras
Multiply Pulses, Sequencer
Output, Digital Output
Output Event, Output Event
Output Statistics, Statistics
Period, FG_TRIGGER_FRAMESPERSECOND
Pin Allocation, Digital Input/Output Mapping
Polarity Input, FG_TRIGGERIN_POLARITY, FG_TRIGGERIN_STATS_POLARITY
Pulse Form Generator, Pulse Form Generator 0
Pulse Multiplication, Control of Three Flash Lights
Queue, Software Trigger with Trigger Queue, External Trigger with Trigger Queue, Queue
Sequencer, Control of Three Flash Lights, Sequencer
Signal Length, Internal Frequency Generator / Grabber Controlled
Signal Width, Internal Frequency Generator / Grabber Controlled
Software Controlled, Software Trigger
Software Trigger, Software Trigger, FG_AREATRIGGERMODE, FG_SENDSOFTWARETRIGGER
Start, FG_TRIGGERSTATE
Stop, FG_TRIGGERSTATE
Synchronized, Multi Camera Applications / Synchronized Cameras, FG_AREATRIGGERMODE
Synchronized Cameras, Multi Camera Applications / Synchronized Cameras
System Analysis, Hardware System Analysis and Error Detection / Trigger Debugging
Trigger IO, Digital Input/Output Mapping
Width, Internal Frequency Generator / Grabber Controlled
Trigger::Camera Out Signal Mapping, Camera Out Signal Mapping
Trigger::Digital Output, Digital Output
Trigger::Digital Output::Statistics, Statistics
Trigger::Output Event, Output Event
Trigger::Pulse Form Generator 0, Pulse Form Generator 0
Trigger::Pulse Form Generator 1, Pulse Form Generator 1
Trigger::Pulse Form Generator 2, Pulse Form Generator 2
Trigger::Pulse Form Generator 3, Pulse Form Generator 3
Trigger::Queue, Queue
Trigger::Sequencer, Sequencer
Trigger::Trigger Input, Trigger Input
Trigger::Trigger Input::External, External
Trigger::Trigger Input::Software Trigger, Software Trigger
Trigger::Trigger Input::Statistics, Statistics