# Is\_locked inconsistent between FLIR and Allied Vision with Aravis
**URL:** https://aravis-project.discourse.group/t/is-locked-inconsistent-between-flir-and-allied-vision-with-aravis/927
**Category:** Uncategorized
**Created:** [June 16, 2025, 11:09am UTC](https://aravis-project.discourse.group/t/is-locked-inconsistent-between-flir-and-allied-vision-with-aravis/927 "2025-06-16T11:09:48Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@\_csgeek](https://aravis-project.discourse.group/u/_csgeek)
#### Post date: [June 16, 2025, 11:09am UTC](https://aravis-project.discourse.group/t/is-locked-inconsistent-between-flir-and-allied-vision-with-aravis/927/1 "2025-06-16T11:09:48Z")
Hello,
I’m currently developing a camera application using **Aravis** and I noticed some inconsistent behavior related to the **is\_locked** parameter in `ArvGcFeatureNode` between FLIR and Allied Vision cameras.
When I connect to a FLIR camera I see certain read-only parameters have **is\_locked** set to `true` while the camera is grabbing or certain properties are not available at that moment. For ex: If PixelFormat is set to BayerRG8 then Hue and Saturation won’t be writable.
This lets me know when it’s not safe to modify certain settings.
However, with **Allied Vision** cameras, the `is_locked` for these parameters are always False.
**Questions:**
- Is this a limitation of Aravis, or a reflection of the GenTL or camera’s capabilities?
- Is there a standard way to detect when parameters are locked in scenarios like this?
Any guidance or best practices for gracefully handling parameter locking across different camera vendors would be much appreciated.
Thank you in advance for your help!
---
### Author:  [@eudoxos](https://aravis-project.discourse.group/u/eudoxos)
#### Post date: [June 16, 2025, 1:35pm UTC](https://aravis-project.discourse.group/t/is-locked-inconsistent-between-flir-and-allied-vision-with-aravis/927/2 "2025-06-16T13:35:11Z")
Without knowing the specifics (about FLIR and AlliedVision cameras you have), those things are described in the genicam XML which Aravis gets from the camera and interprets. You can use arb-tool to get that XML and inspect it for yourself. If the XML is well written, it will express what the firmware is ready to handle, and should not let you do anything which is unsafe (such as modifying payload length or format while acquiring).
Looking at another camera here (VRmagic), some nodes have `...` while others (like acquisition start) might have `...` referring to that register.
Not sure if it is best practice, but I ended up with vendor-specific genicam sequences for stages of setup (one just after connecting after connection; one before acquisition starts; one to stop acquisition etc).