I was wondering if the bitfile path input for the "Open Dynamic Bitfile Reference Function" function is on target file system.
Since this VI is intended to be used for changing bitfiles at runtime, it seems that if this is used in a (Host) VI on an RT target, the bilfile need to be present on the RT file system before hand.
Is that correct?
Yes, the Bitfile path input refers to the location in the hard drive of the system that is executing the function. If you are using a cRIO, then the file path is the location of the .lvbitx file in the cRIO.
I usually use it by adding my .lvbitx file as "Always Included" in my LabVIEW Real-Time Executable Build Specification and then refer to it from the main application from /home/lvuser/natinst/bin/data/myBitlife.lvbitx (this is specific to Linux RT targets). This ensures the bitfile always gets loaded to the RT controller when the application is downloaded.
Not to disagree with Oscar, who has saved me several times in the past, and maybe it is "target-specific", but I've never directly loaded the FPGA Bit File onto my RT Target, in my case, a myRIO.
I typically configure the Open FPGA VI Reference by pointing to the FPGA VI (in the RT-Target part of the LabVIEW Project). This usually works, except when it give me the -61017 Error (I think that's the number). Oscar helped me with this, suggesting I link, instead, to the FPGA Bit File, which (of course) worked fine. And usually, after a day or two (and some reboots), I can revert back to specifying the FPGA VI (instead of the Bit File), which results in a slightly cleaner appearance of the Open FPGA VI Reference function.
I've recently started building RT Executables and even deploying them as Startup Executables. I (so far) have never specified the FPGA code, nor its BitFile, in the Always Included section -- the only thing on the right side of the Build is the Top-Level RT VI. So far, that has always worked ...
I've tried to avoid getting too tangled up in how the NI Linux Real-Time file system is organized, largely for fear of "messing things up". I've learned what the various options of the Build Specifications do (Deploy, Set/Unset as Startup, Run as Startup, Build) do, and in what order to do them. [I've also made the "Sorcerer's Apprentice" mistake of testing a Startup VI that waits 10 seconds, then reboots the Target -- how do you stop this? Took me a while to figure this out ...].
If you point the Open FPGA node to the VI or the actual bitfile, it will always include the according compiled bitfile in the executable as part of the actual Open FPGA node and use that.
If you use a path instead, the bitfile will be loaded from that path and is of course local to the file system of the target. I have recently finished a project where I used that feature to load different configurations of the FPGA bitfile, based on the detected hardware.
First I load a minimalistic FPGA bitfile that returns me the module ID for each slot as populated at that point. Then I determine the available hardware and load the according FPGA bitfile. This was required as I had also simultaneous sampled analog input modules which all were operating on the same clock and also needed to be all read in the same IO node to work. If even one of those modules is not present but included anyhow by the IO node, that node returns with an error, not returning any values and also not waiting for the configured clock cycle, even if the module providing the clock is present.
So I need to use conditional compile to configure multiple FPGA cores that support the pre agreed configurations. Modules that aren't sampled on a fixed clock are simply read in different loops and added through memory reads to the main loops FIFO data, so it doesn't matter if they are present or not. If not present those channels simply always return 0 readings.
Thanks, Rolf, for clarifying (for me) the difference between "Open FPGA VI Reference" and "Open Dynamic Bitfile Reference". I have been using the former, and the Original Poster was probably asking about the latter ...
Hello Oscar, hello Bob, hello Rolf,
thank you all for your replies, it clarified my questions and actually showed me a path to use this function that I hadn't thought of before.
I never thought of including the bitfile in the deployment to ensure that it is present on the target, when using "Open Dynamic Bitfile Reference Function". Thanks also for the path to be looking in for the bitfile.
The overall idea behind it was to actually simply show what bitfile name was used in Open FPGA node, but I couldn't find a way to get that info programmatically from the node or actually just feed it to a node programmatically (and than have it included like described by Rolf). There is such an option, but only for "NXG 5.1 FPGA" (https://www.ni.com/documentation/de/labview-fpga-module/latest/fpga-targets/downloading-running-fpga... as far as I could find.
Linking to FPGA-VI is a good option for development..
I just try to keep changes to FPGA to a minimum, so not "just" change things in the FPGA-VI and by that triggering a recompile makes you think about FPGA changes (and what is to come during development) in a lot more detail and you usually get away with significantly less rebuilds of a bitfile than otherwise (at least my experience).. This also means adhering to the general FPGA wisdom, like "Do not use constants, but instead frontpanel controls with proper default values and than don't write to them.. If necessary you can later change those values from RT at startup and not have to recompile the FPGA (or at least not until you figured out what the constant shall actually be during testing)".
Thanks for clarifying that Open FPGA node actually places a there chosen bitfile in the RT exe... I found hints to it (also in the form of "it works with filepaths on the host PC, rather than the target"), but I couldn't find a clear statement that this is the case.
What you describe sounds a alot like a situation that will come up in my project within the next few month. Therefore I would like to ask a question:
We have two different cRIOs in this project, but with identical modules at identical slot positions (due to world wide cRIO shortage, you take what you can get)..
What would be the most efficient way to account for this in our project?
I was thinking of changing the cRIO modell in the project when building a deployment manually and building for the second cRIO and keeping two deployments, that each include the correct bitfile.
But maybe you have a different idea / best practice...
I'm not sure, but what you describe sounds like it works for having different FPGAs (or more precisely personalities) but still have the same cRIO modell (since it is only one)...
I was hoping for something like maybe having two RT targets in my project, that just share a common code base for FPGA and RT (maybe with wrapper VIs ?) But not sure, if and how this might work...
@Oscar: Is there a NI solution for deploying a project to multiple different targets with comparable configuration (in terms of C-series modules) but developing on just one system ? I sounds like something that could / should be an NI product of some sorts..
Well you need indeed a target for each cRIO chassis type you want to use and in my case also for each hardware configuration, since they are configured using conditional compile definitions.
But the VIs I use in each of them for the FPGA code are exactly the same. Since the actual compiling happens outside of LabVIEW itself there is not even a problem that the VIs are locked because of being used in multiple contexts.
For the RT code I limit myself to only adding the VIs to one of the targets, not more, otherwise the VIs get locked because they are used in multiple contexts. And here is a bit of startup magic. Before running the special build HW Detect FPGA Bitfle I use the NI System Control API to determine the actual hardware present. If I was only using cRIO-904x chassis that would be enough as the System Control API also can enumerate cRIO C modules thanks to the extra DAQmx ASIC on there. For other cRIOs however the System Control API doesn't allow to enumerate the C modules, and since our customer also has a whole bunch of 9035 laying around installed on the factory floor where our redesigned system is going to be installed on too, I had to use the technique with detecting the module IDs on the FPGA, and since our program consistently fills up 98% of the FPGA fabric on the 9035 and 9045, I had to make it a separate bitfile.
So from the System Control API I know what chassis I have and how many slots to expect, then I load the "cRIO-9035_Detection", "cRIO-9039_Detection" or the "cRIO-9045_Detection" bitfile, run it and get back the module IDs. From there I translate them into a string that represents the possible pre-agreed module configurations and then load that one through its name in the form of "cRIO-90xx_1x01010x" and run it. The number behind the cRIO chassis is a coded identifier for the desired module configuration. If it can't find that file it aborts with an error message to the central Syslog server in order for the technicien to be able to debug the issue.
The projects to build the Detection bitfiles are very trivial. It simply consists of a configuration with all slots filled with a standard C module and in the VI it calls for each slot a node that returns the ModuleID and SerialNumber, packs them in an array and returns that to the RT system through a front panel control (Register). That's the whole magic to it. If you always use the same module configuration but just different cRIO chassis you won't need the FPGA module Detection trick however.
thank you for clarifying your appoach / solution.
Since the C-Series modules configuration and FPGA content is identical, I think the following will work:
- Both cRIOs in the project
- FPGA VI and additional VIs for FPGA on both targets
- Compile for both FPGAs
- Develop using one cRIO and keep the RT-VI for that modell as base / reference implementation.
- Right before deploying, copy the RT-VI to the other target (with shared sub-VIs) and change the chosen RIO in the "Open FPGA node" and select the corresponding FPGA bitfile
- Build two deployments and deploy two systems
Hope, that seems reasonably....