04-08-2020 02:09 PM
Running CentOS 7 with LabVIEW C API 18. I have three FPGA cards that I am able to access from my C program (in this case: PXIe-7858R, PXIe-7820R, PXIe-7975R). The problem is that depending on the chassis, I install the cards in a certain physical order, but the underlying NI software re-arranges the cards and changes the RIOx logical name designation based on the bus order (which may not match physical slot order), which is causing my program fits because the bitfiles are for a specific FPGA card and each card is different. When the cards are in the correct RIOx logical designation order, my program works.
What I could do is run 'lsni -v' from within my C program and query the results, then figure out the actual logical RIO name designation based on the card model from that command, but that seems clumsy.
There doesn't seem to be a C FPGA API call to get the card to RIO mapping. Yet the 'lsni -v' command is doing it. There are a lot of libraries installed with the NI RIO software subsystem via yum. Is there documentation on these libraries or does anyone know of a C function call that would give the RIO to card model mapping?
Solved! Go to Solution.
04-09-2020 09:37 AM
You can query what FPGA cards are present and their attributes through NI System Configuration. If you install the "ni-syscfg-devel" package, it will install some headers under "/usr/include/nisyscfg/".
The documentation for the nisyscfg C API is available here: https://zone.ni.com/reference/en-XX/help/373242M-01/
04-09-2020 10:28 AM
Note that some properties are listed in the nisyscfg.h file but not necessarily the help documentation. I'd expect the property value you're looking for would be NISysCfgFilterPropertyUserAlias or NISysCfgFilterPropertyResourceName.
04-09-2020 05:40 PM - edited 04-09-2020 06:02 PM
This sounds perfect! Except I'm not finding ni-syscfg-devel in the repository, at least the 2018-7 one. It's there in 2019. There is ni-syscfg-runtime, which yum says is installed. So will I need to upgrade to the 2019 version of the FPGA C API to get this capability? Is that going to mess up my current development environment?
The documentation seems pretty thorough, although they left out which library to link in.
Thanks!
04-10-2020 01:07 PM
Hi Lorn,
You can upgrade the ni-syscfg-runtime and ni-syscfg-devel to 2019 versions without impacting the C API version. NI System Configuration is designed with the intent that it is fully backwards compatible with older drivers on the system.
Alternatively, you can install an older version (e.g., 2018) from here: System Configuration.
Note: There is a bug in the 2018 version of NI System Configuration where the headers required (e.g., nisyscfg.h) aren't included in the Linux installer. If you decide to go with the 2018 version, let me know and I'll get you the required headers.
04-10-2020 01:45 PM
Ok, I upgraded to the 2019 versions. So I get the impression from what you are saying that I don't need to upgrade to 2019 FPGA C API on the Windows side yet?
So now I've got nisyscfg.h. Did the packages happen to install examples? I haven't found any yet. I can probably figure it out, but I would rather not have to guess. There's some libraries that would appear to need to be linked in, such as libnisyscfg, but I wasn't sure if libnisyscfgExpert needed to linked in also.
Thanks everyone! This has been good info.
04-10-2020 01:53 PM
@Lorn wrote:
Ok, I upgraded to the 2019 versions. So I get the impression from what you are saying that I don't need to upgrade to 2019 FPGA C API on the Windows side yet?
So now I've got nisyscfg.h. Did the packages happen to install examples? I haven't found any yet. I can probably figure it out, but I would rather not have to guess. There's some libraries that would appear to need to be linked in, such as libnisyscfg, but I wasn't sure if libnisyscfgExpert needed to linked in also.
Thanks everyone! This has been good info.
The Windows and Linux RIO Driver versions should generally match, but otherwise you shouldn't have to change anything on the Windows side. And the RIO driver version can be 2018 while the SysCfg driver is 2019.
You should just need to include nisyscfg.h in your design as I believe the OS search path should be able to resolve the library but if you need to know the exact library it would be libnisyscfg as you've noted. I believe that will handle loading of any other dependencies on its own.
As for examples for C Code, I'm not sure where we put those on Linux or if we have them.
04-11-2020 10:27 AM
My end goal was to query the system for the RIO name and the model number so I can properly open the FPGA sessions to the correct cards.
Lacking an example, I read the help and nisyscfg.h and figured out something that gets me the information I need (which pretty much involved a lot of guessing). Enclosed is the code (written and compiled on CentOS 7, but should work on other NI supported Linuxes).
Compile with (last option is lower case "ELL", not to be confused with upper case "eye"):
gcc -g3 -o getit getit.c -L/usr/lib/x86_64-linux-gnu -lnisyscfg
Questions:
1. Model number property errors out saying that property not available, but according to the help I shouldn't use the model name for programmatic decisions. So why should model number property not work?
2. Slot number seems to be an error, but I'm not sure why. nisyscfg and the ni-rio expert knows the cards are there. I don't really need the slot number.
3. The resource name is what I need. The alias happens to be the same, but just curious if the alias is settable somewhere?
4. I only need the model number portion of the model name, but NI help says don't use model name for programmatic decisions because the format might change. So if I can't get model number resource to work, how dangerous is to use model name?
Appreciate any comments/improvements to the program. I won't claim it's correct, but it got the job done.
04-13-2020 05:46 PM
Questions:
1. Model number property errors out saying that property not available, but according to the help I shouldn't use the model name for programmatic decisions. So why should model number property not work?
2. Slot number seems to be an error, but I'm not sure why. nisyscfg and the ni-rio expert knows the cards are there. I don't really need the slot number.
3. The resource name is what I need. The alias happens to be the same, but just curious if the alias is settable somewhere?
4. I only need the model number portion of the model name, but NI help says don't use model name for programmatic decisions because the format might change. So if I can't get model number resource to work, how dangerous is to use model name?
06-07-2021 01:32 PM
Hi, could you detail which version of NI-RIO are you installing in Linux?
Thanks in advance!