LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Better solution for several cases

Hello Together

 

I have a hardware system with a housing, an emergency device and an engine, which are monitored by a DAQ device.

if any of those three got opened or a failure I got an event and a loop, which tells me, which of those has been opened (sometimes other parts produced an event as well, so I have to ignore those)

 

WWolf78_1-1622549808648.png

 

 

in the next step I want to have specific actions, based on which part is opened and if this one is happening the first time or not.

I'm planning by realization by case structure with more cases within each other:

 

WWolf78_0-1622549614949.png

 

I'm sure this works, but isn't that clearly and good to read / debugg.

 

creating an Boolean array the boolean array to nummber would work as well but would be (from my point of view) even less clearly / readable.

 

 

any suggestions to improve this one?

 

(please excuse not posting the whole program, as this is an QMH with four paralell loops with many subcases, whereas only this small issue is relevant)

0 Kudos
Message 1 of 8
(3,268 Views)

I definitely wouldn't go with deeply nested cases to resolve this kind of logic.

 

My initial thought:

1. Create a typedef'ed enum that maps logical ID names to each integer index of interest.  Right now you index your array with regular hardcoded constants, so it seems pretty clear you aren't intending to support flexible ordering of these boolean states.  If you index with enum-based constants, it's more self-documenting.   (I'd probably right click the constant and under "Visible Items" I'd elect to show digital display.)

 

2. Wrap the logic up in a sub-vi with a descriptive name and plenty of comments inside.  True, this merely *defers* the complicated part down to a lower level, but it has the advantage of making the higher level code more digestible-at-a-glance.  After all, once the subvi logic is debugged and robust, you should rarely need to look at it again.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 2 of 8
(3,239 Views)

@Kevin_Price wrote:

I definitely wouldn't go with deeply nested cases to resolve this kind of logic.

 

My initial thought:

1. Create a typedef'ed enum that maps logical ID names to each integer index of interest.  Right now you index your array with regular hardcoded constants, so it seems pretty clear you aren't intending to support flexible ordering of these boolean states.  If you index with enum-based constants, it's more self-documenting.   (I'd probably right click the constant and under "Visible Items" I'd elect to show digital display.)

 

2. Wrap the logic up in a sub-vi with a descriptive name and plenty of comments inside.  True, this merely *defers* the complicated part down to a lower level, but it has the advantage of making the higher level code more digestible-at-a-glance.  After all, once the subvi logic is debugged and robust, you should rarely need to look at it again.

 

 

-Kevin P


To add a bit to Kevin's suggestion #1:

By setting up the Display Format to "binary", the digital display will display in binary.  Caveat, you can't display the radix with the digital display.  My solution was to make a free label with the radix.  Not great, but "good enough".

 

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 3 of 8
(3,209 Views)

Hi Kevin Proce,

 

thanks for the reply!

(unfortunately I don't get the idea 100%, but i think I know what you're meaning)

 

thereby I've another issue:

the Inputs of the DAQ is the first I'm looking, on the next step I look, if I'm noticing this the first time or not.

therefore I've the counter, which is zero by default, If I'm entering the case I set them to 1.

 

so my logic is

<EVENT>

Input 1 (T/F)

if (T)

first time (T/F)?

 

if (T)

set counter =1

Reaction A

 

if (F)

Reaction B

 

and so on.

Idea is to first check the important Parts (emergency) then engine and last the housing..

 

any Idea?

0 Kudos
Message 4 of 8
(3,172 Views)

Since the booleans are all from row 0, i'd do a Index array to get that row, then a boolean array to number and 3 ANDs to get your 3 flags (with 0, 1 and 0x1FE)

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 5 of 8
(3,164 Views)

While I get the general idea of your pseudo-code, I'm pretty sure it's only *part* of what you're working to figure out and implement in LabVIEW.  I'd recommend you lay out your pseudo-code more clearly and completely, including indentation to show nesting of if-then structures.  You may find it helpful to create some truth tables as well.

 

Another thing I do when I have elaborate combinations of conditions to consider is to revert back to how I was taught Algebra back in high school (thanks Mrs. Anderson!).  Start by clearly defining all the variables, then express the equation in terms of these variables.  For example:

let S1 = switch 1 state (on = T, off = F)

let S2 = switch 2 state (on = T, off = F)

let S3 = switch 3 state (on = T, off = F)

and so on...

 

Action 1 when: ( (S1 AND ((NOT S2) )OR (NOT S3)) ) OR (S2 AND S3)

Action 2 when: (NOT S1) AND (NOT S2 )AND (NOT S3)

and so on...

 

Laying it out formally often helps me find ways to analyze the logic and find equivalent expressions that can be coded up more cleanly.   For example, up in the condition for Action 1, I can see that (NOT S2) OR (NOT S3) is the same as NOT(S2 AND S3).   So then I'd define a new variable for myself and work with it:

let R1 = S2 AND S3

then Action 1 when: (S1 AND (NOT R1)) OR R1

 

Just a little more truth table work lets me reduce that to:

Action 1 when: S1 OR R1

expanding, Action 1 when: S1 OR (S2 AND S3)

 

Ok, I got off on my own little tangent there but I hope it illustrates what I mean.  When you have to do complicated boolean evaluations, it can really help to slow down and be methodical.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 6 of 8
(3,132 Views)

Hi Kevin Price,

 

based upon your suggestion i've thought about my code and made some improvements.

 

first of all there's a prioritization: most important is Input 1, then input 2 and input 3-8 is less important but still important.

so first following an Event I made a loop checking which is TRUE:

 

WWolf78_0-1622806793652.png

in the following step I reduced that on to case structure which only have one additional case structure, which checks, if this is the first time it got called or not.

 

WWolf78_1-1622806940806.png

 

that structure would work (not tested jet)

 

 

 

 

 

 

Message 7 of 8
(3,061 Views)

I don't know enough about your app's specifics to comment on any details.

 

Very generally, I'd just bring up the thought that choosing the "best" way to resolve complicated combinations of various boolean states is part art, part science.

 

Deep nesting of case structures where every case has active content is something I try hard to avoid.  But I've had situations with nested case structures where *most* of the combos were no-ops and only 2 or 3 had active content.  Theere, a nested approach made more straightforward logical sense.

 

Sometimes boolean logic operators make things more concise and clear.  Other times more concise but less clear.  Same with converting boolean "bits" to an integer or to an array to be searched.

 

So the friendly (but kind useless and frustrating) advice is that once again, "it depends."  Just stay aware that it's really valuable to emphasize the clarity of the logic.  That's usually a combination of the coding approach and good comments.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 8 of 8
(3,012 Views)