How to handle success/fail chains

[knicewar]

I'm still getting the hang of this LabView programming style and have found a repeating (and annoying) design pattern that I'm sure others have encountered.  I have a long series of steps to perform.  Each step is a prerequisite of the next step and each could fail.  So I've found myself creating these massive nested case structures so that step 2 only gets called if step 1 succeeds, step 3 only if step 2 is OK, etc.  YUCK! What is the Right Way to handle a chain like this? Thanks,Keith. 

[mikeporter]

Vi's only begin executing when all their inputs are satisfied, right? Well, make use of that by paying attention to all the data your VIs can generate - or might need. Say you have three VIs (A, B and C) that need to execute in the order listed. What information does A output that B would need? Regardless of exactly what A and B do there is one piece of information that will be there 90% of the time. I am speaking of status. A needs to let what comes after know whether an error occurred during its processing. Likewise B needs to know if an error occurred before it started. The mechanism that LV provide for this status communications is the Error Cluster. It contains a boolean that serves as a basic error flag (T = error, F = no error); a numeric that can hold a general error code to specify in general what the problem is, and a string that you can put as much information as you want to identify the issue. Stringing VIs together using the error clusters is an excellent way of structuring linear code - and can make your applications more robust. At least 90% of LV programs that appear to "lock-up" or "freeze" are due to errors that don't get reported. Mike... 

[knicewar]

OK, I get that -- use the error cluster to sequence things.  But how does that prevent the VIs further down the chain from getting called if there was an error upstream? Keith. 

[Dennis Knutson]

To add to what Mike has said, the majority of the built-in LabVIEW functions are written such that if passed an error condition, they do not execute - they simply pass the error on. So, you can do the error reporting at the end of the chain. For subVIs that you write, you can do the same thing. Say you have a subVI with a loop in it. You don't want to execute the loop if you pass it an error. What you do is put a case statement around the loop and wire the error in cluster to the case selector. You now have a case statement with two different cases - 'no error' and 'error'. Place your code in the 'no error' case. In the 'error' case, simply pass the error in out through the case to the error out.

[knicewar]

Right, and this leads to the nested case statements if I have a bunch of trivial (non-VI) things I want to do ...Are you sure that standard VIs all check the status before executing? 

[Dennis Knutson]

There should not be that much nesting if the subVI is designed logically with dataflow in the first place.  Yes, I am sure. There are some exceptions. These are usually functions that do a 'close'. For example, you would want to execute a VISA Close no matter whether one up the upstream functions caused an error or not.

[Ipshita_C]

Hi Knicewar, If your code is modularized into sub-VIs and you can divide it up into sequences which depend on each other you can use a mixture of structures such as sequences and loops. It all depends on how you develop your VI. Ipshita C.

[knicewar]

OK, I think I'm getting the hang of this.  So for a loop that calls something that uses error clusters, I should use a shift register, right?  And if I have two or more things that I don't care if they are in a particular sequence, I should split the error cluster then merge it? Thanks, Keith. 

[mikeporter]

Yes, if you have things that happen in parallel you can split the error cluster and then merge the two branches back together. One thing to be look out for when merging separate error chains is to not duplicate error messages if both branches contain the same error. Mike...