Non sequential Typedefs/Ring

[shred444]

This has been discussed several times in these forums, but I have never actually found a resolution to the question:

 

In this scenario, I have a C enumerator defining a bunch of errors:

enum{    NoError = 0,    NotInitialized = 1,    MotorOverheated = 2,    MotorDisconnected = 4,    CommutatorError = 8}

 

When this value is sent to LabVIEW, i'd like to parse that easily by wiring it directly to a labview enum that I have created.

 

 

Here's the problem, the C enumeration is not sequential, and LabVIEW enumerators must be.  So there is an offset.  

 

Now if I were to use a Ring to define my motor errors, I run into the problem discussed in many threads regarding how rings do not update even if they are strict typedefs.

 

What i end up having to do is create a conversion VI that basically uses a case structure to convert the error from the C enumerator, to a labview typedef. What a pain.

 

 

So what's the best way to do this?

 

[hooovahh]

I don't know if this is the "best way" but have you thought about making your enum with Reserved3, Reserved5, Reserved6, Reserved7 placed in between valid values?  This way you can have your enum in a case statement, but also directly change from a U8 of value 4 to MotorDisconnected.

 

In the past my numbers have jumped alot, say from 0, 1, 125, 500, 1000 so using an enum with blanks was not a solution, but for this it may be.  In my case I was lucky and my enum value was something to the effect of "500 Baud", "1000 Baud" so I got it as a string and converted it to 500 and 1000 decimal but that too is not an option here.

 

EDIT:  Is there a valid reason why Enums must be sequential by the way?

Edited October 4, 2013 by hooovahh

[shred444]

So yes, I have thought of putting Reserved elements, but my example above was too simplistic for some of the elements I would need to parse. They could skip hundreds, like you were saying.

 

I guess my main problem is, Why do enums need to be sequential. In all other languages, they are not.

Edited October 4, 2013 by shred444

[shoneill]

There's a proposal for "sparse enums" on the Idea Exchange on the NI site.  Vote for that if you really want this functionality.  You're certainly not alone.

[shred444]

Good find, Here's the link for others to upvote: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-sparse-enums-to-LabVIEW/idi-p/925224

[Yair]

What i end up having to do is create a conversion VI that basically uses a case structure to convert the error from the C enumerator, to a labview typedef. What a pain.

 

ConversionVI.png

 

It should be pointed out that this could be automated by reading the definitions from the C code, making it considerably less painful. There's probably even some code which does this in the LAVA CR or elsewhere on the site.