Calling VI doesn't show correct value of Boolean returned from subVI

[Dr_M]

I have a subVI that returns a Boolean to indicate whether the system is WoW64 or not. When I run this VI by itself or with a probe, I get a TRUE output (my OS is Win8 64-bit, and I am running LV2015 32-bit).  When the VI is called as a subVI, and the output is wired to a Boolean on the caller's front panel, the value is FALSE, even though inside the subVI it is TRUE.  The LV2014 code is attached below.  This happens in 2014 as well but not 2013.  Is there something to do with the DLL calls made by the subVI that is corrupting the subVI call?

[Bob_Schor]

---

@Dr_M wrote:

The LV2014 code is attached below.  This happens in 2014 as well but not 2013.  Is there something to do with the DLL calls made by the subVI that is corrupting the subVI call?

---

On my machine, LabVIEW 2014 refused to open it, saying it was LabVIEW 2015 (which we have not yet received from NI).  I've got a partial version (from downloads) running in a VM -- I'll see if I can reproduce your findings ...  Meanwhile, if the problem is, indeed, a LabVIEW 2014 issue, could you attach the mis-behaving code saved for LabVIEW 2014?

Bob (Dr. Bob) Schor

[Bob_Schor]

That is absolutely the strangest thing I've seen with LabVIEW.  On a VM running LabVIEW 2015, Win 7/64 on a PC running Win 7/64, I absolutely can reproduce this behavior.  The "Is LabVIEW Process ..." returns True, it's wired to an output connector, and the caller shows False.  I Diagram-disabled the inner code (which makes all sorts of Windows calls, probably lousing things up) and just had it return True, and (as one would expect) it returned "True".  Somehow the calls to Windows internals is messing the "Is LabVIEW Process..." up -- outside my area of expertise, however.

Bob (Now a Believer) Schor

[Dr_M]

Thanks Bob, nice to know I'm not crazy.  Needs someone from NI to replicate this now.

[natasftw]

Quick troubleshooting.  Stepping through or highlight execution show a true coming out of the subVI. 

Creating a second LED gives the same behavior. 

Strangely enough, right-click->create->indicator starts with the LED in the true state rather than false. 

Creating a new VI to use the subVI has the same odd behavior.

Highlighting the code in the subVI and choosing to create a subVI from the selection reproduces the problem with the new subVI.

Changing to a generic LED also has the same behavior.

[Bob_Schor]

Curiouser and Curiouser.  I saved the 2015 code for LabVIEW 2014 and verified that when the subVI returns True, its caller reports False (as in LabVIEW 2015).  I then saved for LabVIEW 2013 and verified that in this earlier LabVIEW version, the code works as expected, with the Caller showing True.

Just in case there was a weird timing thing going on, I put a probe on the boolean wire going into the Is WoW64? indicator on the subVI, put on the same wire in the caller, turned on Highlight Execution (to slow down the subVI), and verified that the subVI returned True before the Caller returned False (in case the subVI somehow managed to subvert DataFlow).  I also tried putting a 1000 ms delay on the output of the subVI (again, in case of fragile timing), but it made no difference.

It definitely has something to do with Booleans.  Moving the connector to a different output pin makes no difference.  However, if you wire the boolean to a "Boolean to 0, 1" function and bring this numeric value out, you get False on the Boolean but 1 on the Value (the subVI, of course, gives True and 1).

BS

[altenbach]

Very strange. I can confirm that problem here.

It all works correctly in LabVIEW 2015 if you inline the subVI.

[Gregory]

Can you post the 2014 version, Bob?

[altenbach]

 made a quick bug note in the monthly bug thread. Hopefully somebody from NI will chime in. 🙂

[Bob_Schor]

I'm attaching a Zip file with both the 2014 version (which shows the bug) and the "Save for Previous Version" in LabVIEW 2013, which works as it should.  I named it "Dr M Dilemma".

BS