Original Code
          Consulting Original Code Consulting

OCC Home Page  LabVIEW
              Programs for Download  Products  MICAS-X  LabVIEW related
              publications  LabVIEW Presentations

Recommendations for Setting up a Windows Data Acquisition Computer

February 15, 2015

    This page is intended to serve as a resource for myself, my clients, and the community when someone needs to configure a Windows OS computer as a dedicated data acquisition system.  Obviously, not all of these recommendations apply to every situation, and in fact these recommendations are generally tuned to my own experience and my clients needs as of the date noted above.  In addition, these are only recommendations, and Original Code Consulting accepts no responsibility for any consequences of their application by a third party not related to OCC.  It is also recognized that many additional recommendations could be suggested from others with experience in this area, and those suggests are welcome.  Please send any such suggestions to support@originalcode.com.
    When a recommendation is followed by two-letter abbreviations in bold, that indicates that that point is a requirement for installing LabVIEW software I have provided to specific clients.  Any such client will have been notified of their abbreviation in a separate communication.  Note, however, that  MX  refers to data acquisition systems using MICAS-X, and are therefore relevant to anyone who is using that program.

LabVIEW Installation


  • To allow the Shared Variables through Windows Firewall:


OS Setup


Updating Policy

    It is critical that no one update the data acquisition computers’ OS or NI software without ensuring that they are following prescribed guidelines.  Applying any update before it has been vetted can result in failure of the system to operate correctly.  Applying an update without synchronizing with the entire group can create massive maintenance issues.  JG VG UF

Network and Routing setup (Shared Variables/Dual Network solution)

There has been an ongoing issue where machines that use both network adapters (wired and wireless) have difficulty with LabVIEW Shared Variables.  Generally the LabVIEW devices are all on the wired network, and the wireless network is used to connect to a wireless router with access to the Internet, or other required services.  There are a few things that can be done to resolve this issue.  

  1. In Microsoft’s great wisdom it was decided that wireless network adapters, when present, will be elected the “default” network adapter.  The following instructions will show you how to “promote” the wired network adapter to be the “default” adapter:

Start=> Run…=> ncpa.cpl (this is just a quick way to get to the Network Connections Adapter Setting page) => Press Alt-n-s (or Alt, then select Advanced menu->Advanced Settings…).   In the “Connections” box on the “Adapters and Bindings” tab Move the “Local Area Connection” to the top of the list by highlighting it and using the up arrow buttons on the right of the window. I also suggest moving any VPN connection just below the top item followed by the “Wireless Network Connection” that corresponds to the actual Wireless network card, followed by any“virtual” wireless connections (“Wireless Network Adpater X” which are labeled as Microsoft Virtual WiFi Miniport Adapters when viewed in the “Network Connections” window).  Remote Access Connections and any other connections should come last.  Click the “OK” button.

  1. If there is an “Instrument” network that is not connected to the internet (or another network via a router), the DEFAULT GATEWAY should NOT be set.  I also recommend removing or disabling the TCP/IPv6 protocol for all adapters that don’t need it. The following will only work if the computer is configured with a static IP address:

Start=> Run…=> ncpa.cp l=> right click on the wired network adapter (LabVIEW devices, not internet connected) => Properties => uncheck “Internet Protocol Version 6 (TCP/IPv6)”.  Highlight “Internet Protocol Versoin 4 (TCP/IPv4) with the mouse and press the “Properties” button => under “Use the following IP address:” Delete all numbers in the “Default gateway:” box. Press OK to close the IPv4 Properties, and OK again to close the Properties window.

  1. Here we will manually override the network “Cost” (i.e. METRIC) of all active network adapters to help prioritize the computer’s routing table for the wired network adapter.  Should any conflict arise, this may help keep LabVIEW traffic flowing over the wired network.  For each active network adapter, follow the instructions below to manually override the Connection’s Metric.  I suggest the following settings:

Wired “Local Area Network” connection(LabVIEW) : Metric 10

Bluetooth Adapter (if present): 1500

Wireless Network Adapter Connection (i.e. the actual wireless card): 2000

Any other active connections, just increment from the Wireless Network by 500...

To get to these settings:

Start => ncpa.cpl => right click on the connection => Properties => select TCP/IPv4 protocl => Properties => Advanced… => uncheck “Automatic metric” => enter the appropriate value (see above).  click OK to close the “Advanced TCP/IP settings,” OK to close the “TCP/IPv4 Properties,” and OK again to close “XXX Connection Properties” windows.

  1. Setting permanent static routes.  I believe this step is not necessary, and I recommend only trying this after implementing 1-3 above if you are still having issues with shared variables.  Setting permanent static routes could lead to confusion down the line if a computer is repurposed for another task using different network settings and someone doesn’t remember to delete the static routes.

Start => All Programs => Accessories => right click on “Command Prompt” and select run as Administrator.  Click Yes to allow UAC to run the program with Administrative privileges.  This example assumes that the wired network connection uses a statically assigned network address of, and that using the command shown in 5 below you determine that the wired ethernet adapter is interface 11:

route add -p mask  metric 10 IF 11

The “-p” makes this a persistent route that survives a reboot.  You can test a route add statement without the -p.  If it causes problems, rebooting or shutting off and restarting the computer should clear that route.  If you want to remove the persistent rout entered above you could use the following command:

route delete

  1. netstat -rn - A useful command prompt command to look at the routing table, and to determine the interface number for a particular adapter.

Windows 10 Issues

    Windows Updates

    Among other changes, Windows 10 has locked down the options for how Windows Updates are installed. Without going in to more advanced settings, one cannot prevent the computer from rebooting on its own after an update. One way to prevent this in Windows 10 is as follows:
    1. Search for Group Policy in the Control Panel. This should launch the Local Group Policy Editor.
    2. Under Administrative Templates, expand Windows Components. Then click on Windows Update.
    3. In the left pane, double click on Configure Automatic Updates. This opens another dialog box.
    4. Select Enabled near the top.
    5. Select "3 - Auto download and notify for install" or whichever option is most appropriate for your system in the lower left.
    6. Click on OK.
    7. These changes will not take effect until the system checks for Windows Updates once. To force this check, search for Windows Update in the Control Panel, then press the "Check for updates" button.
    If the above configuration is used, updates will be downloaded to the computer in the background, but only installed when the operator chooses. For some systems, it may be better to prevent updates from being downloaded completely. Note that with this tweak, the OS will still enforce a reboot within a few days after you allow it to install an update.

    To prevent the OS from ever rebooting the computer when a user is logged in, launch gpedit.msc from a cmd window. Navigate to Computer Configuration/Administrative Templates/Windows Components/Windows Update. Double click on "No auto-restart with logged on users for scheduled automatic updates installations". Enable it and click apply. This can done by editing the registry using Regedit and making the key "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" NoAutoRebootWithLoggedOnUsers (DWORD) have a value of 1.
    For Home edition, it is not possible to edit Group Policies. This link has information on another way to prevent Windows from rebooting itself.
    Even after the above edits, it Windows will still try to push certain updates. Once they have been received, it will eventually force a reboot. The only way to prevent this type of forced reboot is to prevent the forced updates from being installed. This link has information on how to do that.

OCC Home Page LabVIEW Programs
            for Download  MICAS-X  LabVIEW related
            publications  LabVIEW Presentations  BotLabs Web Page - home of the Saurobots!  Links
Please report any bad links, other problems, or comments to: 

Site Map and Downloads