Access Mode on acquisition

Hello,

I’ve played with Aravis for some time, and I had some questions about Feature nodes and their Access Mode.

When I start the acquisition of a camera, some features are still marked as writable when I check their actual Access Mode while it’s supposed to be read only.

For example, I expect the feature “Width” to be read only after I start the acquisition, but it’s writable. And when I write on it, the camera is in a weird state, where all my buffers status are ARV_BUFFER_STATUS_SIZE_MISMATCH.

I’ve tested this on a Basler camera (acA2500-14gc) and with a Fake camera.

I also tested this with a Daheng camera (MER-503-20GC-P) but I got a different result: Access Mode is still marked as writable, but when I try to write on it, it raises an exception.

Is this intended ? Is there another way to check the access mode of a feature node I’m not aware of ?

I’ve tried these scenarios with python bindings of aravis 0.8.13 and 0.8.21 and got the same results.

Thanks

Hi,

AccessMode is available in Aravis API, but is not enforced on read/write operations. Which means some cameras may be put in an incorrect state if a feature is written while it is read only. On other devices with a better implementation, an error message is returned, which generate an exception in Aravis (I guess you are using Python).

The reason AccessMode is not enforced in Aravis is it is still not considered completely reliable. It is better to always allow read/write feature access than forbid a legitimate access due to an incorrect AccessMode value.

This issue is tracked here: Implement access_mode_policy · Issue #664 · AravisProject/aravis · GitHub

Cheers.

Hello Emmanuel,

Thank you for your response and your explanation,

Yes, I forgot to mention that I was using Python bindings, but I also tried the case with C code directly to make sure this wasn’t a problem from the bindings or python itself.

I understand the reasons now. What would be the reason of the lack of reliabiliy of this feature ? It isn’t supposed to follow the genicam standard ?

Hi,

The main reason is nobody stepped up to improve its reliability. And also because testing the reliability means to be able to test Aravis on a lots of devices.

1 Like