GigE Vision and frame grabbers

Companies engaged in machine-vision inspection are increasingly adopting the GigE Vision protocol. I asked Dwayne Crawford, product manager at Matrox Imaging, to explain how GigE Vision differs from other interfaces and how it works with frame grabbers.

Dwayne Crawford Product Manager, Matrox Imaging Courtesy of Matrox Imaging.

A: The earliest image solution fed camera data into a frame grabber, which reconstructed the image before sending it to the host. The host had to know a lot about the camera configuration and the frame grabber’s data format.

Camera Link standardized the data format. IEEE 1394 (FireWire) added another twist, incorporating a higher level of camera communication and allowing commercially available parts to lower costs.

GigE also incorporates commercial parts, but the camera describes itself to the host automatically. The application can now easily determine how the camera will behave. GigE also permits 100-m cable lengths, by far the longest of the available standards.

GigE addresses a variety of applications, but GigE Vision is intended for one and only one purpose—industrial machine vision. Its features are optimized for that task.

Q: How is GigE Vision different from what came before?

A: GigE Vision performs in software what frame grabbers did in hardware. Even protocols like Camera Link use frame grabbers to take some of the burden off the host. GigE Vision takes advantage of the power of current CPUs—in particular, their multicore architectures. The data crunching that image analysis requires would prove too slow in a single-core environment. But today, manufacturers offer dual, quad, or even eight cores in a single device or chipset.

Q: What kind of software is required?

A: A software driver communicates with the camera through the standard GigE Vision protocol and API (application programming interface) layers. It examines the incoming data, sorts it, and decides which is image data, which is command data, and so on. It can then unpack, reassemble, or perform color conversions on the image, presenting it in a suitable format for image-processing software.

Q: How are the drivers implemented?

A: We define three types of drivers. The first, a filter driver, handles all protocols—motion controllers, encoders, and so on—through a single cable, taking advantage of the indigenous Windows protocol stack. It identifies GigE Vision data, passing other data to the host unaltered.

The second, a stack-replacement driver, dedicates a special stack to GigE Vision, independently performing only GigE Vision through its own cable and network interface card (NIC). Its proponents contend that stack replacement saves a few steps and therefore performs better, but it also requires that the Ethernet controllers use GigE Vision cards that are matched and optimized for the particular GigE Vision camera.

We have developed a third type of driver as a compromise (and have incorporated it into our Solios GigE NIC). Like the filter driver, our driver handles all protocols through a single conduit, but we incorporate special hardware on the network card to reconstruct the data, sending it to the host as a single image instead of as a large number of individual packets. This approach gives users the benefits of the filter driver and outperforms the stack-replacement driver.