We have developed a project that runs unique top level VIs in interactive mode on 3 different FPGA targets (two 7852 and one 7813). Once compiled, the VIs run smoothly, however closing the front panels then requires that the bitfiles be recompiled before the VIs can be run again in interactive mode. A variety of subVIs are used by all three top level VIs and they seem to be the root of the issue as the VIs break when opened together and the errosr are of the "VI edited in other application instance" type and are corrected by doing a synchronization, which then allows the bitfiles to be compiled.
In the project there are two PXI crates, PegFPGA1 & PegFPGA2. The crate relevant to this issue is PegFPGA1, PegFPGA2 should be ignored as it was only included in the project recently to verify its setup. The PegFPGA1 crate holds 3 FPGAs that each run their own version of a main, top-level VI called "Splitter_Combiner_Main_FPGA#.vi", found by expanding PegFPGA1, expanding an FPGA target and then the Splitter-Combiner System folder. The 3 Main VIs are to be deployed and run simultaneously in "interactive mode" to report current states to the user and allow users to re-configure certain settings. All other VIs are either subVIs called by the Main VIs or are VIs used for other testing/debugging/simulation purposes. The VI with the compile issue referenced in the post subject field is the top-level "Splitter_Combiner_Main_FPGA#.vi".
Yesterday I tried compiling and running the FPGA1 Main VI alone. I was able to open and close not only the front panel, but also the project without needing to recompile. I then compiled and ran FPGA2s Main VI with that of FPGA1 and again I'm able to open and close the project and LV without the need to recompile these two VIs. The problems begin when I open FPGA3s VI, which breaks the FPGA1 and FPGA2 VIs.
Opening FPGA1 first, shows the VI in a ready to run state (good run arrow, regardless of compile state). Opening FPGA2 does not change the state of FPGA1 and both VIs can be opened together in a ready to run state. Now opening FPGA3 results in both FPGA1 and FPGA2 VIs breaking, run arrows now broken with errors of the "VI edited in other application instance" type, while FPGA3 shows a ready to run state. It appears something about the way FPGA3 is implemented is causing the subVIs to come into conflict and require a re-synchronization before compiling. If you then compile all three together, they can be run, but require recompile if you close the VIs.
Some guidance I have received regarding this issue is that the subVIs break when FPGA3 is opened because it is a different target type and to create unique subVIs for that target. Doing so would require a non-trivial amount of work because of the extensive use of subVIs and would eliminate the whole benefit of subVIs. Before embarking on that path I thought it wise to seek input from the collective experience of the forums in the hopes of finding an alternative solution.
If you've gotten this far thanks for reading my somewhat verbose post and thanks in advance for any assistance offered.
-- Chris