Different behaviour in MAX vs. LabVIEW when writing to IMAQdx GigE attribute

[AnthonV]

Hi, I am controlling a Dalsa GigE camera in LabVIEW RT using IMAQdx.  Apart from a couple of quirks with the interface we are acquiring images without much problems at the moment.  

However, there are one or two issues that are confusing us.  In this case, it is possible to set an attribute in MAX (a command attribute that instructs the camera to perform internal calibration) but when setting the same attribute in LabVIEW the error 0xBFF69010 (-1074360304) Unable to set attribute is thrown.  See attached images.

I check whether the attribute is writable before attempting a write.  It is, however the write is unsuccessful and reading the iswritable attribute then returns false.  In MAX I can write to this attribute without any issues.  

Is there anything that I need to configure/read/write in my LabVIEW code that MAX does.  Does MAX write to all attributes (based on the values in the XML file) when it opens the camera or does it simply read all the values from the camera.  When LabVIEW opens a camera reference does it perform the same steps as what MAX does - I'm trying to figure out what the difference between MAX and LabVIEW could be that could be causing this behaviour.

Any help will be appreciated.

[Paul_M.]

Hi AnthonV,

Try running the Grab and Attributes Setup.VI Example to see whether or not you're able to write to that particular attribute. You can find this example in the Example Finder under Hardware Input and Output » IMAQdx » High Level » Grab and Attributes Setup.VI. This example creates an attribute table that should match with the attributes that are displayed in MAX.

Paul M 

[BlueCheese · Accepted solution]

---

@AnthonV wrote:

Hi, I am controlling a Dalsa GigE camera in LabVIEW RT using IMAQdx.  Apart from a couple of quirks with the interface we are acquiring images without much problems at the moment.  

However, there are one or two issues that are confusing us.  In this case, it is possible to set an attribute in MAX (a command attribute that instructs the camera to perform internal calibration) but when setting the same attribute in LabVIEW the error 0xBFF69010 (-1074360304) Unable to set attribute is thrown.  See attached images.

I check whether the attribute is writable before attempting a write.  It is, however the write is unsuccessful and reading the iswritable attribute then returns false.  In MAX I can write to this attribute without any issues.  

Is there anything that I need to configure/read/write in my LabVIEW code that MAX does.  Does MAX write to all attributes (based on the values in the XML file) when it opens the camera or does it simply read all the values from the camera.  When LabVIEW opens a camera reference does it perform the same steps as what MAX does - I'm trying to figure out what the difference between MAX and LabVIEW could be that could be causing this behaviour.

Any help will be appreciated.

---

Hi AnthonV,

"Quirky" is a good way to describe the Spyder3 when it comes to the GigE Vision/GenICam interface (as opposed to Dalsa's driver which communicates using custom serial commands to the camera over ethernet).... 🙂

The Spyder3 has a lot of timing-dependent issues. It is possible that the delay between opening the camera and setting that feature is different via MAX vs your code in LabVIEW. Also, there are certain cases where MAX will surpress the error from being displayed. Ignoring the error shown vs. not, do you see the feature take effect in either of the two cases?

The basic behavior between MAX and LabVIEW is the same. In both cases when you open the camera all the settings are loaded from our camera file which has the saved camera settings. This file is created the first time you open the camera and is updated whenever you click Save in MAX or call an API function to save the settings. In any case, I do know that the Spyder3 has various issues saving/restoring settings to our camera files.

I suggest talking with Dalsa about the issues you are having. They might be able to set you up with newer firmware that addresses some of these problems (we have worked with them in the past to identify many of them).

Eric

[AnthonV]

Success!

I tried Grab and Attributes setup.vi in the examples and this returned the same error.  Then I tried BlueCheese's suggestion of simply ignoring the error as this is what MAX would do - the camera DID in fact perform the calibration even though the attribute error mentioned above was returned.  I will try this method with some of the other quirks I am seeing and I am sure I will be a happy man tonight.  

I have also requested the latest firmware from Dalsa and will do an upgrade for what it is worth.  

FYI using Dalsa's own interface program comes with its own set of frustrasions as different quirks and bugs appear.

An aside - I am not clear how GeniCAM maps to GigE Vision attributes nor do I know how to get into "GURU" mode - dalsa informed me that in GURU mode I will be able to see and set the DeviceReset attribute in MAX as I want to reset the camera programatically.  Does anyone have any idea what this means?

[BlueCheese]

---

AnthonV wrote:

An aside - I am not clear how GeniCAM maps to GigE Vision attributes nor do I know how to get into "GURU" mode - dalsa informed me that in GURU mode I will be able to see and set the DeviceReset attribute in MAX as I want to reset the camera programatically.  Does anyone have any idea what this means?

---

GenICam translates feature access to register access over GigE Vision. The Spyder3 translates those register commands internally to serial commands that match what the CameraLink version of the Spyder3 uses. This translation is a bit rough in some areas.

GenICam defines multiple levels of visibility for features. If you look in MAX you'll see that the feature tree has a drop-down menu item that lets you filter what level you can see. The default level is "Advanced" and translates the "Guru" in GenICam terminology.

The reason you are not seeing the DeviceReset attribute is that the IMAQdx driver intentionally overrides the visibility of this to Hidden. This is because the resetting the camera causes the camera to simply reset and so if someone were to click on it in MAX the camera would simply get timeout errors after the reste and have to be opened again. It is something that generally you would use in code but not via MAX. Hidden features can still be accessed via IMAQdx's API the same as any visible features. Additionally, we have a VI in our IMAQdx.llb (where all our palette VIs live, although this particular VI is not on the palette) called "IMAQdx Reset Camera" that works for GigE Vision and FireWire cameras and abstracts this behavior.

Eric

[AnthonV]

Hi Eric,

I called IMAQdx reset camera.vi in IMAWdx.llb but I get the error message "Camera already in use".  Initially I thought I might still have MAX running but no the only program running is my realtime VI that is calling this function.  Any ideas?

[BlueCheese]

---

@AnthonV wrote:

Hi Eric,

I called IMAQdx reset camera.vi in IMAWdx.llb but I get the error message "Camera already in use".  Initially I thought I might still have MAX running but no the only program running is my realtime VI that is calling this function.  Any ideas?

---

I believe the VI might expect the camera to be closed when you call it (because it will be closed after the reset).

Eric

[AnthonV]

Yes that worked thanks Eric.  Even though the help on the reset vi states that it will stop any currently active acquisitions I had to close the camera and wire the cam reference (now strictly speaking not valid anymore?) to the reset vi.  

This solves my problem.  Thanks for all the help.

[DarkLordOfG]

Why are some attributes not writeable outside of max?  Is this because of the camera setup needing to know the image size (i.e. why cannot I change the binning)?

John

[AnthonV]

First you need to confirm that MAX is actually successfully writing to the attribute.  I found that even if an attribute is not grayed out in MAX and you change its value, this change doesn't always get registered by the camera.  I think MAX masks the error returned, but doing the same in LabVIEW will return an error.  It could be that the camera manufacturer simply didn't bother implementing access to that variable across the Genicam interface, but that it is writable via their own provided interface program.

However if you do see that the change is done successfully using MAX but not in LabVIEW, then it could be that the camera needs to be in some specific state before that attribute can be set (e.g. not acquiring images) or that the attribute's writability depends on the value of another attribute.

You could ask the camera manufacturer about this.  On my Spyder I found at 1 attribute that wasn't implemented via Genicam, the newer model of the camera does have it implemented.