wesdac.pdf

Document Number: TL-409

Windows SCADA Wesdac Scan Task User’s Guide ____________________________________________

March 17, 2006 This manual describes the functionality and data entry requirements for the Wesdac scan task used in the Windows SCADA system.

Survalent Technology Corporation Mississauga, Ontario

Copyright © 2006 Survalent Technology Corporation All rights reserved.

Wesdac Scan Task User’s Guide Survalent Technology Corp. 2600 Argentia Road Mississauga, Ontario L5N 5V4 TEL (905) 826 5000 FAX (905) 826 7144

The software described in this document is furnished under license, and may only be used or copied in accordance with

the terms of such license.

The content of this manual has been carefully checked for accuracy. However, if you find any errors, please notify Survalent Products Corporation.

Revisions Date Description March 6, 2006 Initial version.

March 17, 2006 Added “RTU Local Status”.

Wesdac Scan Task User’s Guide Contents Windows SCADA

i

Contents

1 Introduction 1-1

2 Operation of Scan Task 2-1

2.1 Introduction .................................................................................................................................... 2-1 2.2 Initialization.................................................................................................................................... 2-1 2.3 Normal Polling ............................................................................................................................... 2-2 2.4 Status Changes................................................................................................................................ 2-2 2.5 Sequence Of Events........................................................................................................................ 2-2 2.6 All-Data Poll................................................................................................................................... 2-2 2.7 Accumulators.................................................................................................................................. 2-2 2.8 Time Synchronization..................................................................................................................... 2-3 2.9 Control ............................................................................................................................................ 2-3 2.10 Communication Errors................................................................................................................ 2-3 2.11 Port Switching............................................................................................................................. 2-3

3 Communication Line 3-1

3.1 Communication Line Data Fields—General .................................................................................. 3-1 3.1.1 Protocol ....................................................................................................................................... 3-2 3.1.2 Auto Start .................................................................................................................................... 3-2 3.1.3 Associated Points ........................................................................................................................ 3-3 3.1.4 Polling Parameters ...................................................................................................................... 3-4 3.1.5 Configuration Switches............................................................................................................... 3-4 3.2 Communication Line Data Fields—Channel.................................................................................. 3-5 3.2.1 Network....................................................................................................................................... 3-5 3.2.2 Mode ........................................................................................................................................... 3-5 3.2.3 Time Between Scans................................................................................................................... 3-5 3.2.4 Short Response Timeout ............................................................................................................. 3-6 3.2.5 Long Response Timeout ............................................................................................................. 3-6


ii

3.2.6 DLL Short Response Timeout .................................................................................................... 3-6 3.2.7 DLL Long Response Timeout .................................................................................................... 3-7 3.2.8 Error Recovery Time .................................................................................................................. 3-7 3.2.9 Idle Time..................................................................................................................................... 3-7 3.2.10 Poll Retry Count ......................................................................................................................... 3-7 3.2.11 Interleave Factor ......................................................................................................................... 3-7 3.2.12 Dial-Up ....................................................................................................................................... 3-7 3.2.13 Port Parameters ........................................................................................................................... 3-7

4 RTU 4-1

4.1 RTU Data Fields—General ............................................................................................................ 4-1 4.1.1 RTU Address .............................................................................................................................. 4-2 4.1.2 Network ...................................................................................................................................... 4-2 4.1.3 Scout ........................................................................................................................................... 4-2 4.1.4 Status Point ................................................................................................................................. 4-3 4.1.5 Fast Scan Point............................................................................................................................ 4-3 4.1.6 Switches ...................................................................................................................................... 4-3 4.2 RTU Data Fields—Connections..................................................................................................... 4-3 4.2.1 Host Name .................................................................................................................................. 4-4 4.2.2 Host Port ..................................................................................................................................... 4-4 4.2.3 Dial-up ........................................................................................................................................ 4-4 4.2.4 RTU Data Fields—Switches....................................................................................................... 4-4 4.2.5 Port Switch Point ........................................................................................................................ 4-5 4.2.6 Switch Port after ......................................................................................................................... 4-6 4.2.7 Channel Switch Point, Switch Channel after .............................................................................. 4-6 4.3 RTU Data Fields—Statistics .......................................................................................................... 4-6 4.3.1 Percentage Communication Point............................................................................................... 4-6 4.3.2 Total Message Count .................................................................................................................. 4-7 4.3.3 Good Message Count.................................................................................................................. 4-7 4.3.4 Bad Message Count .................................................................................................................... 4-7 4.3.5 Timeout Count ............................................................................................................................ 4-7 4.3.6 Send Message Count................................................................................................................... 4-8 4.3.7 Dial-up Override Interval............................................................................................................ 4-8 4.3.8 Dial-up Status ............................................................................................................................. 4-8 4.3.9 Time of Last Good Poll .............................................................................................................. 4-8 4.4 RTU Data Fields—Scout................................................................................................................ 4-8

5 Status Point 5-1

5.1 Telemetry........................................................................................................................................ 5-2 5.1.1 Telemetry Address ...................................................................................................................... 5-2 5.2 Input Format Code.......................................................................................................................... 5-3 5.3 Control............................................................................................................................................ 5-6 5.3.1 Control–0, Control–1 .................................................................................................................. 5-6 5.4 RTU Local Status ........................................................................................................................... 5-6

6 Analog Point 6-1

6.1 Telemetry Address.......................................................................................................................... 6-2 6.2 Input Format Code.......................................................................................................................... 6-2 6.3 Scale Factor and Offset................................................................................................................... 6-2 6.4 Zero Clamp Deadband.................................................................................................................... 6-3 6.5 Setpoints ......................................................................................................................................... 6-3 6.6 Accumulators.................................................................................................................................. 6-4

7 Monitoring Communication 7-1

7.1 Monitoring Wesdac ........................................................................................................................ 7-2

8 Implementation Table 8-1


iii

1 Introduction

This document describes the operation and database requirements of the Wesdac scan task in the Windows SCADA system. Chapter 2 describes the general operation of the scan task. Chapters 3 to 6 describe how to define: • Communication lines • RTUs • Status and controls • Analog points You can monitor communications between this scan task and your RTUs, using the ScanMon utility. This is described in chapter 7. The scan task described in this document conforms to the protocol specification contained in the following document:

WESDAC Protocol Definition For B.C. Transit/Skytrain MICRO-23235-100-00 Revision:00 Date: January 1988 DATAP Systems

Chapter 8 contains a table of Wesdac functions that are supported by this implementation of the scan task.

Wesdac Scan Task User’s Guide Introduction Windows SCADA

1-1

Wesdac Scan Task User’s Guide Introduction Windows SCADA

1-2

This manual describes the use of the SCADA Explorer to create communication lines, RTUs, analog and status points. The description is specific to the Wesdac communication protocol, as implemented by this scan task. For additional information regarding these database items, and the Windows SCADA database in general, you should refer to the series of documents described in Table 1-1, especially the Point Database Editing Guide. If you have other scan tasks installed in your system, you should also consult the User’s Guides published for those scan tasks.

Table 1-1 Windows SCADA Database Documentation

Document Number

Document Name

DB-400 Database Editing Overview

DB-401 Point Database Editing Guide

DB-402 Alarm Database Editing Guide

DB-403 Automation Database Editing Guide

DB-404 Historical Database Editing Guide

DB-405 Report Database Editing Guide

This document assumes you have some familiarity with the protocol involved. Terms specific to the Wesdac protocol are used throughout, without defining them. If you need clarification, you may want to read the RTU vendor’s protocol documentation.

Wesdac Scan Task User’s Guide Operation of Scan Task Windows SCADA

2-1

2 Operation of Scan Task

2.1 Introduction In the Wesdac protocol, all message transactions between the master station and the RTU are based on a “master-slave” relationship. RTUs respond to the master station only when commanded by the master station. The master station will “stop-and-wait” for each RTU response message or time-out before initiating another RTU message transaction. The protocol, and hence the scan task, does not support quiescent operation.

2.2 Initialization At startup, and on detection of RTU restart, the scan task performs the following initialization functions:

• Time synchronization if required • All-data poll

The time synchronization is done through the Wesdac “Time Update” command when the communication line is configured to do so. The all-data poll is done by use of the Wesdac “Return All Current Data” command, which is the same (and only available) command used by the normal poll.


2-2

2.3 Normal Polling The Wesdac protocol does not support polling for exceptions. The scan task therefore continuously polls for analog and status input data by using the Wesdac “Return All Current Data” command. Periodically, the scan task:

• issues all-data polls at the all-data-poll interval (the actual commands sent to RTUs are the same

command as that for normal data poll).

• issues time sync commands if the communication line is configured to do so (see section 3.1.5, Configuration Switches, for more details).

In addition, on request from the operators and application programs, the scan task issues control and setpoint commands.

2.4 Status Changes The status changes in Wesdac RTUs are acquired on normal-data polling as described above, not on exception basis because of the nature of the protocol. Wesdac RTUs do not report timestamps with the status changes.

2.5 Sequence Of Events There is no SOE data available from Wesdac RTUs.

2.6 All-Data Poll The scan task issues an all-data poll command:

• to each RTU at startup • to one RTU, in round-robin order, at every all-data poll interval. See section 3.1.4, Polling

Parameters. • to any RTU that resets • on request by the operator (via an Activate command directed to the RTU point). When you trigger an all-data poll by Activating an RTU point, the scan task sets the condition code of all of the analog and status points on the RTU to telemetry failed (indicated by the letter “F” displayed beside each point). Then, as the requested values are returned by the RTU, the telemetry failed indicators clear.

2.7 Accumulators The Wesdac protocol does not support accumulators.


2-3

2.8 Time Synchronization If the communication line has been identified as having RTUs that require periodic time sync (see section 3.1.4, Polling Parameters), the scan task periodically sends a “time-update-command” to each RTU. The interval at which time syncs are sent is specified by the TIME SYNC INTERVAL field of the communication line Polling Parameters (see section 3.1.4, Polling Parameters).

2.9 Control On a control operation, the scan task first places the RTU on fast scan, which means that after every Nth poll, the scan task re-polls the RTU that is on fast scan. This is so that any status changes as a result of the control about to be performed can be reported as quickly as possible. The parameter N, called the interleave factor, can be set in the Channel tab of the communication line definition. See section 3.2, Communication Line Data Fields—Channel. Next, the appropriate sequence of control messages is transmitted to the RTU. The scan task supports both select-before-operate and direct-operate controls for trip or close. In a select-before-operate control, the scan task first issues a select request. On reception of a good select checkback, the scan task then issues the execute command and expects an execute checkback from the RTU. If the scan task does not receive a select or execute checkback within a response timeout, it declares a checkback timeout. After the control is complete (meaning that the expected status change was either received or timed out), the scan task takes the RTU off fast scan. The Wesdac protocol does not support setpoint controls.

2.10 Communication Errors The scan task normally polls the RTUs in round-robin order.

On a poll error, such as a timeout or a message security error, the scan task places the RTU on “error scan”. This means that it re-polls the RTU that had the communication error after every Nth normal poll, where “N” is a user-settable interleave factor that is usually set to one or two (see section 3.2, Communication Line Data Fields—Channel). The RTU is maintained on error scan until a good response is received or until the retry count expires, whereupon the RTU is declared failed. Failed RTUs continue to be polled, but less frequently. On each round-robin poll sequence, only one failed RTU is polled.

2.11 Port Switching Two communication ports may be specified in the definition of a communication line, or two connections may be specified in the definition of an RTU. In either case, the scan task will switch to the alternate

connection whenever communication on the primary one fails. In such as case, an RTU will be marked as Failed only if communication on both primary and alternate ports fails. A separate port switch status point is used for each RTU, to indicate which port is currently in use when communicating with that RTU. See section 3.1.3, Port Parameters, and section 4.2.5, Port Switch Point. This feature may be used to make use of redundant terminal servers and/or redundant communication lines, or to implement a fault-tolerant “looped” communication line. In the latter case, a break in the line would cause the scan task to poll the RTUs on one side of the break using one port, and poll the RTUs on the other side of the break using the other port. The advantage of such an arrangement is that a single break in the communication line causes no loss of communication with any RTU.


2-4

3 Communication Line

This chapter describes how to define a communication line for the Wesdac scan task. You should be familiar with the discussion of communication lines in DB-401, Point Database Editing Guide before proceeding. In this document, only the items that are specific to the Wesdac scan task are discussed in detail. The SCADA Explorer is used to create or modify a communication line’s definition. The dialog box that allows you to do that has several tabs, each of which includes different data. You will normally begin on the General tab, which is illustrated in Figure 3-1.

3.1 Communication Line Data Fields—General The discussion below contains information that is particular to the Wesdac scan task. The fields mentioned can be found on the General tab of the Edit Communication Line dialog that you call up using the SCADA Explorer. For more information on fields not detailed here, refer to DB-401, Point Database Editing Guide. If you need more information about the SCADA Explorer, see DB-400, Database Editing Overview.

After creating or changing a communication line definition, or editing the telemetry

address of any points on the communication line, remember to come

back to this dialog to build the scan table.

Wesdac Scan Task User’s Guide Communication Line Windows SCADA

3-1

Figure 3-1 Edit Communication Line Dialog (General)

3.1.1 Protocol This is the name that identifies the protocol to be used to communicate with the RTUs connected to this communication line. For the Wesdac scan task, choose the name Wesdac from the drop-down list.

3.1.2 Auto Start Set this flag if you want the scan task to start automatically when the SCADA system starts up, either initially, or as the result of a failover.


3-2

3.1.3 Associated Points This area includes fields for the communication status point (which is required) and for six other points. You must specify points that already exist in the database. To create the points you could abandon the editing of this communication line, and go to the desired station in the SCADA Explorer. But you may prefer to temporarily start a second copy of SCADA Explorer, and use it to create the necessary points. These associated points must not be telemetered. Their values will be written by the scan task. Therefore they will not need telemetry addresses of their own. Since they are special in this regard, you should consider designating separate User Types for these points. Status Point

The first Associated Point is not optional, and must be a status point. This point will be used by the scan task to indicate the Up or Down status of the communication line. The scan task will set the point to its normal state when the communication line is working (i.e. there is successful communication with at least one RTU), and to the abnormal state when it is failed.

Timeout Point

The Wesdac scan task does not make use of this analog point to count timeouts. Instead, it uses an analog point defined on each RTU to maintain a count of timeouts for each RTU. See section 4.3.5, Timeout Count.

Bad Messages

The Wesdac scan task does not make use of this analog point to count bad messages. Instead, it uses an analog point defined on each RTU to maintain a count of bad messages for each RTU. See section 4.3.4, Bad Message Count.

Unexpected Messages

The Wesdac scan task does not make use of this analog point to count unexpected messages.

Channel Switch

The Wesdac scan task does not presently support a second communication channel (although it will switch between two ports defined on a single channel—see below). Do not specify a point in this field.

Port Switch

The Wesdac scan task does not make use of this status point when switching between ports. Instead, each RTU defines a status point to indicate which port is used to communicate with that RTU. See 4.2.5, Port Switch Point.

Current RTU

The Wesdac scan task does not make use of this analog point.


3-3

3.1.4 Polling Parameters Various timers are specified to control the rate of certain events. Integrity (all-data) polls, accumulator (integrated total) polls, and time synchronization commands are described in more detail in sections 2.6, All-Data Poll, 2.7, Accumulators, and 2.8, Time Synchronization. All Data

This is the field that specifies an all-data poll interval (in seconds). You should use this to specify how frequently you want all-data polls on this communication line. Remember that only one RTU will receive an all-data poll at each All Data poll interval.

Accumulator

Since the Wesdac protocol does not support accumulators, the scan task does not use this field. Leave it blank.

Hourly Offset

Since the Wesdac protocol does not support accumulators, the scan task does not use this field. Leave it blank.

Time Sync Interval

If any RTUs on this communication line require periodic synchronization of their clocks, you must specify the TimeSync configuration switch (see section 3.1.5, Configuration Switches) and enter the desired time interval here. Otherwise, time sync commands will only be sent to RTUs that request them. In many instances, sending time sync messages to the RTUs when they request them will be sufficient. In this case, no periodic “all stations” time sync messages are needed, and you can leave this field blank.

Demand Averaging Interval

This field is not used by Wesdac scan task.

3.1.5 Configuration Switches This field allows you to specify certain “command line” switches to control the behavior of the scan task. The switches supported by the Wesdac scan task are described below. Specify each switch you need by entering /name=value in this field. You do not need to add a space or punctuation (other than the “/”) between switches. /TMSYNC

This switch should be set to 1 if the periodic time sync is required, 0 if not.


3-4

/Log

The Log option specifies the scan task is to log communications to a file. The file will be created in the folder specified when Windows SCADA was installed; the default folder is C:\Program Files\Quindar\ScadaServer. The file name is comprised of the protocol name, the communication line id and the current date. For example, a file from communication line 7 on May 18, 2006 would be WESDAC7-2006-5-18.log.

The valid values for this option are:

• hex – Log all communication, including raw data in hexadecimal form

• errors – Log only communication errors

• debug – similar to “hex”, with decoded details

• all – Log all communication The logging that you will find in this file is the same as the logging that is displayed by the ScanMon utility.

3.2 Communication Line Data Fields—Channel The Channel tab on the Edit Communication Line dialog (see Figure 3-2) contains the data fields discussed below. Fields that have a generic purpose, not specific to the Wesdac protocol, are not described in this document. Please refer to DB-401 Point Database Editing Guide.

3.2.1 Network This specifies the type of communication network to be used. Choose COMM for communication lines that will communicate directly through a serial port on the SCADA host (i.e. a COM port known to Windows). Choose TCP/IP for all connections that rely on the TCP/IP network, such as serial ports on terminal servers. Choose Use RTU only if you will be specifying the connection information individually for each RTU (for example, if each RTU has its own IP address). Refer to DB-401 Point Database Editing Guide for more detail.

3.2.2 Mode This is a drop-down list that can be set to either Poll or Quiescent. If Poll is chosen, the scan task performs regular round-robin exception polling. Quiescent means the scan task does not poll, but accepts unsolicited messages from the RTUs. The Wesdac protocol does not support Quiescent mode. Therefore select Poll mode only.

3.2.3 Time Between Scans This parameter specifies the time to wait (in milliseconds) between each poll.


3-5

Figure 3-2 Edit Communication Line Dialog (Channel)

3.2.4 Short Response Timeout This is not used by the Wesdac scan task.

3.2.5 Long Response Timeout This parameter specifies the time to wait, in milliseconds, for a complete response from the RTU. The time includes the transmission time of the request itself.

3.2.6 DLL Short Response Timeout This is not used by the Wesdac scan task.


3-6

3.2.7 DLL Long Response Timeout This is not used by the Wesdac scan task.

3.2.8 Error Recovery Time This is not used by the Wesdac scan task.

3.2.9 Idle Time This specifies the minimum time delay, in milliseconds, that the scan task is to execute between all transmissions on this communication line.

3.2.10 Poll Retry Count This field contains the number of times the scan task is to retry polling an RTU that is not responding, before giving up and declaring the RTU failed. If omitted, the scan task defaults to three retries.

3.2.11 Interleave Factor This parameter specifies how often the scan task is to interrupt its normal round robin polling to perform a fast-scan poll or a retry after error. If the interleave factor is 2, for example, then the scan task will check for fast scan or error retry requirements after every 2 normal polls.

3.2.12 Dial-Up Dial-up communication lines are not presently supported by the Wesdac scan task.

3.2.13 Port Parameters The communication channel provides for two communication ports. If information is provided for both ports, the scan task can switch from one to the other if communication using the first port is not successful. Normally, at least one port is required to create a functional communication line (except when connections are defined for each RTU, as described in section 4.2, RTU Data Fields—Connections). Each port corresponds to a physical or logical connection from the host computer to the communication medium. The type of Network (see section 3.2.1, Network) determines how these fields are used. For COMM networks, the port means a serial port attached to the host computer. For TCP/IP networks, a port might mean a serial port on an external terminal server. Refer to DB-401 for a detailed discussion of the Port Parameters that are not described here.


3-7


3-8

Host Name

For RS232 communication lines, this must be the name that identifies the serial port, in the form COMn, where n is a unique number. This is the same name that Windows knows the port by. For TCP/IP communication lines, this will usually be the name that identifies the other device that we are communicating with over the network. It may be the RTU itself, or more commonly, a terminal server. Alternatively, it may be a fixed IP address of the form nnn.nnn.nnn.nnn.

Host Port

For a TCP/IP connection, there will be a TCP/IP port number that must be entered here. For terminal servers, the port number of the desired serial port should be entered. Consult the terminal server documentation to determine which port numbers to use.

Baud Rate, Parity

Select from the available choices for baud rate and parity (this is not applicable to TCP/IP connections or terminal server ports). Note that the hardware you are using (modem, radio, RTU, etc.) must support the chosen speed as well.

Keying, Keyup Delay

The Wesdac scan task does not presently support carrier keying, except by using an external Port Transfer Module (PTM). The PTM must be configured to buffer the outgoing message and assert RTS at the required time. This action is transparent to the scan task, so leave this field set to <None>.

Retry Count

This field contains the number of times the scan task is to retry polling an RTU that is not responding, before switching to the other port (if one has been defined).

To set the number of tries the Wesdac scan task makes before switching ports, specify a value in the definition of each RTU on this communication line. See section 4.2.6, Switch Port after.

Wesdac Scan Task User’s Guide RTU Windows SCADA

4-1

4 RTU This chapter describes how to define an RTU for the Wesdac scan task. Only the items that are specific to the Wesdac scan task are included in this discussion. The SCADA Explorer is used to create or modify an RTU’s definition. The dialog box that allows you to do that has several tabs, each of which includes different data. You will normally begin on the General tab, which is illustrated in Figure 4-1.

4.1 RTU Data Fields—General The data fields found on the General tab of the Edit RTU dialog are described below.


4-2

Figure 4-1 Edit RTU Dialog (General)

4.1.1 RTU Address Each RTU must have a unique address on the communication line. RTU addresses do not have to be assigned sequentially. Enter the actual Wesdac address of the RTU here. For the Wesdac scan task, the valid range for individual RTU numbers is 1 to 255. The scan task uses RTU number 0 for messages broadcast to all RTUs.

4.1.2 Network If you have specified connection information on the communication line (in section 3.2, Communication Line Data Fields—Channel), then you should set this to Use ComLine. But if your communication line is set to Use RTU, then you must choose TCP/IP here. This makes the fields on the Connections page available for you to specify individual connection information for this RTU (see section 4.2, RTU Data Fields—Connections).

4.1.3 Scout This field is not used by the Wesdac scan task, so leave it unchecked.


4-3

4.1.4 Status Point This is the name of a status point that exists in the database. This point will be used by the scan task to indicate the communication status of the RTU. You must define this point. It is not optional.

4.1.5 Fast Scan Point This is the name of a status point that can be used as a switch to speed up polling of the RTU. Setting this point to a value of “1” causes the scan task to place this RTU on “fast scan” (i.e. poll this RTU more frequently than others, based on the interleave factor). Setting this point to a value of “0” causes the scan task to take the RTU off fast scan. If this field is left blank, the RTU will still be fast scanned automatically during control operations, but you will not be able to initiate fast scan yourself.

4.1.6 Switches This field allows you to specify certain “command line” switches to control how the scan task deals with this RTU. The switches that are supported by the Wesdac scan task are described below. Specify each switch you need by entering /name=value in this field. You do not need to add a space or other punctuation between switches. There are no switches defined for the Wesdac scan task. Leave this field blank.

4.2 RTU Data Fields—Connections This page (see Figure 4-2) provides for one or two communication connections for this RTU, as well as the configuration of the dial-up modem, if any. The dial-up parameters will only be available if you have selected a dial-up mode of Scheduled or On Demand on the communication line that is connected to this RTU (in section 3.2.12, Dial-Up). Only these modes allow a separate phone number for each RTU. The connection information will only be available if you have set the Network type to TCP/IP (see section 4.1.2, Network).


4-4

Figure 4-2 Edit RTU Dialog (Connections)

4.2.1 Host Name This is the name or IP address that identifies the device that we are communicating with over the network (e.g. the terminal server or RTU network interface).

4.2.2 Host Port For a TCP/IP connection, there will be a TCP/IP port number that must be entered here. In a terminal server, it may correspond to the hardware port on the server (for example, port 2003 might correspond to the 3rd terminal server port). Port numbers below 1024 are normally not used, since they are reserved for other well-known protocols used on the network.

4.2.3 Dial-up Refer to the discussion of Dial-up connection in DB-401, the Windows SCADA Point Database Editing Guide, in the chapters covering communication lines and RTUs. For those cases where the RTU must have individual dial-up parameters specified, enter them here.

4.2.4 RTU Data Fields—Switches This page contains information related to the port-switching feature. You may use the Browse buttons provided to select a status point for each switch discussed below.


4-5

Figure 4-3 Edit RTU Dialog (Switches)

4.2.5 Port Switch Point If this RTU is on a communication line that has two ports defined (section 3.2.13, Port Parameters), or the RTU is on a TCP/IP network and has two connections specified (section 4.2, RTU Data Fields—Connections), this status point is required. The point is used to show which port the RTU is currently being polled on. When the point’s value is 0, the scan task is using the first port. When the status point’s value is 1, the scan task is using the second port.

Whenever it wants to poll an RTU, the scan task first tries the port currently indicated by the RTU’s port switch status point. If the poll fails, the scan task places the RTU on “error scan” and retries. If the retry count expires, the scan task switches to the other port (and sets the RTU’s port switch status point accordingly). If polling fails there also, after its own retries, the scan task declares the RTU failed, but continues to poll the RTU, flipping between both ports as described above. The retry count used for port switching is specified by Poll Retry Count in the definition of the communication line. See section 3.2.10, Poll Retry Count.

You can force the scan task to either port by manually setting the port switch status point. The port switch status point should be defined as a non-alarm point because you don’t want to be bothered by alarms on this point when the scan task is constantly switching ports hunting for a dead RTU. If the port switch point is defined and the scan task switches ports while the RTU is up, it notifies the operators via a separate alarm of the form:

mm/dd hh:mm:ss rtu_name rtu_description PRIMARY SELECTED and

mm/dd hh:mm:ss rtu_name rtu_description ALTERNATE SELECTED While the scan task is using one particular port for an RTU, it does not check the other port for availability. Such checks can be made manually by manually setting the port switch point. If you do this, don’t forget to remove the manual set, or the scan task will not be able to switch ports when it needs to. If you define the port switch point as a control point associated with a dummy scan task, then you don’t have to worry about manual set. Alternatively, you can automate the forced switching process via a command sequence.


4-6

4.2.6 Switch Port after Enter the number of consecutive error responses (timeouts, wrong replies, security errors, etc.) that will be tolerated before the scan task switches from the current port to the other one (if one is defined for the communication line the RTU is using).

4.2.7 Channel Switch Point, Switch Channel after The Wesdac scan task does not presently support channel switching, so leave these fields blank.

4.3 RTU Data Fields—Statistics Several point names may be specified on this page, using the browser buttons provided. The function of these points is described below.

Figure 4-4 Edit RTU Dialog (Statistics)

4.3.1 Percentage Communication Point This is an analog point to contain a percent active communication statistic (100% means no errors have occurred). The statistic is calculated by passing 0s and 1s through a low-pass digital filter, where 0 is


4-7

input to the filter on a communication error and 1 is input on a communication success. Errors include timeouts, security (Checksum) errors and wrong replies. The digital filter consists of: ( ) ( iii uKxKx )×−+×=+ )1(1

where: ui is the input to the filter xi is the filtered output K is the filter constant The filter constant used is 0.5. If this point is not specified, then no percent communication statistic is calculated for this RTU.

4.3.2 Total Message Count This is an analog point to contain a count of all messages received from this RTU. You can use this, in comparison with the three counters discussed below, to evaluate the communication with this RTU. If this field is left blank, the statistic is not maintained.

4.3.3 Good Message Count This is an analog point to contain a count of correct messages received from the RTU. It is incremented whenever a correctly formed reply is received, and was expected. If this field is left blank, this statistic is not maintained.

4.3.4 Bad Message Count This is an analog point to contain a count of incorrect messages received from the RTU. The bad message count is incremented whenever an incorrectly formed reply is received (including security errors), or when the reply was not the one expected (either the RTU number or the function code in the message was incorrect, for example). If this field is left blank, this statistic is not maintained.

4.3.5 Timeout Count This is an analog point to contain a count of communication timeout errors (no response errors). The timeout count is incremented once each time the number of bytes of data from the RTU falls short of the expected number.


4-8

If this field is left blank, this statistic is not maintained.

4.3.6 Send Message Count This is an analog point to contain a count of all messages transmitted by the scan task. It is incremented each time a message is successfully sent. This will be the total of all polls, control commands, setpoint commands, and broadcasts sent to this RTU. If this field is left blank, this statistic is not maintained.

4.3.7 Dial-up Override Interval This is not used by the Wesdac scan task, so leave this field blank.

4.3.8 Dial-up Status This is not used by the Wesdac scan task, so leave this field blank.

4.3.9 Time of Last Good Poll This is not used by the Wesdac scan task, so leave this field blank.

4.4 RTU Data Fields—Scout This page is available only when the Scout flag on the General page is checked (see section 4.1.3, Scout). The Wesdac scan task does not use the information contained in this tab.

Wesdac Scan Task User’s Guide Status Point Windows SCADA

5-1

5 Status Point

This chapter describes how to define status points on the Station Editor for the Wesdac scan task. The Edit Status Point dialog from the SCADA Explorer is illustrated in Figure 5-1. A status point can be defined to be any one of:

• Indication only • Control only • Combined indication and control

depending on whether a telemetry address and any control addresses are specified for it.


5-2

Figure 5-1 Edit Status Point Dialog (Telemetry)

5.1 Telemetry This page defines the telemetry address and two control addresses. You should consider the RTU to be part of the telemetry address too, since you may have another point with the same address on this communication line, although it is on a different RTU. Consult DB-401, Point Database Editing Guide, for a discussion of the fields not mentioned in this document, including the External Name and Type. Each of the three addresses specifies the location of an input or output within the RTU, and is made up of four fields labeled A, B, C, and D. These fields represent different things in each type of address.

5.1.1 Telemetry Address The telemetry address specifies the location of the status point within the RTU. The meaning of the parts of the address is given in Table 5-1. If this point is to be a telemetered point, select the RTU that will provide the data, tick the checkbox for Telemetry Address, and fill in the required A, B, C, and D fields.


5-3

Table 5-1 Status Telemetry Address Fields

Telemetry Address Field

Meaning

A Line number (2 – 15) in the RTU

B Byte number (1 – 6) within the line

C Bit number (0 – 7) within the byte

For a dual-bit status point, this is the low order bit.

D 0 (not used) Note: In the WESDAC protocol, data types are distinguished by unique ranges of transmitted line

numbers. Status points are contained in line numbers 2 to 15. Each line has 6 bytes, thus containing data for 48 status points.

5.2 Input Format Code This field specifies how the scan task should process the status input data from the RTU. Below, the formats are referred to by code (ID) number, but you will select them from a list of user-defined names. If Wesdac is the only scan task on your system, the formats can be given names that describe their function. But if multiple scan tasks are being used, they may use the same format numbers for different purposes, so you may not be able to come up with a better name. In that case you may prefer to name them for the ID numbers listed here.

If you are in doubt about which format code is which, look at their definitions using SCADA Explorer.

Format Code 1

Format code 1 specifies normal processing of single bits. That is, received bit values of 0 and 1 are stored in the database as 0 and 1 respectively.

Format Code 2

Format code 2 specifies inverted single bit processing. That is, received bit values of 0 and 1 are stored in the database as 1 and 0 respectively.

Format Codes 3, 4, 5 and 6

These format codes allow dual-bit status points from the RTU to be mapped in four different ways into a consistent internal database representation. The internal representation is shown in the table below:


5-4

Table 5-2 Standard Status Values

Status Value

State

0 Open 1 Closed 2 Transition 3 Error

Note that if any read response (whether exception or all-data) reports both bits of a dual-bit point as changed, then there will be two transitions recorded for the point.

Format Code 3

This format code specifies “low bit on = open” and “high bit on = closed”. When both bits are off, the point is in transition.

Table 5-3 Format Code 3 Raw Bits to Database Mapping

Binary Value From RTU

Value Stored in Database

State

00 2 Transition 01 0 Open 10 1 Closed 11 3 Error

Format Code 4

This format code specifies “low bit on = closed” and “high bit on = open”. When both bits are off, the point is in transition.




State

00 2 Transition 01 1 Closed 10 0 Open 11 3 Error


5-5

Format Code 5

This is equivalent to format 2 inverted. It specifies “low bit off = closed” and “high bit off = open”. When both bits are on, the point is in transition.




State

00 3 Error 01 0 Open 10 1 Closed 11 2 Transition

Format Code 6

This is equivalent to format 4 inverted. It specifies “low bit off = open” and “high bit off = closed”. When both bits are on, the point is in transition.




State

00 3 Error 01 1 Closed 10 0 Open 11 2 Transition

Format 7

Format 7 specifies pass-through processing for dual-bit points. Both bits received from the RTU are stored into the database as is.




State

00 0 Open 01 1 Closed 10 2 Transition 11 3 Error


5-6

Format 8

Format 8 specifies inverted pass-through processing for dual-bit points. Both bits received from the RTU are complemented and then stored into the database as is.




State

00 3 Error 01 2 Transition 10 1 Closed 11 0 Open

5.3 Control

5.3.1 Control–0, Control–1 The open (0) and close (1) control addresses that can be defined for each status point give the location of one or two control relays in the RTU. The meaning of the parts of each address is given in Table 5-9. You must tick the checkbox next to any address you intend to use.

Table 5-9 Control Address Fields


Meaning

A Control point number (1 – 255)

B Control method

= 0 if select before execute

= 1 if direct execute

C 0 (not used)

D Control command

= 0 if open control (trip)

= 1 if close control

5.4 RTU Local Status By means of a key-switch, the RTU can be placed in local mode. In this mode, the RTU continues to service poll requests, but ignores control requests from the host computer.


5-7

The RTU indicates whether it is in local or remote mode by means of a mode bit in line zero. This bit is clear (0) while the RTU is in local mode and it is set (1) while the RTU is in remote mode. This mode bit can be mapped into a status point in the host database by defining a status point with the following address values: A = 0 B = 6 C = 6 D = 0 Only format codes 1 or 2 should be used for this point.

Wesdac Scan Task User’s Guide Analog Point Windows SCADA

6-1

6 Analog Point

This chapter describes how to define analog points for the Wesdac scan task. The Edit Analog Point dialog from the SCADA Explorer is illustrated in Figure 6-1. Accumulators and setpoints (analog outputs) should be defined as analog points.

Figure 6-1 Edit Analog Point Dialog


6-2

6.1 Telemetry Address The telemetry address specifies the type and location of the point within the RTU. It is made up of four fields labeled A, B, C, and D. You should consider the choice of RTU to be part of the telemetry address as well, since you may have another point with the same address on this communication line, so long as it is on a different RTU. The meaning of the parts of the address is given in Table 6-1. If this point is to be a telemetered point, tick the checkbox for Telemetry Address, select the RTU that will provide the data, and fill in the required address.

Table 6-1 Analog Telemetry Address Fields


Meaning

A Line number in the RTU (16 – 80)

B Start byte of the point within the line

=1 for the 1st point

=3 for the 2nd point

=5 for the 3rd point

C 0 (not used)

D 0 (not used)

6.2 Input Format Code This field specifies how the scan task should process the input data from the RTU. Valid format codes are listed in Table 6-2. Analog point values should be assigned format code 1 or 2.

Table 6-2 Input Format Codes for Analog Points

Code Meaning

1 Scale, clamp to zero if value is within zero-clamp deadband and store in database 2 Scale, clamp to zero if value is within zero-clamp deadband and add to database

6.3 Scale Factor and Offset The scale factor and offset represent the conversion factors for a linear transformation of the RTU’s raw input values to engineering units. To determine the appropriate scale factor and offset, you can use the two formulas below:


6-3

Max engineering value - Min engineering value (1) Scale Factor = ________________________________________ Max raw value - Min raw value (2) Offset = Min engineering value - (Scale factor * Min raw value) where the Max and Min engineering values are the values you want to see, and the Max and Min raw values are the range of values obtained from the RTU. Suppose, for example, that you are using a 4-20 ma transducer to measure water level in a reservoir, and that the RTU’s D/A converter converts this to measured raw values in the range 400 to 2000. If the minimum and maximum water levels are 100 and 200 meters respectively, then equations (1) and (2) produce: 200 - 100 Scale Factor = _________ = 0.0625 2000 - 400 Offset = 100 - (0.0625 * 400) = 75.0

You can check your work by using the resulting scale factor and offset to convert a mid-point raw value. In this case, a mid-point raw value of 1200 scales to the expected engineering value of 150 meters.

6.4 Zero Clamp Deadband This defines a deadband range of engineering values inside of which an input will be clamped to an engineering value of zero. This allows you to eliminate noisy readings around the zero mark of the engineering scale. The zero clamp deadband is specified in engineering units, and is applied to points with format code 1 or 2 only. See section 6.2, Input Format Code. You can use this to eliminate the annoying couple of amps or volts that often show up on a dead line because of sensor noise or slight miscalibration. Or in a pipeline application, you can eliminate extremely low pressure or flow readings in an empty pipe. For example, if the zero clamp deadband is 3.0, then any input value which converts to between +3.0 and -3.0 engineering units will be clamped to zero.

6.5 Setpoints The Wesdac protocol, and hence also the scan task, do not support setpoints.


6-4

6.6 Accumulators

The Wesdac protocol, and hence also the scan task, do not support accumulators.

Wesdac Scan Task User’s Guide Monitoring Communication Windows SCADA

7-1

7 Monitoring Communication The SCADA system includes a client program called ScanMon that allows you to monitor logging from various SCADA programs. ScanMon is discussed in detail in SM-400, Survalent SCADA System Manager’s Guide for Windows. Once ScanMon is connected to the Wesdac scan task for the desired communication line, it will log all communication with one or all of its RTUs. You can use the information shown in the log to diagnose communication difficulties you may be having, or to confirm that the SCADA system is receiving the expected data.


7-2

7.1 Monitoring Wesdac To connect to the scan task you will need to enter its name when you start logging, as shown in Figure 7-1. Enter the name “Wesdac”, plus the ID number of the communication line. Both of these pieces of information can be found on the communication line dialog in the SCADA Explorer. For example, if your communication line has an internal ID number of 7, then the name you need is Wesdac7. Next, choose what communication you want to monitor. You can specify which RTU you are interested in, in the RTU Address field, and you can choose the type of information to include in the log from the drop-down list Log Type.

Figure 7-1 "Start Logging" Dialog

The support for ScanMon built into the WESDAC scan task includes the log types shown in Table 7-1. The other choices you may find in the list are not intended for use with this scan task.

Table 7-1 ScanMon Log Types

Log Type ScanMon Function

Default Log each transmitted and received message, formatted for reading.

Hex Log as above, but include a listing of every byte sent or received, in hexadecimal.

Debug Log as in Hex mode, but with additional decoded details of point values.

Errors Only Only log messages containing errors (e.g. timeouts or security errors).

A sample of typical ScanMon output is shown in Figure 7-2 using Debug logging. (Lines containing “... ... ...” indicate where sections of the log have been removed so that an example of an all-data poll could be included.)


7-3

Figure 7-2 ScanMon Output 4 ******************************************* 5 Logging of wesdac7 started 15:20:11 Tuesday, February 28, 2006 6 ******************************************* 7 8 15:20:11.656 Wesdac7 <2228> P--> ["Normal", 6] "Return All Data" 9 01 00 03 00 63 78 10 RTU: 1 Func:0 Ident:3 Start:0 Stop:99 BCH:x78 11 15:20:12.078 Wesdac7 <2228> P<-- [Success, 72] "Return All Data" 12 01 00 03 00 63 09 00 33 13 00 01 02 03 04 05 02 2C 14 00 01 02 03 04 05 03 59 15 00 01 02 03 04 05 04 54 16 00 01 02 03 04 05 10 02 17 00 01 02 03 04 05 11 77 18 00 01 02 03 04 05 12 4B 19 00 01 02 03 04 05 13 3E 20 00 01 02 03 04 05 14 33 21 RTU: 1 Func:0 Ident:3 Start:0 Stop:99 Lines:09 Line0:00 BCH:x33 22 Status Line:2 23 Byte1(0-7): 0 0 0 0 0 0 0 0 24 Byte2(0-7): 1 0 0 0 0 0 0 0 25 Byte3(0-7): 0 1 0 0 0 0 0 0 26 Byte4(0-7): 1 1 0 0 0 0 0 0 27 Byte5(0-7): 0 0 1 0 0 0 0 0 28 Byte6(0-7): 1 0 1 0 0 0 0 0 29 Status Line:3 30 Byte1(0-7): 0 0 0 0 0 0 0 0 31 Byte2(0-7): 1 0 0 0 0 0 0 0 32 Byte3(0-7): 0 1 0 0 0 0 0 0 33 Byte4(0-7): 1 1 0 0 0 0 0 0 34 Byte5(0-7): 0 0 1 0 0 0 0 0 35 Byte6(0-7): 1 0 1 0 0 0 0 0 36 Status Line:4 37 Byte1(0-7): 0 0 0 0 0 0 0 0 38 Byte2(0-7): 1 0 0 0 0 0 0 0 39 Byte3(0-7): 0 1 0 0 0 0 0 0 40 Byte4(0-7): 1 1 0 0 0 0 0 0 41 Byte5(0-7): 0 0 1 0 0 0 0 0 42 Byte6(0-7): 1 0 1 0 0 0 0 0 43 Line16(1-3): 1 515 1029 44 Line17(1-3): 1 515 1029 45 Line18(1-3): 1 515 1029 46 Line19(1-3): 1 515 1029 47 Line20(1-3): 1 515 1029 48 49 15:20:13.140 Wesdac7 <2228> P--> ["Normal", 6] "Return All Data" 50 01 00 03 00 63 78 51 RTU: 1 Func:0 Ident:3 Start:0 Stop:99 BCH:x78 52 15:20:13.578 Wesdac7 <2228> P<-- [Success, 72] "Return All Data" 53 01 00 03 00 63 09 00 33 54 00 01 02 03 04 05 02 2C 55 00 01 02 03 04 05 03 59 56 00 01 02 03 04 05 04 54 57 00 01 02 03 04 05 10 02 58 00 01 02 03 04 05 11 77 59 00 01 02 03 04 05 12 4B 60 00 01 02 03 04 05 13 3E 61 00 01 02 03 04 05 14 33 62 RTU: 1 Func:0 Ident:3 Start:0 Stop:99 Lines:09 Line0:00 BCH:x33 63 Status Line:2 64 Byte1(0-7): 0 0 0 0 0 0 0 0 65 Byte2(0-7): 1 0 0 0 0 0 0 0 66 Byte3(0-7): 0 1 0 0 0 0 0 0


7-4

67 Byte4(0-7): 1 1 0 0 0 0 0 0 68 Byte5(0-7): 0 0 1 0 0 0 0 0 69 Byte6(0-7): 1 0 1 0 0 0 0 0 70 Status Line:3 71 Byte1(0-7): 0 0 0 0 0 0 0 0 72 Byte2(0-7): 1 0 0 0 0 0 0 0 73 Byte3(0-7): 0 1 0 0 0 0 0 0 74 Byte4(0-7): 1 1 0 0 0 0 0 0 75 Byte5(0-7): 0 0 1 0 0 0 0 0 76 Byte6(0-7): 1 0 1 0 0 0 0 0 77 Status Line:4 78 Byte1(0-7): 0 0 0 0 0 0 0 0 79 Byte2(0-7): 1 0 0 0 0 0 0 0 80 Byte3(0-7): 0 1 0 0 0 0 0 0 81 Byte4(0-7): 1 1 0 0 0 0 0 0 82 Byte5(0-7): 0 0 1 0 0 0 0 0 83 Byte6(0-7): 1 0 1 0 0 0 0 0 84 Line16(1-3): 1 515 1029 85 Line17(1-3): 1 515 1029 86 Line18(1-3): 1 515 1029 87 Line19(1-3): 1 515 1029 88 Line20(1-3): 1 515 1029 89 …….. 213 15:20:18.078 Wesdac7 <2228> P--> ["All Data", 6] "Return All Data" 214 01 00 03 00 63 78 215 RTU: 1 Func:0 Ident:3 Start:0 Stop:99 BCH:x78 216 15:20:19.015 Wesdac7 <2228> P<-- [Success, 72] "Return All Data" 217 01 00 03 00 63 09 00 33 218 00 01 02 03 04 05 02 2C 219 00 01 02 03 04 05 03 59 220 00 01 02 03 04 05 04 54 221 00 01 02 03 04 05 10 02 222 00 01 02 03 04 05 11 77 223 00 01 02 03 04 05 12 4B 224 00 01 02 03 04 05 13 3E 225 00 01 02 03 04 05 14 33 226 RTU: 1 Func:0 Ident:3 Start:0 Stop:99 Lines:09 Line0:00 BCH:x33 227 Status Line:2 228 Byte1(0-7): 0 0 0 0 0 0 0 0 229 Byte2(0-7): 1 0 0 0 0 0 0 0 230 Byte3(0-7): 0 1 0 0 0 0 0 0 231 Byte4(0-7): 1 1 0 0 0 0 0 0 232 Byte5(0-7): 0 0 1 0 0 0 0 0 233 Byte6(0-7): 1 0 1 0 0 0 0 0 234 Status Line:3 235 Byte1(0-7): 0 0 0 0 0 0 0 0 236 Byte2(0-7): 1 0 0 0 0 0 0 0 237 Byte3(0-7): 0 1 0 0 0 0 0 0 238 Byte4(0-7): 1 1 0 0 0 0 0 0 239 Byte5(0-7): 0 0 1 0 0 0 0 0 240 Byte6(0-7): 1 0 1 0 0 0 0 0 241 Status Line:4 242 Byte1(0-7): 0 0 0 0 0 0 0 0 243 Byte2(0-7): 1 0 0 0 0 0 0 0 244 Byte3(0-7): 0 1 0 0 0 0 0 0 245 Byte4(0-7): 1 1 0 0 0 0 0 0 246 Byte5(0-7): 0 0 1 0 0 0 0 0 247 Byte6(0-7): 1 0 1 0 0 0 0 0 248 Line16(1-3): 1 515 1029 249 Line17(1-3): 1 515 1029 250 Line18(1-3): 1 515 1029 251 Line19(1-3): 1 515 1029 252 Line20(1-3): 1 515 1029 253 254 15:20:19.015 Wesdac7 <2228> P--> ["TimeSync", 6] "Time Sync"


7-5

255 01 03 0F 14 13 5E 256 RTU: 1 Func:3 Time: 15:20:19 BCH:x5E 257 15:20:19.875 Wesdac7 <2228> P<-- [Success, 8] "Time Sync" 258 01 03 0F 14 13 01 00 4D 259 RTU: 1 Func:3 Time: 15:20:19 BCH:x4D 260 261 15:20:20.937 Wesdac7 <2228> P--> ["Normal", 6] "Return All Data" 262 01 00 03 00 63 78 263 RTU: 1 Func:0 Ident:3 Start:0 Stop:99 BCH:x78 264 15:20:21.375 Wesdac7 <2228> P<-- [Success, 72] "Return All Data" 265 01 00 03 00 63 09 00 33 266 00 01 02 03 04 05 02 2C 267 00 01 02 03 04 05 03 59 268 00 01 02 03 04 05 04 54 269 00 01 02 03 04 05 10 02 270 00 01 02 03 04 05 11 77 271 00 01 02 03 04 05 12 4B 272 00 01 02 03 04 05 13 3E 273 00 01 02 03 04 05 14 33 274 RTU: 1 Func:0 Ident:3 Start:0 Stop:99 Lines:09 Line0:00 BCH:x33 275 Status Line:2 276 Byte1(0-7): 0 0 0 0 0 0 0 0 277 Byte2(0-7): 1 0 0 0 0 0 0 0 278 Byte3(0-7): 0 1 0 0 0 0 0 0 279 Byte4(0-7): 1 1 0 0 0 0 0 0 280 Byte5(0-7): 0 0 1 0 0 0 0 0 281 Byte6(0-7): 1 0 1 0 0 0 0 0 282 Status Line:3 283 Byte1(0-7): 0 0 0 0 0 0 0 0 284 Byte2(0-7): 1 0 0 0 0 0 0 0 285 Byte3(0-7): 0 1 0 0 0 0 0 0 286 Byte4(0-7): 1 1 0 0 0 0 0 0 287 Byte5(0-7): 0 0 1 0 0 0 0 0 288 Byte6(0-7): 1 0 1 0 0 0 0 0 289 Status Line:4 290 Byte1(0-7): 0 0 0 0 0 0 0 0 291 Byte2(0-7): 1 0 0 0 0 0 0 0 292 Byte3(0-7): 0 1 0 0 0 0 0 0 293 Byte4(0-7): 1 1 0 0 0 0 0 0 294 Byte5(0-7): 0 0 1 0 0 0 0 0 295 Byte6(0-7): 1 0 1 0 0 0 0 0 296 Line16(1-3): 1 515 1029 297 Line17(1-3): 1 515 1029 298 Line18(1-3): 1 515 1029 299 Line19(1-3): 1 515 1029 300 Line20(1-3): 1 515 1029 Notes:

• The scan tasks only log to the destination specified by the most recent ScanMon command. If you, for example, start a ScanMon at your computer, and then someone else starts a ScanMon at another computer, the output in your window will stop.

• On a scan table rebuild, the scan task process stops and restarts. Any ScanMon that was previously going on will stop. If you wish to continue monitoring, you will need to start logging again.

Wesdac Scan Task User’s Guide Implementation Table Windows SCADA

8-1

8 Implementation Table

The following implementation table indicates the Wesdac function codes that are supported by the present implementation of the Wesdac scan task.

Table 8-1 Implementation Table

Implemented

Execute Code

Indent Code

Function Description

0

3

Return all current data (full update) – current values of all implemented points are returned.

0

6

Data acknowledge – acknowledges receipt of data by master.

1

0

Close control point on command. Method is either direct or select/check/execute.

1

1

Trip control point on command. Method is either direct or select/check/execute

3

n/a

Time update – all stations or specific station. This command also clears the RTU restart flag.

255

n/a

RAM download – store a single byte to a RTU memory location

wesdac.pdf

Documents

Transcript of wesdac.pdf