Darren's Weekly Nugget 03/16/2009

[Darren]

This nugget is the fourth in a series of nuggets on Case structures.  Today I will discuss Case structures that use Enum data types for their selector values.

Enum selector

The Enum data type allows you to have sequential numeric data that has a textual representation.  If you have an enum with the values 'abc', 'def', and 'ghi', those names are actually part of the Enum data type values.  Contrast this with a text or menu ring, which displays text, but on the diagram will only return numeric data (0, 1, 2, etc.).  This difference can most easily be seen when wiring enums and rings to Case structures:

 

Due to the self-documenting nature of enums, state machines that use them for their selectors tend to be pretty common.  However, in the comments of last week's nugget, several users began debating the merits of using enums vs. strings for controlling the execution of state machines.  I recognize the pros and cons of each approach, and honestly, I see both sides.  I have used both string and enum case structures for state machines over the years, but I'd say my weapon of choice is usually the enum case structure.  The self-documenting and less error-prone nature of enums is a big sell.  I used to be a fan of the "Add Case for Every Value" option, but found that a lot of the enums I depend on are maintained by other people, so my code would often break when new values were added to enums that were outside my control, so I opted to code up safe "Default" cases instead.  My situation is rather unique though (working in LabVIEW R&D, shipping code that is part of LabVIEW, and utilizing enums in my code maintained by other people), so I'm guessing "Add Case for Every Value" is more useful for developers outside NI.

Finally, I offer this advice...always typedef your enums.  I can't think of any reasonably-sized project I've worked on where I didn't have to edit the contents of enums in my project multiple times.  Even if you're positive you'll never add another value to your "On" and "Off" enum, you never know when the boss will come in and demand a new "Lukewarm" case.

Message Edited by Darren on 03-16-2009 11:37 AM

[Intaris]

Amen to the "Typedef" suggestion.

I don't recall ever regretting making a control a Typedef whereas I've often thought "Why didn't I make this a typedef ages ago..... It would have saved me so much p.i.t.a work."

Shane.

[dan_u]

Sometimes you'll need the enum value as string (for instance to log states of the state machine).

It was already discussed in the forums how this can be done, the easiest way is to use "Format Into String".

 

Daniel

Message Edited by dan_u on 03-16-2009 05:44 PM

[Ben]

Thanks Darren,

Could you comment on the speed of the various selector data types?

Boolean vs Error Cluster

Enum vs String    - the effects of the length of the string on the speed.

What kind of dealy am I introducing to code when I used an error case when there is "NO error"?

Ben

[johnsold]

Excellent question, Ben.

While it is probably irrelevant to most state machine applications of case structures, it may be significant in other applications.

Darren, Another speed case: Greater than Zero with boolean case selector versus integer case selector with cases ..0 and 1..

Lynn

[Broken_Arrow]

Perfect, well done Darren. I have regretted not type-deffing Enums a few times, but I have more often regretted using strings for case structures.

Speaking of other people using/modifying the enums you create, I have found it very valuble to pepper in a few "Spare1", "Spare2", etc.

[MattBradley]

The amount of time I have saved typdefing enums has been substantial...

[Ray.R]

I hope that more than just the regular crowds will read these important nuggets.. 

Thanks Darren!

[Darren]

---

Ben wrote:

Could you comment on the speed of the various selector data types?

---

I have a pretty simple benchmarking VI that I wrote for my NI Week 2008 presentation.  Using that as a starting point, I discovered the following tidbits. Since we're dealing with extremely small differences in time here, I can't give any exact figures, so these are general results:

• An error cluster wired directly to the selector of a case structure runs a tiny bit faster than an error cluster that is unbundled, whose status is wired to the selector.
• A diagram whose code is surrounded by an error case runs slightly slower than a diagram with no surrounding case.
• A numeric wired directly to the selector of a case structure with "..-1" and "0.." cases runs a tiny bit faster than being first wired to a "Greater or Equal to Zero?" function, whose output is wired to a Boolean case structure.
• An Enum wired into a case selector can run quite a bit faster than a string wired to a case selector.  The number of cases didn't seem to matter too much, but as Ben probably guessed, the longer the input string, the wider the discrepancy in performance...longer strings take a while for the string case selector to parse.

The morals of the story:  Wire data types directly to the selector when you can, and stick with Enums if you're concerned about performance.  I remember when the JKI State Machine came out, my first question for Jim was to ask how the performance of the state machine was affected by its heavy utilization of string cases.  His response (which was perfectly valid) was that, for their state machine, the usability gains they achieved by using strings were significant enough to outweigh any performance benefits they may have seen with another data type.  Since one of the biggest benefits of the JKI State Machine is indeed its usability, I agree with that line of reasoning.

[JK1]

Hai,

When it comes to the condition as shown in the picture i.e. having cases like hai,Hai string and enum acts similar way of execution.  But in strings there is a "case insensitive match" option which will force user to have only hai or Hai case.  This might be of use in certain occasions.  iam still a fan to 'enums' though

Just pulling in some differences to get more out of the Forum