Better use of case structure

[jyang72211]

Hi all,

I am trying to convert some text-based code to labview.  I am working on a section that determine what spec to use, depending on the current level, power factor, class, and energy type (see attached).  The attached table is for real energy.  There is a different table for reactive and apparent.  As I start to convert the code into labview, I run into a lot of nested case structure, which makes the code very difficult to understand.  Also, I find it harder to think in Labview when I have nested condition statements (see a protion of the code that I need to convert).  My questions are

what is the best way to code a nest conditional statement to ensure best readability and efficiency?  In LabVIEW, what are the ways that I can use to make my code more readable?  Also, are there good methods that can help me to think through my code graphically?  I guess I can code everything in a text-based language first and convert, but I find it very ineffcient.

Thanks!

select energyChannel

!Active Energy

case KWH_D, KWH_R, KWH_DpR

if ( C < 1)

if (setPF = 1) 

if (setAmps[T] >= (0.01 /*1%*/* ampsNominal) and setAmps[T] < (0.05 /*5%*/ * ampsNominal))

limit = 2 * C

elseif (setAmps[T] >= (0.05 /*5%*/ * ampsNominal) and setAmps[T] <= (1.2 /*Imax*/ * ampsNominal))

limit = 1 * C

else

limit = N_A

endif

elseif (setPF >= -0.5 and setPF <= 0.8)

if (setAmps[T] >= (0.02 /*2%*/* ampsNominal) and setAmps[T] < (0.10 /*10%*/ * ampsNominal))

limit = 1.7 * C + 0.15

elseif (setAmps[T] >= (0.10 /*10%*/ * ampsNominal) and setAmps[T] <= (1.2 /*Imax*/ * ampsNominal))

limit = 1 * C  + 0.1

else

limit = N_A

endif

else

limit = N_A

endif

else /* C >= 1*/

if (setPF = 1) 

if (setAmps[T] >= (0.02 /*2%*/* ampsNominal) and setAmps[T] < (0.05 /*5%*/ * ampsNominal))

limit = 1 * C + 0.5

elseif (setAmps[T] >= (0.05 /*5%*/ * ampsNominal) and setAmps[T] <= (1.2 /*Imax*/ * ampsNominal))

limit = 1 * C

else

limit = N_A

endif

elseif (setPF >= -0.5 and setPF <= 0.8)

if (setAmps[T] >= (0.05 /*5%*/* ampsNominal) and setAmps[T] < (0.10 /*10%*/ * ampsNominal))

limit = 1 * C + 0.5

elseif (setAmps[T] >= (0.10 /*10%*/ * ampsNominal) and setAmps[T] <= (1.2 /*Imax*/ * ampsNominal))

limit = 1 * C

else

limit = N_A

endif

else

limit = N_A

endif

endif

[RavensFan]

I don't know if I completely understand the table you have posted.  What are the inputs you are testing vs. what are the outputs (the last two columns?)

But what if you treated this like a  2-D lookup table.

If you have a set of conditions for the X value.  You do the comparisons and it gives an enum that tells you what row of the table to look at.

You have a set of conditions for a Y value.  You do the comparisons and it gives you an enum that tells you what column of the table to look at.

You use those enums as indices to pick out a value from a 2-D array.

Since it looks like your right hand two columns have several repeated formulas, some of which are "no requirement", perhaps the lookup from that 2-D array is another enum which tells a final case structure which set of formulas to use.

[Darin.K]

This is the exact type of code that led me to suggest the following:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-Multiple-Case-Selectors/idi-p/1301780

You could cross your fingers that by LV20 something like this might come along.  These type of nested comparisons can be refactored and improve readability over the "pyramid" you build with nested case structures.

Since I am not holding my breath for that one, my suggestions are the following:

1) You can collect all of the comparisons and all of the results limits=???.  Create a binary array from the comparisons and map the results to the appropriate case (set case radix to binary).

2) Use a state machine, avoids nesting case structures but the zigging and zagging required to follow the code is almost as bad as nested case structures.

3) Bite the bullet and nest the case structures, just use free labels everywhere to try to make it easy to follow.  I also try hard to align the different case labels as much as possible.

4) Deep in the bowels of a subVI place this code with minor modifications into a formula node.  Try to compensate for the lameness of this method by giving the subVI a really cool icon.

[Yamaeda]

My first thought was nested cases, but since you ask for a cleaner solution ... could each column work as a sub-vi of it's own? If so you'll need one 'main' calculatio vi with a few connections and a simple chain of column vi's inside. *brainstorming*

/Y

[jyang72211]

Hi Darin,

Can you elaborate on 1)?  

[jyang72211]

Hi Ravens,

How do we just a enum to look up a 2D array?  I thought I am supposed to specify row and column when I look up a 2D array?  Can you give a quick example?

[RavensFan]

Kind of like this.

I'm just using a pair of enum constants.  But the enums values that get fed into the Index Array could come from the result of other comparisons.  And the end results of that is looking up a particular string value in the 2D array.  The 2D array could be an array of enums that would be the driver of another case structure that could contain calculations.