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.
posted by Marc | 12:03 PM
6 Comments:
"The bottom line is, use the Merge Errors.vi liberally in your code to handle multiple errors".
This line might mislead some people, since if you have more than one error coming into the VI it will only handle one of those errors and discard the others.
The error cluster is kind of problematic in general when it comes to handling errors in real applications. It has no easy way of adding details of the specific error (unless you develop a convention of adding them to the source element) and doing it properly using the error chaining basically requires you to have a series of nested case structures if you have more than one error generating action in a VI (which happens, for instance, when using property and invoke nodes).
When LVOOP was new Stephen Mercer created a nice demo replacement for the general error handler which flattened a class into the error cluster so that the error cluster had additional data with it which could be handled elsewhere. It would be nice if NI did some more official stuff like that which would make it easier to handle errors. Of course, with the error cluster prevalent through many versions of LabVIEW, that might be more complicated now.
Posted for Stephen Mercer:
Back in LV 7.1 times, I ran a survey program over thousands of VIs -- from vi.lib, from NI apps and from customer apps -- to find the most common nodes used in LabVIEW so we would know which nodes were the most promising to optimize. Of the top 30 nodes, all were built in nodes except one: Merge Error.vi. Turns out that was the single most called subVI in all of LabVIEW. It got a lot of attention at that time to be made as efficient as possible, and we saw substantial improvements in a few apps as a result.
I have recently seen customers using the Select Node (the one with T and F inputs and a middle ? input to choose which of the other two should be output) to do Merge Errors. Wire one error cluster to the T and to the ?. Wire the other error cluster to the F. You'll lose any warnings information on the T line doing this, but if you don't care about propagating warnings, this is VERY efficient code.
Yes, I remember him mentioning that program before, as well as the changes made to the merge VI (which are visible through the comments it has).
It would just be really nice if NI could find a way to handle multiple errors elegantly.
Here's one crazy idea, off the top of my head: Create a special error wire type which will have new functionality (e.g. more data, the ability to hold more than one error) and have that type somehow backward compatible with the existing error cluster wires, so that existing code will still work.
I have no idea what this would look like from the dataflow perspective, but I'm sure that R&D can come up with the problems and the details much better than me.
The key point is that we need better error handling tools and techniques. In a parallel language where errors can occur anywhere and can sometimes require user intervention before proceeding we find ourselves having to do all kinds of acrobatics to get things to work as we want. So yes, we're programmers and that's what we're supposed to do, but it would still be good to have better alternatives.
I agree with Yair. The merge errors has always bothered me as it is a lossy error handler. Long ago in a very parallel application I started to convert everything to arrays of errors when I needed to merge them. That way I could keep all the errors and then cycle through the array and taking the appropriate action.
For efficiency it might be done with queues of queueing the errors and then passing the queue reference up the chain to where the error handling is. Queues are fast and you could add extra info into the queue as well.
It is hard at design/compile time to decide which error is the one you want to report at run time. The important one is the answer, but aye there's the rub!
I use the merge error but I don't really like it.
Sir, We are a system integrator, I want to know whether Siemens Numeric Relay can be integrated with Labview, it is working in IEC 68150 protocol.
Amit, this isn't the place for this, but you have several options:
1. Search.
2. Contact NI by phone.
3. Post a message to the NI forums.
Post a Comment
<< Home