LabVIEW FPGA Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
dwisti

Remove restristions on FPGA target names

Status: New

With multiple hosts in one project remove the restriction of FPGA target names.  If I have 2 cRIOs in one project and the FPGA in those cRIO's is the same then so should the FPGA target name.

 

FpgaName.jpg

 

 

Of course, FPGA target names must be unique if they are within the same host.

4 Comments
gsussman
Active Participant

I agree with this 100%.

 

I have a couple of systems with the same scenario as you. Two identical cRIO systems (different IP addresses) in the same project.

 

While I think it would be a big change in how the project works, it would also be helpful to allow multiple identical targets to be spcified using the same build specifications. (i.e. compile your code once and deploy to multiple targets)

dwisti
Member

I'm glad I'm not the only one with this issue.  It seems NI has a 1 target 1 project policy.  The project environment does not scale well with identical cRIOs.  I posted about this back in 2006.  Here the link to the post:

 

Two cRIOs with the same code in 1 project

Vrmithrax
Member

I'd like to bump this one, but note it should also be easier to handle with the Scan Interface as well, not just FPGA...  I've got a project similar to @dwisti in which I have multiple cRIO targets that need to run the same (or slight variations of) code, but are associated with the same host programs built to interface to the cRIO controllers.  I can establish the targets in the project, have all my host files and builds available, and get all of the proper items put under each target.  But, when I try to deploy the build for cRIO #2, for example, it won't work unless cRIO #1 can be found...  Even though all of the files in the build for cRIO #2 are independent and have nothing to do with cRIO #1.  This weird limitation makes it very clunky, forcing us to have to build multiple projects for the exact same code, which makes it very easy to miss updating all of the possible branches when a revision is introduced.  A project file should be able to cover the whole project (as it was initially intended), not force us to break things up and recreate items over and over...  Shouldn't it?

Dragis
Active Participant

I would love to see this fixed as well. This is something NI has looked at internally but never gotten enough push to actually implement it. Perhaps if we get enough Kudos ...