Package collision

Programming Questions C-style API
, , , ,
5

Ok, I try to break it up a bit…

Regarding the Image ActiveX control

The stop mode depends on a Windows Registry value: :slight_smile:

HKEY_LOCAL_MACHINE\SOFTWARE\Common Vision Blox\Image Manager\Global ACQ Kill Enabled

When set to 0 (the default) the acquisition is stopped (thus the current transmission is waited for). With 1 it is aborted. The resulting behavior depends on the camera: It also may immediately stop transfering data or finish its frame.

This is one of the reasons I prefer the CVB.Net API as it free from such side effects (the other non-ActiveX APIs, too; but as you are currently using C#…).

Grab Stop (.Grab = false)

As sending by the camera and receiving data by the acquisition engine are parallel operations it may happen that the camera still is in process of sending an image although the acquisition engine has stopped. If you want to be really safe in that regard either use triggers or wait one frame after setting .Grab to false.

Snap

Something as described in the stop case can also happen with snap. In its essence it is

  1. start acquisition (G2Grab)
  2. wait for one frame to arrive (G2Wait)
  3. stop acquisition (G2Freeze)

The GenICam.vin tries to setup the camera to single-frame mode (GenICam SFNC features AcquisitionMode and AcquisitionFrameCount) which then should circumvent “double” send scenarios. If the camera does not support that the problem and the solution are the same as in the stop case.

Hardware

Last but not least the other hardware components. I talked a bit about the capabilities of the cameras, but the router(?)/switch and the network interface cards (NIC) are also important. Dependend on their memory and processing power we also have seen issues that a (single) fast camera could overload a switch/NIC. That also can be circumvented via interpacket delay. Sometime jumbo frames also help (less processing power is needed as fewer packets arrive).

How to decide?

After all the ifs and maybes: a quick test would be to wait one frame time after each .Snap. If the error is gone it is probably a double image send. Also for analysis use the acquisition statistics (G2GetGrabStatus). See Stream Statistics and the following Transfer Monitoring post for more info. The corrupted frames might not always be that visible as the old data may look no different than the new.

For a detailed analysis we would need a Wireshark dump sent to support@stemmer-imaging.de.

1 Like