LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

[FPGA] Bitfile must be recompiled every time VI front panel is opened

Solved!
Go to solution

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
0 Kudos
Message 1 of 17
(3,487 Views)

Switching context will cause that a lot.  I run into this problem and it's very frustrating.

 

What I have started doing is opening parallel projects with one target in each in Virtual machines for testing.  This essentially "sandboxes" them and allows one to continue even if the others have been used int he meantime.  Once I find a bug, however, I need to make sure I close all others, implement the bug fix and then re-copy the new files to the other directories also and re-start the VMs.  Tedious, but less so that having to constantly re-compile.

0 Kudos
Message 2 of 17
(3,432 Views)

Thanks for the feedback Intaris.

 

It sounds like this is a known issue that you've run into; could you explain the cause in more detail? By "switching context" do you mean changing the target (running VI on different FPGA)?

 

The workaround you propose seems like it would work for some of the development, but what do you do for a final deployment? Deploy as parallel projects on Virtual machines?

 

-- P

 

 

0 Kudos
Message 3 of 17
(3,422 Views)

It's weird behaviour.

 

Some changes, like switching to simulation mode and back don't seem to re-trigger the need to recompile but any other conditional disables I change (my own custom values) seems to lead to requiring a recompile.

 

Changing target can also be a context change, so that is highly likely to trigger a "code has changed" flag.

 

I'm not sure what you mean with "final deployment".  Projects and contexts don't exist in our final deployment, there's no source code involved..... Could you elaborate a little?

 

Shane

0 Kudos
Message 4 of 17
(3,414 Views)

In our case final deployment means we install the PXI crate with the 3 FPGAs in our rack, connect all the I/Os and deploy the blessed versions of the VIs (think verified to conform to specs) in interactive mode (I know interactive mode is not ideal, in hindsight we should have used RT architecture). The plan is to run the VIs from the same project, but when we do this we get the recompile issue. It seems like your suggesting running parallel projects on Virtual machines, one for each target. I'm asking if this is true or if it is not, what you would do for a project like ours? It requires simultaneously deploying 3 FPGAs in the same PXI crate and running top-level VIs on them in interactive mode, all of which use the same subVIs. According to an NI tech, the problem is because one of the targets (7813) is not like the others (7852); I wish I could elaborate more on why that's causing problems, but I didn't get that good of an explanation and I'm still waiting for him to provide some documentation (e.g. white papers) that does.

0 Kudos
Message 5 of 17
(3,402 Views)

Instead of interactive mode, make a host UI to interface with the controls on the FP of the FPGA VI via the FPGA reference.

 

Takes some maintenance but avoids the problem with interactive mode.

0 Kudos
Message 6 of 17
(3,395 Views)

What problem with interactive mode? Are you implying that the recompile issue is somehow related to running in interactive mode?

0 Kudos
Message 7 of 17
(3,380 Views)

Yes, the problem is kind of tied to interactive mode.

 

Assuming you choose to deploy a bitfile as opposed to a VI (which would be the preferable method if not using interactive mode) then your changes are irrelevant, it will simply deploy the last compiled version.  This is how we do it.  Only when using Interactive mode do we run into these problems.

0 Kudos
Message 8 of 17
(3,375 Views)

Ah I see. I'll run that up the food chain. Thanks for all your input!

0 Kudos
Message 9 of 17
(3,370 Views)

If you have any scripting wizards at your company, you might even be able to script a UI to mimic the one on the FPGA VI, saving you the maintenance work.  I'd be interestied in doing that, I might even try it myself because I'm forever having to rely on interactive mode for some low-level debugging and can't make ANY changes until compiled and tested..... This slows down my development a lot.  Sometimes I just want to test a snapshot, even if things change in the meantime.

0 Kudos
Message 10 of 17
(3,366 Views)