Since its adoption in 2006, the GigE Vision standard has become a favorite of the machine vision industry, growing to more than 30% of units sold annually, according to data compiled by the Automated Imaging Association. There have been many reasons for the standard’s rapid rise in popularity, including its high data rate (1,000 megabits per second, or Mbps), long transmission distance without hubs or repeaters (up to 100 meters), use of low cost standard cables, and direct “grabberless” connection capability to host computers. 

 

One fundamental characteristic of the standard that is often overlooked in articles describing its benefits is the fact that it is the only machine vision interface standard built around a true “network” architecture. This gives it some unique advantages over the point-to-point approaches employed by the other machine vision interfaces. 

 

A prime example of this is GigE Vision’s ability to use a technique called multicasting across a network of connected cameras, PCs and other devices. While this lesser-known capability provides unique advantages for machine vision users that are unavailable with any other type of interface, it can also create a variety of problems if not utilized properly.

 

To understand multicasting, it is important to first understand the two main rules that any GigE Vision system must follow:

 

Only one application/host can have complete control of a camera at a time. (This is known as the primary application.)

 

Both the host and its camera IP addresses must be on the same local subnet.

 

Other hosts may be allowed to access a controlled camera but only as secondary applications, which means they are restricted to read-only access to the camera’s feature values and won’t normally receive any images.

 

In normal operation a camera is controlled by a single host and when it streams images, all of the image data packets are addressed specifically to the controlling host. In this case, even though the host and camera are on a network using a networked protocol, the actual image stream is unicast from the camera to the host. No other hosts will normally receive this stream and if the data packets go through GigE switches they will be routed to only the addressed host.

 

In multicasting mode a GigE camera streams its images to an IP address within the special multicast range (see below) rather than to the controlling host. 

 

Multicast IP addresses are a special address range from 239.0.0.0 to 239.255.255.255 for administratively-scoped (local) multicast addresses and from 224.0.1.0 to 238.255.255.255 for globally-scoped (Internet-wide) multicast addresses.

 

Since packets addressed to this multicast IP range are distributed across the network and passed on to all receivers this means that any host on the network can connect to the camera and receive images from it. So there could be dozens of receiving hosts all listening in to a single camera’s stream and receiving the same image.

 

Note that this doesn’t violate the above GigE rules since there is still only a single controlling host which can start and stop acquisition and all the systems have IP addresses within the local subnet. The receive-only hosts still have only read-only access to the camera’s features but with one exception: they are allowed to request resends in the case of any missed image packets.

 

So to summarize, multicasting only differs from normal streaming in that the image packets are addressed to a special IP address rather than a single host and secondary applications, in addition to accessing the camera’s feature values, are allowed to receive image streams and request packet resends.

 

The big benefit of multicasting is that it takes advantage of the network nature of GigE Vision and allows multiple hosts to receive images from a camera. This eliminates the need to retransmit images or ROIs of images to other hosts for display or processing.

 

For example, a backend system acting as the primary application can control and acquire from a camera while a secondary operator system can also receive and display the camera images without any extra work or bandwidth. The shared images come for free.

 

Multicasting also makes it easy to set up a distributed processing system without having to worry about explicitly distributing the input image data. So a set of processing nodes could all receive the multicast streamed images from a camera, independently process separate ROIs, and pass only the results to a central node. Since the network automatically handles the distribution of the image stream, it’s almost trivial to scale up the number of processing nodes.

 

The exact steps to set up multicasting on the camera may vary from vendor to vendor depending on the GigE Vision API being used, but most only require that the desired multicast address be written to a single register for each data stream. For cameras following the GenICam SFNC (Standard Feature Naming Convention) this will be GevSCDA.

 

In most cases, the primary application program will initiate multicasting by sending a command to one or more cameras that it intends to control. The primary application also has to make sure that the host is configured to receive packets from the appropriate multicast address(es). Secondary hosts must also be configured to receive data from the appropriate multicast address(es).

 

Some software development kits offer features to streamline this setup process. For example, a single function call from the primary application can be used to initiate multicasting mode for both the camera(s) and the primary host, while secondary hosts automatically detect and configure themselves for multicasting as they are connected to cameras over the network. Taking the time to evaluate and select a development environment that has been optimized for multicasting can make application programming much easier for the developer.      

 

Given its benefits and ease of setup, multicasting would seem to be ideal for nearly every system. However there are circumstances when the side effects of multicasting may outweigh any benefits.

 

One case is a system where there are multiple cameras multicasting to multiple hosts. Typically this is done through a switch or system of switches.  

 

In non-multicast operation there is no problem with the required bandwidth since each camera is essentially unicasting to a single host and the switches can keep the traffic separate. However with multicasting enabled it is quite possible to unintentionally exceed the available network bandwidth since camera data could be routed to every system on the network—both hosts and cameras. In the worst case this can essentially become a self-created DOS (Denial of Service) attack where there are so many incoming packets that aren’t relevant to a host that it is simply unable to do any work other than dealing with the packets. 

 

To avoid this, the network should be laid out to physically separate the traffic as much as possible and switches should be configured to eliminate unnecessary traffic routes—in other words, multicast packets should only be routed from cameras and to hosts.

 

Another use of multicasting that leads to problems is using multicasting as a way to keep multiple image handling processes on a single host completely independent. Here a master process would start the camera multicasting an image stream and each additional process would connect to the camera and receive images as a secondary application. The idea behind this is that it makes the overall application more robust since each process is responsible only for its own processing and can easily be restarted in the event of a crash without having to reestablish control of the camera. 

 

Unfortunately, while tempting, in practice this often leads to more complexity and consequent application bugs than having all image acquisition handled by a single process on the host. To avoid such problems, it is best to use multicasting only when you have multiple hosts.

 

Multicasting has long been viewed by users as a murky and complicated area of the GigE Vision standard. For this reason, it is often overlooked by system developers. However, as shown here, it can actually be quite simple to set up while providing a number of unique benefits.  If you have an application that could possibly benefit from a networked architecture with distributed processing, multiple ROIs, or multiple monitoring points, make sure you consider GigE Vision multicasting. And when getting started, be sure to work with consultants, integrators, or equipment suppliers with experience implementing multicasting projects.

 

TECH TIPS GigE Vision is the only machine vision interface standard built around a true “network” architecture.  This gives it some unique advantages over the point-to-point approaches employed by the other machine vision interfaces.  A prime example of this is GigE Vision’s ability to use a technique called multicasting across a network of connected cameras, PCs and other devices.