VI-Based Server - Developing a Server

You can write an Industrial Automation Device Server as a LabVIEW VI. Writing a VI-based IA server is a simple way to emulate hardware or connect the LabVIEW Datalogging and Supervisory Control (DSC) Module to a simple device. You can use the same LabVIEW development environment to create the server as you used to develop your application. The VI-Based Server Development Toolkit for creating a VI-based device server is included on the DSC Module CD:
- Examples: LabVIEW\examples\lvdsc\servers
- Manual: LabVIEW\manuals\viserver.pdf

The server development process involves several steps, discussed in the following sections:

1. Create the Server
2. Register the Server
3. Include Error Handling and Status Checks
4. Set Up the Server-User Interface
5. Debug and Test Your Server
6. Create a Server Configuration Utility (Optional)
7. Server Changes

Create the Server

You can build a VI-based server using the Server Interface VIs of the VI-Based Server Development Toolkit. The server uses a set of subVIs to communicate with the Tag Engine during server execution. These are contained in the DSC Server Development palette.

Servers are launched dynamically when the Tag Engine is launched. Servers must execute until their shutdown status becomes TRUE. The shutdown status is returned by several of the
server interface VIs.

Server Initialization
When the Tag Engine launches a server, the server first must call the SRVR Get Item List VI, passing in the server name it registered under. This VI returns the list of items the Tag Engine uses from the server and details on how to use the listed items. This VI also returns a list of groups that specify timing information for the items. Information specified for each item includes the following parameters: device name, item name, datatype, item direction, item datatype, scan rate, notify on change flag, refnum (a signed 32-bit integer), group name and access path. Information specified for each group includes the following parameters: group name, scan rate, deadband and device name.
Note The server must use the refnums when it passes item information to the Tag Engine or receives information from it.

You can have multiple tags assigned to an item. The server updates all refnums associated with that item. Although it is best to support this capability, if you cannot, send the can’t support multiple connections to item status for duplicate items in the item list. Next, the server sorts through the item list. If any device or item names are incorrect, not configured for the requested item direction, or not available for some reason, the server writes the status information using the SRVR Write Input Queue VI. The server can use the group list to determine the timing configuration for each item. The scan rate and device name information is already duplicated in the item list. One additional parameter, % deadband, is available only from the group list. A server can ignore the group list if it does not implement %deadband. Finally, the server polls all valid input or I/O items for their current readings and writes those to the input queue. If there are problems with any items, the appropriate status is written to the input queue.

Server Input and Output
The server must run continuously, usually executing two parallel loops: an input polling loop and an output polling loop. Both loops must run until the server is signaled to shut down. The server should configure timing for input polling to match the scan rate requested in the item list or as close to the specified scan rate as possible.

The server polls its inputs according to its polling configuration and writes all new or changed input data to the input queue, along with timestamp and status information. The SRVR Write Input Queue VI returns the number actually written to the input queue, which notifies the server of any queue overflow situations. Ideally, the queues allocated by the Tag Engine are large enough to prevent overflow. By default, the server can instruct the DSC Module to block the server and handle the rewrite. The server directly handles retries by clearing the block if queue full input; however, the server also must check and rewrite data as necessary, or the data is lost.

In addition to polling the item inputs, the server occasionally reads the output queue to obtain item output values.

Wire the server name to the SRVR Read Output Queue VI, along with a maximum number of values to read (max #to read= 0 reads all available values for the server) and a maximum timeout period to wait before reading the queue. The VI returns as soon as one of the following events occurs:

• Information is available in the queue
• The server shutdown or changes pending status is TRUE
• A timeout occurs

To indicate any error status for those items to the Tag Engine, the server must write the server input queue using the refnums corresponding to output items to the input queue. If the item is used as an output, only the value is ignored; however, the status is read, saved, and then reported. The server must write to the input queue with the status of an output item when that status changes. If a problem occurs when outputting to the item, the server must write to the input queue with the appropriate status. If the status previously was bad but has become good, the server also must write to the input queue with a good status value.

Server Shutdown
When the engine stops, it sends shutdown notification to the servers. Shutdown can be detected from the SRVR Write Input Queue VI, SRVR Read Output Queue VI, and SRVR Get Status VI. The event-driven SRVR Read Output Queue VI is a good place to wait for shutdown notification because it returns immediately if the engine goes into shutdown mode. You can use this mechanism even if the server has no output items. You also can explicitly poll the server status occasionally using the SRVR Get Status VI.
A server is given about 30 seconds to shut down by default. If the server has not stopped execution by that time, the user is asked for permission to abort (close) the server.

Register the Server

In order for Tag Engine to launch a VI-based server and allow a user to configure tags that use the server, you must register the server. This toolkit includes a server registration example named
Register Dummy Server.vi in the Sample folder.

See Also:
VI-Based Server - Registering a Server
VI-Based Server - Sample Server Registration

Include Error Handling and Status Checks

Status is an indication of the quality of the value passed to the server - good, uncertain, or bad. The status parameter is stored along with the value and timestamp for each tag. When status is less than zero, indicating bad status, the Tag Engine assumes that the value for that item is not valid. If a value is good or uncertain, LabVIEW updates the value, timestamp, and status fields with the new information, after scaling the value as necessary. The DSC Module also computes alarms and performs historical logging on the value, as was configured for the associated tag.
If a value is bad, LabVIEW updates the timestamp and status fields but retains the last value with a good or uncertain status. LabVIEW does not compute alarm levels. Users can activate bad status alarm notification on any tag as part of the tag configuration.

status is a 32-bit signed integer. The top 16 bits (MSW) must be set to one of the status numbers listed in the VI-Based Server Development Toolkit Reference Manual. The bottom 16 bits (LSW) are used by the server, sometimes to pass server-specific status information; otherwise, leave these bits set at 0. The server determines the appropriate status meaning and passes the corresponding MSW status value. The server-specific information is passed to the LSW. The more specific the status returned, the better; however, the server must indicate if the value is good, uncertain, or bad.

The server must timestamp values even when reporting a bad status. The server uses the SRVR Post Message VI to post human-readable events and errors to the Tag Engine system message handler. Use this VI to report catastrophic and general errors, such as losing communication with a device, and the subsequent recovery from such errors. These messages are displayed to the user and logged to a systemlog file, so be concise and avoid sending excessive messages. As long as things are operating correctly, no messages are necessary. Report these errors once during
start-up/initialization and on a per device basis. The server still must pass the appropriate status for all requested items on the input queue. If an error message is reported and the server later recovers from the error, the server should send a non-error message notifying the user of the recovery.

Set Up the Server-User Interface

The front panel of the server VI remains hidden from the user during VI execution, but can be displayed using the Server Browser utility from the Tag Engine. The server can display general server status or other information on its front panel. The user sees this information only if the front panel is open. Use VI Setup to hide the server toolbar and prevent the user from closing or aborting the server while it is running.

Debug and Test Your Server

The DSC Module provides a utility, the Interactive Server Tester that allows you to simulate the Tag Engine and run your server in LabVIEW where you can use the G environment debugging tools.

See Also:
VI-Based Server - Testing a Server

Create a Server Configuration Utility (Optional)

Depending on the complexity of the server, you might choose to provide a server configuration utility rather than just a server registration VI. Relevant server configuration information can be stored in a file and retrieved by the server at run time. This configuration utility then also registers the server information. This toolkit includes a server configuration example called srvr_cfg.llb available in the LabVIEW\examples\lvdsc\servers\Sample directory.

Server Changes

To obtain information about item changes for the server, the server either acquires a completely new item list and group list by calling the SRVR Get Item List VI or retrieves lists of exceptions by calling the SRVR Get Item Changes VI. The SRVR Get Item Changes VI specifically lists the items and groups that are obsolete, new, or have changed. Items with no associated changes are not included in the outputs. Calling the SRVR Get Item List VI or SRVR Get Item Changes VI resets the changes pending status.

The server now sorts through the changed item and group lists. If any device or item names are incorrect, not configured for the requested item direction, or not used for some reason, the server must write the status information using the SRVR Write Input Queue VI.

Reader Comments | Submit a comment »