LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How can I get rid of some of these nested case structures?

Solved!
Go to solution

Hi Mark, thanks for your response. it's probably not obvious from the screenshots, but I’m not acquiring data or opening/closing the valve in this loop, My program is a QMH and data is acquired elsewhere and is sent here to be checked. This look just checks the incoming data, if the data exceeds limits it messages another loop to act accordingly. (Acquire data, open valve and close valve are all cases in other loops.) I had a little look at the TLB and unless I misunderstand, I think my QMH is giving me a lot of that functionality (I may be misusing it).

 

But you're right that the problem is this one case is doing too much. I think in particular because it’s checking for two sets of limits. I've broken it up now into subsequent cases. So it checks for the major limit and the status of the valve in 'check level', then if those limits pass it messages itself to check the upper or lower bound depending on that prior status.

 

Shiv0921_2-1615984237110.png

 

 

 

This is where I get a little confused in terms of good coding practices. I didn't want the nested case structures, because they look messy and make the code hard to follow, and because it makes it hard to break up the sequence of execution.(right?)

I feel like with using subsequent cases it's now neater and would be possible to interrupt the sequence of execution, but I feel it's harder to follow. Perhaps because in this instance they will always execute sequentially as 1&2, so it feels artificial to split them up. Other cases won't trigger 2, they must go via 1, then 2, and I don't (think I) need to interrupt their execution.

 

I suppose if I wanted to make it quicker, (which in this instance isn't important) I could split 1 to be the producer and 2 to be the consumer, so the checking of both limits is always happening at once. 1 being able to execute without 2, but 2 cannot without 1. So I can see the advantage there being that there would be no interrupt to the major limits being checked.

 

So I feel like with them being sequential I prefer* this:

Shiv0921_3-1615984302084.png

 

But is the other one better?

 

*I realise my preference is very possibly based on what is easy, rather than what's good

0 Kudos
Message 11 of 15
(569 Views)

It smells bad if you have to add a shift register to pass the waveform array data back to the next iteration of the loop to perform another range check. A subVI with inputs of current array data and current valve state and an output of next action seems like a good idea. One subVI would keep the array data (and current valve state) in a context where it is needed to make the decision without letting the array spaghetti across your diagram. I wouldn't even push the less than or equal to deeper into the nest.  

Doug
NI Sound and Vibration
Message 12 of 15
(532 Views)

Thanks, I've reverted back to both checks in the same case and added the subvi. That does make it look neater, and I like what you say about keeping the data in the context in which it's used, I hadn't thought of subVis like that before. 

I thought about pulling out the comparison function, but one case needs it to be less than and the other needs greater than, so unless I'm misunderstanding what you mean I don't think I can move it. 

Shiv0921_0-1616589949570.png

 

0 Kudos
Message 13 of 15
(518 Views)
Solution
Accepted by topic author Shiv0921

What about this?
Calculate Next Action subVI and Next Action Case.png

 

Pretend with me that the flat sequence is actually a subVI. Now within the 'Acquiring' case, we would have a subVI and one case structure with four possible next-action cases. Did we cheat by moving a case structure into the subVI? Let's agree to call that success instead. One objective metric for measuring success for a refactor is to run VI Analyzer and verify that cyclomatic complexity is better (lower) with the revision.

 

Doug
NI Sound and Vibration
Message 14 of 15
(494 Views)

Hi Doug, 

 

Apologies for the delay in responding, I had been pulled away to other projects. Thank you so much for that! That is a much more elegant solution than I was thinking. I'll be implementing that and will bear this approach in mind in future. Thanks again!

0 Kudos
Message 15 of 15
(462 Views)