11-23-2016 07:37 AM
Hi guys,
I have a probably silly question, at least a question of programming style.
It often makes sense to terminate a loop if an error occurred. A lot of people extract the status boolean from the error cluster and connect it by a logical "or" operation to some other termination condition (which usually is also a boolean).
I usually connect the error cluster directly to the "or" which should be equivalent. There isn't even a coercion dot since logical operations accept booleans and erro clusters as well.
What is the advantage to extract the status from the error cluster? It can be also found in original design patterns or in LabVIEW examples.
Solved! Go to Solution.
11-23-2016 08:01 AM
I don't recall when LabVIEW allowed the Error Cluster to be treated with Boolean comparisons as though it were a simple Boolean (possibly 2010?). For earlier versions, the Boolean operators only took Booleans, so you had to extract the Status element -- old code reflects this necessity.
I'm sure that the implementation of this feature has no "penalty" in terms of code speed or size (I trust that it has been "efficiently" implemented). I just did a small experiment to see what is actually being recognized as an "Error Cluster" for purposes of being wired to a Boolean without error. The following appears to be a requirement -- a Cluster of three elements (not four or two), consisting of a Boolean, an I32 (not a Dbl or a U32), and a String.
Bob Schor
11-23-2016 09:04 AM
Thanks a lot, since direct usage of the error cluster was not possible in earlier versions it probably shouldn't be done in examples.
The error cluster is not a type definition. But the order of the entries has to be Boolean, I32, String. Otherwise it does not work (at least here it does't).
As a conclusion one could say that for newer LabVIEW versions the usage of the error cluster is the best practice.
11-23-2016 09:50 AM
@mthimm1 wrote:Thanks a lot, since direct usage of the error cluster was not possible in earlier versions it probably shouldn't be done in examples.
The error cluster is not a type definition. But the order of the entries has to be Boolean, I32, String. Otherwise it does not work (at least here it does't).
As a conclusion one could say that for newer LabVIEW versions the usage of the error cluster is the best practice.
Then again, you wouldn't be able to open the VI with this feature in a version of LabVIEW that didn't have the feature. Plus, any examples that ship with LabVIEW will have code appropriate for it to open with an unbroken arrow. In fact, I would argue that shipped examples should be regularly updated to take advantage of major improvements. You wouldn't want an example that polls Booleans if an event structure is more appropriate for that example, right?