Real-Time Measurement and Control

cancel
Showing results for 
Search instead for 
Did you mean: 

FPGA code with changing modules

Solved!
Go to solution

I need to create FPGA code for a cRIO-9072 that copes with changing modules.

My cRIO will have any number of NI 9203 (analogue acquistion) and NI 9411 (digital acquisition) modules as inserted by the operator. Upon power-up, the system must identify which of the two possible modules have been inserted into each slot. Subsequently, it will then know which selections of code to call to acquire data from the individual modules.

 

I found the knowledgebase article for CRI that interrogates each module and reports back the module type, and I can successfully use this to detect the modules, but what LabVIEW fails to allow me to do is compile my FPGA code that's designed to cope with more than one possible module. Upon compile, I get the error:"FPGA I/O project item not found. You must add the I/O item to the Project Explorer window or select a different item from the FPGA I/O control or constant" because the compiler requires the appropriate modules to be configured in the LabVIEW project. Unfortunately, this would require two different modules to be configured for each slot simultaneously, as there are sections of code for the 9203 modules and sections for the 9411 modules for all eight slots co-existing in one vi.

 

Does anyone have any ideas on how to get LabVIEW to somehow compile my FPGA code? 

 

Many thanks in advance,

Thoric (CLA, CLED, CTD and LabVIEW Champion)


0 Kudos
Message 1 of 9
(6,300 Views)
Solution
Accepted by topic author Thoric

With the current LabVIEW FPGA project you can not compile a LabVIEW FPGA VI which handles more than one configuration of C series modules.

 

For your application you would need to create a target in your project for each of the possible module configurations and build the corresponding FPGA VI. Then compile each of the VIs to create the necessary FPGA bitstream for each configuration. Then in your host VI you can detect what the current module configuration is and download the appropriate bit stream to the FPGA. One additional issue to consider is that the reference to the FPGA VI/bitstream returned by the Open FPGA VI Reference function will be unique to each bitstream/module configuration. So in your host VI you will need to treat each module configuration with a separate set of code communicating with the FPGA.

 

If you are only considering two different modules and an eight slot chassis, there are 9 possible combinations of modules. The requirement would be that the end user would place all modules of one type together, either from the left or right side of the chassis.

authored by
Christian L, CLA
Systems Engineering Manager - Automotive and Transportation
NI - Austin, TX


  
Message 2 of 9
(6,286 Views)

Christian,

 

Since posting my message, I had been playing around with the available possibilities and was slowing coming to the same conclusion. It's great to hear it from an NI Engineer though, so I know it's my only option and now I can confidently get on with building the solution.

 

I notice you specifically refer to the C series modules in the first paragraph of your response. Are you hinting that on other platforms/architectures it is possible to create a single code that can adapt to different module configurations? Perhaps the compact FieldPoint?

 

Many many thanks for your response! It has given me hope! Smiley Very Happy

 

Best Regards,

 

Thoric (CLA, CLED, CTD and LabVIEW Champion)


0 Kudos
Message 3 of 9
(6,270 Views)

Thoric wrote:

 

I notice you specifically refer to the C series modules in the first paragraph of your response. Are you hinting that on other platforms/architectures it is possible to create a single code that can adapt to different module configurations? Perhaps the compact FieldPoint?

 

 


I wasn't trying to hint at anything, but you are right, FieldPoint does allow you to make these types of changes dynamically at run time. The FieldPoint API for I/O allows you to select and configure the acquisition channels based on the modules present in the system.

 

Here's one example that shows how to acquire data from different FieldPoint module configurations without needing to change the VI running on the FP controller.

 

Compact FieldPoint Embedded Data Logger Example Program

authored by
Christian L, CLA
Systems Engineering Manager - Automotive and Transportation
NI - Austin, TX


  
Message 4 of 9
(6,257 Views)

Christian,

 

Having created nine similar bitstream files, I need to have the RealTime code select the appropriate one for download to the FPGA.

However, my little subvi that uses a case structure to provide the appropriate FPGA VI reference is showing a wiring conflict. Unless I 'up-cast' all my references, they cannot be wired to the same exit node of the case structure. But if I use the FPGA up-cast function, LabVIEW won't allow me to use the Invoke Download Method. It reports the Error: "Invoke Method: method not available for current target."

 

I can't find any help on downloading select FPGA VIs or bitstream files programmatically, so I'm stuck.

 

Any ideas?

 

The attachment is my 'select bitstream reference' subvi, which as you can see needs to use 'up-cast' to allow the merge of the FPGA reference at the exit of the case structure. But any attempt to use this reference usefully is met with an error...

Thoric (CLA, CLED, CTD and LabVIEW Champion)


0 Kudos
Message 5 of 9
(6,188 Views)

The FPGA bitstream will be downloaded by the Open FPGA VI Reference node, so you do no need to call any other method to download the bitstream. You do need one of these nodes for each of your bitstream as you are doing now.

 

You need to use the Upcast function on each of the FPGA references to make all of the references generic enough to be passed by the same wire.

authored by
Christian L, CLA
Systems Engineering Manager - Automotive and Transportation
NI - Austin, TX


  
Message 6 of 9
(6,167 Views)

Thanks Christian,

 

I did want to upload the bitstream outside the subvi, by passing the reference out and performing a few more tasks first, but I guess I have no choice - I'll have to rework my code a little.

 

Many thanks! 🙂

 

Thoric

 

 

Thoric (CLA, CLED, CTD and LabVIEW Champion)


0 Kudos
Message 7 of 9
(6,151 Views)

Hi,


I know that this thread is old so I am sorry to dig it up like that but I am facing this days the same kind of problem with FPGA code which would have to deal with different modules on the same CRIO slot. So I am wondering if 10 years later there are new possibilities to do such things or if this is still the best choice and the state of the art to deal with scalability in projects involving CRIO.


Thank in advance for any help on this topic.

0 Kudos
Message 8 of 9
(3,730 Views)

Hi Noar,

 

I quickly read through the answers above and as far as I know this is still the only way to achieve this functionality.

 

Andreas

Andreas
CLA, CTA
Message 9 of 9
(3,715 Views)