NI does not actively maintain this document.
This content provides support for older products and technology, so you may notice outdated links or obsolete information about operating systems or other relevant products.
This document contains the LabVIEW Real-Time Module known issues that were discovered before and since the release of LabVIEW 2013 Real-Time Module. Not every issue known to NI will appear on this list; it is intended to only show the severe and more common issues that can be encountered.
The LabVIEW 2013 Platform Known Issues contains a full listing of known issues, including LabVIEW toolkits and modules.
The Known Issues Document is divided into two separate tables. The section linked below displays the issues by category.
Please refer to Developer Zone Article: LabVIEW Known Issues Categories Defined for a detailed explanation of categories and the types of issues listed in each category.
For those who wish to locate newly reported issues or issues by date, the section linked below displays the issues sorted by date the issue was reported.
Feel free to contact NI regarding this document or issues in the document. If you are contacting NI in regards to a specific issue, be sure to reference the ID number given in the document to the NI representative. The ID number contains the current issue ID number as well as the legacy ID number (use the current ID number when contacting National Instruments). You can contact us through any of the normal support channels including phone, email or the discussion forums. Visit theNI website to contact us. Also, consider contacting us if you find a workaround for an issue that isn't listed in the document so that we may update the document.
The following items are known issues in LabVIEW 2013 Real-Time Module sorted by Category.
ID | Known Issue | |||||
---|---|---|---|---|---|---|
Building and Distributing LabVIEW Applications | ||||||
371282 Return | A Real Time Executable with a Packed Project Library set to "Always Included" cannot be remotely debugged A Real Time Executable with a Packed Project Library set to "Always Included" cannot be remotely debugged. When connecting to the executable the "failed to connect to remote application" error message will be displayed. Workaround: Use other standard debugging methods.
| |||||
410058 Return | RT deployment window reports free target memory, but deployment fails from an out of memory error When deploying some RT applications, the RT application deployment window may report significant amounts of free target memory, but the deployment fails with an out of memory error. Memory reporting in this window is incorrect and the target is indeed out of memory available to LabVIEW. Workaround: Reduce memory usage on the target by removing unnecessary software, hosting shared variables on a remote machine, etc.
| |||||
Controls and Indicators | ||||||
323607 Return | On an RT OS, Numeric Control With "Visible" Property Node Stops Updating If a VI contains a Numeric Indicator and this Indicator has a property node of the type Boolean Visible; once the Indicator is made invisible (i.e. Property node = F), then is made visible once again the value on the indicator no longer updates. Note: the system is still passing through the correct value, it is simply not being updated onto the front panel. Workaround: Put the numeric indicator on a Tab Control, then make the property of the tab control invisible/visible rather than the numeric indicator itself.
| |||||
DataSocket | ||||||
196504 Return | FieldPoint Data Channels Swapped when Reading Data using Datasockets in a For Loop When calling a single Datasocket Read function multiple times in a For Loop the FieldPoint channel data could randomly swap between the channel. Workaround: 1. Use a sequential read with multiple Datasocket functions. 2. Explicitly open the Datasocket connections and then use a Datasocket Read in the for loop. 3. Use a different API to access the IO point (SV, FieldPoint, etc)
| |||||
File I/O | ||||||
387418 Return | Set Number of Records function erases all datalog contents on VxWorks targets Using the Datalog - Set Number of Records function on VxWorks targets wipes all logs contained in the file. Workaround: Use binary file, TDMS or another file format to store cluster data.
| |||||
Functions, VIs, and Express VIs | ||||||
298990 Return | Clear Errors VI can affect determinism on RT targets The Clear Errors VI is not reentrant and becomes a shared resource when it's called from multiple loops in an RT application. This can introduce higher levels of jitter in time critical code segments. Workaround: Create custom "Clear Error" VI.
| |||||
305567 Return | File/Directory Info function reports two extra files when called on for an external hard drive Calling the File/Directory Info function and pointing it at a folder on an external hard drive connected to a CompactRIO returns two more files than exist in that folder. For example, if the function points to a empty folder on the CompactRIO hard drive, it will return zero; if it's pointed to an empty folder on an external drive, it will return 2. Workaround: Subtract 2 from the file count returned from the File/Directory Info function when reporting on a folder on an external hard drive.
| |||||
346430 Return | Certain CompactRIO controllers produce high CPU load while changing date/time On certain CompactRIO controllers (verified on 9074 and 9076), the CPU usage will hit 100% for several seconds when setting the date and time using the RT Set Date and Time.vi. This will only happen if the current date/time is significantly different from the date/time being set; small changes to the date and time do not affect the CPU usage. Workaround: Set the date and time during an initialization stage of the application. Wait for the CPU load to return to normal levels before proceeding.
| |||||
387275 Return | Array of ByteString data type in OPC UA reports generic error Support for the ByteString Array data type has not been added although the option appears in the data type ring control. Workaround: Don't use ByteString Array data type until support is added.
| |||||
399608 Return | RT FIFO writes produce high level of jitter on Linux-RT targets On Linux-RT ZYNQ based targets, writes to an RT FIFO can introduce a high level of jitter compared to VxWorks and PharLap targets when the RT FIFO read occurs on a thread running in a different processor core. Workaround: Prioritize RT FIFO read and write operations so they take place in threads running on the same processor core.
| |||||
429471 Return | Copy primitive fails with a permissions error when copying files to or from /u/ on linux-RT On targets running the linux-RT operating system, the file copy primitive fails with a permissions error when attempting to copy files to or from an external storage device at /u/ Workaround: Use the system executive VI and copy the file from the command line
| |||||
Hypervisor | ||||||
176762 Return | Time Triggered Variables do not work on NI Real-Time Hypervisor Systems You cannot use Time-Triggered Shared Variables on an NI Real-Time Hypervisor system. Workaround: If you need deterministic Ethernet in an NI Real-Time Hypervisor system, you can use the virtual Ethernet device to communicate between Windows and the RT target or you can use NI EtherCAT to communicate with add-on I/O.
| |||||
Miscellaneous | ||||||
115784 Return | Timed-Structure CPU Usage not Reported as Time-Critical Priority by RTSM and CPU Measurement VIs on VxWorks On VxWorks targets, the Real-Time System Manager (RTSM) and CPU Measurement VIs incorrectly report CPU usage by Timed Structures as normal priority. The NI Real-Time Execution Trace Toolkit correctly reports the priority as Timed-Structure priority. Workaround: Use the NI Real-Time Execution Trace Toolkit to monitor thread priorities.
| |||||
340541 Return | End of line constant behaves differently in interactive mode than as a built executable On a VxWorks target the End of Line (EOL) constant writes a carriage return and a new line in interactive mode but, when built into an RT EXE the EOL constant only writes a new line Workaround: Add a carriage return constant to the new line for use in a RT Executable
| |||||
Operating System Specific | ||||||
275880 Return | UDP Broadcast behaves differently on Phar Lap and VxWorks Real-Time Targets UPD Broadcast may behave differently for Real-Time targets running different operating systems. VxWorks targets cannot read back a message it has broadcast, while this is possible on Phar Lap targets. Workaround: N/A
| |||||
Performance | ||||||
346430 Return | Certain CompactRIO controllers produce high CPU load while changing date/time On certain CompactRIO controllers (verified on 9074 and 9076), the CPU usage will hit 100% for several seconds when setting the date and time using the RT Set Date and Time.vi. This will only happen if the current date/time is significantly different from the date/time being set; small changes to the date and time do not affect the CPU usage. Workaround: Set the date and time during an initialization stage of the application. Wait for the CPU load to return to normal levels before proceeding.
| |||||
365498 Return | Timed loops on Linux-RT are slow / don't meet timing on first iteration On Linux-RT the thread in which a timed structure resides must be moved to a particular control group of threads and moving threads between cgroups is inherently non-deterministic. This thread move executes during the first iteration of the timed loop because it's not possible to move a thread that doesn't yet exist (i.e. before the timed loop executes). Workaround: Run timed structures with warmup iterations and monitor execution time. When execution time meets the desired specification, then run desired code.
| |||||
412606 Return | Using System Configuration VI's locally on Linux RT Target can cause high jitter Using System Configuration VI's locally on RT Target can cause high jitter in time critical loops on Linux RT Target. Workaround: Use system configuration VI's remotely or in non-deterministic loops instead of in time critical RT code segments.
| |||||
399608 Return | RT FIFO writes produce high level of jitter on Linux-RT targets On Linux-RT ZYNQ based targets, writes to an RT FIFO can introduce a high level of jitter compared to VxWorks and PharLap targets when the RT FIFO read occurs on a thread running in a different processor core. Workaround: Prioritize RT FIFO read and write operations so they take place in threads running on the same processor core.
| |||||
Remote Target | ||||||
413077 Return | Cannot reconnect to myRIO if USB is unplugged while an application is running If the USB for the myRIO is unplugged while running a VI with a front panel open it is possible to get the controller into a state where LabVIEW cannot reconnect to the controller and receives an Äccess Denied" error. Workaround: Reboot the myRIO
| |||||
218506 Return | Connecting to an RT target currently running an executable overwrites ni-rt.ini tokens When you connect to an RT target that is currently running an RT startup executable, two ini tokens may be forced back to their default values. "RTTarget.LaunchAppAtBoot=True" will be deleted (returning back to default False behvaior) and "RTTarget.ApplicationPath" will be changed back to the default path for that target Workaround: Redeploy the original executable and set as startup from the LabVIEW project before rebooting the controller
| |||||
435115 Return | Daylight Saving Time Changes on Wrong Date for Europe for Real Time Controllers Daylight savings time adjusts on real time controllers on October 27th. This is not the correct date to adjust the time for Europe. Workaround: N/A
|
Document last updated on 1/15/2014