Linux Users

cancel
Showing results for 
Search instead for 
Did you mean: 

Query PXIe FPGA card RIO logical name from C API

Solved!
Go to solution

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?

0 Kudos
Message 1 of 11
(5,434 Views)
Solution
Accepted by Lorn

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/

Message 2 of 11
(5,397 Views)

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.

Charlie J.
National Instruments
0 Kudos
Message 3 of 11
(5,392 Views)

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!

0 Kudos
Message 4 of 11
(5,381 Views)

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. 

Charlie J.
National Instruments
Message 5 of 11
(5,360 Views)

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.

0 Kudos
Message 6 of 11
(5,355 Views)

@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.

Charlie J.
National Instruments
Message 7 of 11
(5,353 Views)

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.

Download All
0 Kudos
Message 8 of 11
(5,326 Views)

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?

  1. Hmmmm. That sounds like a bug but I'm honestly not sure. Might be worth making a support ticket to get one created if it doesn't already exist. 
  2. The -1 value indicates that the slot is either unknown or not populated correctly. I'm not sure why you would receive that unless the driver simply isn't populating that information. One way to check that you're getting all of the right values and to see what other information might be present would be to run the "lsni -v" command and see if the slot number information is present. 
  3. That can be modified with the NISysCfgRenameResource function. I believe this will change the user-assigned resource name (that is, the alias), not the resource name. 
  4. It's not really that dangerous assuming you code with the knowledge that we might change the field value in a future release. For example, I believe we've changed that field in the past to be more consistent. That has typically been along the lines of adding or tweaking the non-numeric characters in the Model Name. The warning is more meant to ensure users don't expect that field to be static throughout all releases just in case. 

 

Charlie J.
National Instruments
Message 9 of 11
(5,292 Views)

Hi, could you detail which version of NI-RIO are you installing in Linux?

Thanks in advance!

0 Kudos
Message 10 of 11
(3,001 Views)