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\\GenICam.vin"
print(vinDriver)
#Open all devices
for portid in range(mincamport, maxcamport+1):
try:
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")
logging.error(traceback.format_exc())
sys.exit("Came to an end")
Without any error this outputs something like
C:\Program Files\STEMMER IMAGING\Common Vision Blox\Drivers\GenICam.vin
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\GenICam.vin
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 ".\startuptest_stemmer.py", 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).
Rotation/GenICam.vin:
- 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
)