Leaderboard

I know LV style guidelines and conventional wisdom states that sub vis should always have error in and error out terminals as a way to enforce data flow if it is needed. I found that without some insight into the sub vi's error handling I tend to wire them all up and impose an artificial data flow on my application. Sometimes I ended up going to great lengths to reorganize a vi so the error wire was clean when in fact the sub vis I was connecting weren't significantly affected by the error in terminal and didn't generate an error on their own that needed to be caught. I started removing the error terminals if it was simply passed through the sub vi, but I didn't really like that solution either. I've played around with various combinations of settings for the error in and error out terminals and documenting error behavior ("This vi runs normally regardless of the error in condition.") in the properties dialog box but couldn't find anything that was simple/intuitive enough to use yet expressive enough to describe the most common situations. Recently I came up with this idea based on setting the terminal's connection property: error in terminal - Not all sub vis case out the error in terminal and so the input value is irrelevant. Recommended - The sub vi's output depends on the error in condition. Optional - The sub vi runs normally regardless of the error in condition. error out terminal - Not all sub vis generate errors so the error out terminal is irrelevant. Recommended - The vi (or one of its sub vis) may change the value on the error wire, either setting an error or clearing an error. Optional - The error out terminal value is always equal to the error in terminal value. Using this scheme the error terminals on most typical sub vis would be Rec/Opt. Sub vis that do I/O or generate internal errors would be Rec/Rec. Close Reference sub vis would be Opt/Rec. My class accessor vis would be Opt/Opt since I set the new value regardless of the error terminal. Thoughts? Is this a reasonably clear way to convey basic error handling information to the user?

I haven't used the scheme you came up with before, but I really like it. The only downside I can see is that without the context help open, you lose visibility. Even then, you'd have to mouse over each VI to check the terminal requirements. If you're just eye-balling a block diagram, especially a big one, that can be a bit unwieldy. In the past, I've followed NI's example of Invoke/Property Nodes and added a little red "?!" to the icon if my subVI is going to ignore error. There's no option to ignore incoming error, but obviously you can do whatever you want with your own subVI.

I'm waiting breathlessly for info on the LAVA BBQ. It is, after all, the *real* reason I'm coming to Austin, and definitely the only thing that would convince me go there in August. NIWeek is just a convenient excuse.

For those who use scripting, you might want to support these 2 ideas : Expose "Replace With" LabVIEW Project Method via VI Server Expose all available LabVIEW Project Methods via VI-Server

I wouldn't bother with individual controls, even if you're going to do this fairly often. It should probably not take long to execute if you defer updates. Based on your description, I would say you should get the references to all the controls on the FP once (using the Controls[] property or, if you have nested controls, using <vi.lib>\utility\traverseref.llb\TRef Get All FP References.vi) and then build the controls you don't want to reset into an array and remove them from the first array using a for loop. You now have an array of all the controls you want to reset which you can go over in a for loop. You can call the reinit method for each one.