IMAQdx Enumerate Objects.vi and IMAQdx Write Attributes.vi inconsistent results

[bean123]

I would like to create a module that allows the user to quickly review, change, and save camera attributes from LabVIEW (not using MAX).  The reason is that I want them to be able to change things on the fly in the app to test different setups. Its annoying to have to stop the app, switch to MAX open the camera, start grabbing, change the settings, close the camera and max, and restart the app.  I got tired just writing that sentence.

I found a nice example in LabVIEW xxxx\examples\Vision Acquisition\NI-IMAQdx\High Level\Grab and Attributes settings and used that as a baseline. The problem I'm having is IMAQdx Enumerate Objects.vi seems to return a different list of objects from time to time.  It appears that with just LabVIEW open, when I use IMAQdx Enumerate Objects all the "camera attributes" are missing (not returned).  But if I go and open MAX, open the camera in max, the LabVIEW VIs seem to return all the attributes including the "camera attributes".  Also when saving the IMAQdx Write Attributes.vi seems to save a different list of attributes to a text file depending on the conditions.

Why does this happen?  Is it a bug?  Is there a way to use the same function that MAX uses to enumerate the list in LabVIEW?  Why does the IMAQdx Write Attributes.vi save a different list of attributes from time to time?

For right now, I'm only using a system webcam and haven't tried this out on a machine vision camera, but I'm not going to go much further down the path unless I can convince myself that I can load and save attributes in a repeatable manner. 

[kensign]

Hello,

It definitely seems unexpected that calling Enumerate Attributes would vary in what it returns. Did you see the optional parameters to provide a root and a visibility? Are you just going with the defaults there? To my knowledge, what you're doing in MAX absolutely should not affect the results of calling that VI, but I'm just curious if you see more consistency if you explicitly set those. I have attached my little VI that's doing that.

Regarding the Write Attributes VI, the list of which attributes are written out to the file should absolutely be consistent. The driver attributes are fixed, and the camera attributes should be dependent on what the vendor provides. Admittedly I am much less familiar with strange things that can happen with webcams, so maybe there's a gotcha there. For machine vision cameras, I've never seen an issue like that before. Can you attach the files that get written in the cases that they are different?

If you can attach a simple VI you're using and explain what you're doing in between to get different results (i.e. Open the camera in MAX, change something, close the session), then I will try to reproduce it here.

Thanks,

Katie

Senior Software Engineer, Vision R&D

[bean123]

Yes I see the root and visibility optional parameters and am using the defaults. I attached a simple VI that modifies some example code from the NI directory and a video to demonstrate what I'm seeing.  Hopefully it helps.  when I run the attached code, the tree will populate without the "camera attributes".  If you press the reinit button (which should execute the same steps again), the camera attributes appear.

I agree webcams are funny.  I haven't tried this out on our Basler camera but I think I remember seeing something similar happening.  I initially thought it was a race condition because every once in a while, the camera attributes will appear on the first call.  That's why I added the wait in the code, but it doesn't seem to change anything

[bean123]

So I tested the code with a Basler ace gigE camera and the bug did not happen.  The reading and writing of Attributes was consistent for the Basler.

I also tested the code on another laptop webcam and the bug happened with a different webcam.  It seems to be only appearing on webcams, but that begs the question why?  Is there something different about the imaqdx code for attributes on those camera types?

[kensign · Accepted solution]

Hello,

Sorry for the delay in getting back with you. I watched your video and it was definitely puzzling. I'm relieved that at least for the Basler (your ultimate intended use-case?) things behave more sanely.

Is there something different about the imaqdx code for attributes on those camera types?

Yes, the attributes are handled very differently between the two. If a camera is GenICam compliant (like your Basler GigE camera), IMAQdx is using GenICam standard software to download the camera's XML file and determine which attributes should be persisted. We thoroughly test the interoperability of IMAQdx and GenICam compliant cameras for attribute enumeration and persistence, and we have complete visibility into what's happening there in the event something goes wrong.

In the case of webcams, we're interacting with the DirectShow API, which is a black box to us. There are more quirks for specific camera models, and it's much more likely that there can be some sort of bug in a particular webcam or class of webcams that can cause strange behavior with attribute enumeration and persistence. Webcams are not standardized to the same level of quality that we're used to with GenICam cameras.

So, I'm not really sure what's wrong in your webcam case -- we'd probably have to get one in house and try to step through the code to see what's happening. Regardless, strange behavior there should not impact the riskiness of using IMAQdx with a GenICam camera -- more likely than not it's a webcam-specific quirk. Either a bug with the camera's DirectShow driver (that's my bet), or a bug in IMAQdx that is specific to the webcam case.

Hope this helps,

Katie

[0Forest0]

Hi, bean123. I am looking to same vi. I'm trying to  make a camera get its attributes from .icd file at start a program. I see you do reinitialize step in your video. How it is? May you save your VI to prevarius version (Labview 17)?

I change .icd file and set attribute to camera by propertie node. But in MAX they not take effect.