Academic Company Events Community Support Solutions Products & Services Contact NI MyNI
1 ratings:
 3 out of 5     Rate this Document

Frequently Asked Questions (FAQ) for the NI Real-Time Hypervisor



Primary Software:
Primary Software Version: 2009
Primary Software Fixed Version: N/A
Secondary Software: N/A

Problem:
Note that 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 KnowledgeBase 5KHF6UOE: NI Real-Time Hypervisor Known Issues.

The Booting Process
Troubleshooting Network Connections
Real-Time OS Environment
The PXI Platform
Recovering the System

Solution:
The Booting Process
  1. Why do I not see any Real-Time boot information from Hyperterminal?
    • 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.

  2. How can I see more boot information from Real-Time in Hyperterminal?
    • 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.

  3. Why can't I boot directly into LabVIEW Real-Time after using Real-Time Hypervisor?

Troubleshooting Network Connections
  1. Why can I not see my IP Address in hyperterminal from the virtual COM4?
    • 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.

  2. Why can I not see the Real-Time target from MAX when booting into the Real-Time Hypervisor?
    • 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.

  3. If the Real-Time OS has a physical and virtual ethernet port, which is used as the primary?
    • 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.

Real-Time OS Environment
  1. Why is File I/O slower from the Real-Time OS?
    • 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.

  2. What happens to the Real-Time OS if Windows crashes?
    • 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.

  3. Why do I have to assign a device to a specific operating system?
    • 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.

  4. Can I assign the number of processor cores allocated to Windows XP and LabVIEW Real-Time?
    • 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.

  5. Why does Windows have only one CPU when I boot into Windows?
    • 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 How to Troubleshoot Windows 2000 Hardware Abstratction Layer Issues

  6. How much RAM does a Real-Time Hypervisor system support?
    • 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.

  7. Can I use the NI-Watchdog timer on the Real-Time OS?
    • 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.

The PXI Platform
  1. Is PXI triggering supported?

  2. Is PXIe supported?
    • Real-Time Hypervisor 1.0 does not support PXIe.
    • Real-Time Hypervisor 2.0 supports PXIe-8108 and PXIe-8133.
    • Real-Time Hypervisor 3.0 adds support for the PXIe-8135.

  3. What happens if I have a PXI devices that requires more than one slot?
    • 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.

  4. How do I set a PXI device to a specific slot in the Real-Time Hypervisor Manager?
    • The Advanced tab allows users to manually configure PXI device OS partitioning and slot location.

  5. Why is the Real-Time Hypervisor Manager asking my to change the slot positioning of my PXI devices?
    • Refer to the NI Real-Time Hypervisor Manager section of the NI Real-Time Hypervisor Help for more details on slot positioning.

  6. Can I use the serial ports on my PXI controller in Hypervisor Mode?
    • Yes, you can use the serial port in Hypervisor Mode.
    • With Real-Time Hypervisor 1.0 and 2.0 the serial port must be accessed at a baud rate of 9600.
    • As of Real-Time Hypervisor 2.1, the serial port can be assigned to either OS and be used at any baud rate.

  7. Can I use MXI?

Recovering the System
  1. How do I format my Real-Time system?
    • 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.
      1. Create a Utility USB Key in MAX. Boot from the USB key and choose the Format option. Follow the prompts to complete the formatting process.
      2. Boot the controller into Windows, format the FAT32 partition (typically the drive D: labeled "LABVIEW_RT") by following the steps provided in How to use Disk Management to configure basic disks in Windows XP then reboot into Real-Time Hypervisor. National Instruments is actively investigating remote formatting for Real-Time Hypervisor targets.
    • If you have Hypervisor 3.0 and the Real-Time system is using a virtual disk image.
      1. Boot the controller into Windows only, open the Real-Time Hypervisor Manager, switch to the advanced tab, open the disk image configuration option and create a new disk image file.

  2. How do I recover my Real-Time Hypervisor system?


Related Links:
KnowledgeBase 5EBG1VH1: NI Real-Time Hypervisor Support For MXI and MXIe Configurations
KnowledgeBase 667CEAP7: Viewing the RT Console Using the NI Real-Time Hypervisor Virtual COM Port
KnowledgeBase 50DF9GJ4:  Booting into LabVIEW Real-Time Only After Using NI Real-Time Hypervisor
Developer Zone Tutorial: Manual Installation of an NI Real-Time Hypervisor System
KnowledgeBase 4Y8CEGL3: Basic NI Real-Time Hypervisor Trigger Routing
KnowledgeBase 4ZUC5K0S: Advanced PXI Trigger in NI Real-Time Hypervisor
KnowledgeBase 4X6F33DO: What Hardware is Supported by NI Real-Time Hypervisor?
KnowledgeBase 5KHF6UOE: NI Real-Time Hypervisor Known Issues
How to use disk management to configure basic disks in Windows XP 
How to Troubleshoot Windows 2000 Hardware Abstraction Layer Issues

Attachments:





Report Date: 06/16/2009
Last Updated: 06/21/2013
Document ID: 4YFEI84I

Your Feedback! poor Poor  |  Excellent excellent   Yes No
 Document Quality? 
 Answered Your Question? 
  1 2 3 4 5
Please Contact NI for all product and support inquiries.submit