[Bug?] In Range and Coerce Comparison Mode

[Darin.K]

It seems that changing the Comparison Mode of the IR&C function with Arrays or Clusters attached does not trigger Type Propagation, or whatever is responsible for selecting the proper instance.  For example, if I wire up three arrays to the inputs of IR&C, change comparison mode to Compare Aggregates, then create an Indicator from the In Range? output, the result is the wrong indicator and a broken wire.  Likewise, I can change the mode on an IR&C function with a wired In Range? output and it will not break the wire until a later change triggers a recompile or type propagation.

LV10 (not SP1) and Win7.

[Matt_McLaughlin · Accepted solution]

Hi Darin.K,

I was able to replicate the behvior you are seeing in LabVIEW 2010 SP1. If arrays are input and the Comparison Mode is change to 'Compare Aggregates' creating an indicator will incorrectly create an array of boolean indicators wired to a single boolean output.

This was previously reported in a Corrective Action Request (CAR) and the behavior has been corrected in LabVIEW 2011. Thank you for taking the time to report the issue and I'm sorry for any inconvenience it caused.

[Darin.K]

Thanks, always good to know that I am not imagining things.  I did not see it in the LV11 bug fixes, so I imagine it was an internally generated CAR.  What I did see was this ominous bug fix:

282333

—

In Range primitive does not work correctly for cluster inputs

Could you provide the details of this guy?  I would hate to be relying on buggy behavior with IR&C.  If that is the case then I'll have one reason to upgrade and one reason not too....

[Matt_McLaughlin]

Hi Darin,

As mentioned, that CAR refers specifically to clusters and the 'In Range?' boolean output of the In Range and Coerce function. The specific VI that showed the issue always had an In Range output of true for all elements of the cluster except the first. However, it is worth note that the Coerced results showed correct behavior, unbundling showed correct behavior, changing the numeric representation of the compared elements (even changing back to the original representation of U32) corrected the behavior, this error is fixed in LabVIEW 2011, and when I recreated the VI from scratchn in LabVIEW 2010 it behaved as expected.

So, it is very unlikely that the error fixed in this CAR will impact your use of the In Range and Coerce function.

[Philippe_RSA]

Bug with In_range for clusters is evident in LabView15 also.

See attached.