CVBPy find devices by Device Configurator config ini file

Hi, we have encountered some problems after update to 13.04.005.

Earlier we were opening cameras using

with + "/Drivers/", self.parameters.cvb_port) as device: =

but after updating to 13.04.005 it has stopped working and we started to get exception.

 {C-API call failed} ({LoadImageFileW})

Using open_port method also fails.

cvb.DeviceFactory.open_port(cvb.install_path() + "/Drivers/", self.parameters.cvb_port) as device:


with + "/Drivers/",cvb.AcquisitionStack.Vin, self.parameters.cvb_port) as device:

I receive Exception:

no IBoardSelect or IBoardSelect2

Cameras are added in GenicamBrowser on right side and config is saved.

One solution I have found is to use this method: but then we are not able to rotate and set camera order easily using configurator.

So my question would be, is there any solution, to load cameras defined in Device Configurator from CVBPy like in earlier versions.


Thank you for the report and sorry for the inconvenience.

As the first step, I would like to clean up the environment first if you do not mind.

( Excuse me, I know, I start speaking without hearing your opinion. :wink: )

  • First, remove CVB by using Windows’ “Add or remove programs”.
  • Next, make sure the installation directory has been completely empty; if something is still remaining then please manually delete them.
  • Then, install CVB 13.05 again.
  • Finally, please try to run the original script that you listed on the top.

If the phenomenon can be observed even if the installation was fresh, then it may imply there’s a defect that prevents CVB to work with your setup.

I’ll be looking forward to hearing from you.



it seems, that this issue is still causing trouble. My cvb Version is also the current stable version: v13.04.005. (Found out, that users can get a newer version in this forum: also testet everything with v14.00.002 → same error.)

We try to use 4 laser cameras at the same time and I don’t want to itereate over all discovered devices, since I need to know the exact identity of each laser. Using the open_port() method would be the reliable approach in an industrial setting, due to the fact that the user can parameterize the configured devices as an ordered list. The discover method does not fulfill this demand.

Could you please fix this issue, since it is pending for a long time?

Just to clarify this in advance: yes I am able to write a node_map parser and to find out which laser camera is in the tree, but since the cvb documentation suggests the open_port() method the users want to utilize it.

Thank you!

Very similar thing here: We need to reliably identify cameras which have been preconfigured using GenICam Device Configurator. We used open_port() to do that in the past, but going for an update made it stop working for ports > 0 (program just exits, no error or anything, similar to

Sure MAC addresses, IPs or serials could be used, but given that there are several sets of cameras those things are basically meaningless and would need another layer of mapping. As long as the CamPort (position within the set) is identical, configuration would be fine. open_port() was the easiest thing to go for instead of discover and filter in some complicated manner…

I´ve tried to reproduce your issue under CVB 14 but I wasn´t successful. Could you please send us the code that fails on your machine and the corresponding error?

@silas (and also others)
I’m not Tobias, but given that I encounter similar problems I now tried CVB 14.00.002 with Python cvb-1.5 which I didn’t go for because of his post mentioning that it would work.

I was able to open devices via open_port again in our setup if all cameras being configured are connected and available. So far, so good…

If camera on port 0 is not available I end up with the same (to me unclear) exception as @augas111 mentioned in the initial post for all camera ports. Even if I request opening port 2 while 0 is unavailable I get the exception which now reads RuntimeError: C-API call failed; try getting a log by using CVB LogGUI/silogutil: {"Name": "LoadImageFileW", "CVC_ERROR_CODE": 1}.
If any other camera on a port != 0 is offline, there is an exception when opening that one (RuntimeError: failed to set port) which is way better as connecting all cameras except the one being offline works.

Looking for a solution I found a rather old post mentioning that this may be because of the driver always opening port 0 first regardless of what is requested. This is rather annoying and difficult to understand on first encounter as one camera being offline renders the whole setup useless even if it this one is not opened at all.
The second solution from this thread (using AutoSwitchEnable=1) works even worse as this leads again to crashes without even having a message/exception when encountering the port which cannot be opened (regardless of its index).

Another thing as it was mentioned in the initial post: Rotation of acquired images:
Rotation settings are saved to GeniCam.ini (located in C:\ProgramData\STEMMER IMAGING\Common Vision Blox\Drivers) when set in GenICam Browser, but are not evaluated in the integrated viewer. They are honored when opening the stream with my scripts, so the problem here is only the Device View part of GenICam Browser which IMHO should behave as the old Device Configurator in Management Console which did rotation as configured.

To sum up: CVB 14.00.002 works better than 13.04.005 in my hands/scenario, but still room for improvement.

Hi @h.lenz

thank you for your feedback. Basically what you wrote is all true. However let me explain some things, as this clumsy interface has some history.

It is true that opening a device via a VIN driver always opens port=0 and board=0 first before switching to the requested device, so if port=0, board=0 is in use or not available you will get an error. This mechanism predates GenTL or GigE Vision and was designed with frame grabbers in mind. Therefore today it only works with static setups assuming that all cameras are connected and accessible.

Using AutoSwitchEnable=1 is half a workaround. If activated and port=0, port=0 is not available it should automatically switch to the next available camera. But this way you would not know which camera you’ve actually opened if some are not available. So there must be a switch afterwards.
The crash in your case is clearly a bug. We will have a look int it. Can you please provide some code to reproduce it.

Based on what you’ve written I can assume that you have a rather dynamic setup as camera can be missing or switched of. In that case I’d always recommend using DeviceFactory.discover_from_root() which gives you a list of DiscoveryInformation (one for each device found) without opening any devices. The property access_token which is essentially a json string can then be used to identify the device and open exactly that one device via
If you need some additional settings like e.g. the number of buffers you can set them before opening with DiscoveryInformation.set_parameter as key value pair like it was in the GenICam.ini.

Regarding the rotation: The GenICamBrowser does not use the so it cannot show the rotation applied by the Please be aware that the driver does not actually rotate the image it just interprets the memory differently. Therefore using algorithms on rotated images can result in poor performance due to cache misses.

1 Like

Dear @Andreas,

thanks for the detailed explanation and clarification.

First for the “real bug” while using AutoSwitchEnable=1. My code looks like this:

import cvb
import traceback
import logging
import sys

mincamport = 0
maxcamport = 2
vinDriver = cvb.install_path() + "Drivers\\"

#Open all devices
for portid in range(mincamport, maxcamport+1):
		print("Trying to connect device on port {}".format(portid))
		device = cvb.DeviceFactory.open_port(vinDriver, portid)
		if device.connection_state == cvb.ConnectionState.Connected:
			print("Device connected successfully")
		print("Try done")
	except Exception as e:
		print("Exception during connection try")

sys.exit("Came to an end")

Without any error this outputs something like

C:\Program Files\STEMMER IMAGING\Common Vision Blox\Drivers\
Trying to connect device on port 0
Device connected successfully
Try done
Trying to connect device on port 1
Device connected successfully
Try done
Trying to connect device on port 2
Device connected successfully
Try done
Came to an end

If AutoSwitchEnable=1 and CamPort 0 being offline it spit out 2 days ago:

C:\Program Files\STEMMER IMAGING\Common Vision Blox\Drivers\
Trying to connect device on port 0

and then returned to command prompt without any exception, text or exit message.

Strange enough today this code produces a different result (computer not restarted, just continued where I ended):

Trying to connect device on port 0
Exception during connection try
ERROR:root:Traceback (most recent call last):
  File ".\", line 15, in <module>
    device = cvb.DeviceFactory.open_port(vinDriver, portid)
RuntimeError: failed to set port

Trying to connect device on port 1
Device connected successfully
Try done
Trying to connect device on port 2
Device connected successfully
Try done
Came to an end

This is “better” than a silent crash, but still does not do what AutoSwitchEnable=1 is intended to do, right? From your explanation I would expect it connecting successfully on all three ports with some other auto-switched camera running on that port.

For my setup this is not useful anyway because one does not know which camera has been opened (I already feared that, but wanted to test it anyway). In principle my setup is static and all cameras should be available for proper function. I just got here because in some (rare) cases cameras may get lost for some reason (hardware error, PoE failure, …) and I would like to detect that and report properly like “Camera on port xx cannot be opened, please check connection”. But given the error handling/exceptions that are thrown this very simple task brought me here and still does not seem to be solvable if port 0 is the one having a problem (which unfortunately up to now is the most likely one).

Doing discovery does not really make sense IMHO. I also played around with this feature, but as mentioned in my first post in this thread then I would have to somehow map cameras using their IP, MAC or something to a static ID and check which one is missing during discovery - this all does the CamPort + User config provide already so why reimplement it (obviously similar thinking for others like @augas111 and @tobias.bettinger).


  • Could you please elaborate a bit more what alternative way the GenICamBrowser uses and why it was skipped to do the configured rotation there? Obviously the “old” Device Configurator/Management Console then did use the driver as rotation was directly visible. So why does the program having “GenICam” in its name not use the driver (anymore)?
  • I also would like to know more about the possible issues with the rotation. What algorithms and cache misses are you referring to?

Thanks very much in advance

Hi @h.lenz

we have a look into the auto switch behavior.

Yes, this is what the “User Defined Name” in the camera can used for. This is persistent (powercycle) string that will show up in the discovery. So is up to you to provide an ID that your application can work with.


  • The GenICam Browser works directly on GenTL interface which is more powerful but also much more complicated than the interface CVB offers. The GenICam Browser was started platform independent application as the GEV Config Manager was Windows only and as the name suggest a little to GEV focused. Back then the CVB API did not offer all that was needed to configure a camera from scratch. However, as of today everything the GenICam Browser can do with a GenTL can also be done with the CVB API.
  • I believe it would be beyond the scope this post to go into memory performance details here. If performance matters avoid jumping through your data in memory keep the data for your algorithm close together. This is true for pretty much any algorithm.


we have found and fixed the bug regarding auto switch it will be fixed in the next service release CVB 14.00.003. The bug could effect every not working port switch!

Best regards