Squeezing Parallelism Out of Your Diagrams with Merge Errors.vi

There are two different ways to run your code on multiple cores in LabVIEW, static and dynamic. We've talked about the dynamic case before, getting a reentrant reference to a VI in a loop and running it. Now I'd like to talk about some simpler methods of squeezing parallelism out of your code.

When I code, I find that I usually, for convenience, chain everything together with error clusters. So I would have one long string of actions, all tied together with an error cluster wire. It's convenient, but cuts down on LabVIEW's ability to run code in parallel. I have come to heavily use the Merge Errors.vi to help me run more code in parallel.

Merge Errors.vi has three error clusters and an array of error clusters as input, and one error cluster as output. So you fork your incoming error wire to each of the sub-VIs that can run in parallel, and then take their output and run them into Merge Errors.vi. If you have more than 3 error clusters to merge, you can also drop a build array node for the remainder.

When ordering is important, make sure the error you want to return to the user is in the first terminal. For instance the code shown below is a "destroy" VI. It must destroy the data, regardless of any errors coming in. This is like the close file primitive. You may have gotten an error while writing to the file, but you still want to close the file. However, we want to return any errors that were passed in to us, even if the destroy resulted in an error.

The bottom line is, use the Merge Errors.vi liberally in your code to handle multiple errors instead of chaining all error clusters and preventing sub-VIs from running in parallel.

Simple Preferences VIs

NIWeek was very informative. I got to talk to a lot of customers who use Macs and got a lot of feedback.

I was talking to Travis Pape (pronounced poppy) about his really cool iBike app (LabVIEW built app for Windows and Mac that allows access to iBike computer). We were talking about the difficulties he was having with preference files, and I suggested he simplify the code.

I wrote two VIs that access the OS preference mechanism. They allow you to store key/value pairs for your application. I've posted these VIs at:

http://decibel.ni.com/content/docs/DOC-1832

Another example of using vi.lib/Platform/CFString.llb and CallLibraryFunction nodes. Took about 20 minutes to look up the functions, wire it all up, and then use Polish VIs to add the documentation.