I am working on a system with dual cameras. To detect them, I am setting the AutoSwitchEnable to 1 in GenICam.ini before calling LoadImageFile, and this works.
On another machine where there is only one camera, this worked as well… until today. Without changing the code nor the configuration, the flag doesn’t work anymore and the second detection returns the same (and only) camera.
How is this magic possible ?
The AutoSwitchEnable can only work with two or more devices. It changes the camera port to the first available device.
On your machine with one camera the AutoSwitchEnable has no effect at all.
It is meant to be used with two or more cameras.
I assume that with the “second detection” you mean loading the camera with LoadImageFile/LoadImage.
A second call of LoadImage with the GenICam driver within the same process indeed loads the camera without a problem.
Then you have two instances to the same camera and the same image data. This behavior is intended to be used in situations with more than one camera that you can load the camera and then change to the camera you want with CSSetCamPort or the CamPort Property of the Grabber Control.
If you try to load the same camera the second time on another process the call to LoadImageFile/LoadImage will fail.
Regards
Sebastian
No, I mean that previously, on the single camera machine, I was performing two calls to LoadImageFile; the first succeeded and the second failed as is the expected behavior with AutoSwitchEnable set.
But now, for no reason, the two calls succeed and the same camera is indeed loaded twice.
I understand this functionality correctly and it used to work. What can cause the behavior to change ?
AutoSwitchEnable has no effect in a one camera setup and if we use LoadImageFile within the same process.
Two Cameras and LoadImage file from two separate processes
AutoSwitchEnable=1
First LoadImageFile succeeds
Second LoadImageFile succeeds.
AutoSwitchEnable=0
First LoadImageFile succeeds (Process 1)
Second LoadImageFile fails. (Process 2)
One Camera and LoadImageFile within one process
One Camera and LoadImageFile from two separate processes
The only explanation I can think off is that previously you called the second LoadImageFile from another process or between the time of the first and the second LoadImageFile the camera disconnected somehow because of an error.
The current behaviour of your application is correct. If you face the previous behaviour again please contact our Technical Support(
+49 89 80902-200 | 
support@stemmer-imaging.de) and we can investigate what causes this issue.
If it is like this, then it is impossible to determine how many cameras there are by this method.
How can I know the number of available cameras ?
Also notice that I am performing the LoadImageFile from a single thread and the camera does not disconnect.
For automatic device detection you can use
[SYSTEM]
CreateAutoIni=1
After loading the driver you can query the number of devices via CS2GetNumPorts. But for this you need to be able to load the GenICam.vin. But be careful if you are automatically discovering devices: the GenICam.vin will detect GigE Vision cameras twice on Windows operating systems:
You would need to filter the GenICam.ini manually.
For opening GenICam-devices you can use the function I proposed here:
https://forum.commonvisionblox.com/t/old-image-broken-after-setting-new-camport/66/5?u=parsd
LoadImageFile(const char *, IMG &) creates a new device image object with the IMG parameter being an “out” parameter. This means that the referenced IMG variable will simply be overwritten. If you reuse the IMG handle variable for the second LoadImageFile call, the old device object the IMG handle points to, is not released, but leaked. And the device is kept open. Treat the :cvb: handles (IMG, NODE,…) like raw pointers.
I personally use a smart handle for life-time management:
https://forum.commonvisionblox.com/t/old-image-broken-after-setting-new-camport/66/6?u=parsd
I obviously don’t overwrite the handle as I want to work with all the cameras I detect !
Dear @YvesDaoust,
were you able to solve your issue with the information we gave you?
Sebastian,
it turns out that the behavior has reverted to how it was before, overnight, and theproblem is gone. Possibly a combination of camera reboot and PC reboot unlocked things.
I confirm the the AutoSwitchEnable flag does have an effect on a singel camera machine, contrary to what you said.
Thanks for the care,
YvesHi @YvesDaoust,
Now I tested the influence of the AutoSwitchEnable flag when loading the driver within the same process. I was surprised to see that the driver could´t load if auto switch is enabled. This is not how I thought it should work and i am sorry that I gave you wrong information.
I will create a bug report for the driver developer.
PLEASE DON’T.
This is a desirable behavior. Without it, discovering the cameras would become a pain.