WESgate Interface 1.

Introduction

1 June 2011

WESgate is the name given to a general propose interface process that runs on a WEStation. It allows a remote computer device to access WDPF process point data. It is described in document U0-8701, WESgate Interface User's Guide. WESgate supports three different communication protocols: TCP/IP, DECnet, and RS232 serial. One of three executable files is used depending on the desired protocol: dls_xdr_tcp, dls_xdr_dni, dls_xdr_serial. This uses a client/server communication protocol. The WESgate process is the server and the remote device is the client. The client sends a request message to the server and the server returns a response message. The structure of the request and response messages is based on the external data representation (XDR) standard. This standard was developed to allow data transfer between dissimilar machines. The messages are described in U0-8701. The user must develop the client process to decode these messages. The WESgate package only supplies the server. The following commands are supported: read process point data, write process point data, read history data, get current highway time, get all point attributes, and get selected point attribute. 2. WESgate Operation The client first makes a logical link connection to WESgate server. For dls_xdr_tcp this is done by making a socket connection to the socket number defined by the configuration parameter DL.Server.1.DeviceName. For dls_xdr_dni this is done by making a DECnet logical link connection to the object defined by the parameter DL.Server.1.TaskName or DL.Server.1.ObjectNumber. If configured, the DECnet WESgate server will verify the userid and password from a connect request with the DL.Server.1.Userid and DL.Server.1.Password parameters before accepting a DECnet connection. After a connection is made, the client sends an ENABLE command to the server. The ENABLE request is used to cause the client and server to agree upon a maximum message size. This may cause some responses to be broken up into multiple messages. The client can then send a POINT DATA REQUEST message to the server to request the current value and status of selected process points. The point names can be listed in the request, or the message can contain the identification number of a predefined list of names. The server will gather the point data and return a response message to the client. Normally a client will periodically request the current data for point group. The first response may be slow because the server needs to look up the point names in the system point directory file. The client can also request history data for a group of points. A request message for history data contains a start time, number of samples, interval time and point group number. The server will make a request to the HSR Station for the history data. The gathered data is then returned to the client in a response message. History data requests are limited to 16 process points.

The DL.Server.1.MaxLogicalLinks defines the number of logical links that can be made to the server from the client. The server forks a child process to service each link. The client should always close a logical link when it has finished communicating with the server. 3. Software Installation The WXdlui and WXdlwg packages are to be installed on a Software Server. Do not install them on the Software Development Station or the Data Link Server. Copy the WX*.tar.Z files to the /tmp directory. Uncompress the *.Z files. uncompress WXdlui.tar.Z uncompress WXdlwg.tar.Z Use the tar command to unbundle the tar files. tar xvf WXdlui.tar tar xvf WXdlwg.tar su to root and install the packages. pkgadd -R /export -d /tmp (answer y to all questions) Logout of superuser mode. 4. WDPF Configuration Start the WDPF Admin Tool and WDPF Init Tool. In the Init Tool... Select the Data Link Server drop number and select Modify/Add/Delete Drop types. Select the desired datalinks from the "Available packages:". The Data Link Server drop should be given its own drop type, such as; Operator Station / Data Link Server. If this is not done then all Operator Stations would have the data link packages. The Data Link Server Manager is a user interface window program that is selected from the Device Maintenance Menu. It displays the status of all the datalinks in the system and allows them to be restarted. The "Data Link Server Manager" package should be added to all drops where this UI will be used. Save to disk and restart application. In the Admin Tool... Select the 'Install Configuration on Software Server' function. Select all topics in the the 'Software Server' filter and install. This reinstalls the Software Server software so that it gets the data link query files. Select the Base Software filter. Select the "BASE WEStation type configuration" topic and install. This changes the westation_type files so that they contain the datalink packages.

The MMI menu configuration must be reinstalled to enable the DLS Manager. In the Admin Tool, select the 'Install Configuration on Software Server' function and the 'Operator' filter. Select the 'MMI Menu Configuration' topic and install. Select 'Download Configuration to Drops' and the 'Operator' filter. Query/download to all MMI drops. In the Admin Tool, select the 'Maintain Project Data' function. Select the 'Data Link Server' filter. Edit the start_datalinks file to start the desired datalinks. This file should be unique for each Data Link Server drop. Edit the 'CONFIG.DL Configuration File' to contain configuration parameters for the selected datalink. Each datalink includes an example configuration file. For example; for a modbus datalink, cut and paste the parameters from the 'CONFIG.MODBUS Example Configuration' file into the CONFIG.DL file and then edit them. The CONFIG.DL file should be the same for all drops. Edit the point group configuration for the datalink. The PointGroupDefFile parameter defines the name of the point group file used by the datalink. An example point group file is included with each datalink package. For example, 'MODBUS.GROUP Configuration File' defines the Modbus register to WDPF process point mapping. If a different file name is desired then edit the file directly in the /export/wdpf/rel/data/dl/config directory. The point group files (DLS.GROUP) file should be the same for all drops. 5. Query/Download In the Admin Tool, select the 'Download Configuration to Drops' function. Select the Base Software filter and select the Download button. Download the new westation_types file to the Data Link Server. Select the Engineering filter and download. This causes the new data link man pages to be downloaded. These should be downloaded to each Software Server and EWS. Select the Data Link Server filter and select the Download button. Download the datalink files to the Data Link Server drop and the MMIs. The new datalinks should now start when the station is booted. 6. WESgate Configuration CONFIG.DL The CONFIG.DL file is used to configure the interface. All data link routines running on any WEStation use the same CONFIG.DL configuration file. This file is also used by the Data Link Server Manager to locate each interface. The DLS Manager is a GUI program that runs on a Operator Station and is started from the Device Maintenance menu. An example of a CONFIG.DL file for WESgate is included in the WXdlwg package. ; the link name is displayed on the DLS Manager DL.Server.1.LinkName : WESgate Server ; hostname of drop that is running the WESgate server DL.Server.1.LocalHost : drop211

; name of point group file DL.Server.1.PointGroupDefFile

: DLS.GROUP

; communication parameters used by dls_xdr_tcp ; socket number for TCP/IP communication DL.Server.1.DeviceName : 4055 ;Used to display status messages to shelltool or text file. ;This is only used during debug and is normally commented out. ;DL.Server.1.TestMsgFile : stderr ; maximum allowed connections DL.Server.1.MaxLogicalLinks : 5

; enables messages sent to general message display 3 = error 7 = debug DL.Server.1.SyslogPriority : 3 ; PB status point read by DLS Manager DL.Server.1.LinkStatusPoint : XRPI1LSC ; AI status point read by DLS Manager DL.Server.1.LastCommPoint : YRPI1LTB ; Used by DLS Manager to restart process DL.Server.1.RestartProcedure : $WDPF_HOME/dl/bin/dls_xdr_tcp -l 1 ; If no messages are received for this time then set all ; originated points to bad quality. This is optional. ; DL.Server.1.DeadmanTimeout : 100 DLS.GROUP The DLS.GROUP point group file defines lists of WDPF process points and associates each list with a number. This allows process point information to be requested by a group number instead of listing the point names in the request message. WESgate has the ability to perform value conversions. The value conversion types are described in UO-8700. A conversion is performed on a value from a STORE DATA request before it is written to a originated process point. A conversion is also done on a point value before it is included in a POINT DATA response message. Example of a point group with conversion parameters. /GROUP: name = "point group #1", number = 1, # point group number originated = true A0001, 1, 3, 6.6 # y = 3n + 6.6 A0002, 1, 0.8, 0 # y = 0.8n + 0 A0003 # y = n An example of a DLS.GROUP file for WESgate is included in the WXdlwg package. 7. Data Link Operation When a datalink package is downloaded to a WEStation, the name of the

package (WXdlui.) is included in the /usr/wdpf/init/westation_type file. This causes the /usr/wdpf/init/root/S82.WXdlui. file to be executed when the station is booted. The S82.WXdlui. file causes the /usr/wdpf/dl/ init/startup.dl script to be run. This in turn causes the /usr/wdpf/dl/ init/start_datalinks file to be run. The start_datalinks file is unique to each Data Link Server. This file must be edited to cause the desired data links to be started. It is done this way to allow flexibility to the configuration of datalinks. The datalink binary files reside in the /usr/wdpf/dl/bin directory. The configuration file reside in the /usr/wdpf/dl/config directory. The CONFIG.DL file contains datalink configuration parameters such as baud rate and message timeout. All datalinks on all WEStations use the same CONFIG.DL file. This allows the DLS Manager to locate each datalink and display its status. 8. Debug The interface routines can be started in a shelltool to observe their operation. The DL.Server.1.TestMsgFile parameter in CONFIG.DL is set to stderr to cause status messages to be displayed. This parameter is commented out during normal operation. The SyslogPriority parameter can be set from 3 to 7 to vary the number of status messages. The -t display command line option is used to display the sent and received XDR messages. All running WESgate programs need to be stopped first. This is done using the ps and kill commands as described below. Example: dls_xdr_tcp -t display 9. Menu Mode The WESgate server can be started in a shelltool in a test menu mode. dls_xdr_tcp -t menu Test Menu: 0. Open SHC memory 1. Display CONFIG.DL params 3. List point group 5. accept connect 7. get HSR data 9. enter point value 11 read group attributes

2. 4. 6. 8. 10 12

Display point values for group Open device close device timestamp conversion validate password exercise status points

This allows the user to perform tests of the program's basic operation. Option 0 opens the SHC and should be done first. Options 2 and 3 will verify the correct configuration of the point group file. Option 1 displays the parameters from the CONFIG.DL file. It also shows the default parameters. Option 7 is used to test the ability to communicate to the HSR. Option 9 is used to set a process point value. 8. Notes If the server process is killed (ctrl-C) while a socket connection is active, it will not be able to restart for about two minutes. Even

though the socket was closed, it enters the TIME_WAIT state and cannot be reopened until it times out. use netstat -a grep 4000 to display the status of socket 4000 use the Solaris command ps -ef grep dl to view the running WESgate tasks The ps command displays the PID for each task. The PID can be used to terminate a task. kill -9 345 Where 345 is the PID of the task to kill.

44444444444444444