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 192.168.1.50, and that using the command shown in 5 below you determine that the wired ethernet adapter is interface 11:

route add -p 192.168.1.0 mask 255.255.255.0  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 192.168.1.0

  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.


Recommendations for Operating a Windows Data Acquisition Computer


    Once a data acquisition system has been set up, there are several common-sense guidelines for how it should be maintained and operated. Two cases are described here. The first, which is less common, applies to systems that are not connected to the internet. The second applies to data acquisition systems that are connected to the internet. The final section includes general recommendations relevant to both types of systems.


Network-Isolated Data Acquisition Systems

    If the data acquisition computer is not connected to the internet, it may be best to maintain a very static installation. Once the software is installed and tested, all updating mechanisms should be turned off. This includes LabVIEW, Windows Updates, anti-virus, and any other installed programs that may have automatic updating mechanisms. (Since the computer is not on the internet, these updating mechanisms will not normally be able to automatically engage themselves, but turning them off adds an extra layer of protection in case the network is ever connected, even briefly.) For this type of system, it is often possible to disable or uninstall antivirus programs, firewalls, and other anti-malware programs. It can also be useful to uninstall other programs that may have been pre-installed on the computer by the manufacturer. Once the system has been completely configured this way, it is a good idea to create a disk image or backup of the system, which can later be used to recreate the known-good configuration if the hard disk should fail.


Network-Connected Data Acquisition Systems
    When a data acquisition computer is connected to the internet, it is generally a good idea to leave firewalls, anti-virus, and automatic operating system updates turned on, to help ensure that the computer remains secure as threats evolve. It is possible, though generally unlikely, that updates to these services will adversely effect the data acquisition system, but that risk is generally less than the risk posed by malware. It is still recommended that automatic updates to NI software and LabVIEW be turned off. NI software updates are generally trouble-free, and sometimes include security patches. But on a data acquisition computer, these updates should done intentionally by the computer administrator, after being carefully reviewed, not automatically.

    Any additional software installed on a data acquisition computer, especially anti-virus and anti-malware software, should be from reputable vendors and should have well-established reputations for robust operation. Some anti-virus programs in particular can be intrusive and cause issues with data acquisition performance. OCC tends to use the anti-virus programs built into Windows 7 and Windows 10. Although those programs are not always rated as highly as others in providing protection from all viruses, they are generally rated fairly high, and they have been found to be non-intrusive and to not adversely affect most data acquisition applications.

All Data Acquisition Systems
    In the ideal situation, a data acquisition computer will be used only for its dedicated data acquisition purpose. In this case, no software not required for the data acquisition system should be installed on the computer, and no other programs should be run on the computer. In reality, there are often cases where a computer must serve more than one purpose. In these cases, all software to be installed on the data acquisition computer should be reviewed carefully to ensure that it really is necessary. It is always best to limit the number of programs and drivers installed, to reduce the chances of incompatible software impairing the data acquisition functionality. In addition, when other programs ARE installed on a data acquisition computer, it is highly recommended that none of them are run and used in parallel with the data acquisition program. Although it is common to see web browsers and Excel run while a data acquisition program is also running, and often this can be done with no adverse effects, it is still advised to avoid this practice whenever possible.
    Disk defragmenting seems to be much less needed on modern computers than it was some years ago. OCC generally does not recommend using disk defragmenting programs.
    Backing up your data acquisition computer is always a good idea. Many options are available for automatic backup systems. Unfortunately, many of these programs suffer from a simple bug: when backing up files, they appear to require read/write access to the files, rather than read-only access, which seems like it should be sufficient. When these programs attempt to back up data files that are currently open in a data acquisition program, errors can result, either in the backup or in the data acquisition program. It is therefore highly recommended that automatic backups be configured in such a way as to only back up data files that have been closed. For example, on a system which runs continuously 24/7, it may be useful to put data files in a date-stamped folder structure with a new folder started each day. The backup program can then be instructed to only back up folders that are at least one day old.

   


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