How does LabView 8 handle Ring constants?

[JasonWB]

Hi all,

This is probably more for NI guys, but I am wondering how LabView 8 handles text rings?  In the past, constants dropped into a VI that are of type "enum" will be updated when the typedef is updated, however, ring text constants will not.  Has this changed in LabView 8?

Thanks,

Jason

[ChrisJ]

Hi Jason,

That is a great question. I don’t believe the functionality of the text ring has changed much from previous versions, however you should be able strictly type a ring control in both LabVIEW 7 and 8. When a control is strictly typed it will force all instances to be identical to the strict type definition and update all of the text constants. The regular type def only checks to see if the data type of the control has changed. I hope this helps.

Cheers,

Chris J

[Ben]

Part 1 of 2

Hi Chris,

Please forgive me for differing on this point but you should have written

"

When a control is strictly typed it will force all  [front panel] instances to be identical to the strict type definition and update all of the text constants.

"

The "strict" part only takes care of the appearence and those changes only affect instance were they are seen by a user. The strings associated with the enum do not affect block diagram constants.

The attached image and zip illustrates that the representation of an enum and a ring a very different. An enum has the defined strings "hidden" in the wire and the numeric value can only be one of the valid indexes of the defined strings. In this example I have shown three different constructs that illustrate the fundemental difference between rings and enums.

1) Case Structures - An enum driven case will pickup the valid choices as defined by the enum's definition. A ring does not carry this info in the wire so it is NOT possible to label the cases to match the ring. This brings up another compliation. If the case structure does not have a default case defined there must be a case for each possible selection value. The strings of an ring can be defined at run-time. Is LV supposed to re-compile the case structures code every time the ring is re-populated? In the case of an enum driven case, this is not an issue because enums that are used in a VI that is running or reserved to run can not be editied.

2) The "Format into string" can pick-up the valid enum strings by decoding the type descriptor of the enum wire. This is not the case with a ring because the ring is just a number.

3) The "Flatten into string" function will return the type destriptor of whatever is wired to it. The typed descriptor contents of a enum shows that every valid selection for that enum is defined in the enum wire. Please note that the type descriptor for a ring has no information about any strings.

End of part 1 of 2

Ben

Message Edited by Ben on 10-15-2005 10:41 AM

[Ben]

part 2 of 2

A ring is nothing more than a numeric with a fancy GUI implementation that allows you to choose the value based on a list. Once the numeric value is selected the strings do not come into play.

In order to change a rings functionality such that it behaves like an enum would require the data type of the ring be redefined. This would make all data log files or any other data structure that is produced by doing a "flatten to string" incompatable with earlier versions of LV. LV 7.1 can open datalog files going back to LV 5.0 because this data structure has been stable. Similarly, VI server in LV 7.1 is able to call VI's served by LV 6.1.

There would have to be a VERY good reason to abandon all of those older versions of data log files and other functions for LV 7.1 and and earlier.

Although this request may seem trivial, if implemented, all of the VI that have been devloped over the last 7 years would become obsolete and incompatable with the new version of LV. If this type of change is implemented, NI better put on their flame suits because there will be a lot of un-happy developers.

The enum and ring although similar in appearance are very different data types. Each have their place in LV and perform their functions well.

Trying to help,

Ben

Message Edited by Ben on 10-15-2005 10:42 AM

[Ben]

I should have written

"

The "strict" part only takes care of the appearence and those changes only affect instance were they are seen by a user. The strings associated with the ring do not affect block diagram constants.

"

Ben

[JasonWB]

Hi everyone,

Thanks for all of the replies - I appreciate it!  It apears as if we will have the same problem with rings that we did in earlier versions of LabView - it probably will not update.  What I am trying to do is the equivalent of a typedef enum in C with specified values, such as:

typedef enum

{

     Cmd_1 = 0x1000,

     Cmd_2 = 0x1100,

     Cmd_3 = 0x1200

}  Commands;

The problem here is that if you creat a *constant* somewhere, then go back and change the value of Cmd_2 from 0x1100 to 0x1150, for example, the constant in your code will *not* reflect that change.

Thanks again!

Jason

[Ben]

Hi Jason,

What you are looking for is "sparse enums".

We have been asking for that feature for years.

Years ago Rolf Kalbermatter posted to Info-LabVIEW explaining how to create them in in CVI and then import them to LV.

I also would like to "sparse enums".

Ben

[Ben]

This is the Info-LabVIEW posting by Rolf Kalbermatter wrote.

"

>You will find the following values of this enum-const:
>first item: value = 0
>second item: value = 1
>third item: value = 20
>
>This is a very interesting phenomen. But how can I produce such a
>enum-const with individual value by myself?

You really can't (yet)! Although LabVIEW can deal with such sparse enums
there is no editor interface to create them. The ComponentWorks library
has an according definition in the ODL file and LabVIEW generates such
an enum when importing that ODL definition. Another way to create them
is by creating a FunctionPanel in LabWindows CVI and import that Function
Panel with the Tools->Instrumentation->Import CVI Instrument Driver.

Rolf Kalbermatter
"

Ben

[JasonWB]

This is pretty much the feedback I have been getting.  IMHO, it really comes down to a design deficiency in the LabView enums.  LabView provides a graphical way of programming, but to be considered a "real" programming language by some of the hardcore C and C++ guys, it is going to have to mimic some of that functionality.  A "C" enumeration will assign sequential numbers, starting at '0' if you just have:

typedef enum

{

   item1,

   item2,

   item3

} items;

However, you can include "=" signs afterwards to manually control this.  That functionality really ought to show up in LabView one of these days.

[Ben]

"That functionality really ought to show up in LabView one of these days."

Ditto that!

A converter will let you code this up.

Wire up an enum to a case and get rid of the "default" case.

Make sure there is one case for each enum value.

In each case drop the proper constatnt and wire it out through an output tunnel of the case structure.

Drop this VI beween the enum and "something else" any time you want to convert from enum to the "sparse" version.

If the enum is made a type def AND there is no default case, when new enum values are added, the "converter" will break reminding you that the "converter" needs updated to keep up with the enum.

Yes, LV should have "sparse enums"!

Ben