After upgrading to the recommended acquisition stack, we noticed that AcquisitionMode property changes when calling stream.start(). This does not happen via GenieCam.
We checked cvb13 and cvb14 and the issue is present in both.
We had to downgrade to cvb13 to use the Vin in order for the API to work as expected.
Trying to open a Vin on cvb14 causes a silent process crash when we call stream.start().
What should we do?
import cvb
# Connect to the device (OK)
devices = cvb.DeviceFactory.discover_from_root(cvb.DiscoverFlags.IgnoreVins)
with cvb.DeviceFactory.open(devices[0].access_token, cvb.AcquisitionStack.GenTL) as device:
# Create a stream (OK)
stream = device.stream(cvb.ImageStream)
# Confirm AcquisitionMode is "MultiFrame" (OK) -- this can be set here (below) or in GenieCam.
node_maps = device.node_maps["Device"]
print(f"AcquisitionMode: {node_maps['AcquisitionMode'].value}")
# >>> AcquisitionMode: MultiFrame
# Set it manually (OK)
# node_maps['AcquisitionMode'].value = "MultiFrame"
# print(f"AcquisitionMode: {node_maps['AcquisitionMode'].value}")
# # >>> AcquisitionMode: MultiFrame
# Start the stream (WRONG AcquisitionMode > sets it to "Continuous")
stream.start()
print(f"AcquisitionMode: {node_maps['AcquisitionMode'].value}")
stream.abort()
Hi @John and thanks for the example code which makes it easy to understand what you are trying to do.
The AcquisitionMode is a feature in the camera which we do not change when starting the acquisition from CVB with stream.start().
Are you 100% sure that changing the CVB version to CVB 13 fixed the issue?
With the information I have here, I would think that the camera behaves not as expected.
Do you have another camera at hand from another manufacturer to confirm this behaviour?
The issue seems to be in both 13 and 14 when using GenTL.
The issue does not appear to be in 13 when using Vin provider. When we try to use Vin provider in 14, we get a silent process crash.
We have tried different cameras (same manufacturer, but different firmware) and swapped out all hardware in including cables. We also redownload the software to check for corruption.
I have to correct myself, as I found out in exchange with the development that the GenTL stack indeed changes the AcquisitionMode.
The stream.start() function uses the default values to start the acquisition engine in the background and the device acquisition in the camera. And the default is a continuous acquisition.
To start a multi frame acquisition, you need to start the acquisition engine and the device acquisition separately with the functions stream.EngineStart(count) stream.DeviceStart(count)
Where the count is the number of frames you want to acquire in your multi frame acquisition.
Issue 1 - GenTL stream.start()
Please can this be noted clearly in the migration guide and documentation? We could not find it in either. As you (an expert) and we made the same mistake, this is a very unintuitive change to the behaviour of stream.start().
For your knowledge, this has cost us at least 6 mans days, and I wonder how many devices in the field will have migrated and have this subtle error introduced? We would recommend to the GenTL developers not re-use the name stream.start() if it has such different behaviour.
We will test start and stopping with stream.EngineStart(count) and stream.DeviceStart(count) and let you know if it is working.
What is the engine vs device? Do we need to start/stop them both or should they be re-used?
Issue 2 - CVB14 VIN Driver Silent Crash
Do you know why we get a silent crash when trying to use the VIN driver in CVB 14?
I am really sorry, that you ran into this issue. I will get into an additional exchange with the development regarding this topic.
Engine / Device
I hope I explain it correctly.
The Engine is the acquisition engine of CVB. The device is the physical device.
Both need to be initialized and started. This is what the stream.start() does automatically for both. But with these default parameters.
Issue 2
What do you mean with silent crash? Do you get an error message, or is the application exiting without a message?
steam.start()
This is a convenience method combining many things that are required to setup the acquisition in one call. I agree that the configuration of the acquisition mode in the device should be in the documentation, we will add this. We consider continuous acquisition the most common use case, therefore it would be useful to know why you use “MultiFrame”, which is by the way not even available in some cameras. Also be aware that it is dangerous to combine “MultiFrame” with “PassCoruptFrames=False” cameras, as the camera will stop after the configured amount of frames, even if one of the frames was discarded, causing the engine to wait for ever or to timeout.
Finally Engine / Device
We refer to the “Engine” as the host part of the acquisition, which typically includes allocating buffers, managing buffer states, setting up threads and talking to the device drivers. These operations are usually much more expensive than starting the acquisition in a camera (device). So it can be useful to start the engine once, and keep it running and just start and stop on the device on demand.
