Darren's Weekly Nugget 2/6/2006

[Darren]

Do you ever use Merge Errors.vi?  If you ever profile the performance of your applications, you may be surprised to find that Merge Errors.vi takes a significant amount of time to execute, mainly because of the iterating it has to do on each incoming error to check for both warnings and errors.  If you have places in your code where you need to merge two errors, and you are not concerned about warnings, then you can use a nifty trick with the Select function:

The Select function (located on the Comparison palette) can take an error cluster as its conditional input, and it uses the "status" value of the error cluster to determine the True/False condition.  So with two errors, you can have the Select function output the first error cluster if it contains an error, otherwise it will output the second error cluster.  I use this trick all over the place in my user interface VIs.

-D

Message Edited by Darren on 02-06-2006 10:19 AM

[tst]

Well, that's another one I know and love.

I do have one problem with the Merge Errors VI. It doesn't actually "merge errors", does it? All it does is to take the first error encountered, discarding the other errors. It would be nice if in future versions the error cluster for all the primitives could be either a cluster or an array of clusters.

As a temporary solution, I use Mike Porter's method, shown here. It also discards the smaller error number, but at least it keeps the error text. I created some additional VIs which also go up and down and make it even more convenient to do this.

[EdDickens]

I use the Select function all the time with the Error cluster to handle different things. Works great, and the Error cluster can also connect directly to the Case Structure select terminal and the While loop condition terminal.

One thing I've always wondered was why can't I wire the Error cluster directly to all the boolean functions? If the three functions above can automatically unbuldle the status bit, why can't the rest? Think about it, how many times have you dropped an Unbundle by Name to get the status bit from an error cluster to wire into an Or gate to stop a loop if there's an error when you have other conditions (like a stop button) that also need to stop it.

Maybe I'm just getting lazy, but I think this would be a nice feature.

Ed

[Darren]

Yes, that would be a nice feature...maybe we'll be seeing it in a future LabVIEW version... 😉

-D

[altenbach]

---

@Darren wrote:

If you ever profile the performance of your applications, you may be surprised to find that Merge Errors.vi takes a significant amount of time to execute, mainly because of the iterating it has to do on each incoming error to check for both warnings and errors. 

---

On a side note, It is cute how each recent LabVIEW version tweaked "merge errors" to optimize performance. Here are some of the diagram comments found inside it:

LabVIEW 7.0: This VI is one of the most commonly called subVIs in all of LabVIEW and has been noted as a performance bottle-neck in applications. It has been modified to be as efficient as possible. Be aware of this if you edit this VI.

LabVIEW 7.1 (and 8.0): This is a common VI, and is most often called with no errors, pretest to make this case fast.

So it seems that pre 7.0 (?), it was really inefficient :o. Curiously, LabVIEW 7.1 added another optimization using a few pretests and a case structure, so there was obviously some slack left in 7.0. 😄

[Ray.R]

Thanks Darren,

I used to unbundle by name to get the boolean in order to select which error cluster to use.  Nice trick.  I did use the error cluster directly for Case Statements, but never thought of it for a selector.

Again excellent info!

Thanks,

Ray