In my program I do a DeviceFactory.Discover(DiscoverFlags.IncludeInaccessible) once.
Then give the DiscoveryInformation to a class which opens the connection and starts grabbing.
Is there an event that triggers when the camera is available? Or is polling with TryOpen the only way?
Polling is the only way. Technologies like e.g. GigE Vision only implement polling. Also this produces broad cast traffic which we try to minimize. You are more likely to know when it is ok to produces extra traffic 
.
And yes, there are devices that react allergic to broad casts…
When I let this code poll every second:
private bool _OpenDevice()
{
// Get device
if (_Device == null)
{
try
{
DeviceFactory.TryOpen(_Info, out _Device);
_Device.ConnectionStateChanged += Device_ConnectionStateChanged;
}
catch (Exception)
{
return false;
}
}
try
{
if (_Device.Stream != null) _UnsubscribeStream = _Device.Stream.Subscribe(this);
else return false;
}
catch (Exception e)
{
OnError(e);
return false;
}
return true;
}
Stream returns null.
Code works when the Device can connect right away.
Hi BenDevos,
this will be fixed in the next release.
I have attached the new dll.
Just replace it with the existing one at your CVB installation directory (%CVB%).
CVFactory.zip (289.4 KB)
Cheers,
Tim
With new dll it wasn’t solved, these are my references:
using Stemmer.Cvb;
using Stemmer.Cvb.Driver;
Stemmer.Cvb is from inside the %CVB% folder:
C:\Program Files\STEMMER IMAGING\Common Vision Blox\Lib\Net\Stemmer.Cvb.dll
Changed my polling code a bit now I get few times system null reference and after that the connection is ok.
private bool _OpenDevice()
{
// Get device
if (_Device == null)
{
try
{
DeviceFactory.TryOpen(_Info, out _Device);
}
catch (Exception)
{
return false;
}
}
try
{
if (_Device.Stream != null)
{
_Device.ConnectionStateChanged += Device_ConnectionStateChanged;
_UnsubscribeStream = _Device.Stream.Subscribe(this);
}
// No stream in device, retry connection in next _OpenDevice call
else throw new NullReferenceException(nameof(_Device.Stream));
}
catch (Exception e)
{
if (_Device != null)
{
_Device.Dispose();
_Device = null;
}
OnError(e);
return false;
}
return true;
}
When I use your dll I sometimes get System.AccessViolationException, reverted back to the old dll, my solution works too and didn’t have the error yet:
System.AccessViolationException
HResult=0x80004003
Message=Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
Source=<Cannot evaluate the exception source>
StackTrace:
<Cannot evaluate the exception stack trace>
StackTrace " at Stemmer.Cvb.ImgLib.LoadImageFile(String fileName, IntPtr& image)\r\n at Stemmer.Cvb.DeviceFactory.InternalTryOpen(String provider, Device& device)\r\n at Stemmer.Cvb.DeviceFactory.TryOpen(String provider, Device& device)\r\n at Stemmer.Cvb.DeviceFactory.TryOpen(DiscoveryInformation info, Device& device)\r\n at WpfApp1.CvbGrabber._OpenDevice() in C:\\ServerCopy\\19-0062 Pick and skewer\\Sync\\Test\\WpfApp1\\WpfApp1\\CvbGrabber.cs:line 84\r\n at WpfApp1.CvbGrabber._Polling_Elapsed(Object sender, ElapsedEventArgs e) in C:\\ServerCopy\\19-0062 Pick and skewer\\Sync\\Test\\WpfApp1\\WpfApp1\\CvbGrabber.cs:line 45\r\n at System.Timers.Timer.MyTimerCallback(Object state)\r\n at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)\r\n at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)\r\n at System.Threading.TimerQueueTimer.CallCallback()\r\n at System.Threading.TimerQueueTimer.Fire()\r\n at System.Threading.TimerQueue.FireNextTimers()" string
Hi BenDevos,
can you please provide a working minimum example so we can reproduce this behaviour?
Cheers,
Tim
My setup has 2 camera’s, I open “Common Vision Blox Management Console” and select one under the GenICam Device Configurator.
In my own program I only connect to the one selected, then switch from device in CVBMC.
Camera’s in my setup:
in %CVB% I rename the CVFactory_new CVFactory_old depending on which I want to use.
Tested it again with latest code, now I sometimes get this error with both CVFactory dlls:
System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'VinDevice'.
at Stemmer.Cvb.Driver.VinDevice.get_Streams()
at Stemmer.Cvb.Device.get_Stream()
at WpfApp1.CvbGrabber._OpenDevice() in C:\ServerCopy\19-0062 Pick and skewer\Sync\Test\WpfApp1\WpfApp1\CvbGrabber.cs:line 96
I just saw that the siFilterDriver was missing because I did a reinstall of the software.
with old CVFactory dll I did a few tests and problem didn’t happen.
New one gave the problem above.
the memory access violation did’t happen anymore.
WpfApp1.zip (2.0 MB)
Your attached app is crashing for me when I try to run it.
Please provide a working minimum example that shows the error in question.
Hi @BenDevos,
could you explain again what exactly you are doing?
I tried your attached program and it seems to work for me when I have a camera connected with the ID “Meat”.
I also tried to disconnect the camera while it was being opened and then reconnected it while the polling was ongoing. After a short while the camera was loaded and the MainWindow showed up.
If there seems to be something wrong with your siFilterDriver I’d suggest completely uninstalling cvb and reinstalling it fresh.
Or is the procedure I am using to test your attached application wrong?
Cheers,
Tim
Thats also what i’m doing, once in a while I get the System.ObjectDisposedException.
Installed CVB 2018 Windows 64 bit 13.01.006 | 555 MB
https://www.commonvisionblox.com/en/download-cvb-windows-32-bit-and-64-bit/
And
https://ftp.commonvisionblox.com/webdavs/forum/setups/addon/Common%20Vision%20Blox%20Bindings%201.00.000%20(x64).exe
Still not convinced of the polling solution…
Our current setup has 7 camera’s and when one camera isn’t connected while our software starts up then that camera starts polling but this has a negative effect on the other 6 working camera’s I think?
Bad implementation at my part now is that each camera has its own polling. While this behavior should be implemented at factory level to reduce unnecessary polling requests.