VisionPro uses objects called acquisition FIFO (first-in first-out) queues to acquire images. To acquire an image, you issue a request to the FIFO. After issuing the request, you can either proceed with other tasks (including issuing more acquisition requests), or you can wait until the acquisition process completes and the image is available. The acquisition FIFO processes the oldest request first and queues any other requests that may arrive while an image is being acquired. As you obtain images, they are removed from the FIFO.
This topic contains the following sections.
VisionPro supports a variety of camera types. The following topics provide specific information on acquiring images based on the type of camera you are using:
- Acquiring Images with a CCD Camera and Frame Grabber
- Acquiring Images with a Line Scan Camera
- Acquiring Images with GigE Vision Cameras
| Term | Definition |
| acquisition FIFO | An object that maintains a first-in first-out queue of acquisition requests. Typically, you create one acquisition FIFO for each camera connected to the frame grabber. |
| acquisition properties | A set of parameters that control the way a camera works or the way that a camera interacts with its acquisition FIFO. |
| asynchronous simultaneous acquisition | An image acquisition method in which two or more FIFOs receive acquisition requests and acquire images at the same time. |
| automatic triggering | A method that begins image acquisition when a pulse is detected on a trigger line. Also called hardware triggering. |
| Camera Configuration File (CCF) | A file stored in the in the VisionPro bin directory (by default C:\Program Files\Cognex\VisionPro\bin) that contains information used by the acquisition system to create a video format object for a particular camera. Not all frame grabbers and CVMs use CCFs. |
| Cognex Video Module (CVM) | Hardware that provides the interface to different kinds cameras. CVMs can be built into the frame grabber or factory-installed as daughter cards. CVMs are specified by a number, such as CVM4. |
| FIFO | A first-in first-out list. Items are removed from a FIFO in the same order in which they were added. |
| frame grabber | Hardware that digitizes images, and makes them available to software. In CVL, the objects that represent frame grabbers describe the capabilities of the hardware and the video formats the hardware supports. |
| manual triggering | A method that begins image acquisition when a function is invoked. Also called software triggering. |
| simultaneous acquisition | Acquiring images from more than one FIFO at the same time. |
| synchronous simultaneous acquisition | An image acquisition method that lets you designate a master FIFO and one or more slave FIFOs; when the master FIFO receives an acquisition request, the slave FIFOs begin acquiring images also. |
| ticket | A value returned by StartAcquire that you can pass to CompleteAcquire to get the image that corresponds to a specific acquisition request. |
| trigger event | A signal on a trigger line or a function invocation that starts an image acquisition. |
| trigger line | A dedicated hardware input line on the frame grabber used to signal the acquisition software to start an image acquisition in response to an external event. |
| video format | A description of camera type, image size, and image depth. |
This section contains the following subsections.
ICogAcqFifo are created by ICogFrameGrabber objects. The frame grabber installed on your computer controls any cameras connected to it. The specific frame grabber model that you have installed determines the kinds of cameras you can use and which video characteristics are available. When you ask a frame grabber to CreateAcqFifo an acquisition FIFO, you specify the video format, which describes the camera you are using, and the pixel depth of images you will acquire with that camera. Once you create an acquisition FIFO, you cannot change the frame grabber that it is associated with, and you cannot change the video format. You can, however, always create a new acquisition FIFO.
Depending on the particular model, a frame grabber will have one or more NumCameraPorts to which you can connect cameras. After you create an acquisition FIFO, you can CameraPort the camera port that it is associated with. You should keep in mind, however, that a frame grabber may not be able to acquire images from all camera ports simultaneously.
You can also create a slave acquisition FIFO from an existing FIFO to acquire images from two (or more) sources simultaneously. See Simultaneous Acquisition later in this document to learn more about master/slave FIFOs.
A video format describes a specific camera model and various parameters that control the physical interface between the camera and the frame grabber such as the image size, maximum pixel depth, and synchronization source. Cognex supplies video formats as Camera Configuration Files that specify these parameters. Although they are not user-editable, you can view these CCF files. The VisionPro installer installs these files in the VisionPro bin directory which is by default C:\Program Files\Cognex\VisionPro\bin.
In VisionPro, you specify video formats as a text string that includes the camera manufacturer, model, and synchronization information. For example, "Sony XC-75 640x240 IntDrv CCF" is a video format name. Some of the video formats in the CCF directory work only with particular Cognex frame grabbers. To help you choose from video formats that work with your frame grabber, and to ensure that you use a valid video format name, use the frame grabber property AvailableVideoFormats, which returns a list of compatible video formats.
For example, the following table shows you how to interpret the video format name "Sony XC-75 320x240 IntDrv (rapid-reset, shutter-sw-SDONPISHA) CCF":
| Manufacturer and Model | Image Size (width x height) | Synchronization Source | Special Properties | CCF |
| Sony XC-75 | 320x240 | IntDrv | (rapid-reset, shutter-sw-SDONPISHA) | CCF |
Identifies a specific camera model | The image size in pixels | IntDrv: Internal drive. Synchronization signal is provided by the frame grabber. ExtPLLCo: External PLL Composite signal. Signal is provided by the camera. ExtPixClk: External Pixel Clock. Signal is provided by an external pixel clock. To learn more about synchronization models, see the topic Synchronization Models. | Additional properties such as rapid-reset and shuttering. | A CCF-based video format. |
Most Cognex frame grabbers allow you to connect more than one camera. However, that does not mean that you can acquire images from all four cameras at the same time. The number of simultaneous image acquisitions depends on the number of video channels your frame grabber has. A video channel is the hardware on the frame grabber that processes images; one video channel can serve more than one camera port. VisionPro provides a function, NumVideoChannels, that reports the number of video channels your frame grabber has.
On some frame grabbers there may be different kinds of camera ports. For example, there may be camera ports for analog and for digital cameras. In such cases you can GetNumCameraPorts to tell you how many camera ports are available for a given camera format, or you can NumCameraPorts to tell you how many camera ports are available for the video format you selected when you created it.
This section contains the following subsections.
An acquisition FIFO acquires images in response to an acquisition request. The way that a request is issued depends on which CogAcqTriggerModelConstants you specify for the acquisition FIFO. The trigger model you choose depends on the specific needs of your vision application. You can acquire images:
- by calling a function
- by sensing a pulse from an external source on a trigger line
- by a combination of function call and external trigger
- by allowing the acquisition system to acquire images as quickly as possible
In addition to these, you can also use master/slave acquisition, described later in this document, to acquire from two or more FIFOs at the same time.
The simplest way to acquire images is to use manual triggering. With this trigger model, you call StartAcquire to issue an acquisition request and then call CompleteAcquire to obtain the image once it is available. This two-step process allows you to issue acquisition requests and continue with other operations (possibly issuing more acquisition requests) without waiting for the image to be acquired. If your application does not require this kind of processing, you issue the acquisition request and wait for the image by calling Acquire.
StartAcquire returns a ticket that you can later pass to CompleteAcquire if you want to get the image that pertains to a specific acquisition request.
For some applications, the best way to acquire an image is to issue the request in response to an external trigger. Every frame grabber provides at least one trigger input that can be used to issue an acquisition request. When the acquisition software detects a TriggerLowToHigh on the trigger line, it starts the acquisition. With automatic triggering, it is an error to start an acquisition manually. Your application calls CompleteAcquire to obtain the images in the order they are acquired.
The size of an acquisition FIFO is limited to 32 requests, so you must obtain images to remove them from the FIFO. If you do not, the FIFO will fill up and subsequent images will not be acquired. Use GetFifoState to monitor the number of pending acquisition requests in a FIFO. You can use CompleteAcquire to obtain outstanding completed images or Flush to remove outstanding requests. If you need to ignore trigger signals, you can use TriggerEnabled to disable triggers for the FIFO.
It is not an error for two or more FIFOs to use the same trigger line. However, the first FIFO that gets the hardware resources will continue to use them, and any other FIFOs using that trigger will be blocked.
Semi-automatic triggering is a mixture of manual triggering and automatic triggering. As in manual triggering, your application calls a function to start the acquisition request. But as in automatic triggering, subsequent acquisition requests are issued whenever there is a transition on the trigger input line.
In this trigger mode, the acquisition system acquires image at the highest frame rate that the camera and frame grabber support. Your application must call CompleteAcquire to get the next available image. It should not call StartAcquire.
This section contains the following subsections.
VisionPro provides two kinds of simultaneous acquisition. Asynchronous simultaneous acquisition allows two or more FIFOs to receive acquisition requests and to acquire images at the same time. Synchronous simultaneous acquisition lets you designate a master FIFO and one or more slave FIFOs; when the master FIFO receives an acquisition request, the slave FIFOs begin acquiring images also.
The number of NumVideoChannels on your frame grabber determines the number of images you can acquire at the same time. The Cognex MVS-8100L frame grabber provides one video channel.
In asynchronous simultaneous acquisition, two or more acquisition FIFOs can process acquisition requests and can acquire images without waiting for another FIFO to finish. Asynchronous simultaneous acquisition is useful in applications where you have two or more cameras responding to different triggers.
If you are using manual triggering, you can call StartAcquire to issue acquisition request for each FIFO. If you are using automatic triggering, each FIFO's trigger signal starts the acquisition. As long as each FIFO is associated with a different NumVideoChannels, each acquisition request is processed independently.
If the frame grabber you are using has only one video channel, such as the MVS-8100L, acquisition requests are queued until the FIFO that is using the video channel has finished. This is sometimes called pipelined acquisition.
In synchronous simultaneous acquisition (also called master/slave acquisition), a single acquisition request to one FIFO (called the master) can cause one or more FIFOs (called slaves) to start acquiring images as well. Synchronous simultaneous acquisition is well suited for applications where you want to acquire images from two or more cameras in response to a single signal. Only frame grabbers with more than one video channel can use master/slave acquisition.
Since the master FIFO provides the timing information, all of the cameras involved in synchronous simultaneous acquisition should be of the same type and video format to obtain the best results.
CreateSlaveAcqFifo lets you create slave FIFOs from a master FIFO that you created previously. If the frame grabber you are using does not have enough video channels, you cannot create slave FIFOs.
The slave FIFO that CreateSlaveAcqFifo returns has its camera port set so that it is compatible with the camera port of the master FIFO. It is not an error for two FIFOs to share the same camera port, but you may get unexpected behavior. If CreateSlaveAcqFifo cannot find a suitable camera port, it returns an error.
Once the master/slave FIFOs are set up, any acquisition request to the master FIFO, either through a trigger or through a call to StartAcquire, results in an acquisition request sent to the slave FIFOs. You use CompleteAcquire to obtain the image from the master FIFO and each of the slave FIFOs.
Line scan cameras capture images of objects one row of pixels at a time, building the image incrementally as the object moves past the camera. A line scan camera can capture images with a format of 1024 x 4096, 2048 x 2048, or 2048 x 4096, and you can use two line scan cameras to capture two images simultaneously. Most applications that use a line scan camera use a region of interest to focus on a particular area of the total image available.
Line scan cameras use an encoder to keep track of the position of the object as it travels past the camera, communicating this information to the CVM on the frame grabber to control when image acquisitions begin and end. You must provide the acquisition FIFO with the number of encoder steps that correspond to a single image line, and the direction the encoder turns, either positive or negative. If you use two line scan cameras, each camera can use different encoders or both can use the same encoder.
Before you deploy your application to the production environment you can use a test encoder and have the VisionPro software simulate the signals received by an actual encoder. Using the TestEncoderEnabled can be helpful in developing your application away from the production environment or for troubleshooting the acquisition FIFO later. To troubleshoot images, you can use the test line scan camera ("Test LS 2048x2048"). This virtual camera produces images that consist of eight 256-pixel-wide light-to-dark gradients. VisionPro can support line scan cameras from Dalsa or Basler, depending on the specific frame grabber you use.
This section contains the following subsections.
Depending on the camera and other hardware you are using, you may want to set additional properties of an acquisition FIFO. The following table lists the properties you change, although some properties apply only to specific kinds of cameras. For example, the Digital Gain property works only with digital cameras.
Each of these acquisition FIFO properties is implemented as a separate COM interface. In order to manipulate a property, you must first obtain that property's interface from the acquisition FIFO object. If the property does not apply to the FIFO, then no interface is returned. The example code for each of the interfaces in this table shows how to obtain and use the interface.
| Property / Interface | Description | Frame Grabber Support |
| ICogAcq1394DCAMICogAcq1394DCAM | Properties of IEEE 1394 DCAM cameras, such as camera bandwidth. | IEEE 1394 DCAM Cameras |
| ICogAcqBrightnessICogAcqBrightness | The brightness level of the acquired image. | 8100L, 8501, 8504 |
| ICogAcqContrastICogAcqContrast | The contrast level of the acquired image. | 8100L, 8501, 8504 |
| ICogAcqExposureICogAcqExposure | For shuttered cameras, the shutter speed. For strobed acquisition, the duration of the strobe. | 8100L, 8501, 8504 |
| ICogAcqROIICogAcqROI | The region of interest (ROI) that allows you to acquire a subsection of an image. | 8501, 8504 |
| ICogAcqStrobeICogAcqStrobe | Controls whether a signal is sent to the strobe output line when an acquisition starts. | 8501, 8504 |
| ICogAcqStrobeDelayICogAcqStrobeDelay | Specifies the delay between the shutter pulse and the strobe pulse. | 8501, 8504 |
| ICogAcqTriggerICogAcqTrigger | The trigger model. | 8501, 8504 |
You need a light source to be able to acquire images. Your application will typically use one of three lighting sources:
- Ambient light
- A strobe
- A Cognex lighting device
With ambient light, once you set up your light sources, they remain on during the course of your application. You can use the ICogAcqBrightness and ICogAcqContrast properties to adjust the acquired image.
If you use a strobe light as your light source, you connect it to your frame grabber's ICogAcqStrobe. Whenever your application issues an acquisition request (either manually or because there was a signal on the trigger input line), the strobe fires.
For some applications, such as optical character recognition, a Cognex lighting device such as the Cognex acuLight provides the best lighting control. VisionPro provides the ICogAcqLight interface to control up to two lighting devices.
The Timeout controls how long to wait for an image to become available. This timeout period is useful in handling the case where a trigger was never received, but your application is still waiting for an image.
VisionPro provides the following five event handlers that fire as the acquisition system acquires images:
- The Changed event fires when an acquisition FIFO property is changed.
- The Flushed fires when an acquisition FIFO is flushed.
- The MovePart event fires after the camera has integrated the image, but (possibly) before it is available in video memory. When this event fires, it is safe to change the scene visible to the camera.
- The Complete event fires when an acquisition has completed and the image may be available. (The complete event fires even if an image is not available when the acquisition times out.)
- The Overrun event fires when an acquisition fails because, even though the acquisition system was able to obtain the required resources, it was unable to start the acquisition in a timely fashion.