setting IMAQdx enum attributes #@!?%!

[lanmat]

Even though enums were beautiful for setting 1394 attributes, I'm fine with using strings for the new IMAQdx vis. But who was in charge of setting the enums?!? I get the following for the Strings[] and EnumValues[] properties for the CameraAttributes::Shutter::Mode--

Absolute      1
Auto             3
Relative       0
OnePush     4
Ignored         5

Does anyone see a 2? And why aren't they in order? And why did I have to make my own little vi to figure this out instead of it being somewhere in a help file? It's bad enough that we aren't given any of these enums as typedefs at all, but it's another to have the enum values not sorted and missing values here and there. Sure, I could make an enum myself with the appropriate text in sorted order, skipping the #2 slot, but why should I have to when there could easily be a list of accepted U32 values and what they correspond to in a help document somewhere? Maybe it's because I didn't get much sleep the past few days, but it seems like an obfuscating step backward to me even if it does allow communication with GigE cameras.

Message Edited by lanmat on 11-29-2006 05:48 PM

[JohannS]

lanmat

The available enumerations for any attribute (including Shutter Mode) is dynamically determined by the driver. Only the enumerations that is supported by the attribute is returned to the user. The available enumerations for the Shutter::Mode attribute is

FeatureMode = {
  Relative = 0,
  Absolute = 1,
  Off = 2,
  Auto = 3,
  OnePush = 4,
  Ignored = 5,
};

That means that the driver determined that your camera does not support the Off shutter mode. I agree that the ordering is confusing, but the intent is to dynamically populate a control in LabVIEW with the available enumerations and set the attribute from the selected values. See the attached VI for a simple example. Also see shipping Grab and Attributes Setup.vi example for a complete example.

I assume you want an enum in order to quickly hard-code a value in your application. The danger is that if you do hard-code a value and you change cameras, then the value might suddenly be invalid. If you can ensure that the camera is not going to change, then its safe to hard-code a constant integer or string value.

Hope this helps,

JohannS

[Ben]

Johann wrote;

"

but the intent is to dynamically populate a control in LabVIEW with the available enumerations

"

Do you have LV code that will create a spase enum?

Could you share it?

Ben

[JohannS]

Ben

See attached file (DynamicMode.vi) from my previous reply.

JohannS

[Ben]

You are teasing me here Johann.

Lanmat's issue was with the SPARSE ENUM.

We have been waiting and watching for the first sign that sparse enums can be created in LV.

Your example just populates a ring. Bummer

Still waiting and hoping,

Ben

[JohannS]

Ben

How about this example? It is a ring with a non-sequential list of enumerated values.

Johann