Failure to interact with Device after reconnection

Programming Questions .Net API
1

Bug description

It appears that any attempted interaction with a device via CVB.Net fails if it disconnected while a stream was running and if the GenICam VIN is responsible for debayering the image.

Information

  • OS: Windows 10 Enterprise LTSC, Version 10.0.17763 Build 17763
  • Tested with CVB 13.03.003 and CVB 14.00.004
  • Tested behaviour with own application code and example program SystemBrowser (%CVB%\Tutorial\Image Manager\Cvb.Net\SystemBrowser)
  • Tested with AlliedVision Mako G-234C, AlliedVision Mako G-234B and Teledyne Dalsa Nano-M1280 GenICam devices

Related forum post

Camera disconnection
This post describes a similar problem, but never seemed to reach a conclusion.

Steps to reproduce

  1. Launch SystemBrowser.exe (%CVB%\Tutorial\Image Manager\Cvb.Net\SystemBrowser\bin\Release) and open a camera with a Bayer sensor
  2. Ensure the PixelFormat is set to BayerRG8 or similar
  3. (Optional) Set the TriggerMode to On and TriggerSource to anything but Freerun, since Freerun seems to cause some inconsistent behaviour, especially when debugging.
  4. Ensure the device is grabbing after the changed PixelFormat has taken effect
  5. Interrupt the connection to the device (e.g. by disabling the TCP/IPv4 stack in the network adapter if connected by GigEVision)

Expected behaviour

The SystemBrowser application monitors the connection of the device. When the link to an opened device disappears, it will attempt to abort streaming (if applicable), dispose said device and perform a discovery of available devices. If the connection to the device is re-established and a new discovery is performed, the device should reappear in the device list and opening it should be possible

Result

The stream is not stopped, the device is not disposed and no automatic discovery is performed. No meaningful interaction with the opened device is possible but triggering a discovery of devices by any means will result in the device no longer being present in the list. If the connection to the device is re-established and a new discovery is performed, the device reappears in the camera list but is not accessible.

Additional information

By debugging the application it becomes clear that the following call never returns in CameraProxy.cs line 333:

327    /// <summary>
328    /// Stops the Grap
329    /// </summary>
330    public void StopGrab()
331    {
332      if (Device.Stream.IsRunning)
333        Device.Stream.Abort();
334    }

Other operations on the Stream (TryAbort(), Stop(), etc.) and Device (Dispose()) result in the same blocking: pausing the program after such a call shows the thread waiting for current function to return.

If the same steps are repeated either with a monochrome camera or a Bayer camera with its output set to Monochrome or RGB8Packed, there is no issue and the expected behaviour takes place.
If the same steps are repeated with a Bayer camera but it is kept in Freerun, a breakpoint is triggered before line 333 is reached and execution is not immediately resumed, the expected behaviour might also take place.

It is unclear if letting the GenICam VIN debayer the image is truly the cause of the issue, but it at appears related. At the very least this behaviour seems unintended. Could this be confirmed?

2

Hi @ThomasDb

we can reproduce the behaviour you described and we will see, what we can do to avoid this.
I will let you know as soon as there are any news on this.