Enabling use Labview FPGA front panel in interactive mode without recompilation-

[andrewsi]

Technically, I suppose you could consider this a bug.

The situation is this:

• You develop an FPGA module for an sbRIO, cRIO, or what have you.
• You share the compiled code and .lvbitx with a team member, who needs to run that front panel in interactive mode, however, his sbRIO lives at a different IP address.
• The only change he makes to the product is to right click on the target in Project Explorer, so as to be able to change the expected IP address.  However, the target hardware is otherwise completely identical.

Net result:

•  The co-worker has to wait for a complete recompilation of the bitfile, which can be an hour or more in the case of a complex design.  There's no reason why the user shouldn't be able to completely re-use the existing bitfile just to send it to a different IP address.

Perhaps there's some technique I'm missing, but this is causing our team a pretty significant loss in productivity.  (Note that we have no issue with re-using the .lvbitx from RT host code, that works just fine - it's using an existing front panel in interactive mode that you can't do without recompiling it locally.)

Project Explorer:

Change the target IP address:

Now you have to recompile...

[MattN]

This _should_ work, though it's always possible you've found a bug.

Just to confirm, when you say "You share the compiled code and .lvbitx with a team member",  you're sharing the whole project, the FPGA, all of its subVIs, etc.?  And when your coworker opens up that FPGA VI, that VI and all of its dependencies don't need to be re-saved?

It's not intended that the IP address is included in the "signature" of the bitfile (the signature is what tracks when a FPGA VI needs to recompile).  As a test, have you tried pointing your project (that works) to the IP address of your coworker, and seeing if it runs or requires a recompile?

The other thing you may be running into is the naming scheme for default bitfile name in the build spec.  To support some use cases, it actually consumes the whole path of the project in the algorithm it uses. Have your coworker open up the properties of the build spec under the FPGA, and check the bitfile name that is there.  If it is different from the name of the .lvbitx file you sent him, have him try changing it to match that existing bitfile.  Or you and he/she could agree on a non-default bitfile name that you both could use (this has the advantage of being less "alphabet soup" than the default naming scheme).

[andrewsi]

I'm sharing the whole project - the whole thing is checked into source control, so the team member has the full source and the compiled bitfile, and opens the .lvproj via project explorer.  By convention, everyone should be opening it from an identical path on the local machine so that Labview doesn't get confused by potentially different root tree structure above the top of the source-controlled tree.

I'll investigate a little further, but the claim from the co-worker is that just opening the project locally and attempting to run the top level VI interactively forces a local recompile if any changes were made on the server and the project was resynced (including the bitfile).

[mdmorar]

I am having identical behavior. The situation is the following. Code is in source control I have it all checked out.

1. I have an FPGA reference pointing to the compiled bitfile form my RT.

2. I check the bitfiles signature and it matches for a specific cRIO.

3. I take an image of the cRIO using RAD and push it onto a brand new cRIO and it doesnt work.

4. I use my dev environment like above and change the IP address to point to the new cRIO.

5. I check if the bitfile matches and it does not.

6. I FTP the cRIO and the entire image matches the previous cRIO.

7. I try identical things using the build spec and the FPGA VI itself from the FPGA reference.

Nothing works and I'm not sure how to proceed but this is very pressing.

Imaging a cRIO should completely take everything and if the startup.rtexe contains a reference in the software this shouldnt be an issue when compiled.

Suggestions?

Monil

[Darren]

Any idea that has received less than 6 kudos within 6 years after posting will be automatically declined.