CompactRIO System Configuration Information (CRI) Library

[lharding]

The System Management and Information (SMI) Library is recommended for new designs using LabVIEW 2013 or later. SMI retains all of the features of CRI, however palette member VIs are not "drop-in" replaceable. The CRI Library has been deprecated, and no future versions are planned for release.

The development of advanced and dynamic CompactRIO (cRIO) applications sometimes requires the ability to detect the current configuration of a CompactRIO system. The CompactRIO Information (CRI) library provides functions to retrieve information about a local or remote cRIO controller, backplane, and modules, including the type and serial number of each of these system components. It can be used with CompactRIO, Single-Board RIO (sbRIO), myRIO, MXI-Express RIO, and EthernetRIO, for reporting the configuration information of RIO hardware controller, chassis, and modules for local or remote targets.

Functionality

The CRI library provided with this tutorial allows you to programmatically retrieve information about the components of a CompactRIO (cRIO) system. It provides access to the following information:

Controller

• Model Name
• Model Code
• Serial Number
• MAC Address
• Host Name
• IP Address

Backplane

• Model Name
• Model Code
• Serial Number

Modules

• Module ID
• Vendor Name
• Model Name
• Serial Number

The CRI library includes two sets of VIs, one set to run directly on a cRIO controller targeted with LabVIEW Real-Time, the other set to run remotely to retrieve the configuration of any cRIO system on the network.

Using the CRI Library

The CRI installer will add the CRI function palette to the User Library function palette. All of the CRI VIs are located in the main palette.

Figure 1: cRIO Information (CRI) function palette

The CRI library includes a high-level function (Get cRIO System Info) to retrieve the complete system configuration of a CompactRIO chassis. This VI returns information about the controller, backplane and modules.

Note:

In order to retrieve information about the modules located in the cRIO backplane the function must load a custom bitstream onto the FPGA. This bitstream will replace any existing bitstream or LabVIEW FPGA VI running on the FPGA. Use this function carefully if the cRIO system and FPGA may be monitoring or controlling any external hardware.

Figure 2: CRI Get cRIO System Info.vi

The remote version of this VI allows you to retrieve the information from a cRIO system on the network by specifying the system IP address or network name. In order for this function to work properly the remote cRIO system must be configured with a compatible version of LabVIEW, NI-RIO, NI-VISA and the NI-VISA server.

Figure 3: CRI Get Remote cRIO System Info.vi

Controller and Backplane Information

The high-level function CRI contains three individual VIs to retrieve information about the controller, backplane and modules. Using these VIs individually you can customize these operations in your application as necessary.

The controller and backplane information are read directly from drivers and registers in the controller and backplane. The VI is run while targeted to the cRIO controller.

Figure 4: Retrieving the controller and backplane information

Modules

The VIs included in the CRI library for retrieving information about the individual modules in a chassis deploy a custom bitstream to the FPGA in order to retrieve information from EEPROM memory on each individual C series module. This custom bitstream aborts and replaces any other bitstream or LabVIEW FPGA VI currently running on the FPGA. Therefore you must use this function carefully to avoid causing any problems with devices and actuators connected to the physical I/O of the system.

To retrieve the current module configuration you must specify the type of cRIO backplane used in the system so that the correct bitstream is downloaded to the FPGA.

To retrieve information about the modules in a remote cRIO system, specify the system IP address or network name.

Figure 5: CRI Get Remote cRIO Modules Info.vi

The list of supported backplanes of each version of the CRI library is provided in the VI package description.

The CRI library includes a separate FPGA bitstream for each of these targets. If the Get cRIO Modules Info VI is targeted to the LabVIEW Real-Time controller of a cRIO system, all bitstreams referenced in the VI are downloaded to the program memory of the cRIO system even though the current system only contains one possible cRIO backplane. This can use up a significant portion of the cRIO program memory (RAM). In order to optimize your application and reduce memory usage, the CRIO library includes individual VIs for each of the cRIO backplanes which only include the bitstream for one of the cRIO backplanes/FPGA targets. You can use these if you know during development which of the cRIO backplanes will be employed in the deployed application.

Note: If a C series module is removed from a running system, the first time the module configuration is read using the CRI library, the vendor and model ID returned from the now empty slot may not be 0. It may be returned as a non-0 value and the module name will be <Undefined>. On the next operation it will return a vendor and model ID of 0.

Implementation

This section provides some additional information about the implementation of the CRI functions, which may be useful in customizing these VIs or implementing similar operations in your application.

Controller and Backplane

The VIs provided to retrieve controller and backplane information use standard LabVIEW Real-Time and NI-RIO functions  to retrieve the information. 

The CRI Get cRIO Controller Info VI uses a modified version of the RT Ping Controllers VI to retrieve the information. This function may also be used to retrieve information from a PXI or Compact FieldPoint LabVIEW Real-Time controller.

The CRI Get cRIO Backplane Info VI uses functions from the NI-RIO driver to retrieve information about the backplane. The model code of the backplane is converted to an enumerated value representing the  backplane model name. The conversion is performed in the cri_Parse Backplane ID subVI using a lookup table containing  the list of backplanes and their model codes.

Figure 6: Block diagram of CRI Get cRIO Backplane Info.vi

The lookup table containing the list of available backplanes is stored in and provided by cri_cRIO Vendor and Components Library.vi. This VI contains a list of all current cRIO devices and vendors and their IDs and is used in a number of CRI VIs. The list of devices is stored in the default value of a series of front panel indicators. Any new cRIO devices may be added to these lists.

Figure 7: cri_cRIO Vendor and Components Library.vi: Lookup tables of cRIO components and vendors

Modules

The information about each individual module is stored in an EEPROM located on the module and includes the module and vendor ID and the module serial number. This information can be read in any LabVIEW FPGA VI using the I/O property node.

Figure 8: LabVIEW FPGA diagram and indicator used to retrieve information from four C series (cRIO) modules

The CRI library uses a simple LabVIEW FPGA VI to retrieve this information from all slots in the backplane. A unique FPGA VI is used for each backplane type. These FPGA VIs are compiled and the resulting bitstream (*.lvbit) is provided with the CRI libraryVIs.

The source code and project for these FPGA VIs is not included in the installed CRI library, as it is not required to retrieve the module information. Only the compiled bitstreams are required. The source code and project is provided in a separate download ZIP file if desired.

The project used to generate the FPGA bitstreams includes a separate FPGA target for each of the cRIO backplanes. For each target, a cRIO module is configured for each slot in the backplane to read the module information from the EEPROM of each module. The project uses a NI 9203 for each slot in the configuration, but the software allows you to retrieve the module information from any module regardless of the module type. This technique is used to retrieve the module information from all slots in the backplane regardless of the type of module in each slot.

Figure 9: LabVIEW project used to generate the FPGA bitstreams for retrieving module information

After the module information is retrieved for each module, it is returned to the host VI running either on the cRIO controller or on a networked target. In the host VI (e.g. CRI Get cRIO-9101 Modules Info.vi) the module ID is converted to the vendor name and module name using the lookup tables contained in cri_cRIO Vendor and Components Library.vi.

Figure 10: CRI Get cRIO-9101 Modules Info.vi: Retrieving and converting module information on the host

Applications

The CRI library can be used to add advanced functionality to many different types of cRIO-based application. Here are a few examples of how the CRI library may be used.

Logging of System Configuration

In many applications where data is recorded or logged it is necessary to also record information about the recording system being used in order to meet certain standards requirements. Using the CRI librarycyou can retrieve information about all of the cRIO components used in the system including their serial numbers and can record this information in a file or database along with the data being recorded. When components are replaced in a system it is easy to track these changes. A more advanced system may record the calibration intervals for each module in a database and notify the user if individual modules will require re-calibration in the near future. 

Dynamic FPGA Code Selection

Due to the nature of FPGAs, a LabVIEW VI performing I/O operations is developed and compiled for a specific configuration of module types in the backplane. A bitstream generated from a LabVIEW FPGA VI for one configuration of  modules cannot be used with a different configuration of I/O modules. For example if you have configured a NI 9215 analog input module during the compile process, you can not run the bitstream using a NI 9201 analog input module instead. However, you can configure and compile multiple FPGA VIs, one for each possible module configuration, and then select the proper FPGA VI or bitstream at run-time to match the current configuration of modules.

Using the CRI component you can detect the current configuration of modules in the backplane and can then select the proper FPGA bitstream to download and run. This detection and selection of the FPGA bitstream will be part of LabVIEW Real-Time application running on the cRIO controller.

Application Licensing

In some cases you may want to apply a license to an application and link it to a specific set of hardware. This would prevent a user to move the application/code from one cRIO system to another system containing the same hardware. Using the CRI library you can uniquely identify each system component using its serial number, as well as the MAC address of the controller, and can build a licensing solution that links the application to the specific set of hardware.

The process of creating a license key and linking the application to the hardware is not handled by the CRI library and must be implemented separately.

Download and Installation

The current version of CRI (v2015.0.0.1) is available through the LabVIEW Tools Network using VI Package Manager (VIPM). It includes support for MXI-Express RIO and EthernetRIO expansion chassis, in addition to existing support for myRIO and select sbRIO targets. VIPM also contains older versions of CRI, compatible with previous versions of LabVIEW. You can install them using the Install Other Version.... option in VIPM, although they may not include support for all of the latest controllers and backplanes.

Support and Feedback

Please post questions, comments and suggestions for the CRI library in the CRI discussion forum.