Developing Networked Data Acquisition Systems with NI-DAQ

Application Note 116 Developing Networked Data Acquisition Systems with NI-DAQ Tim Hayles What Is Remote Device Access? With the NI-DAQ Remote Device Access (RDA ) feature, you can run LabVIEW or LabWindows /CVI programs that access and control National Instruments data acquisition devices located in other computers on your network. Programs written in LabVIEW or in the CVI Easy I/O library need no modifications to use this feature. Access to remote devices is transparent to your program. There is nothing new to learn. Take advantage of your existing network infrastructure and your existing programming investment to install a remote data acquisition system. RDA works on every product controlled by NI-DAQ for Windows. The term RDA Client refers to the computer in front of you. This computer must be running a LabVIEW or CVI Easy I/O application and have NI-DAQ 6.0 or later installed. It does not need to have any DAQ hardware installed. The term RDA Server refers to the computer elsewhere on the network. This computer must have NI-DAQ 6.0 or later and some DAQ hardware installed. It does not need any application software installed. What Can I Do with RDA? Basically, you can do anything with a DAQ board installed in an RDA Server elsewhere on your network that you can do with it installed in the computer in front of you. If you have written the DAQ portion of your application in LabVIEW or in the CVI Easy I/O Library, that application will work remotely over the network immediately after installing NI-DAQ. You can take snapshots of data remotely and analyze and display the data locally. You can easily collect data from two or more remote computers for analysis and display on a single local computer. You can send analog and digital data to your remote computer(s) for purposes of remote control. RDA works with the Internet. However, sometimes you encounter firewalls that won t let you connect. If you don t have an existing network to plug into, you can easily create your own local network. See the section below entitled Creating Your Own Local Network for details. Transfer rates across the network via RDA may surprise you. During testing, we have routinely run the Cont Acq&Chart (buffered).vi at 100,000 scans/s, scanning a single channel. Ordinarily this is not cause for celebration. However, when the VI is running on one computer and the MIO board is in another computer and both machines are using an ordinary network connection for communication, it is! Your own maximum transfer rates will depend on the speed of your network and amount of traffic on it, as well as the speed of the computers used. Product and company names are trademarks or trade names of their respective companies. 341452A-01 Copyright 1998 National Instruments Corporation. All rights reserved. March 1998

We have acquired data from an RDA Server in Austin using RDA Clients from as far away as Japan and Australia. It took about three seconds from the click of the LabVIEW Run arrow for the 1000 data points acquired in Austin to appear on the computer in Japan. The time to actually acquire the data in Austin was about 10 ms. A single RDA Client can access remote devices in several RDA servers. You are able to monitor conditions at many places from a single computer. The RDA Client can use a local DAQ board as well. A remote device in an RDA server can be used by several RDA clients. There are some considerations to keep in mind, however. For example, if client A configures Analog Input Channel 3 in group 0, and client B configures Analog Input Channel 5 on the same remote device and also using group 0, the readings taken by client A will be from channel 5 and not channel 3. Both clients will be passing the same taskid to the server. If both clients are reading from the same channel using immediate I/O, things will work fine. Buffered I/O is more of a problem for multiple accesses because of its asynchronous nature. If client B calls AI Group Config on the remote device after client A has called AI Control to start its acquisition, the client A acquisition will be halted. Ordinarily, the NI-DAQ per-process state tables would prevent this sort of interference. However, every call to NI-DAQ on the server comes from the same process, the NI-DAQ RDA Server executable. So, even though the different calls may originate from different computers, they all look as though they are coming from the same place to NI-DAQ installed on the RDA server. Here is one scenario that takes advantage of this behavior. If you start a continuous acquisition on an RDA server from a client using group number 0 in the call to AI Group Config, then any number of clients can call AI Buffer Read to read data from the server. They need only to use the device number (whichever local device number they have assigned on that client to the remote device on the server) in the calls. The clients must account for the fact that NI-DAQ on the server is maintaining only one read pointer for the acquisition buffer. Unless the clients work around this, each read will advance the read pointer on the server computer and the reads will not begin where a client believes they should. To work around this situation, each client needs only to remember the value of the read mark scan in the mark locations cluster in the AI Buffer Read vi after its call. Then, with each subsequent call, each client will reposition the read mark there again by setting the read/search mode to relative to start of buffer and the read/search offset to the desired position. Both of these controls are in the read/search location cluster of AI Buffer Read vi. How Does It Work? RDA extends the NI-DAQ model across the network. Upon receiving a call from LabVIEW or the CVI Easy I/O Library, one of the first things NI-DAQ does is to check the device number and decide which family of products this device belongs to. We have added remote devices as another product family. Any National Instruments DAQ product can belong to the remote family. When NI-DAQ sees that the device is remote, the call is packaged up and sent via Remote Procedure Calls (RPC) (see Technical Background section) to the remote computer. There, the RDA Server application receives the call, unpackages it and sends it to NI-DAQ, this time on the remote computer. To NI-DAQ on the remote computer, the call is a normal NI-DAQ call. The device number used on the remote computer is the actual device number of the board. When NI-DAQ checks the device number on the remote computer to see which family of products it belongs to, it does not come up with the answer remote device. Rather, it sees that this is a PCI-MIO device, or a USB device, etc. The call then executes normally on the remote computer. When it is finished, the results are sent back to the client computer and back to LabVIEW or CVI. This process is totally transparent to you! How Do I Use It? If you have a TCP/IP based network already at your facility you are ready to go. Just follow these instructions. If not, then skip to the section entitled Creating Your Own Local Network and then come back here. You must designate one or more computers, running Windows 95 or Windows NT 4.0, as NI-DAQ RDA Servers. These computers must be connected to a network using the TCP\IP protocol. You must know either the name or the IP address of these computers. 2

Follow these steps to turn an ordinary computer into an NI-DAQ RDA Server. 1. Install NI-DAQ. 2. Install and configure your data acquisition devices. 3. Make sure your devices are working properly by testing their resources with the Test Panels. 4. Launch the NI-DAQ RDA Server Utility. A shortcut to this utility is in your Start menu under the NI-DAQ for Windows selection. If you want this computer to become an RDA server every time it starts up, place a shortcut to the NI-DAQ RDA Server Utility in your Startup folder. There is no interface to interact with. The window will say only that the RDA Server is in operation. Next, you must designate one or more computers, running Windows 95 or Windows NT 4.0, as NI-DAQ RDA Clients. These computers also must be connected to a network using TCP\IP protocol. Follow these steps to turn an ordinary computer into an NI-DAQ RDA Client. 1. Install either LabVIEW or LabWindows/CVI. 2. Install NI-DAQ. 3. Start the NI-DAQ RDA Configuration Utility. A shortcut to this utility is in your Start menu under the NI-DAQ for Windows selection. Note: Beginning with NI-DAQ 6.1, the RDA Configuration Utility will not exist as a stand-alone executable. Instead, it has become another tab in the NI-DAQ Configuration Utility tabbed dialog interface. So, if you have NI-DAQ 6.1 or newer, launch the NI-DAQ Configuration Utility and select the tab marked RDA Devices. 4. Locate the computer that you have turned into an RDA Server using either of the following steps: If you know the name or the IP address of the RDA Server computer, simply enter it into the Remote Name/IP Address field of the RDA Configuration Utility and click on the Connect button. Use the network tree interface at the left of the utility to explore your network (or click the Browse button if you are using NI-DAQ 6.1 or newer). Click on the Network label to reveal your network names and continue clicking to find your domain names and computer names. When you find the name of the computer you need, highlight it by clicking once on its name. The name will appear in the Remote Name/IP Address field. Now, click on the Connect button. Or, if you already know the computer name, just type it in and connect. If you also know the domain name, you can append it to the computer name as well (example: mycomputer.natinst.com). 5. Once you have connected to your RDA server, a list of remote devices installed on that server appears in the box on the lower right of the utility. Select one of these devices by clicking once on its listing (you must click on the entry in the Remote Device # column) and then click on the Assign button. A dialog box will appear with a list of possible local device numbers. Select one of these and click on OK. Then click on Exit and you are done. The local device number you have chosen will be the one you will use in your local programs. 6. If you wish to connect to a different computer, click on the Disconnect button (instead of Exit) and follow step 4 to connect tor another computer. Once you have finished these steps you are ready to go. You can write an application that uses a single remote device, multiple remote devices on a single remote computer, multiple remote devices on multiple remote computers, or all of the above plus devices in your local computer. All of the DAQ or Easy I/O Library example programs will work with RDA. If you wish to undo your local device number assignment to a remote device, first start the RDA Configuration Utility. Disconnect from the remote computer to which you are connected. The box on the lower right lists the remote devices currently configured on your RDA client when the RDA Configuration Utility is not connected to an RDA Server. Highlight the device you want to undo and click on the Delete button. 3

Creating Your Own Local Network What if you do not have an Internet connection or some kind of local area network already in your building? Well, you can rather easily network two or more computers directly to form your own local area network. First, you need to buy plug-in network adapter cards for each computer. There are many vendors who make reliable network adapter cards. Some PCs even have these adapters built into the motherboard. Ethernet adapters come with various types of connectors twisted-pair (looks like big modular phone jacks), coaxial, or AUI (looks like serial port). All these types will work with RDA, but this note covers only twisted-pair wiring. If you are connecting only two computers (just one RDA server and one RDA client), you can get by with connecting the computers to each other directly with a special crossover cable. You can purchase such a cable for about $15 at a computer store. The pinouts on each end do not match, similar to a null-modem cable. These cables are terminated with RJ-45 jacks. They are identical to normal twisted pair 10Base-T cables except for the different pinouts at either end. You can build such a cable yourself if you follow this wiring: pin 1 3, 2 6, 3 1, 6 2. Some 100 Mbp (100Base-T) networks do not work with crossover cables. If you are connecting more than two computers, or you want the option of expanding in the future, you will need to buy a hub. Reliable hubs are available from many vendors. A hub typically has four to 16 ports (sometimes even more). With a 4-port hub, you can connect four computers together. Maximum length for 10Base-T connections is 100 m from hub to PC. That makes 200 m safe between two PCs. Cables come with different ratings. Consider using Category 5 cables, which are commonly available and not much more expensive than cables with inferior ratings. 100Base-T Ethernets (Fast Ethernets) are becoming common. These networks transfer data at 100 Mbps instead of 10 Mbps, but they require 100Base-T hubs. Because your computers are not on the network, you will have to assign them IP addresses. Go to the Control Panel, open the Network applet and double-click on the TCP/IP entry. If you do not see the TCP/IP entry, you will need to add that protocol using the Windows 95 CD. Select Specify an IP address and enter something like the following: IP Address: 11.11.11.22 Subnet mask: 255.0.0.0 Because your computers are not part of a larger network, you can assign any IP address you want. However, there are some IP Addresses and Submasks that are special. Implications of certain special IP Addresses and Subnet masks are beyond the scope of this article. So if you do not have any reason to set these addresses to something else, save yourself some headaches and use these suggested numbers. Now reboot both your client and server computers. The first three addresses of your client and server should have the same numbers (11.11.11 in this example). Afterwards, you should be able to connect to your RDA server by entering its IP address into the RDA Configuration dialog on the client. For an independent way to test the TCP/IP connection you have just made, use the ping command. Type ping 11.11.11.22 where 11.11.11.22 is the IP of the other computer. If you receive four replies of 32 bytes each from your other computer, the connection is good. SCXI Considerations The RDA configuration utility will show you which DAQ products that have device numbers on your RDA servers. Once you assign a local device number you no longer need to know what the actual device number is on the remote machine. However, the RDA configuration utility will not tell you anything about any SCXI products configured on your RDA server. 4

When you want to use SCXI equipment on a remote computer via RDA from a local computer, you will have to use the exact chassis IDs and module slot numbers that are assigned to the SCXI products on the remote computer. For example, lets say you have an SCXI-1100 in module slot 3 in an SCXI-1000 chassis with chassis ID 2 connected to a PCI-MIO card with device number 1 on a remote computer. Running the RDA configuration utility on the client computer you assign the remote PCI-MIO card a local device number of 10. Then you run Acquire N Scans. You enter your device number of 10. The channel string you enter must be sc2!md3!ch0. Thus, you must remember your SCXI configurations on your RDA servers when you use SCXI in a program on an RDA client. There is a special consideration when using any of the SCXI-116x digital modules via RDA. The taskid produced by the DIO Port Config.vi for an SCXI-116x module does not have the local device number embedded in it. In place of the device number, NI-DAQ places the SCXI chassis ID number. We made this change when we eliminated the limit of 16 SCXI-116x devices that are usable at one time. NI-DAQ uses the SCXI chassis ID to look up the local device number. So, if you have more than one server that has an SCXI chassis containing SCXI-116x modules, you must assign unique chassis IDs to all of them. Because there are more than 32,000 chassis IDs to go around, this should not be a problem. Channel Wizard Considerations To use the Channel Wizard in an RDA application you must remember to follow two rules. 1. Run the Channel Wizard on the RDA server (not the RDA client). 2. When you use the named channels in your application on your RDA client, you must also supply the local device number of the device on the RDA server. Let s say you have a PCI-MIO on your server. You configure a named channel on your server called channel 1. Next, you run the RDA config utility on your client. You assign a local device number of 10 to that PCI-MIO on your server. Now, you want to run Acquire N Scans and you want to use the named channel. To do so, just be sure to enter the local device number of 10 into the device control. Type in the named channel ( channel 1 ) into the channel string and run. The reason you must use the local device number even though you are using named channels is that the information needed by NI-DAQ to translate the named channel to a device number and a channel number exists only on the server. In order for NI-DAQ to realize the call is supposed to go to a server it must have access to the local device number. You cannot use the Channel Wizard on your client to configure named channels on a server because the Channel Wizard is unaware of any remote devices. What Are the Precautions? To use RDA, the computers must be running Windows 95 and/or Windows NT 4.0 (any combination will do) and the network protocol used must be TCP/IP. Although programs need no modifications to use RDA, there are four VIs that are not supported. The DAQ Occurrence Config vi is not supported, thus, if your program uses the messaging feature of NI-DAQ, it will not work properly when run on a remote device. Get SCXI Information, SCXI Cal Constants, and Set SCXI Information are also not supported. If your program uses one of these it may not work properly when run on remote devices. However, acquisition and control with SCXI products is fully compatible with RDA along with all other PCI, PXI, PCMCIA, USB, ISA, VXI, and parallel port products. NI-DAQ does not attempt to connect to the RDA server computer until you first use the remote device in a program running on your client. When the connection fails, any attempt to use the remote device will result in a -10401 (unknowndeviceterror) status code. If the initial attempt at making a connection succeeds but the connection disappears at a later time (if the RDA server program is terminated for example), any attempt to use the remote device while the connection is gone will produce the -10340 error. 5

It s important to remember that your RDA Server computer (the remote computer) is a slave to your client computer. It can do nothing on its own without responding to a request from the RDA client computer. Technical Background RDA uses Remote Procedure Calls, also known as RPC. Microsoft s implementation of RPC is based on the Open Software Foundation s definition as part of their Distributed Computing Environment (DCE). RPC is designed to be both operating system and hardware independent. Although RPC works with all popular protocols TCP/IP, NetBEUI, IPX/SPX, Named Pipe and Windows Sockets RDA currently works with TCP/IP only.