NI CompactRIO Device Drivers December 2017 Known Issues

MDK modules will not auto-discover in cRIO-904x/5x targets

Third-party MDK modules will not be auto-discovered in cRIO-904x and cRIO-905x targets. When trying to discover an MDK module in a cRIO-904x or cRIO-905x, LabVIEW returns a "Module is not supported" error message.

Workaround: Manually add a the MDK C Series module to the LabVIEW Project. Change the module programming mode to FPGA or Real-Time Scan.  

Back to top

Deploying an EtherCAT Master Changes the Programming Modes on cRIO-904x to Real-Time Scan

Deploying an EtherCAT master with a NI 9144 or NI 9145 slave containing C Series modules in Scan Mode will also change the corresponding C Series modules' program mode to Scan Mode on the local cRIO-904x chassis. If you have an existing FPGA application running on the cRIO-904x while deploying the EtherCAT master, the C Series' I/O Nodes will report error 65673 (if error terminals are enabled) and will hold the last reported value. You can confirm this is the issue you are experiencing by looking at the C Series modules in NI MAX and noting their programming mode has changed to "Real-Time Scan (I/O Variables)".

Workaround: After deploying the chassis, you can use System Configuration functions to programmatically change the module's Programming Mode before starting the FPGA application. The general way to change programming modes programmatically is documented in this KnowledgeBase article, and a specific example (workaround_706379.zip) is attached to this document.  

Back to top

Cannot Open an FPGA Reference to a NI-9147 or NI-9149 FPGA Target From VxWorks Host

Calling Open FPGA VI Reference.vi on a VxWorks-based controller will return error -63193 ("The requested feature is not supported.") when targeting the FPGA on a NI Linux RT device. For example, this would occur when a cRIO-9074 (VxWorks) attempts to open an FPGA Reference to a NI-9149 (NI Linux RT).

Workaround: If the NI Linux RT target is a cRIO or sbRIO, you can encapsulate the desired FPGA resources using Network Shared Variables (for Read/Write controls) or Network Streams (for FIFOs). If the target is an Ethernet RIO (NI-9147 or NI-9149), you could route desired resources through a Windows host PC. This does not affect the NI-9146 or NI-9148 Ethernet RIOs.  

Back to top

FIFOs can fail to report hardware errors

Host to Target and Target to Host DMA FIFOs on cRIO-906x, sbRIO-96x7, sbRIO-9651, NI 9147, NI 9149, NI 793x, roboRIO, and myRIO can fail to report low-level bus errors. This can result in stale data followed by a timeout error.

Workaround: N/A  

Back to top

FPGA's "General" tab in NI MAX shows "Unknown" for Chassis and Slot of the built-in FPGA

The Chassis and Slot fields appear for both cRIO-903x and cRIO-904x. However, these fields should not be present in this window. The value of "Unknown" in the fields does not indicate that anything is wrong with the FPGA target or communication to the FPGA target.

Workaround: N/A  

Back to top

FPGA Single Cycle Timed Loops driven by imported clocks can vary in frequency

When using the sbRIO-9651 (System On Module/SOM), sbRIO-9607, or sbRIO-9627, the sbRIO Clip Generator does not place constraints into the .XDC constraints file for imported clocks. If your FPGA application uses one of these clocks to drive a Single Cycle Timed Loop, the period of that loop may become erratic.

Workaround: Follow the guidance of this LabVIEW FPGA Help page to add the necessary constraint(s) to the CLIP file.

Back to top

User Defined Variables can fail to correctly transmit data under certain conditions

User Defined Variables (UDVs) written to in a Single Cycle Timed Loop driven by a derived clock can occasionally fail to transmit data to the host. In some circumstances, this is accompanied by the error code -1 on the FPGA UDV writer node.

Workaround: Use a target-scoped block RAM FIFO to transmit the data from the loop driven by a derived clock into a loop driven by the base 40 MHz clock.

Back to top

Some legacy controllers do not have enough storage to install all items in the Recommended Software Set

There are multiple symptoms that might be due to this cause. Some targets may fail the installation process. Others might succeed installation and report a LabVIEW error (such as -52006 or -52010) on the RT Target Error log.

Workaround: Choose only the software components required to install based on your application.

Back to top

A VI copied from one controller to another can attempt to run on the original controller

When copying a VI from one target to another and attempting to run that VI on the new target, the VI tries to run on the original target. This attempt may or may not be successful based on the particulars of the VI being run and the hardware setup. This was identified in LabVIEW 2017 and has been reproduced in LabVIEW 2016.

Back to top

Synchronization tab in NI MAX reports that there are no cDAQ modules found for cRIO-904x targets

NI 9469 synchronization methods using NI-DAQmx are not supported in NI-DAQmx 17.6 on cRIO-904x targets.

Workaround: N/A

Back to top

Serial port items for 987x modules do not show up under the module item in MAX for cRIO-904x controllers

The serial ports of the NI 987x may show up in MAX under the FPGA target instead of under the module item. Serial port functionality is not impacted.

Workaround: Reboot the target.

Back to top

lvrt process may crash when discovering a network cDAQ chassis or initializing an NI System Configuration session on cRIO-904x

A crash of the lvrt process would cause all running LabVIEW applications to crash. This has only been seen on congested networks with many discoverable NI devices.

Back to top

Normal priority tasks hang on cRIO-904x controllers when CPU pool has been set and a high priority task is running

A normal priority task will hang until the high priority task is stopped. This occurs when the CPU pool has been set using the RT Set CPU Pool VI during boot or before running tasks.

Workaround: Set the CPU pool after running high priority tasks. Or, if the CPU pool is set on boot, run normal priority tasks first and then run high priority tasks.

Back to top

Compilation fails on cRIO targets when bitfile includes NI 985x FPGA IO Nodes

This impacts all cRIO targets except cRIO-904x targets.

Workaround: Enable error terminals to the NI 985x FPGA I/O Nodes to compile successfully.

Back to top

Pre-compilation error on cRIO-904x targets when using top-level clock of 120 MHz or greater for NI 9770 and NI 9775

When you try to compile an FPGA VI with a NI 9770 or NI 9775 on cRIO-904x targets with a top-level clock frequency of 120 MHz or greater, you get the following code-gen error:

Error -61037 occurred at An internal software error has occurred.
Please contact National Instruments technical support.
Clock signal, 'Clk40Derived2x1', was requested for a FROM-TO constraint, but does not exist. 

This is happening due different clock naming on cRIO-904x targets.

Workaround: In your LabVIEW Project, derive an 80 MHz clock from the 40 MHz clock. Put a Single Cycle Timed Loop (SCTL) on your FPGA VI and configure it to be driven by the derived 80 MHz clock. You do not need to put any logic inside the SCTL (other than wiring a boolean constant to the "Stop" terminal). If the SCTL is not present, LabVIEW will assume you aren't using the derived clock for anything and will not compile it, causing the same problem.

Back to top