vimba.error.VimbaCameraError: Accessed Camera 'DEV_1AB22C003FC4' with invalid Mode 'AccessMode.Full'. Valid modes are: (<AccessMode.Full: 1>, <AccessMode.Read: 2>)

[marciojersey]

When I attempt to save camera settings using the following 2 lines:

            with tempfile.NamedTemporaryFile(suffix='.xml') as fp:
                c.save_settings(fp.name, PersistType.All)

I get an exception with the following stack trace:

Traceback (most recent call last): File "./camera_allied_vision.py", line 72, in getRescannedConnectedCameras c.enter() File "/opt/conda/lib/python3.8/site-packages/vimba/util/tracer.py", line 134, in wrapper return func(*args, kwargs) File "/opt/conda/lib/python3.8/site-packages/vimba/camera.py", line 359, in enter self._open() File "/opt/conda/lib/python3.8/site-packages/vimba/util/tracer.py", line 134, in wrapper return func(*args, *kwargs) File "/opt/conda/lib/python3.8/site-packages/vimba/util/context_decorator.py", line 44, in wrapper return func(args, kwargs) File "/opt/conda/lib/python3.8/site-packages/vimba/camera.py", line 907, in _open raise exc from e vimba.error.VimbaCameraError: Accessed Camera 'DEV_1AB22C000D01' with invalid Mode 'AccessMode.Full'. Valid modes are: (<AccessMode.Full: 1>, <AccessMode.Read: 2>) Traceback (most recent call last): File "./camera_allied_vision.py", line 72, in getRescannedConnectedCameras c.enter() File "/opt/conda/lib/python3.8/site-packages/vimba/util/tracer.py", line 134, in wrapper return func(*args, kwargs) File "/opt/conda/lib/python3.8/site-packages/vimba/camera.py", line 359, in enter self._open() File "/opt/conda/lib/python3.8/site-packages/vimba/util/tracer.py", line 134, in wrapper return func(*args, *kwargs) File "/opt/conda/lib/python3.8/site-packages/vimba/util/context_decorator.py", line 44, in wrapper return func(args, kwargs) File "/opt/conda/lib/python3.8/site-packages/vimba/camera.py", line 909, in _open self.__feats = discover_features(self.__handle) File "/opt/conda/lib/python3.8/site-packages/vimba/util/tracer.py", line 134, in wrapper return func(*args, **kwargs) File "/opt/conda/lib/python3.8/site-packages/vimba/feature.py", line 1242, in discover_features call_vimba_c('VmbFeaturesList', handle, None, 0, byref(feats_count), sizeof(VmbFeatureInfo))

Any idea on what's going on here? Every once in a while the error manifests and won't go away until I unplug the camera's usb cable and reconnect. Then the camera will be fine for a while but the error will eventually come back.

[NiklasKroeger-AlliedVision]

vimba.error.VimbaCameraError: Accessed Camera 'DEV_1AB22C000D01' with invalid Mode 'AccessMode.Full'. Valid modes are: (<AccessMode.Full: 1>, <AccessMode.Read: 2>)

Similar to your error report in #48 the error message does not make much sense. It claims that AccessMode.Full is available, but you still cannot open it with that mode... I will need to check how those access modes are checked to see if this may be some caching issue where VimbaPython does not realize that the available access mode may have changed.

Every once in a while the error manifests and won't go away until I unplug the camera's usb cable and reconnect.

Am I understanding this correctly, that this error does not appear every time you run the code? Is there a reliable way to reproduce the issue for me? Ideally a fully working code example would be nice.

Since you mention the need to unplug/replug the camera, my first guess would be, that some process is still holding the camera connection open. Perhaps earlier runs from your python script did not exit cleanly and the camera handle has not been closed properly. If that is the case, the camera may refuse your attempt to talk to it, because it thinks there is still another process it should be associated with.

[marciojersey]

Thanks for responding. I managed to solve this issue and issue #48 in the meantime. My project consisted in a RESTful API for remotely controlling a camera and it appeared to me that every time a camera connection was closed, by leaving the "with" statement, some background work was still being done closing the camera and if another attempt to open the camera was made during that moment through some other RESTful API call, the camera fell into an inconsistent state that could only be remedied by resetting the camera or unplugging and plugging back in the usb cable. My workaround might not be ideal and uses VimbaPython in a way that may not have been intended but it completely solved the problems for me. What I do now is on my module's startup I store a reference to Vimba.get_instance() and call its _startup() method. Then I obtain a reference to the camera and call its _open() method. Throughout the lifetime of the module I use the vimba and camera instance that were opened on startup. Then on my module's shutdown. I call vimba's _shutdown() method and the camera's _close() method. With this strategy, I don't use the vimba and camera instances inside any "with" statements.

[jeanchristopheruel]

Thanks for responding. I managed to solve this issue and issue #48 in the meantime. My project consisted in a RESTful API for remotely controlling a camera and it appeared to me that every time a camera connection was closed, by leaving the "with" statement, some background work was still being done closing the camera and if another attempt to open the camera was made during that moment through some other RESTful API call, the camera fell into an inconsistent state that could only be remedied by resetting the camera or unplugging and plugging back in the usb cable. My workaround might not be ideal and uses VimbaPython in a way that may not have been intended but it completely solved the problems for me. What I do now is on my module's startup I store a reference to Vimba.get_instance() and call its _startup() method. Then I obtain a reference to the camera and call its _open() method. Throughout the lifetime of the module I use the vimba and camera instance that were opened on startup. Then on my module's shutdown. I call vimba's _shutdown() method and the camera's _close() method. With this strategy, I don't use the vimba and camera instances inside any "with" statements.

Also not a fan of the "with" statement which is not a threadsafe context manager. async with might have been a better choice. Also this design choice is not multi-paradigm, constraining the user to bind to its design dependencies.

[NiklasKroeger-AlliedVision]

async with might have been a better choice

Thank you for the input on this. I believe async with would be problematic because it can only be used within coroutines itself. From the link you provided:

It is a SyntaxError to use an async with statement outside the body of a coroutine function.

From my personal experience this is not yet really used among our userbase, but this might be a chicken-egg problem where nobody uses it because we do not provide it....

[jeanchristopheruel]

Indeed, async with is meant to be used with coroutines only. I agree that this might not be a better solution in the sense that it adds even more design dependencies.