06-18-2015 12:10 PM - edited 06-18-2015 12:12 PM
What's wrong with a clear error and a merge error? I would prefer that method anyway because the VI analyzer will find places that error out wires are used, and it shows a sign that the developer put thought into how to handle errors instead of using the automatic error handler, or just ignoring them unknowingly.
EDIT: Oh and you're going to want to close that VI reference the OpenG method makes a new reference each time. But then again if you leave it unwired it assumes "This VI" reference. Or you could wire the This VI reference to it and you don't need to close it. Either way will prevent a memory leak, where the current one will leak memory eventually.
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
16 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord
06-19-2015 09:15 AM
I agree. A lot of my inherited code was written by EEs who were pressed into service to write all their own tests. The underlying tests are well written but the top-level sequencer assumes those tests are bug-free and so don't require any error handling. Turns out that was... wishful thinking at best.
Fortunately we are hiring help from NI and Bloomy Controls to refactor the whole system so I now have a chance to do everything the right way and learn from the experts in the process. As a bonus we're also getting a big supply of NI training credits.
Good point on that reference. Thanks!