Why an IVI-COM enumerated type does not show up its values in a LabView VI enumerated property input?

[sorinxxxx]

I have a problem with a property that expect an enumerated value as an input in an IVI COM driver.

If I choose Create->Constant for that property then I get a constant I32 that let user any I32 value. I don't want that as the property expect only 1 or 3 values dependinf on the instrument model that the IVI COM address so I go for an enumeration type input.

If I select an Enum constant control from the Numeric Pallete I see the enumeration control but it is empty letting the user no choice to select.

More than that the Enum control representation is U16 instead of I32 as I would expect and the option I32 is grayed out leaving me no choice but to accept U16 data type?

Thansk

Sorin Lazarescu

[EadieU]

Hi Sorin,

Can you please attach an example of a VI that shows this behavior?  That will allow me to see what you're saying.  

Regards,

Mark E.

Applications Engineer

National Instruments

[sorinxxxx]

Hi Mark

I did not see any way I could attach a VI or a file to my messages. Could you provide me a tip how I may do that?

Thanks

Sorin

[Dennis_Knutson]

Most people just use the 'Add Attachment' that is right below the message body.

[sorinxxxx]

Thanks

I build the VI using a property that expect an enumerated type as parameter. The property called Mode is defined in IMAP200_OAChannelSource interface. When this property is accessed directly trough this interface by using Create->Constant automatically the enumeration values are displayed so the user may select any enumeration value from the set. When the same enumerated property is accessed from a higher level interfaces as the parent interface of IMAP200_OAChannelSource interface which is the IMAP200_OAChannel interface then the Mode property that comes noe as Source.Mode property does not shows the enumerated values when Create->Constant is used but is showing a generic Integer value.

I filled the Source.Mode  integer with 0 for having some value but how the user knows what possible integer values or even if that property called now Source.Mode is an enumrated type and what integere values he should use for this property as input?

The only solution for these kind of properties values that are defined in lower interface level than the IMAP200_OAChannel is to go directly and extract the original definition interface and use that one with all the complexity that comes along as more open interfaces means more closing interfaces and more paths for a single VI.

What is funny is that this issue of porting enumerated values to a higner level interface than the original interface definition is failing only for Properties defintion and not for the Methods definition which seems to keep the enumeration values into the higher level interfaces!

Beside this glitch the ClassBrowser is quite a good tool to develop VIs from IVI-COM drivers as I see.

Thansk

Sorin Lazarescu

[EadieU]

 Where does the IMAP200_OA property node come from?  It does not appear in my Class Browser.  Did you create or import it?

Besides that, what did you mean by "higher interface" when you said that someone would access the property node through a higher interface?  Do you mean that the Source.Mode property node will be in a subVI and the property node will be set through input terminals to that subVI?  If so, do you want an enumerated list when you select Create»Constant for that subVI's input terminal?

[sorinxxxx]

Hi Mark

The IVI-COM driver referenced in my VI samples is installed on my PC and I open it using the OpenRef. Of course you don't have the IVI-COM driver installed on your PC so there is no way to have a real connection to a real IVI-COM on your PC. That does not mean that the problem presented in this topic is not real and I sugest you to direct this to someone more familiar with the usage of IVI-COM drivers trough the Class Browser interface. Even if you install my custom IVI-COM driver on your PC that would not change the matter of the problem as described below.

The above 2 VIs show clearly that the Class Browser shows the input of the same Property, that uses enumerated values, in two different formats depending what interface accesses this Property.

Thanks

Sorin

[EadieU]

Hi Sorin,

I can help you, but you didn't answer my question and there's only one VI.  Please answer my question and post the other VI.  

[sorinxxxx]

Sorry there is only one VI required to show the real problem so no need for two VIs as I stated earlier.

In that VI I accessed the same enumerated property called "Mode" trough two different branches. In one branch of the VI I accessed from the Source interface directly and in the other branch I accessed from a parent interface of the Source interface that is the Channel interface. As it is clearly shown in that VI the if Mode is accessed from the Source interface the enumeration values are shown but if the Mode property is accessed from a parent interface of the Source interface the enumeration values are not shown anymore being replaced by integer value only. I repeat that this VI is build using the Class Browser for IVI-COM drivers that is a feature of the LabView 8.6.

All the required information to adress the Class Browser issue with IVI-COM drivers in regard to enumerated properties display is there waiting for few weeks to be addresed by anyone interesed in having a feedback on the Class Browser tool.

Sorin

[EadieU]

Sorin,

I am looking into your issue, but had one question. Is it possible that your methods are being inherited from the parent class but the properties are not?  That is one possible explanation for the behavior you are experiencing.  

You should heck out this, if you haven't already: LabVIEW Object-Oriented Programming: The Decisions Behind the Design  

It won't necessarily answer your questions related to your post, but is a very good introduction to LabVIEW's approach to OOP.