Print
PDFOverview
This document contains the LabVIEW 2012 Real-Time Module known issues that were discovered before and since the release of the LabVIEW 2012 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 2012 Platform Known Issues contains a full listing of known issues, including LabVIEW toolkits and modules.
Documents Organization
The Known Issues Document is divided into two separate tables appearing in two separate Developer Zone documents. The following document displays the issues by issue category.
The known issues in this document are organized by the category of issue. Please refer to Developer Zone Article "LabVIEW Known Issues Categories Defined" for an explanation of the categories and what types of issues are in each category.
For those who wish to locate the newly reported issues, we have also published another version of the known issues table sorted only by date the issue was added to the document.
Contacting NI
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 the NI Website to contact us. Also consider contacting us if you find a workaround for an issue that is not listed in the document so that we can add the workaround to the document.
Known Issues by Category
The following items are known issues in the LabVIEW 2012 Real-Time Module sorted by Category.
| ID | Known Issue | |||||
|---|---|---|---|---|---|---|
| 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)
|
|||||
| Functions, VIs, and Express VIs | ||||||
| 298990 Return |
Clear Errors VI is Not Reentrant If the Clear Errors VI is used in parallel loops on LabVIEW Real-Time, you introduce a shared resource. This will affect the code's determinisms 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 |
High CPU usage when setting date and time on certain CompactRIO controllers 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 at the beginning of the Real-Time application and wait for the CPU to return to normal levels before executing the rest of the application.
|
|||||
| 358016 Return |
Cannot connect to debuggable executable when Wait on IRQ Timed Out is wired to case structure selector When connecting to a debuggable executable on a cRIO that is using the Wait on IRQ method to sync with an FPGA VI, if the "Wait on IRQ" "Timed Out" terminal is wired to a case structure that passes through the FPGA reference, the connection will fail with error message "Failed to connect to remote application". Workaround: Put an "Or" or other boolean logic in between the "Timed Out" terminal and the case structure.
|
|||||
| 360665 Return |
Memory Leak When Calling "String to IP" on a Dual NIC PharLap Real-Time Targets On dual Ethernet port PharLap Real-Time targets, every call to "String to IP" will leak 30 bytes of memory. This does not affect VxWorks targets or single NIC PharLap targets. Workaround: Limit the calls to "String to IP".
|
|||||
| 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.
|
|||||
| LabVIEW Object Oriented Programming | ||||||
| 345803 Return |
VIs or controls that use library items in community scope fail to download on VxWorks targets VIs or controls that use library items in community scope fail to download on VxWorks targets. They also do not work in built applications on these targets. Workaround: Change "community scope" vis in lvlibs and lvclasses to "public scope". Consider renaming these vis in a way that indicates they should not be used by external clients (i.e., rename "method.vi" to "__method.vi"). You might also restructure your class relationships to use a different access restriction policy.
|
|||||
| 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.
|
|||||
| 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 |
High CPU usage when setting date and time on certain CompactRIO controllers 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 at the beginning of the Real-Time application and wait for the CPU to return to normal levels before executing the rest of the application.
|
|||||
| 358920 Return |
Deployment of Real-Time VIs Slower in LabVIEW 2012 The first deployment of Real-Time VIs to the Real-Time target may be slower in LabVIEW 2012 than in LabVIEW 2011 and 2010. This slow down will only occur if the VIs or subVIs being deployed are also in memory in the Windows context during deployment. The slow down will not be seen on subsequent deployments if no changes are made to the VIs that would require it to be reloaded in to memory. Workaround: Close VIs in the Windows context that are shared with the LabVIEW Real-Time target.
|
|||||
Document last updated on 8/03/2012
Known Issues by Date
The following items are known issues in the LabVIEW 2012 Real-Time Module sorted by Date.
| ID | Known Issue | |||||
|---|---|---|---|---|---|---|
| 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.
|
|||||
| 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.
|
|||||
| 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
|
|||||
| 298990 Return |
Clear Errors VI is Not Reentrant If the Clear Errors VI is used in parallel loops on LabVIEW Real-Time, you introduce a shared resource. This will affect the code's determinisms 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.
|
|||||
| 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)
|
|||||
| 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.
|
|||||
| 345803 Return |
VIs or controls that use library items in community scope fail to download on VxWorks targets VIs or controls that use library items in community scope fail to download on VxWorks targets. They also do not work in built applications on these targets. Workaround: Change "community scope" vis in lvlibs and lvclasses to "public scope". Consider renaming these vis in a way that indicates they should not be used by external clients (i.e., rename "method.vi" to "__method.vi"). You might also restructure your class relationships to use a different access restriction policy.
|
|||||
| 346430 Return |
High CPU usage when setting date and time on certain CompactRIO controllers 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 at the beginning of the Real-Time application and wait for the CPU to return to normal levels before executing the rest of the application.
|
|||||
| 358016 Return |
Cannot connect to debuggable executable when Wait on IRQ Timed Out is wired to case structure selector When connecting to a debuggable executable on a cRIO that is using the Wait on IRQ method to sync with an FPGA VI, if the "Wait on IRQ" "Timed Out" terminal is wired to a case structure that passes through the FPGA reference, the connection will fail with error message "Failed to connect to remote application". Workaround: Put an "Or" or other boolean logic in between the "Timed Out" terminal and the case structure.
|
|||||
| 358920 Return |
Deployment of Real-Time VIs Slower in LabVIEW 2012 The first deployment of Real-Time VIs to the Real-Time target may be slower in LabVIEW 2012 than in LabVIEW 2011 and 2010. This slow down will only occur if the VIs or subVIs being deployed are also in memory in the Windows context during deployment. The slow down will not be seen on subsequent deployments if no changes are made to the VIs that would require it to be reloaded in to memory. Workaround: Close VIs in the Windows context that are shared with the LabVIEW Real-Time target.
|
|||||
| 360665 Return |
Memory Leak When Calling "String to IP" on a Dual NIC PharLap Real-Time Targets On dual Ethernet port PharLap Real-Time targets, every call to "String to IP" will leak 30 bytes of memory. This does not affect VxWorks targets or single NIC PharLap targets. Workaround: Limit the calls to "String to IP".
|
Document last updated on 8/03/2012
Reader Comments | Submit a comment »
Legal
This tutorial (this "tutorial") was developed by National Instruments ("NI"). Although technical support of this tutorial may be made available by National Instruments, the content in this tutorial may not be completely tested and verified, and NI does not guarantee its quality in any way or that NI will continue to support this content with each new revision of related products and drivers. THIS TUTORIAL IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND AND SUBJECT TO CERTAIN RESTRICTIONS AS MORE SPECIFICALLY SET FORTH IN NI.COM'S TERMS OF USE (http://ni.com/legal/termsofuse/unitedstates/us/).