LabView Advanced Programming Techniques, SECOND EDITION ch7

299 7 Shared Variable This chapter discusses the shared variable concept released in LabVIEW 8. The shared variable is a standard feature for the language that provides a service for distributed data throughout LabVIEW. The Data logging and Supervisory Control module extends the level of functionality. Shared variables are available for use on any operating system and real time (RT) targets. The shared variable engine itself requires a Windows installation or an RT target. This chapter is devoted to a discussion of the shared variable and includes a discussion of the shared variable engine and communications employed to distribute data. On the surface, it may seem questionable to devote an entire chapter to a distributed data system. As this chapter progresses, it will become clear that the shared variable is not a simple service. 7.1 OVERVIEW OF SHARED VARIABLES Shared variables are primarily a mechanism for distributed networking support. In general, distributed applications have processes that perform specific tasks with information that needs to be shared with other elements of the application. The shared variable provides a mechanism to the LabVIEW programmer that abstracts away the complexities of distributed programming. Distributed applications do not make life easier on the developer as they add-in a number of exception cases that need to be considered. For example, how does the application know if messages were lost, what if messages are late, the data is old, or what if it is necessary for IP networks to check that multiple copies of the same message have not been received? The shared variable engine absolves LabVIEW developers from the vast major- ity of these issues. From a development perspective, what we primarily need to be concerned about is dragging and dropping the correct shared variable. Networking issues are handled by the shared variable engine and the client. It is possible from a shared variable to determine if the information is “fresh” or if the variable has not been updated in awhile. Network security issues are also addressed in config- urable fashions through the shared variable engine and supporting NI security services. Distributed application development is roughly as complex as working with global variables. Adding shared variables to projects and basic information are provided in Chap- ter 1 and Chapter 2. This section expands on shared variable mechanics and the benefits and penalties for using them. © 2007 by Taylor & Francis Group, LLC 300 LabVIEW: Advanced Programming Techniques Shared variables support essentially every data type that can be found in Lab- VIEW. Pull-down selection menus in the shared variable configuration screen pro- vide what might be considered an incomplete list until you arrive at the last entry: custom control. Complex clusters can be configured as custom controls which, as stated, make the shared variable capable of supporting any data type that would be needed for distribution. 7.1.1 SINGLE-PROCESS VARIABLES When creating a shared variable, one of the configuration items is to determine if the variable is network-published or single process. Single-process shared variables do not sound so intuitive. What is the benefit of using a shared variable that is not shared? It would seem not of much benefit at all. Essentially, a single-process shared variable functions much like a global variable. In fact, there is a considerable amount of common code used between the shared single-process variable and the standard LabVIEW global variable. Any place a global variable is used, a single-process shared variable will also work — such as sharing data between two parallel loops. Using a single process shared variable does have two advantages: The first is the ability to network-publish the variable with a simple configuration change; going from a global variable to a network-published variable requires code rework. The second advantage is the ability to use the time-stamp functionality of the shared variable, which does not exist on the global variable. There is one significant disadvantage to using the shared variable in a single process. Performance benchmarking performed by National Instruments shows that the reading of a shared variable and global variable are roughly equivalent. The time required to write data to a shared variable, however, is more than for a global variable. The buffering feature of the shared variable can also be used to emulate the performance of a queue. Similar to replacement for a global variable, this is useful for RT targets and should be used in any queues that are expected to be distributed at a later time. One key difference between the single process variable and network-published variable is that historical data logging is not available to single-process variables. 7.1.2 NETWORK-PUBLISHED VARIABLE There are two supported formats for network-published variables. The shared vari- able configuration screen only allows the selection of a network-published variable. Data socket bindings are still supported and usable; however, new development should focus on the use of shared variables. Unlike single-process variables, network-published variables can be buffered. The nomenclature of buffering is somewhat misleading; the variable’s buffering functions as a FIFO queue. When using the queue, time-stamping data corresponds to when the particular copy was added into the queue. The use of the buffering feature needs to be carefully designed. All designs involving a queue have one exception case that must be considered: queue overflow. In the case of the shared variable, overflowing the queue is not allowed. Any writes to the queue when it is © 2007 by Taylor & Francis Group, LLC Shared Variable 301 full get silently discarded. LabVIEW does not receive an error notification that overflow errors are occurring. One disadvantage of a network-published variable, compared to its single-pro- cess counterpart, is the setting of initial values. Default values for published shared variables are not defined unless the DSC module is installed. When designing an application without the DSC module, a VI needs to step up and write data to that variable at system startup. Otherwise, the nodes subscribed to the variable will be receiving undefined data. 7.2 SHARED VARIABLE ENGINE Shared variables are published through the shared variable engine. The engine itself is available only on Windows-based machines or RT targets. On Windows, the engine runs as a service on the machine. As a service, there are a few items to the engine that are worth noting. Services do not require a user to be logged in. The service is running as a part of the operating system and is not tagged to a user in the task manager. This allows for the engine to run regardless of who is or is not actively logged into the machine. Unfortunately, services are not allowed to have their own user interfaces; external applications need to run to communicate with the service. 7.2.1 ACCESSING THE SHARED VARIABLE ENGINE As the shared variable engine is a service, it does not present a direct user interface. There are two ways for an administrator to access the engine: The first interface is through the shared variable manager. The manager is a NI provided application that permits configuration of the engine. The second is the Windows Event Viewer. As a service, the engine logs events to the operating system. The event viewer does not permit configuration of the engine but does allow an administrator to evaluate events the service is generating. 7.2.1.1 Shared Variable Manager The shared variable manager is shown in Figure 7.1. The manager will be the primary tool for accessing the engine as it gives the administrator the most control over the engine. The manager window consists of three frames which are (1) a list of items, (2) the watch list, and (3) the alarms window. The items list provides a listing of all shared variable libraries available on the system, including RT targets. Each library is listed as an independent process and can be stopped and started independently. This is a core feature on large distribution points which may have libraries for multiple applications running concurrently. From the variable manager you can add or remove libraries, assuming you have appropriate permissions. By default, LabVIEW installation sets the shared variable services to operate without security restrictions. In Section 7.7, it will be pointed out that leaving this configuration without security is, in general, not advisable. © 2007 by Taylor & Francis Group, LLC 302 LabVIEW: Advanced Programming Techniques The watch list pane allows for viewing the status of individual variables. Specific elements that can be seen in the watch list are the name of the variable, the current value, its type, the time stamp of last value change, and the quality. The variable manager allows for a user to add and configure variable libraries and variables without running LabVIEW. It also allows for libraries to be created from outside the context of a LabVIEW project. 7.2.1.2 Windows Event Viewer The second tool for accessing the health of the engine is the event viewer. From the Windows Control panel, access administrative tools. The events viewer shows system recorded events for applications, security, and the system. Engine events are recorded in the application window. An example of the application counter is shown in Figure 7.2. The events recorded are fairly generic in nature, but will give an administrator knowledge of when the service was started or stopped. 7.2.1.3 Windows Performance Monitor Another tool that can be used for monitoring the health or usage of the shared variable engine is the performance monitor. The performance monitor does not show directly items involving the shared variable engine but does provide some insights into how the engine and its host machine are performing. Section 7.4 discusses the networking aspects of shared variables, but for now one hint will be provided: the shared variable uses UDP as its transport protocol. The performance monitor is a Windows operating system tool that provides access to a large number of statistics about the health of the computer. Different elements of the operating system are broken up into “objects” such as the CPU, the hard drive, and networking statistics. One of value to us here FIGURE 7.1 FIGURE 7.2 © 2007 by Taylor & Francis Group, LLC Shared Variable 303 is the UDP performance. Figure 7.3 shows the performance monitor reporting on the volume of UDP traffic being processed by the computer. If a distributed appli- cation is experiencing problems, the performance tools can help identify what types of issues the networking may be experiencing. For example, if the error count is high, then there may be a problem with cabling or a switch in the network. As a reference, bit error rates on Ethernet are fairly low; on order of 1 in 1 million bits or less should be corrupted by a network. If you have hundreds of UDP messages per second arriving with errors, the problem probably exists in the network. The task manager’s performance tab would supplement the performance counters. If the packet rates are large, compare this with the task manager’s report of network utilization. A high utilization would suggest additional network capacity is needed. One counter configuration that may be useful in determining the health of a networked application is shown in Figure 7.4. The performance monitor is tracking counters for the IP object, TCP object, and UDP object. Each object is displaying the Send and Receive counters. If there is suspicion that the host machine is very busy on the network — for example, it is hosting a web server for VI control and the shared variable engine — it can be expected to show the TCP and UDP Send/Receive counters running large numbers. It should not be surprising that the IP counters will run even larger numbers; in fact, it should be approximately equal to the sum of the UDP and TCP counters as IP is the underlying protocol of both TCP and UDP. The reason why the IP counter would only be approximately equal FIGURE 7.3 FIGURE 7.4 © 2007 by Taylor & Francis Group, LLC 304 LabVIEW: Advanced Programming Techniques is because there is another commonly used protocol that also uses IP — ICMP. Ping messages and notification of message delivery failure are often sent through ICMP. It is possible for an administrator to monitor counts on multiple computers at once, so the counters shown above can be monitored for the shared variable engine and its clients. 7.2.1.4 Windows Task Manager The Windows task manager is not really a tool to evaluate the health of the shared variable engine, but one tab on the task manager can yield some misleading infor- mation about the network utilization. When examining the Task Manager’s Network Performance tab, it is reporting utilization of what the link is rated for, not what the network is capable of supporting. Most Ethernet links are 100 megabit or faster, but this does not mean the router the cable is plugged into is going to support this data rate. For example, the backbone of Rick’s home network is a Nexland ISB SOHO router/firewall. The router supports 10/100 megabit operation on the links but is only capable of 6 megabit throughput internally. It would be very unlikely to see the Network Performance tab report over 6% utilization! Now this might sound clunky and old but consider the simple fact that it still has a higher throughput than many DSL and cable modem installations. When looking at the task manager’s network utilization it is important to know what the other side of the Ethernet cable is capable of supporting. A remote client with a 128 kilobit DSL link may show 1.2% of its network being utilized, but that is all the DSL link has to offer. This may not be a factor in a typically modern engineering facility, but remote locations with high throughput may need to consider what their link to the system supports. 7.3 SHARED VARIABLE PROCESSES AND SERVICES This section discusses the processes and services used in operating the shared variable. Several services are in use and provide different functional elements. Figure 7.5 shows some of the Windows services involved. Top of the services list is the Lookout Citadel server. The Citadel server is not dependent on the rest of the shared variable engine. It is installed with LabVIEW, but the DSC is needed to take full advantage of Citadel. With the DSC module, additional capabilities available to distributed data include datalogging through the Citadel database, data alarms, data scaling, and initial values. In the event the shared variable engine is being used without the DSC FIGURE 7.5 © 2007 by Taylor & Francis Group, LLC Shared Variable 305 module, one of the first steps the application needs to do is set the shared variable’s initial values on system startup. Citadel is a streaming database and uses a feature called “deadbanding” for logging. If a value of a variable does not change, or does not change significantly, Citadel can be configured to not log the value update, so it is possible to have Citadel only log value changes of significance. The DSC Module’s alarm capabilities make this add-on desirable in many monitoring applications. The alarms have a significant level of configuration so the alarming feature can be tailored specifically to a scenario. Standard alarm configu- rations include values over high and low thresholds and a rate of change alarm. Rate of change alarms are useful in process control; for example, if a temperature sensor is reporting a mixture is heating too quickly or too slowly. The National Instruments Domain Service is responsible for coordinating National Instruments security for the shared variable engine. This service is respon- sible for user logins and access to features of the shared variable such as who is allowed to stop library processes. Usage of this process is discussed in more detail in Section 7.7. The National Instruments PSP Locater Service is responsible for coordinating the Publish-Subscribe-Publish Protocol transactions across system elements. It works with the NI security features that are part of the domain service. This service handles the detection of remote domains. The National Instruments Time Synchronization Service is used primarily with Lookout or the DSC Module in LabVIEW. This module helps synchronization of time between remote machines; in general, there is no need to modify this service. In fact, it can be difficult to modify the time synchronization of a remote client without having either Lookout or the DSC Module installed. In cases where neither Lookout nor the DSC Module is installed, to configure this module to synchronize time to another machine, such as the one hosting the variable engine, use the following steps (note that this only works on Windows-based machines): Start up a DOS window enter: lktsrv -stop enter: lktsvr -start Now this will work and cause the local time service to synchronize with the remote machine — but only until the computer is restarted; then this setting will be lost. To make a change like this “permanent,” you can change the service Startup command in the Windows Services configuration. Go to the control panel and open up Administrative Tools. Open up the Services Applet and double click on the National Instruments Time Synchronization Service. A dialog window will open up and is shown in Figure 7.6. Stop the service, and add the second line shown previously into the start parameters box at the bottom of the window. Every time the computer is restarted, it will bring up the time service with the address specified. It is also possible to configure the service to synchronize time with multiple machines — separate the IP addresses using a space-delimited list. © 2007 by Taylor & Francis Group, LLC 306 LabVIEW: Advanced Programming Techniques The National Instruments Shared Variable Engine is the last service to be men- tioned, and it obviously implements the shared variable engine. This service is dependent on the NI Configuration Manager. 7.4 SHARED VARIABLE NETWORKING Shared variables are transported across networks via a protocol called the NI Publish- Subscribe Protocol (PSP). The PSP protocol is proprietary in nature, so it is not possible to go into significant detail of message exchanges. There are several aspects of the protocol that can be discussed and we will begin with the underlying transport. The PSP protocol itself uses UDP/IP as the underlying transport protocol. UDP is not a reliable protocol; it is possible for PSP packets to be lost during transmission. The advantage to using UDP for the transport protocol is the lack of TCP-related overhead. TCP is reliable, but its windowing algorithm and associated acknowledg- ments can create what is called network jitter. When a TCP packet is lost, almost FIGURE 7.6 © 2007 by Taylor & Francis Group, LLC Shared Variable 307 every TCP stack in commercial use makes a fundamental assumption: the packet was lost due to network congestion. The TCP stack will then perform a delay and then attempt to retransmit the packet. The trouble with this mechanism is that the application sending the message is unable to control the retransmission delay. Retransmission delay is called jitter. Jitter is undesirable in shared variable applica- tions because retransmissions end up delaying applications. If a front panel control is bound to a shared variable, the goal is to attempt to acquire a current value for the control. TCP-based communications could leave the application in a position of waiting around for the TCP windowing to push data up to the application. Another disadvantage to using TCP is the requirement that the connecti