Conditional disable in FPGA code causes endless recompiles of bitfiles

[WNM]

I have a project (LV 11.0.1f2) that uses a NI-9870 (RS-232) module under the FPGA at the cRIO-9024/NI-9114 level plus a second NI-9870 module under the FPGA of an attached NI-9144 EtherCAT. I want to share the VI that handles the four serial ports between the two instances. To do this, since the "FPGA IO Method" calls used to interact with the module are target and backplane-slot specific, I added conditional disable structures to the code to allow the correct IO methods to be used depending on where the VI was used. The switch conditions for the disable structures are a pair of custom symbols (one per target FPGA) I added to the project (NI9870_Slot == 1 or NI9870_Slot ==5).  The NI-9870 VI calls two other VIs that also make use of these same conditional disable structures.

On the surface this all seems to work as it should but when it is time to generate the bitfiles for the FPGAs, things start to fall apart. I can generate the bitfile for the NI-9114 (cRIO) FPGA and that seems to work fine. I can do a "Check Signature" of this new bitfile at this point and "The bitfile is up to date with the build specification". I can then tell the project to generate the bitfile for the NI-9144 (eCAT) FPGA and at "Stage 0 of 7" of the "Generating Intermediate Files" process I get a prompt to "Save Changes" to the VIs because "Changes to front panel data structure or block diagram data flow causes LabVIEW to recompile the VI, generating new execution code."  This change to the VIs apparently results from the flipping of the conditional disabled states when it is opened under the target where it is used. This gives me an ominous feeling but I go ahead and let it save the changes because refusal to save aborts the bitfile generation. After the generation of this second new bitfile finishes, a "check signature" confirms it is good. But I can then go back to the first bitfile that was produced and good an hour earlier and re-check it again and get "The Bitfile Signature does not match". 

The saving of the VIs during the generation of the second bitfile has in essence damaged the connection between the VIs and the first bitfile. If I go on and regenerate the first bitfile again, the VIs will require saving again and that will again damage the link between them and the second bitfile.

In the end I'm left feeling that conditional disable structures don't work when used for multiple FPGA targets within the same project.

Has anyone else experienced this?  Is there a way around it or is it a bug?

[dan_u]

VIs are recompiled when a conditional disable symbol changes. Since there is only one compiled code for each VI (no compiled code per value of the symbol) it has to be resaved when the symbol changes.

But I wonder what compiled code there is for a FPGA VI on a FPGA target. Probably the compiled code to execute it on the host?

On top of that, it should be possible to define the disable symbols in build specifications because by default when changing a symbol and recompiling the FPGA VI it will overwrite the bitfile generated with other symbol values (since it uses the same build sped). If the symbol was defined in the build spec you could just have a build spec per symbol value, so a different bitfile per symbol. There are ideas on idea exchange for that.

Anyway, for your issue I would recommend working with bitfiles instead of VIs. For two symbols you will anyway need to separate bitfiles. You can use the same disable symbol on the RT target and based on that decide which FPGA bitfile to use.

When changing the FPGA code you will anyway have to recompile the FPGA VI for both symbol values. As mentioned above, you could use two build specifications to have a bitfile per symbol value, but you have to do this manually (change the symbol, then use the corresponding build spec).