LV2016 Bug?

[RENN]

Hello Everyone,

we've tested LabVIEW 2016 on windows 7 and windows 10.

we could reproduce a bug which does not exist on previous labview versions.

About the code:

The subVI which outputs its vi refernce to the caller as shown in the picture below.

Caller VI gets the subVI's VI reference through its output terminal.

SubVI refnum is Not A Refnum, 

During the first run of Caller Vi

if the subVis frontpanel is not open and the Caller Vi runs

Please give your feedback.

Best Regards

RENN

[Hooovahh · Accepted solution]

I say bug, and potentially a pretty nasty one at that.  I have had subpanel designs in the past where VI put their This VI reference in globally accessible place, and then a UI can insert them into a subpanel as needed.  That design would break with this bug pretty easily.

Now a work around that fixes this is if you place an Always Copy function inside the SubVI just after the This VI constant then it seems to work properly.  Just another case where the Always Copy icon should be a picture of a band-aid.

[Duffy2007]

Hello RENN,

thanks for the feedback, i will create an internal corrective action request to document and solve this behaviour.

[Hooovahh]

Did a CAR ever get created for this?  If so can the CAR # be posted?  Thanks.

[Yamaeda]

This sounds like an issue we had in G#, it could be that optimization removes the front panel if not needed. Try adding a static ref to a front panel object to force it into memory.

/Y

[Bob_Schor]

Wow.  I missed this, and was so skeptical that I wrote my own little VI and ... Renn and Hooovahh are correct!  I'm also not so familiar with the Always Copy function (fortunately, Quick Drop knows about it, otherwise I wasn't sure I could find it in the Palettes).  I also don't (really) understand (a) why this bug occurs, nor (b) why Always Copy "fixes" it.  Could just be a subtle glitch in the Compiler, I guess ...

Bob Schor

P.S. -- Renn -- please mark Hooovahh's first Post as the Solution!  You are the only one who can do this, and having a Solution identified means anyone else who stumbles across this bug will see that it has been "solved".

[Bob_Schor]

Yamaeda,

     Can you show me how to add such a Static Reference to the "This VI" reference to force it into memory?  I'm not sure I see how to do this.

Bob Schor

[Hooovahh]

This doesn't appear to have anything to do with the front panel being there or not, since this happens in source, and subsequence runs changes the behavior.  This really is just a compiler issue.  And if you aren't familiar with the band-aid Always Copy function, you'll basically find it is a work around for quite a few bugs in LabVIEW.  Here is just a small list that I stopped updating a while ago.

https://forums.ni.com/t5/LabVIEW/TDMS-Write-cannot-accept-datatype-what-s-going-on-here-then/m-p/293...

[Duffy2007]

Hello Hooovahh,

the internal CAR 600216 was created, but the number can be onyl internal be shown and monitored.