Gigabit Ethernet handles real-time inspection

Vision-based factory inspection systems for flat-panel displays, semiconductors, and circuit boards often acquire images directly from the manufacturing process and transfer them to a computer for analysis in real time. Traditionally, these types of applications have relied on costly specialized equipment to achieve their performance goals. Now, Gigabit Ethernet (GigE), the high-speed, third-generation version of the dominant global LAN (local area network) protocol, has emerged as an attractive alternative for transferring image data.

George Chamberlain, president of Pleora Technologies (Kanata, ON, Canada; www.pleora.com), claims that GigE offers numerous advantages over its predecessors. "GigE provides a simpler configuration than previous technologies," Chamberlain notes. "It doesn't require Camera Link equipment, LVDS [low-voltage differential signal] chips and connectors, frame grabbers, digital-signal processing cards, or unique cabling. Instead, it uses standard GigE equipment to deliver dedicated high-speed connections between cameras and PCs at full-duplex data rates of 1 Gbps.

"But development has not stopped there. Next-generation Ethernet systems will reach speeds of 10 Gbps—higher even than today's full-rate Camera Link systems. GigE's networking flexibility supports almost every type of camera-to-PC connection, including simultaneous transfer of image data to multiple destinations in PC-based compute farms, a capability known as multicast. [A compute farm is a group of PCs—usually rack mounted—working together to perform one or more processing tasks.] In addition, because it uses industry standard equipment and cabling, and because of the lower processing and maintenance costs of PC compute farms, GigE costs less than alternatives.

"Nevertheless, as with all real-time vision systems," continues Chamberlain, "GigE-based systems must meet exacting performance requirements. They must transport data at high speeds with no variation in delivery times, ensure that vision applications have uninterrupted access to large amounts of CPU power in host PCs, trigger predictable responses from cameras and other system elements, and ensure data delivery."

According to Chamberlain, essential to the production process is a small and consistent end-to-end latency—the time required between triggering image acquisition and delivering the resulting image to a PC for analysis. For real-time vision applications, he contends that latencies must not exceed 500 µs, depending on equipment and setup. Longer than that would mean leaving more space between products during manufacturing, slowing throughput.

Even when a process experiences most latencies in the 200-µs range, if they sometimes balloon to 10 or 20 ms, the production process must be set up to handle this worst case—a wasteful but necessary precaution that again reduces manufacturing capacity.

In PC-based vision systems, end-to-end latency consists of:

• IP packet formation and queuing for transfer over the GigE link,
• GigE link latency, and
• data transfer to PC memory.

Chamberlain contends that link latency is minimal where data transfers at the full 1-Gbps wireline rate, and he recommends concentrating on the "hot spots" at either end.

Many Ethernet video-delivery setups rely on general-purpose software—the Windows or Linux IP stack and network-interface-card (NIC) drivers—for data transmission and reception. Such systems are designed to accommodate a range of applications as well as varying demands for processing time. As a result, the latency is both too long and too unpredictable for real-time vision applications.

Chamberlain's company, Pleora, has addressed this problem with a product that uses GigE to transfer image data to a computer for analysis. The product, iPORT, deploys a hard-wired, FPGA-based IP engine; it is available as a module as well as in a PCB form factor that can be built into a camera. This single-purpose hardware receives data, processes IP packets at the full 1-Gbps rate, and queues them.

At the PC, end, Pleora uses its iPORT IP device driver rather than the standard NIC drivers to process incoming packets in the operating-system kernel and transfer image data directly into PC memory, thus bypassing the Windows stack. This approach avoids bogging down the CPU, ensuring that vision applications have uninterrupted CPU access to process data.

Many inspection algorithms require CPU resources that exceed the capabilities of today's PCs. Some systems solve this problem by incorporating DSP architectures. Although this approach will work with GigE, GigE's native multicast capabilities may be more cost effective and easier to use. Multicasting allows inspection processing tasks to be shared by several PCs, either simultaneously or in a multistaged processing pipeline.

Chamberlain notes that efficient inspection requires the precise triggering of lighting, cameras, and push arms. Some vision systems send triggers from PC-based application software to the inspection site. Since standard PC configurations run applications on top of Windows and NIC drivers, such remote trigger requests can stall in queues and cause delays. Pleora's iPORT eliminates delays by delivering hardware-based local triggering through a general-purpose I/O port (see figure). In addition, iPORT's time stamps let users trigger events precisely and synchronize system elements independent of latency variation.

In this GigE-based inspection system, images transfer in real time to a preprocessing PC, which distributes them via a switch to a compute farm for further analysis.

Chamberlain notes that standard IP transfer protocols have unacceptable limitations for real-time vision systems. The transmission control protocol (TCP) validates data transfer, guaranteeing packet reception, but its latencies are large and unpredictable, it makes high demands on CPU resources, and its data throughput is low. The user-defined protocol (UDP) offers low-latency and high-speed transfer performance, but it cannot guarantee packet reception. Similarly, the real-time protocol (RTP) supports predictable, real-time multimedia streaming, but it also offers no guarantee of packet reception.

iPORT offers a compromise. It employs UDP for its low and predictable latency characteristics but runs a proprietary protocol on top. This extra protocol includes features for transferring video information and automatic error-checking to ensure packet reception. It labels packets when it sends them to the host PC. If any are missing, the host automatically requests that those packets—and only those packets—be resent.

Because the Pleora method transfers data directly into user memory and analyzes packets at the kernel level, the system resends missing packets and inserts them in the correct memory locations without adversely affecting either system performance or latency. The approach is compatible with all standard IP networks and handles all operations between cameras and PCs (layers 5 to 7 of the standard seven-layer protocol stack). It removes network-connection complexities from vision applications so system developers can take full advantage of GigE's capabilities.

Chamberlain contends that application-specific hardware and software can overcome GigE limitations. He suggests that these technology innovations can deliver sufficient performance for real-time control in a spectrum of demanding vision systems.