Configuring Your Network Adaptor for GigE Visionscape

[Omron Forums Support]

GigE cameras need GigE NICs (network interface controllers). NICs can come built-in to a PC on the motherboard or as PCI or PCIe cards and there are also some USB to Ethernet adaptors available.
Microscan recommends the use of NICs that make use of the Intel Pro/1000 chipsets. That doesn’t mean that no others work, it’s just that we have found that the Intel-based products DO work.
Normally, when you put a NIC into a PC it will be recognized as a network adaptor and inherit all the usual network protocols. These usually include the following:
  

Client for Microsoft Networks
File and Printer Sharing for Microsoft Networks
QoS Packet Scheduler
Internet Protocol (TCP/IP)

 
 Some systems split internet protocol into two separate entries TCP/IP rev 4 and rev6. All Microscan cameras use TCP/IP rev 4.

There may also be anti-virus filters such as “McAfee NDIS Intermediate Filter.”
 
GigE cameras should be on their own dedicated network. This has nothing to do with Microsoft or sharing. Visionscape installs a dedicated driver for GigE cameras which is called JAI GigE Vision Filter Driver. This filter driver recognizes GigE vision packets and filters them so that the CPU doesn’t have to deal with sorting them out. This lowers the CPU load, freeing it up for other things.
  
A GigE vision NIC only needs two items:
 

JAI GigE Vision Filter Driver
Internet Protocol (TCP/IP) (or TCP/IP rev 4)

  
Uncheck all other items from the NIC you want to use for cameras if it will only be used for cameras. (If you use it for cameras one day and regular networking the next then leave everything on)
IMPORTANT: If you are using a third-party camera and you have installed that manufacturer’s control software make sure that you disable it in the Properties dialog below. It will almost certainly conflict with the JAI software that Visionscape uses to receive images from the cameras.

In the picture above, note the two check boxes at the bottom of the dialog box. If you have these checked then you will see a small icon for each NIC in the task bar. This is a useful visual indicator of network status.

 The filter driver requires no setup whatsoever. Clicking on the TCP/IP Properties button will bring up this dialog box.

There is usually no need for cameras to be on a DHCP network so please choose a static address that starts with 192.168.x.x. 192.168 is reserved for private networks. In the picture above the address is set to 192.168.254.2 with the subnet mask set to 255.255.255.0. The mask means that all devices connected to the NIC should have addresses that start with 192.168.254.x. It is recommended that you steer clear of using any address that ends with .1 (for instance 192.168.254.1) as this is sometimes used by networks for gateways (devices that convert one sort of protocol to another).

In addition, you should not use any address like 192.168.x.254 because the GigE driver looks at the last number (254) and enumerates all cameras on the NIC with addresses above that. In the case of the NIC ending in 254 the first camera would end in 255 which will not work.
 
 Short version: Set your NIC to end in .2 ! For instance 192.168.2.2. If you have more than one camera NIC then set the second one to 192.168.3.2 etc.

 

Optimizing the Network Adaptor for use with GigE Cameras

 
To reduce the load on the PC to a minimum you need to optimize the NIC. Visionscape does not do this optimization because every installation has different requirements and every NIC has different limitations. Optimization is done as follows:

1. Go to the network adaptor properties and click on the Configure button next to the network card description.

2. Clicking on Configure… should bring up the following dialog:
   
3. Next, click on the Advanced tab and you should see a list of parameters that can be tuned by the user.

You need to look for Jumbo Frames (sometimes called Jumbo Packets) .Set this to the maximum available – typically 9014 bytes but only 4k or 5k on some NICs.

4. You next need to click on either Receive Descriptors (if available). This is sometimes grouped within Performance Options:

 

5. Click on the Properties button.

The default value for receive descriptors is 256. Set this to the maximum available - typically 2048.

6. Save the changes by clicking on the OK button(s).

So what did you just do? You enabled the NIC to handle larger packets. This means that, instead of sending image data from the camera in chunks of 1500 bytes they can now come in chunks of 9014. That means about 6 times fewer packets for each image.

Increasing the number of receive descriptors enables the NIC to juggle more packets at any one time. If the processor is a little busy when an image arrives the NIC may not be able to send on the data immediately but data is still coming in from the camera. These receive descriptor buffer the system against this. (It is almost essential when using a CMG50 camera).
 
 Note: In some cases we have seen issues with missing or dropped packets from GigE cameras even with all the above apparently set correctly. On one occasion this was fixed by going to the Interrupt Moderation Rate in the Performance Options dialog and changing the setting there from Adaptive to Minimal.

On another occasion everything appeared correct but we still saw missing packets. In this case we were using a gigabit switch. Changing the switch fixed the problem.

The lesson here appears to be that any component, no matter how benign they might seem, can potentially cause problems with high speed networking. Cat6 cables ARE better than Cat5e, some GigE switches do not like to use jumbo packets, some PC NICs have the potential to overwhelm the CPUs.
Test at and beyond the data rates that you will need to work at BEFORE installing anything at a customer.
 

Attaching and configuring the camera(s)

 
Once you have all this done then you can connect your camera directly or plug in a switch and then connect cameras to that. As they come out of the box the cameras should now give themselves addresses in the 192.168.254.x range. They are still getting information about the network from outside in order to make this choice. You can simplify things still further by assigning each camera its own static address.
 

Now the NIC is set correctly we need to adjust the way the software sends the data from the camera to the PC. The NIC “allows” the use of jumbo packets now but it does not enforce the use. We have to tell Visionscape to use them. This is done as follows:

1. Make sure that the dm.config file (C:\Vscape\DM\dm.config) is deleted. This will give you a clean start. Now boot FrontRunner, this will create a new dm.config file and populate the Windows registry with default values.
2. As things stand now the camera is going to use the default 1500 byte packet size that Visionscape uses out of the box. We need to change this before going any further. These values are stored in the registry. From the Start menu select Run… and type in

Regedit

 

3. If using a 32 bit operating system then go to:

 

My Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Visionscape\GigEVision\Camera_0

4. If you are using a 64-bit OS then the key is slightly different:

My Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Visionscape\GigEVision\Camera_0

 [NOTE: in newer builds of Visionscape there are more entries in these directories]

Depending on how many cameras you have connected you may have Camera_0, Camera_1, Camera_2 and Camera_3 directories – these all have the same things inside. You’ll need to repeat the procedure for Camera_0 on all 4 cameras.

The two parameters, InterPacketDelay and PacketSize are both set to 0 which tells Visionscape to use its default values. The first thing you need to do is set the PacketSize to 8192. To do this:

1. Right-click on PacketSize (the actual word) and select Modify. You’ll see the following:

2. Change to Decimal in the Base group.

3. Now enter 8192 in the Value Data text box (note that picture below shows 9014 not 8192).

4. Click on OK and you are done for setting the packet size.

 

We’re still not done though. We’ve told Visionscape to use jumbo packets but the camera is still going to
be sending data at the same rate – as fast as possible.
 
 
 

Setting the Inter-Packet Delay

 
There is no reason to have a camera capable of sending data at 90 frames per second if your particular application only runs at 30fps. It makes a lot more sense (and puts a lot less stress on the PC) to slow the camera down to the point where it is still fast enough to run faster than the inspection requirements  but not much faster. Let’s give the application 10% headroom and say that for our 30fps application we feel safe with the camera capable of running at 33fps.

In other words, we need to slow down the camera now to make sure that the PC can handle the throughput. This is not an issue on PCs with dedicated PCIe x16 graphics cards but it most certainly is on slower devices.

The inter-packet delay is the parameter that will allow us to control the rate of data from the camera.
 
Let’s assume that we are using a CMG03c camera transmitting bayer data. This camera is capable of running at 91fps with an 8 millisecond exposure time. With a 9000 byte packet size one frame of data (656 x 494 = 324,064 bytes + a small overhead) can be transmitted in 38 packets.

The actual data from the camera will be sent over the network at the clock rate which, for gigabit ethernet is 125MHz. This is 8 nanoseconds per clock. Assuming no overhead and no delays between packets our frame of data from the CMG03c would take 324,064 clocks which is 2.59 milliseconds. There is nothing we can do to change this time to actually transfer the data.

With the InterPacketDelay (IPD) set to zero the camera sends one packet of data and then immediately sends the next (actually there is a minimum delay of approximately 96 nanoseconds). This process repeats until all the packets that make up an image have been transmitted. Increasing the IPD tells the camera to take a short break between sending each packet which might give other devices a chance to send some of their data.

We can put a delay between each packet.  The inter-packet delay is set in “ticks” where there are 31,250,000 ticks in one second. From this we know that 1 tick is 32 nanoseconds.
 
Let’s assume that we want our camera to run at 33fps. In this case 1 frame is equal to 30.3 milliseconds. We can take off the fixed data transmission time of 2.59 milliseconds and that leaves us 27.71 milliseconds. With 38 packets per image that means that every packet needs to take 729 microseconds.

Dividing 729000 nanoseconds by 32 nanoseconds give us a tick count of 22,781. This is the inter-packet delay we need to put in the Visionscape registry entry.

Doing some back of the envelope calculations to show how this works in reverse:

 

22781 ticks is 729 microseconds
A 2MB image is approximately 38 9k packets
38 * 729 microseconds  = 27.71 milliseconds.
Add in the 2.59 milliseconds to actually send the data, 2.59 + 27.71 = 30.3 milliseconds per frame
The camera could run at 33fps.
Set the inter-packet delay in the registry in exactly the same way as you set the packet size.

 
 [Note: the Visionscape GigE Camera Control Tool includes a tool to calculate the inter-packet delay. Feel free to use this only when you understand the material presented here!]

 

FrontRunner Live Video

 When you go in to Live Video in FrontRunner with the zoom set to 1 a rather misleading frame rate is displayed on the top left corner of the picture. For instance, it might say 30.1 fps. This means that Visionscape is displaying images at 30.1 fps. It does not mean that the camera is running at this rate and, in fact, it means that the camera is running AT LEAST twice as fast as that. This is due to the way FrontRunner handles live video from the camera.

Imagine that you are using a CMG03c, a VGA camera that can pump out data at slightly more than 90 fps. The display on the PC can probably only manage 60fps. FrontRunner works as follows:
The camera is put into a continuous acquisition mode. If the inter-packet delay is negligible it will indeed be acquiring frames at 90fps. FrontRunner will take a frame and then process it before displaying it on screen. This process is sequential and FrontRunner will not take another frame until it has finished with the image display. It is not pipelining the process the way it does when acquiring images at runtime with triggers.

The sequential nature of the capture-draw-capture-draw process means that the best FrontRunner can ever do is 50% of the camera frame rate. This also depends on how fast the memory is, how fast the CPU itself is and how fast the drawing operations are. It may in fact take more than the frame time to complete the drawing in which case FrontRunner will only show one in three frames.

Experiments on a Core2Duo workstation with a dedicated graphics card and an Intel Pro/1000 NIC connected to a CMG03c camera showed that the maximum frame rate for live video in Frontrunner was 36.9 frames per second. Furthermore, this was not when the packet size was minimized but when it was set to 9000.

None of this is really important at runtime but the perception is that the camera is only running at the rate shown in Frontrunner when really it is the display that is running at that rate. The camera is running at least twice as fast.
 
The main point here, which I am not making very well, is that the rate displayed on screen when in live video is meaningless in terms of the application runtime performance.

 

Dropped or Missing Packets Message

Live video does however stress the PC more than the runtime. If you have reduced the camera frame rate using packet size and inter-packet delay to the rate you absolutely MUST run at and you get “Dropped Packets” messages when running in live video then your PC is not capable of running the application and you should find a faster PC. The usual reason for this is the graphics adaptor. Any on- board adaptor that uses shared memory is going to have problems.

The “Dropped Packets” message means that the NIC could not send data to the system memory in time because the memory or data bus was too busy. As mentioned above, an on-board or integrated graphics adaptor using shared memory uses the bus extensively. A dedicated graphics adaptor is given the data it needs to display and handles all manipulations required within its own memory space thus freeing the system memory bus.
 

Network Cards

 Microscan recommends Intel Pro/1000 cards but, at the time of writing this (August 2012), these are being replaced by newer, thankfully cheaper, cards. The cards that seem poised to become the “Go To” replacements are the Intel Ethernet Server Adapter I350 line. These were actually announced in June 2011 – you can find the announcement at:
 
http://communities.intel.com/community/wired/blog/2011/06/16/announcing-the-new-intel-ethernet- i350-server-adapters
 
This page states that “These Server Adapters are recommended replacements for the older Intel® PRO/1000 PT Server Adapters:”
 
 There are 2-port and 4-port versions available with the 2 port card coming in at under $150 and the 4- port at around $300.
 
There are many other adapters available. When picking one please make sure that it supports jumbo packets and has the ability to have at least 1024 receive buffers if possible, especially if using 5MPixel or greater cameras.
 
Update 2015 – The Intel I350 adapters are proven to work reliably with Visionscape but make sure that all power saving settings are disabled!