# Package collision **URL:** \ **Category:** C-style API\ **Tags:** activex, csharp, acquisition, genicam, gigevision\ **Created:** [November 21, 2017, 10:17am UTC](https://forum.commonvisionblox.com/t/package-collision/276 "2017-11-21T10:17:15Z")\ **Posts on this page:** 1\ **Showing post:** 5
**Author:** ![parsd](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.commonvisionblox.com/parsd/32/7_2.png) [@parsd](https://forum.commonvisionblox.com/u/parsd)\ **Post date:** [November 21, 2017, 3:45pm UTC](https://forum.commonvisionblox.com/t/package-collision/276/5 "2017-11-21T15:45:56Z")
Ok, I try to break it up a bit… ### Regarding the _Image_ ActiveX control The stop mode depends on a Windows Registry value: 🙂 > `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](https://forum.commonvisionblox.com/t/getting-started-with-cvb-net/246/6) 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](https://forum.commonvisionblox.com/t/getting-started-with-cvb-net/246/13) 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](mailto:support@stemmer-imaging.de). --- _[View the full topic](https://forum.commonvisionblox.com/t/package-collision/276)._