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.
Note: This document addresses frequently asked capability, setup, and configuration questions for NI Real-Time Hypervisor systems. For a summary of known issues with Real-Time Hypervisor software, visit NI Real-Time Hypervisor Known Issues.
The virtual COM port in Real-Time Hypervisor requires user input to initiate the connection. If there is no data read from the COM port, press any key on the keyboard to confirm the connection is established. If the "Wait for virtual console on boot" option is not set in the Real-Time Hypervisor, the target may be fully booted by the time the connection is established. For instructions on enabling the "Wait for virtual console on boot" option, see "The Booting Process" number II.
By default, booting into the Real-Time Hypervisor loads both Windows and LabVIEW Real-Time. To delay the LabVIEW Real-Time OS, boot into Windows, open the Real-Time Hypervisor Manager, select Tools»Options, and check the "Wait for virtual console on boot" option. Restart the system, boot into Real-Time Hypervisor, and open a Hyperterminal connection to COM4. The message "Waiting for console input to continue the boot process. Press any key to continue..." should be printed once per second until any key is pressed. At this time, the LabVIEW Real-Time OS will boot with full boot output.
If the "Wait for virtual console on boot" option is not set in the Real-Time Hypervisor Manager, the resulting data printed to screen may not resemble the expected PXI boot output. This is because the Real-Time side begins booting in parallel with the Windows boot and the output will be the end of the boot process. For instructions on enabling the "Wait for virtual console on boot" option, see "The Booting Process" number II.
There are many configurations which can result in a target that cannot be discovered. Review the Configuring Network Connections for a Hypervisor System in the Transferring Data Between Windows and the RT Target section of the NI Real-Time Hypervisor Help for configuration details.
By default, the virtual ethernet port is the primary network interface. To change network configurations, open MAX, select the Real-Time Hypervisor target in the Configuration tree, and select the Advanced Ethernet Settings button on the Network Settings tab.
The controller hard drive is owned by Windows, but the Real-Time Hypervisor allows the Real-Time OS read and write access to the disk. This additional access path adds overhead to the read and write process, slowing file I/O operations.
The controller hard drive is owned by Windows, so a Windows crash prevents the Real-Time OS from accessing the hard drive. Any program running at the time of the crash will continue running but return errors when accessing the hard drive. National Instruments recommends monitoring disk access in real-time code and safely shutting down the real-time application if a Windows failure occurs.
PXI devices are partitioned to improve performance and maintain the determinism of the Real-Time OS. Shared or hosted devices compromise determinism and exhibit decreased performance due to resource management issues.
With Real-Time Hypervisor 1.0, the Real-Time Hypervisor Manager statically assigns the first processor core to Windows and the remaining cores to LabVIEW Real-Time. With Real-Time Hypervisor 2.0, each processor core can be assigned to either operating system with the Real-Time Hypervisor Manager.
With Real-Time Hypervisor 1.0, Windows operates in Standard Mode, which does not support multiple processors or multiple cores. However with Real-Time Hypervisor 2.0, Windows can be configured to use multiple processors or multiple cores. Use the Real-Time Hypervisor Manager to configure which CPU cores are assigned to each operating system.
NOTE: Microsoft does not recommend switching between ACPI (mulit-core enabled) and Standard hardware abstraction layer modes. For more information please review Microsoft's HAL options after Windows XP or Windows Server 2003 Setup.
For Real-Time Hypervisor 1.0, there is a minimum requirement of 1 GB of RAM with a maximum of 2 GB. Using more than 2 GB of RAM on a Real-Time Hypervisor 1.0 system can cause the system to crash unexpectedly or not allow the Real-Time operating system to boot.
For Real-Time Hypervisor 2.0 and later, there is a minimum requirement of 1 GB of RAM with a maximum of 4 GB.
As of Real-Time Hypervisor 2.0, there is no way to assign the NI-Watchdog timer to any OS. Therefore, watchdog timer functionality defaults to Windows and is unavailable to the Real-Time OS.
Most multi-slot devices use only one trigger. The Real-Time Hypervisor Manager assumed all PXI devices use one slot and will incorrectly auto-configure the system to use slots taken up by the multi-slot device. To avoid this conflict, use the Advanced tab to manually configure the Real-Time Hypervisor setup.
The Advanced tab allows users to manually configure PXI device OS partitioning and slot location.
Refer to the NI Real-Time Hypervisor Manager section of the NI Real-Time Hypervisor Help for more details on slot positioning.
No, MXI and MXIe are not officially supported in Real-Time Hypervisor.
Real-Time Hypervisor does not support remote formatting from MAX. There are different ways of reformatting the Real-Time partition depending on how your system is configured. If you have a physical partition that Real-Time is using then you have two options:
If you have Hypervisor 3.0 and the Real-Time system is using a virtual disk image: