Academic Company Events NI Developer Zone Support Solutions Products & Services Contact NI MyNI

Triggering Multiple FireWire Cameras Using Vision Builder AI on a Compact Vision System

0 ratings | 0.00 out of 5
Print

Overview

In many applications, more than one camera is required to meet the requirements of the application. For example the inspection might require a larger area than one camera can accommodate, or the inspection might have two stages that need to be monitored. The Compact Vision Systems (CVS) has the ability to acquire from multiple IEEE 1394 (FireWire) cameras, and in this document, Vision Builder for Automated Inspection will be used to program the CVS. On the CVS, there are three methods of acquisition: free run, direct triggered, and IMAQ I/O triggered. These three methods are described in detail in the Tutorial “Triggering a IEEE 1394 Camera Using Vision Builder AI on a Compact Vision System.” This tutorial develops the methods for acquiring from multiple cameras, but the hardware triggering setups will be similar. The example VBAI scripts included with this document have been programmed to operate with specific cameras on a CVS. To run these scripts, they must be altered to target the cameras connected to the CVS to be used. The settings of the acquisitions should remain the same, especially the acquisition modes (wait for next or immediate).

Unsynchronized Acquisition

To acquire from multiple cameras in free run mode, the two acquisition steps are placed sequentially with any number of intermediate steps, or even in a different state. Any VBAI script which acquires from two cameras, and does not specifically set up triggering to those cameras uses this mode. Any IEEE-1394 camera that can not be triggered must use this mode. The attached example script is the simplest form of this method. It acquires from one camera then acquires from the second. The order of the acquisitions does not matter, nor does the presence or absence of steps before, between, or after the acquisitions.

Hardware setup to trigger two cameras in free run mode.
Figure 1. Hardware setup to aquire from two cameras in free run mode.

Unsynchronized acquisition can be used in many applications. For example, an assembly line might have two unrelated stages moving slowly, and one CVS can be used to monitor both. Another example is security feeds, where the acquisitions can occur in series, and don’t need to be synchronized. Any task that requires independent or non time critical image acquisition can use this mode.

The largest benefit of this method is its simplicity. The acquisitions can be set up as two steps in a script without any complicated wiring or programming. However, with this simplicity comes an inherent lack of functionality. This method is not appropriate for any time critical application because the images are not triggered, but acquired whenever the previous step completes.

Synchronized – Externally Triggered

Externally triggering the cameras requires the trigger signal to be split and directly connected to the trigger input on each camera. In VBAI, the first camera acquisition step must be waiting for the trigger to occur (the acquisition mode must be set to wait for next image). The second acquisition should occur immediately after the first, and should be set to immediate acquisition mode. The process executes as follows: the VBAI script reaches the first acquisition, and waits for the trigger to occur. When the trigger occurs, the step acquires the first image, and proceeds to the second step. The second acquisition is set to immediate mode therefore the image acquired on the last trigger is saved to memory. As long a second triggers do not occur before the second acquisition step executes, the result will be that both steps have acquired an image on the same trigger.

Hardware setup to trigger two cameras from one sensor.
Figure 2. Hardware setup to trigger both cameras directly from the sensor.

Externally triggered acquisition can be used any time there is need to acquire two or more images simultaneously. For example, if a vision application requires an image with an abnormally wide area, two cameras can be used to acquire two adjacent images simultaneously, thereby covering the requisite area. Another example is an application which captures images of the same part from two different angles, and is triggered by a sensor on the assembly line. Any application in which multiple images must be acquired simultaneously on an externally generated TTL signal can use this method.

The benefit of this method is that the images are acquired simultaneously, and the programming is relatively simple. One con is that triggers will be missed if their period is shorter than the length of the VBAI script.

Synchronized – Programmatically Triggered

Programmatically triggering the camera requires the FPGA on the CVS to be programmed with IMAQ I/O Pulse steps. The IMAQ I/O Pulse step allows the user to drive output signals based on input triggers (see Figure 3). The implementation in hardware allows the signal generation to be hardware timed which makes the timing deterministic. The trigger generation is guaranteed to occur on the next 25 nanosecond clock cycle after the trigger input is detected. The trigger inputs to both IEEE 1394 cameras can be sourced by one trigger line, though this could be a problem for high speed triggering if the capacitive load of the IEEE 1394 cameras is too high. The preferred method is to use a separate trigger line on the CVS to trigger each camera. The latter method also allows the timing of the triggers to be set independently for fine adjustments in the timing of the triggering. The source of the trigger can either be one external trigger, two external triggers, or none at all. To achieve the latter case, the IMAQ I/O step is used, which generates a constant pulse stream with a user defined pulse width and period.


[+] Enlarge Image
Figure 3. Software setup of IMAQ I/O Pulse step to trigger each camera independently.

The timing of the triggering is critical in determining which mode to set the acquisitions in. The first acquisition should be set to wait for next image as in the previous triggering method. The second acquisition should be in immediate mode if its trigger is set to occur at the same time or a short period after the first. The definition of short in this case is the time it takes the CVS to acquire the image into memory and move on to the next acquisition step. The second acquisition should be set to wait for next image if its trigger occurs after the second acquisition step is reached.

Hardware setup to trigger two cameras from the CVS independently.
Figure 4. Hardware setup to trigger CVS from sensor, which in turn triggers cameras.

This method can be used in any application that requires the cameras to be synchronized on an external trigger, but either not immediately on the trigger edge or not simultaneously. For example, if the images were being acquired on the trigger signal from a flash, the acquisition should occur a short time after the trigger is received.

The benefit of this method is that it is highly configurable, because the FPGA is being customized to match the requirements of the process. For example the triggers can be offset by a constant time delay, so one camera is triggered before the other. One drawback however, is that the programming is more complex as it requires the IMAQ I/O step in VBAI.

Conclusion

Since the IEEE-1394 bus does not have built in triggering capabilities, the camera must be either triggered, or operated in free run mode. The trigger signal can either come from an external source, or be generated with IMAQ I/O. The required method of multiple camera acquisition is determined by the requirements of the application.

 

Downloads

vbai_multi_cam.zip

0 ratings | 0.00 out of 5
Print

Reader Comments | Submit a comment »

 

Legal
This tutorial (this "tutorial") was developed by National Instruments ("NI"). Although technical support of this tutorial may be made available by National Instruments, the content in this tutorial may not be completely tested and verified, and NI does not guarantee its quality in any way or that NI will continue to support this content with each new revision of related products and drivers. THIS TUTORIAL IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND AND SUBJECT TO CERTAIN RESTRICTIONS AS MORE SPECIFICALLY SET FORTH IN NI.COM'S TERMS OF USE (http://ni.com/legal/termsofuse/unitedstates/us/).