FPGA VI refnums on front panel always force recompile

[NickDngc]

LabVIEW 2013, FPGA Module, PXI-7841R

When trying to close my Host VI after not changing anything, I am prompted to resave it along with several subVIs. When checking the reason for saving, all of the listed subVIs were recompiled. After doing some digging, it appears that all of the subVIs that were recompiled have FPGA VI Refnum controls or indicators on their front panel; and in fact, every VI in my project that has an FPGA Refnum front panel control or indicator is on the list.

However, I'm also passing a cluster (typedef) of front panel controls to subVIs so that the controls can be updated while the subVIs run. I included the FPGA VI reference in that cluster for wiring convenience; whenever I need to access it, I just unbundle it from the cluster and run it into the necessary function or subVI. None of the subVIs that have this typedef cluster (that contains the FPGA VI refnum control) get recompiled automatically.

Why does having an FPGA VI reference control/indicator on the front panel force recompilation, but having the same reference in a cluster control on the front panel not force it? Is this a bug or a feature?

[Door-C]

Does this recompile happen everytime you save the VIs? Are you able to reproduce what you are seeing in another simpler project?

[NickDngc]

It heppens anytime I open the parent Host VI; even if I then close it immediately without running it or modifying it, both it and every subVI with an FPGA refnum front panel control/indicator is recompiled and demands a save. If I save all recompiled VIs, close the project, reopen the project, reopen the Host VI, and then immediately close the Host VI without modifying anything --> I see the same behavior.

I created a simple project with a Target and Host VI where the Host VI had two subVIs (one read and wrote to Target controls, and one read from a Target-Host DMA FIFO). I was not able to recreate the recompile behavior. I have seen it in simpler projects that I've used to debug portions of the Host code, but they still had the complex Target interface (registers, multiple DMA FIFOs, multiple AnlgIn/Outs & DigIn/Outs).

[Door-C]

Would you be able to post the code that you are seeing this behavior? I would like to see if my system sees the same behavior.

[NickDngc]

The original app was relatively large with multiple subVIs and custom controls. I stripped out most of the code in the Host and Target but left all but two of the offending subVIs.

I opened the Host VI from the project display and verified that, without changing anything, the Host VI and all subVIs with FPGA refnum front panel controls recompile on opening. The project is zipped and attached.

[crossrulz]

After I initially resaved everything, they seem to hold for me.  I think the upgrade was going to 2013 SP1 f2.  Have you upgraded to the 2013 SP1 yet?

[NickDngc]

The "About" link on the splash screen tells me I have 13.0 f2. Is there a pre-SP1 f2 patch, or does having f2 mean I have SP1 as well?

Our IT department blocks NI update service, so I get updates only when a service pack upgrade arrives at my office at random intervals.

[crossrulz]

The service pack was released back in March with the semi-annual Developer Suite disk set (2014 DS1).  You do have to have a current SSP in order to get it, as in your SSP had to still be active when the SP was released.

My about box is showing 13.0.1 f2.  I'm pretty sure there was an f2 patch for the pre-service pack version of 2013.  I'm guessing you don't have the SP1 release and this issue may have been fixed in that release.  And doing a search, there is a f3 patch for my 2013 SP1.  Time to do some download and update...

[NickDngc]

SP1 didn't fix it. Same files recompile every time when opened.

I guess I will try the patches now to see if that fixes it.

[NickDngc]

SP1 f2 didn't fix it either. The link for SP1 f3 (32-bit) is broken on the LabVIEW support page.