Citect for Windows Driver Specification Bailey Driver

Author: Company:

Simon Frost WA. Cromarty Pty Ltd 23/1/1998 21/8/1998 8/12/1998

Date: Modified Modified

Driver Design Specification

Contents

1.

QA
1.1 Introduction 1.2 Procedure for generating a new driver

4
4 4

2.

TARGET DEVICE(S) AND PROTOCOL

2.1 Introduction 2.2 Device Manufacturer 2.3 Device Definition
2.3.1 2.3.2 INFI-NET and Plant Loop Interfaces. Control way and Modules Bus interfaces.

5
5 5 5
5 9

2.4 Communications Method 2.5 Communications/Hardware Configuration

2.5.1 2.5.2 2.5.3 Wiring Diagrams I/O Device Settings Software Setup

12 12
12 14 14

2.6 Special Requirements 2.7 Maximum Request Length 2.8 Contacts

14 14 15

3.

PROTOCOL REQUIREMENTS
3.1 Introduction 3.2 Initialising the Board 3.3 Initialising the Port 3.4 Initialising the IO Device 3.5 IO Device Online Test 3.6 State Flow Description 3.7 Message Structure
3.7.1 3.7.2 3.7.3 3.7.4 3.7.5 Initialization Commands Configuration Commands Read Commands Write Commands Tune Commands

16
16 16 16 16 16 16 17
20 20 21 21 21

3.8 Data Format 3.9 Check Sum 3.10 Error Handling

22 22 22

BaileySA1.DOC

Driver Design Specification

4.

USER INTERFACE
4.1 Introduction 4.2 Driver Name 4.3 Boards Form 4.4 Ports Form 4.5 IO Devices Form 4.6 Pulldown lists Help 4.7 IO Device Variable Types 4.8 PROTDIR.DBF 4.9 Parameters and INI options
4.9.1 4.9.2 Standard Parameters Driver Specific Parameters

23
23 23 23 23 24 24 24 30 30
30 31

4.10 4.11 4.12 4.13 4.14

Driver Specific Errors Driver Error Help Debug Messages Stats Special Counters Hints and Tips
Improving System Performance Using BR, BI and BD tags Function Codes Indexing Tags Time synchronisation Troubleshooting

33 35 39 40 41
41 42 42 43 43 43

4.14.1 4.14.2 4.14.3 4.14.4 4.14.5 4.14.6

5.

BASIC TESTING
5.1 Introduction 5.2 Procedure

45
45 45

6.

PERFORMANCE TESTING
6.1 Introduction 6.2 Calculating the Blocking Constant

46
46 46

7.

REFERENCES
7.1 References

47
47

8.

APPENDIX
Appendix A Initialization flow chart Appendix B Configuration flowchart Appendix C Bailey Driver Execution flowchart

48
48 49 50

BaileySA1.DOC

Driver Design Specification

1.

QA

1.1

Introduction

This document follows the development of the Bailey driver. It serves as a functional specification, design specification and test specification.

1.2

Procedure for generating a new driver

The following check list defines the QA steps for generating a new driver. This procedure must be followed for drivers to be integrated into Citect. Description 1 2 3 4 5 6 7 This specification document is written. Specification reviewed and accepted by R&D department. Driver coded. Code and specification reviewed and accepted by R&D department. Testing with connection project, and performance test. Driver integrated into Citect source and built. Documentation is written (HLP or MVB files) At this checkpoint coding is done and the driver is available as a beta. 8a 8b 8c Full testing is carried out. Performance testing is carried out. Specification and documentation updated from testing/performance tests At this checkpoint the testing is complete. 9a 9b 9c 9d 10 Review for completeness by developer, tester, documenter and R&D staff Add driver to install disks Add driver to protocols database Support notified of new driver for training purposes Sales notified of new driver The driver is now finished. PW, SF 18/11/92 Person SF Date 3/09/98

The hand over of a driver requires that all the above steps are completed and checked off.

BaileySA1.DOC

Driver Design Specification

2.

Target Device(s) and Protocol

2.1

Introduction

There are many devices made by Elsag Bailey to enable communication between host computers and their DCS equipment. A simple binary serial protocol is employed via a RS232C connection to interface between host computer and DCS. The interface provides connectivity to the DCS internal network protocol enabling transfer of messages to and from host computers and modules distributed through out the network. The DCS uses a variety of internal protocols such as Module Bus, Control way, INFI-NET and Plant loop to communicate between module, PCU and OIS. Elsag Bailey provides hardware interfaces, which use the common serial protocol to interface host computers to these protocols. The Elsag Bailey DCS comes in two varieties, Network 90 and INFI 90. The names distinguish between the type of communication being used within a PCU and between PCUs. The Network 90 DCS is the older systems which uses Module bus and Plant loop. While INFI90 is the newer system, which uses Module bus, plant loop, Control way and INFI-NET. The two types of Elsag Bailey DCS equipment can be linked together using specialised hardware interface units, meaning that Network 90 and INFI90 systems can coexist in the same, plant, system or PCU.

2.2

Device Manufacturer

Bailey Controls Australia Pty Ltd., Regent Park, NSW Australia. A Babcock & Wilcox Company.

2.3

Device Definition

There are two distinct hardware interface unit types used by Elsag Bailey to provide connectivity between host computers and their DCS system: 2.3.1 INFI-NET and Plant Loop Interfaces.

These interfaces are generally called Computer Interface Units CIU. CIU are combinations of hardware, which provide the following functionality: 1) 2) 3) Host interface (RS232C communication and termination) Process control unit (PCU) interface (INFI-NET or Plant Loop communication) Data storage and data transfer control.

The data storage and data transfer control module holds the exception report routing database and directs the operations of both process control unit interface and the host interface. It acts as the translator between the INFI-NET/Plant loop, host computer and the control way/module bus. It communicates directly with the PCU interface hardware and monitors the local control way/module bus. It polls each local PCU module on the control way/module bus for exception reports using the following criteria: i) ii) iii) A points changes by a significant amount The maximum exception report time expires An alarm condition changes

BaileySA1.DOC

Driver Design Specification

The exception reports are packed together with other exception reports having a common node destination and transferred to the PCU interface for transmission. The PCU interface receives all incoming messages from other PCU interfaces on the loop and retransmits a new stream of messages in a store and forward fashion to the next node. When there are no messages to transmit the module transmit null packets to keep the loop synchronized. The host interface is generally a termination unit, which provides level conversion and isolation between the host computer and the DCS equipment. CIU Host interfaces PCU interface Data storage and control CIC01 SIM (Serial interface module) & PTM (Point table module) BTM(Bus transfer module) & LSM(Loop storage module) PCT ( Plant loop to Computer Transfer module) & BTM Bus transfer module) ICT(Computer transfer module) ICT(Computer transfer module) & MPI (Multifunction Processor interface)

CIC01 NCIU01 or INPCI01

CIC01 TCU (Computer interface termination unit)

None LIM (Loop interface module)

NCIU02

TPL(Plant loop termination unit)

LIM(Loop interface module)

NCIU03 or INPCI02

TMF(Multi function Controller Termination unit)

LIM (Loop interface module)

NCIU04 or INICI01 INICI03

ICL (Communication Termination unit) TPM (Multi function processor termination unit)

NIS (Network interface slave) NIS (Network interface slave)

BaileySA1.DOC

Driver Design Specification

2.3.1.1

Diagram NCIU01/INPCI01

BaileySA1.DOC

Driver Design Specification

2.3.1.2

Diagram NCIU03/INPCI02

2.3.1.3

Diagram NCIU04/INICI01 and INICI03

BaileySA1.DOC

Driver Design Specification

2.3.2

Control way and Modules Bus interfaces.

These interfaces are generally called serial port modules (SPM) or Communication Port modules (CPM). These are single slot units, which occupy one slot in a Module Mounting Unit (MMU) within a PCU. They provide: 1) 2) Host interface (RS232C communication and termination) Module interface (Control way or Modules bus communication)

SPM and CPM are designed to provide local (within PCU) system configuration, tuning and diagnostics. They enable the host to configure, tune and monitor the master modules and their function blocks. They do not provide the exception reporting facility offered by a CIU, instead to monitor a point the host must poll it directly. The diagrams below use the acronyms defined in this diagram. Host computer may be substituted for EWS.

BaileySA1.DOC

Driver Design Specification

2.3.2.1

Diagram IMCPM01

2.3.2.2

Diagram IMCPM02

BaileySA1.DOC

10

Driver Design Specification

2.3.2.3

Diagram IMCPM03

BaileySA1.DOC

11

Driver Design Specification

2.3.2.4

Diagram IMSPMO1 or NSPM01

2.4

Communications Method

CITECT communicates to each style of device via a RS232C connection.

2.5
2.5.1

Communications/Hardware Configuration
Wiring Diagrams

The NSPM01 is designed to function as DCE through a type Z interchange. This is a nonspecified optional interchange, which allows equipment manufactures to define what signals will be used. To minimize the chance of confusion, a detailed description of each signal line of the NSPM01s serial port is given below. Please note that the RS-232C specification identifies pin names and functions with respect to DTE. The pin numbers below refer to the front panel connector on the NSPM01. Kudos

Pin 1 Pin 2 Pin 3 Pin 4

GROUND/SHEILD A protective ground line, which is electrically connected to the equipment frame. TRANSMITTED DATA (TX DATA). Signals on this pin are the input of serial data to the module RECEIVED DATA (RX DATA). Signals on this pin are the serial data output from the module REQUEST TO SEND (RTS). This signal is an input to the DCE that signals a request from the DTE to begin a transfer of data. This signal is not used on the by default in most modules but can be selected using jumpers on the boards.

BaileySA1.DOC

12

Driver Design Specification

Pin 5

Pin 6

Pin 7 Pin 8

Pin 20

CLEAR TO SEND (CTS). This signal is an output from the DCE in response to receiving a RTS signal. Since the RTS signal is disabled by default, the module generates the CTS signal as long as the Machine Fault Timer is in its normal state. DATA SET READY (DSR). This signal is also an output from the DCE to the DTE. Because of the overlap of signal definition with respect to the modules, this signal is synonymous with the CTS signal. Both signals are generated at a common point. SIGNAL GROUND. This is the common for all signals. RECEIVED LINE SIGNAL DETECT (RLSD). This signal is generated to indicate that a valid communication link has been established. For the NSPM01 module, this signal is used to indicate when access to the Module Bus is possible. Again, as with Pins 5 and 6, if the Machine Fault Timer is normal, the communication link is considered to be present. This signal is synonymous with the CTS and DSR signals on the NSPM01 but is provided to allow interfacing with other data equipment. DATA TERMINAL READY (DTR). This is an input to the DCE. It is to confirm that the DTE is there and that the communication link is to be maintained. If the signal is not generated by the DTE, jumpers are provided on the modules so that the need for this input can be eliminated.

All other pin assignments of the RS232C interchange are grouped into a dont care classification.

2.5.1.1 Serial Wiring Diagram (1) for DIGIBOARD ports INFI 90 RS-232 DIGIBOARD PORT ICI-01 (DTE) For DCE wiring reverse these two connections

TX RX RTS CTS DSR SG DCD DTR

2 3 4 5 6 7 8 20 D Connector 25-WAY FEMALE D Connector 25-WAY FEMALE

2 3 4 5 6 7 8 20

TX RX RTS CTS DSR SG DCD DTR

BaileySA1.DOC

13

Driver Design Specification

2.5.1.2

Serial Wiring Diagram (2) for COM ports INFI 90 RS-232 COM PORT ICI-01 (DTE) For DCE wiring reverse these two connections 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 20 D Connector 9-WAY FEMALE D Connector 25-WAY FEMALE SHLD TX RX RTS CTS DSR SG DCD DTR

DCD RX TX DTR SG DSR RTS CTS

2.5.2

I/O Device Settings

Refer to Bailey network 90 Serial Port Module (NSPM01) Product Instruction manual E93-905-1 Special attention should be directed to switches SW3 (port settings) and Jumpers JP9 and JP10 (Connecting baud rate). 2.5.3 None Software Setup

2.6

Special Requirements

There is no special setup required for this protocol - only to ensure the Citect driver (BAILEY.DLL) is used.

2.7

Maximum Request Length

2048 Bytes

BaileySA1.DOC

14

Driver Design Specification

2.8

Contacts

Simon Frost W.A. Cromarty Pty Ltd 79 Howick Street, South Launceston, Tasmania 7249 Tel 03 63449110 Fax 03 63441221

Bruce Kinchin Ci Technologies Pty Limited 10-12 West Street PO Box 174 Pymble NSW 2073 Australia Tel: (02) 855 1000 Fax: (02) 488 9164

BaileySA1.DOC

15

Driver Design Specification

3.

Protocol Requirements

3.1

Introduction

This section outlines the protocol and execution flow of the Bailey driver. The protocol is not covered in depth here as an adequate description is given in [1].

3.2

Initialising the Board

The driver uses standard RS232 communication. Therefore only the normal board initialization carried out by CITECT is required.

3.3

Initialising the Port

The port is opened using the COMSetVector function and reset using the COMReset each time the driver is restarted.

3.4

Initialising the IO Device

The CIU device requires extensive initialization while the SPM and CPM modules require only to be restarted. See Appendix A Initialization flow chart and Appendix B Configuration flow chart

3.5

IO Device Online Test

The device is considered to be online after the initialization has been completed. See Appendix A Initialization flow chart. There exists a special condition where the unit does not go on line until both the initialization and configuration (See Appendix B Configuration flow chart) have been completed. This special case has been included to make swapping from a secondary server back to a primary server seamless. This will only occur if CIU > 0 BackGroundInit = 1 and the device has been initialized successfully by the driver prior to the current initialization attempt.

3.6

State Flow Description

This driver is based on the front-end back-end model. The front end services all requests from the IOSERVER. All requests are handled through the READDCB and WRITEDCB calls. Read requests are separated into tag types, TUNE BLOCK (TR, TI, TD), READ BLOCK OUTPUT (BR, BI, BD) and point tags (PV, SP, RI etc). The back end of the driver maintains a image of the CIU point table and all requests for point tag data are serviced from the in\mage. Read requests for READ BLOCK OUTPUT tags and TUNE BLOCK tags are handled by the back-end. See 3.7.3 Read commands and 3.7.5 Tune commands for respective descriptions. Write request are also separated into point tags and TUNE BLOCK tags. As with the read requests the write tags are handled by the back-end of the driver. To facilitate continuity of the backend polling strategy all requests that cannot be handled directly by the front end are placed in the IN queue. The IN queue is then serviced during the polling operations of the back-end. Commands generated from the IN queue OUT queue or polling cycle are transmitted and placed in the OUT queue. Responses from the Bailey host communication equipment are matched to an item in the OUT queue. The driver replied to the IOSERVER immediately with write responses. Read responses may be replied directly or placed in the RETURN queue. The RETURN queue uses a timer to delay the read responses to the IOSERVER. The OUT queue is given the highest priority during the operation of the back-end. The IN queue is serviced next and finally exception reports are polled. The responses to polled commands are

BaileySA1.DOC

16

Driver Design Specification

decoded and used to update the internal point table image. See Appendix C Bailey Driver Execution flowchart for further details

3.7

Message Structure

The Bailey host communication equipment uses binary COMANDS and REPLIES to send messages back and forth between host and DCS. Each information transfer is a command from the host followed by a reply from the bailey equipment. The message structures are: Command: Reply: <COMMAND CODE><COMMAND STRUCTURE><CHECKSUM>0D <REPLY CODE><REPLY STRUCTURE><CHECKSUM>0D

The message structure of both the commands and replies are outlined in Sections 2 of [1]. Commands and relies are terminated by the 0D (HEX). To avoid 0D as a character within a message, the driver must translate both 0D and 1B into 1B0E and 1B1B receptively for commands and visa versa for replies. Section 3 of [1] covers this topic. The driver communicates with a CIU uses the following messages. To communicate with a CPM or SPM unit only the CIU RESTART, ENVIRONMENT, READ BLOCK, READ BLOCK OUTPUT, TUNE BLOCK and DEMAND MODULE STATUS messages are uses as these units have a reduced command set. (See CIU parameter below 4.9.2.4) The driver used 26 IO Device Variable Types (see 4.7) to perform all its IO with the Bailey host communication equipment. Each IO Device Variable type is associated with one or more of the messages below.

Message/Command
CIU RESTART

CODE
19

Description
Clears the CIU points table and give the CIU its executive control parameters. This command returns the CIU environment data. The data identifies the CIU module type and operation mode Enters a point in the CIU points table and establishes exception report receiving. Removes a point from the points table Enters a point in the CIU points table, and establishes and connects a route so the index receives exception reports Enters a report point into the CIU table Connects already established input routes Disconnects points to keep un-

ENVIRONMENT

69

ESTABLISH POINT

DISESTABLISH POINT

23

ESTABLISH AND CONNECT POINT

49

ESTABLISH REPORT

CONNECT POINT LIST

DISCONNECT POINT LIST

BaileySA1.DOC

17

Driver Design Specification

needed traffic of the loop. READ EXCEPTION REPORT SPECS 24 Provides the host with point specification information. The points module returns this information after the CIU establishes and exception report route Returns the current status and value of each station variable to be read, or an analog, digital or RMSC point for which the CIU has received an exception report. In order to receive exception reports for a point, the point must have been established. Read Miscellaneous Status Exceptions returns the current status of each station, RCM, and module for which the CIU has received an exception report. In order to receive exception reports for station status, RCM, and module status, the status must have been established. Returns the values of the station variable, analog, and digital points in the requested list. Read miscellaneous status list returns the status of station, RCMs, and modules for the requested list. Sends an analog or digital exception report, or sets a station variable or RMSC. The point have been established Sends a digital point report, set station mode, or set/reset an RCM function block or command a device driver. Reads the configuration of a block configured in a module. While the module is in configure or execution mode. Allows the host to read the output of a block in a module, even though the block does not generate exception reports. The block does not need to be es-

READ EXCEPTION

READ MISC STATUS EXCEPTION

22

READ VALUE LIST

READ MISC STATUS LIST

21

OUTPUT VALUE

10

OUTPUT STATUS

11

READ BLOCK

13

READ BLOCK OUTPUT

20

BaileySA1.DOC

18

Driver Design Specification

tablished in the CIU point table TUNE BLOCK 17 Changes the tune parameters of a block. Allows the host to read the status of any module, even if the modules status is not established in the point list.

DEMAND MODULE STATUS

27

Note: The byte structure of each of the above commands and their respective replies can be found in section 2of [1]. Several of these commands require the address of a specific block location within the DCS system. Bailey uses a propriety addressing system, which does not map well into that, used by CITECT. The system refers to a specific block within the DCS using: Name Ring Node Module Block Range 07 0 255 0 31 0 16383 Description The loop that the PCU is on The PCU number The module within the PCU The block within the module.

For exception reporting purposes. Route which map a block within the DCS into a CIU point database are referred to by: Name Index Range 0 10000 Description The point number in the CIU database

To facilitate this in the code the DATAPOINT structure has been mapped into the MAPPOINT structure. Therefore UnitAddress and UnitType fields are assigned as follows at compile time. UnitAddress Bits Bit 31 Bit 30 Bit 29 24 Bit 23 16 Bit 15 0 Write flag Read flag Point type (PV, SP, CO, RI, A, SS, D, SM, MS, RCM, RMSC etc) This byte will be put into UnitAddress when 0 is entered as an index Index Description

UnitType Bits

Description

BaileySA1.DOC

19

Driver Design Specification

Bit 29 16 Bit 15 11 Bit 10 3 Bit 2 0

Block Module Node Ring

3.7.1

Initialization Commands

Initialization is a function performed by the back end of the driver. The driver performs initialization functions with the following commands. CIU RESTART, ENVIRONMENT, CONNECT POINT LIST and DISCONNECT POINT LIST. The initialization takes two forms. If the CIU = 0 or the MapPath = NULL then a CIU RESTART command is issued followed by an ENVIRONMENT. Otherwise the driver uses DISCONNECT POINT LIST to remove all of the existing CIU point routes and then reconnects them using CONNECT POINT LIST. This forces the CIU to refresh its point table and provide a fresh exception reports for each point. 3.7.2 Configuration Commands

Configuration is a function performed by the back-end of the driver. The driver performs configuration functions with the following commands. ESTABLISH POINT, DISESTABLISH POINT, ESTABLISH AND CONNECT POINT, CONNECT POINT LIST and ESTABLISH REPORT. Configuration only occurs if CIU > 0. Configuration is the process of building the CIU internal point table. Each point in the table must be first established using one of the establishment commands and then connected with a connect command. These two commands enter a point into the CIU database and link that point to a block within the DCS. Configuration may occur in the background, or as each point is accessed by CITECT. If BackGroundInit = 0 the driver tries to establish and connect each point as it is accessed by CITECT. Otherwise the driver tries to establish and connect all points which are not being accessed by CITECT in the background during normal polling for exception reports. The majority of IO device variable tag listed in 4.7 can be associated with a point in the CIU. The driver uses the index field when establishing a point in the CIU. The index is a unique number associated with one block in the DCS. All IO device variables addressing the same block within the DCS should have the same index number, making transfer of data more efficient and reducing network overheads. When the MapPath <> NULL the DISESTABLISH POINT command many be used to remove a point in the CIU database if that point (index) has been removed from the CITECT project or the index has been assigned to a different block. The following table shows the IO variable tag types, which are established and removed by the various commands. ESTABLISH POINT DISESTABLISH POINT ESTABLISH AND CONNECT POINT ESTABLISH REPORT MS, WSP, WCO, WRI, SM All PV, SP, CO, RI, A, SS, EMS, D, RCM, RMSC WD, WA

BaileySA1.DOC

20

Driver Design Specification

3.7.3

Read Commands

The driver performs read functions with the following commands. READ EX-CEPTION REPORT SPECS READ EXCEP-TION, READ MISC STATUS EXCEP-TION, READ VALUE LIST, READ MISC STATUS LIST, READ BLOCK OUT-PUT and DEMAND MODULE STATUS. This driver is primarily based on the front-end back-end model however the READ BLOCK OUTPUT and DEMAND STATUS commands fall under the Request based model. When CITECT services tags, which uses these messages the driver issues the commands directly and waits for a reply. All other tags except those associated with tunable parameters (see below 3.7.5) are serviced from the drivers internal image of the point table. This image is maintained by continuously polling the CIU for exception reports. Using exception reporting tags is preferable as READ BLOCK OUTPUT commands are slow and reduce the efficiency of both the driver and DCS network. The following table shows the IO variable tag types, which are read by the various read commands. READ EXCEPTION REPORT SPECS READ EXCEPTION READ MISC STATUS EXCEPTION READ VALUE LIST READ MISC STATUS LIST READ BLOCK OUTPUT DEMAND MODULE STATUS PV, SP PV, SP, CO, RI, A, D, RCM, RMSC SS, RCM, MS, EMS PV, SP, CO, RI, A, D, RCM, RMSC SS, MS, RCM, EMS BR, BI, BD MS

3.7.4

Write Commands

The driver performs write functions with the following commands OUTPUT VALUE and OUTPUT STATUS. Write commands from CITECT are immediately formatted and transmitted. The following table shows the IO variable tag types, which are written by the various write commands OUTPUT VALUE OUTPUT STATUS WSP, WCO, WRI, WA, WD, RMSC RMC, SM

3.7.5

Tune Commands

Tunable blocks within a DCS are both read and written to by CITECT. However they are treated differently by the driver because the function of reading and writing them is slower than exception reporting. Tunable blocks are read using READ BLOCK the resulting reply is cached by the driver and used to service further requests until the data has been cached for a period greater than WatchTime. At which time the following access to that tune block will cause the driver to issue another READ BLOCK command.

BaileySA1.DOC

21

Driver Design Specification

When CITECT writes to a tune block the block is first read using READ BLOCK and then written to using TUNE BLOCK. The driver needs to read the block first to establish all the parameter of the block before changing any of them and writing the block back into the DCS. Tunable parameters can be cached because they are not modified very often. However it is possible that two people could tune the same block within the WatchTime causing one person to have invalid data on that particular block. The following table shows the IO variable tag types, which are written and read by the various tune commands READ BLOCK TUNE BLOCK TR, TI, TD

TR, TI, TD

3.8

Data Format

The data formats used by the Bailey Host Communication Equipment is clearly defined in FIELDS Section 3 Pages 5 8 and Section 6 Page 1 Point 7of [1].

3.9

Check Sum

The byte wise sums of all bytes in the command, except for the checksum byte itself and the command terminator. This single byte quantity is the next to last byte transmitted in the command. Only the command terminator follows it. Commands issued by the host must have checksums. Command replies may have checksums if the checksum option is switched on. The bailey diver expects to see checksums on all replies.

3.10

Error Handling

All reply codes, other than NO ERROR (0) and those mentioned below, received by the driver have 0x100 added to them and assigned to the ErrDriver field of the DCB in the reply to IOSERVER. Data encapsulated in a message with a non 0 reply code is ignored. Certain reply codes can be masked from CITECT using the ErrorMask parameter below (4.9.2.4). In this case the driver uses the error codes to inhibit operations but returns NO ERROR (0) to the IOSERVER. The driver does not return error codes encountered during the polling of exceptions and background establishing of points. Message with non 0 reply codes received during polling are ignored.

BaileySA1.DOC

22

Driver Design Specification

4.

User Interface

4.1

Introduction

This section defines how the user will see the driver. This relates directly to how the Citect forms need to be filled out and any special INI options. For the kernel, the debugs trace messages and the Stats.Special counters are documented.

4.2
Bailey

Driver Name

4.3

Boards Form

Typically you would use a serial board or COM port for this communication. Refer to the instructions for setting up and using COM ports or serial boards, or complete the Boards form as instructed, but with the following specific information. 4.3.1.1 Board Type

If using a serial board or COM port, you should enter COMx . 4.3.1.2 Address

If using a serial board or COM port, you should enter 0. 4.3.1.3 I/O Port

Leave this field blank. 4.3.1.4 Interrupt

Leave this field blank. 4.3.1.5 Special Options

If using a serial board or COM port, you should enter 0.

4.4

Ports Form

You should complete the Ports form as instructed, but with the following specific information. 4.4.1.1 Port Number

This value should match the COM port number. This number is defined in the Ports section of the Control Panel. 4.4.1.2 Baud Rate

This value should match the setting of the ICI-01 - 19200 is recommended.

BaileySA1.DOC

23

Driver Design Specification

4.4.1.3

Data Bits

You must enter 8. 4.4.1.4 Stop Bits

You must enter 1. 4.4.1.5 Parity

This value should match the setting of the ICI-01 - NONE is recommended. 4.4.1.6 Special Options

Leave this field blank.

4.5

IO Devices Form

You should complete the I/O Devices form as instructed, but with the following specific information. 4.5.1.1 I/O Device Address

No address is specified on the ICI-01. Leave this field blank. 4.5.1.2 I/O Device Protocol

You must enter Bailey.

4.6

Pulldown lists Help

The following entries should be included in the Citect Help.DBF spec file. TYPE PROTOCOL DATA BAILEY FILTER

4.7

IO Device Variable Types

Citect data type Address range Description/Special Usage/Limitations READ ONLY

IO Device Type

PV SP CO R A D SS RCM

REAL REAL REAL REAL REAL DIGITAL DIGITAL DIGITAL

Note 4

Process variable Set Point Control Output Ratio Index Analog block (FC 30) Digital block (FC 45) Station Status (FC 21, 22, 23 or 80) Remote switch (RCM, FC62) status

BaileySA1.DOC

24

Driver Design Specification

DD MSDD MS BD BI BR

DIGITAL DIGITAL LONG DIGITAL INT REAL

Device Driver (FC 123) Multi State Device Driver (FC 129) Module Status Read digital block output. Read integer block output. Read real block output. WRITE ONLY

WSP WCO WR WA WD SM WRCM TIME

REAL REAL REAL REAL DIGITAL INT INT LONG None (Note 5)

Write Set Point (Note 1) Write Control Output (Note 1) Write Ratio Index (Note 1) Write Analog block Write Digital block Station Mode Remote switch command (Note 2) Time synchronisation READ or WRITE

RMSC TD TI TR

REAL DIGITAL INT REAL

Remote manual set constant (FC 68) Digital parameter in block (Note 3) Integer parameter in block (Note 3) Real parameter in block (Note 3)

BaileySA1.DOC

25

Driver Design Specification

Note 1. To Use WSP, WCO, or WR, you must put the appropriate Station (FC 21, 22, 23, 80) into the correct mode. This is done with the Station Mode (SM) Command. Station must be set to Computer OK. SM<Index>,<Ring>,<Node>,<Module>,<Block> = 9 SM<Index>,<Ring>,<Node>,<Module>,<Block>=7 SM<Index>,<Ring>,<Node>,<Module>,<Block>=3 This allows the writing to Set Points and Control Outputs (WSP & WCO). When SM = 4 You can then write to Set Points Only (WSP). When SM = 5 You can then write to Ratio Indexes only (WR). Note 2. The WRCM Command writes to Remote Switches, Device Drivers and Multi-State Device Drivers. Referencing the same Index as the DD or MSDD tag enables the WRCM to write to the point. e.g. DD02,0,12,5,100.Q WRCM02,0,12,5,100 MSDD03,0,12,5,120.Q WRCM03,0,12,5,120 Note 3. You can only write to the tunable parameters of a block. Note 4. The Address range has been left blank as the Bailey DCS address system has five fields <Index (1-10000 *)>, <Ring (0-7)>, <Node (0-255)>, <Module (0-31)>, <Block (0-16383**)> each with its own specific range. * ** See specific CIU for maximum point index. See specific Module for maximum block number.

Note 5. No address or index is required. The driver automatically assumes index 1 for the TIME sync tag.

Analog status (PV, SP, CO, R, A) data types have the format PVxxxxx.qqq, SPxxxxx.qqq, COxxxxx.qqq, Rxxxxx.qqq, and Axxxxx.qqq, where "xxxxx" is in the format <Index>, <Ring>, <Node>, <Module>, <Block> and "qqq" is an optional qualifier as detailed below: .BAD .HL .LL .HD .LD Bad Quality High Limit Alarm Low Limit Alarm High Deviation Alarm Low Deviation Alarm

BaileySA1.DOC

26

Driver Design Specification

.RTG .SPT

One or more red tags Set Point tracking

Digital values (D) have the format Dxxxxx.qqq, where "xxxxx" is in the format <Index> , <Ring> , <Node> , <Module> , <Block> and "qqq" is the mandatory qualifier as detailed below: .BAD .ALM .VAL Bad Quality Limit Alarm Value

Station status (SS) data types have the format SSxxxxx.qqq, where "xxxxx" is in the format <Index>, <Ring>, <Node>, <Module>, <Block> and "qqq" is the mandatory qualifier as detailed below: .BYP .MI .OT .DSF .COK .LEV .CRN .A Bypassed, bad analog output Manual Interlock Output Tracking Digital Station failure Computer OK Computer Cascade/ratio Auto

Remote switch (RCM) status has the format RCMxxxxx.qqq, where "xxxxx" is in the format <Index>, <Ring>, <Node>, <Module>, <Block> and "qqq" is the mandatory qualifier as detailed below: .Q .ALM .TAG .OV .SI .SP .RI .OR .FB .SC .RC Bad quality (all other indication are undefined) Alarm Block is tagged Output value of block Logic set input is 1 Set permissive input is 1 Logic reset input value is 1 Override is 1 Feedback value is 1 Set command is 1 Reset command is 1

Device Driver (FC 123) status has the format DDxxxxx.qqq, where "xxxxx" is in the format <Index>, <Ring>, <Node>, <Module>, <Block> and "qqq" is the mandatory qualifier as detailed below: .Q .ALM .TAG .V Bad quality (all other indication are undefined) Alarm Block is tagged Output value of block

BaileySA1.DOC

27

Driver Design Specification

.F1 .F2 .FS .SO .M1 .M0

Input 1 feedback state is 1 Input 2 feedback state is 1 Feedback status value bad is 1 Override is 1 Mode bit 1 Mode bit 0

Multi-State Device Driver (FC 129) status has the format MSDDxxxxx.qqq, where "xxxxx" is in the format <Index>, <Ring>, <Node>, <Module>, <Block> and "qqq" is the mandatory qualifier as detailed below: .Q .ALM .SO .CO .M .TAG .V .F1 .F2 .F3 .F4 .GS1 .GS0 .RS1 .RS0 Bad quality (all other indication are undefined) Alarm Status override is 1 Control override is 1 Auto mode Block is tagged Output value of block Input 1 feedback state is 1 Input 2 feedback state is 1 Input 3 feedback state is 1 Input 4 feedback state is 1 Good state bit 1 Good state bit 0 Request state bit 1 Request state bit 0

Station Mode command Value 0 1 2 3 4 5 6 7 8 9 10 Meaning Go to local-manual (console/station-manual) Go to local-auto (console/station-auto) Go to local-cascade/ratio (console/station-cascade/ratio) Go to computer-manual Go to computer-auto Go to computer cascade/ratio Go to local level (console/station level) Go to computer level Go to computer back-up state Computer OK Go to previous state

Remote Switch (WRCM) command Value Meaning

BaileySA1.DOC

28

Driver Design Specification

1 2 5 6

Sustain reset Sustain set Pulse reset Pulse set

Device Driver (FC 123) command (WRCM) Value 1 2 4 8 Meaning Reset control output Set control output Request manual mode Request automatic mode

Multi-State Device Driver (FC 129)) command (WRCM) Value 0-3 4 8 Meaning Request device driver state (value 0-3) Request manual mode Request automatic mode

Tune block (T) has the format Txxxxx.Sn, where "xxxxx" is in the format <Index>, <Ring>, <Node>, <Module>, <Block> and "n" is the mandatory Specification Number (1 to 128) applied to the specified block. Refer to the Bailey Function Code Manual for details on the Specification Numbers that you can use. Note that not all of the Specification Numbers (parameters) are tunable. Bailey does not use Exception Reporting for tuning parameters, so take care not to slow down the system when using tuning parameters. To improve the performance of tuning parameters, Citect will read tuning parameters every 5 seconds. To reduce the traffic on the Network 90 when reading tune blocks, CITECT reads tune blocks every 15 seconds (3 * [Bailey]Timeout). Writes to tune blocks are performed immediately. Module Status has the format MS.qqq, where "qqq" is the mandatory qualifier as detailed below: .MODE0 .MODE1 see below MODE0 = 0 & MODE1 = 0 Configure MODE0 = 1 & MODE1 = 0 Failed MODE0 = 0 & MODE1 = 1 Error MODE0 = 1 & MODE1 = 1 Execute .ES .STA .EAI .AIE .CAL .LIO .RIO .MSC Errors exist Summary station status (1bad) EEROM contains default configuration (1yes) Auto initialisation input status (1set) Calibration quality status for defined ports (1bad) Summary local IO status (1bad) Summary remote IO status (1bad) for MFC (1backup bad), for LMM (1memory filled)

BaileySA1.DOC

29

Driver Design Specification

.FTX .RING .NODE .MEM .PCU .LT0 .LT1 .LR0 .LR1 .LIM

First time in Execute (1yes) One or more rings are off-line (NCIU04 only) Failure in node environment (NCIU02/03 only) Memory full One or more PCUs are off-line Loop transmit error channel 0 Loop transmit error channel 1 Loop receive error channel 0 Loop receive error channel 1 LIM internal problem (NCIU02/03 only) or Failure in node environment (NCIU04 only)

4.8
TAG Bailey

PROTDIR.DBF
FILE Bailey BIT_BLOCK 1024 MAX_LENGTH 2048 OPTIONS 0x4044b

4.9
4.9.1

Parameters and INI options

Standard Parameters

4.9.1.1

[BAILEY]Block

The blocking constant is a trade-off between the time taken to make multiple data requests and the time taken to read more data in a single request. Allowable Values Default Value 1 to 256 2

4.9.1.2

[BAILEY]Delay

The period (in milliseconds) to wait between receiving a response and sending the next command. Allowable Values Default Value 4.9.1.3 0 to 300 (milliseconds) 0

[BAILEY]MaxPending

The maximum number parameter determines number of pending commands that the driver holds ready for immediate execution. Allowable Values Default Value 1 to 32 1

BaileySA1.DOC

30

Driver Design Specification

4.9.1.4

[BAILEY]PollTime

The interrupt or polling service time (in milliseconds). Setting the polling time to 0 puts the driver in interrupt mode. Allowable Values Default Value 4.9.1.5 0 to 300 (milliseconds) 25

[BAILEY]Retry

The number of times to retry a command after a timeout. Allowable Values Default Value 4.9.1.6 0 to 8 2

[BAILEY]Timeout

Specifies how many milliseconds to wait for a response before displaying an error message. Allowable Values Default Value 4.9.1.7 0 to 32000 (milliseconds) 5000

[BAILEY]WatchTime

The frequency (in seconds) that the driver uses to check the communications link to the I/O Device. Allowable Values Default Value 0 to 128 (seconds) 30

4.9.2

Driver Specific Parameters

4.9.2.1

[BAILEY]BackgroundInit

The driver will establish and connect read points in the background. If the server is an I/O Server but is not an Alarm/Report/Trend Server you may consider setting this parameter to 0. Allowable Values Default Value 0 or 1 1

4.9.2.2

[BAILEY]CIU

As the different Bailey communication devices have different message sets, and message formats the driver needs to know which it is attached to. The three types handled are: 0. NSPM01 1. CIU02/03, /CIC01

BaileySA1.DOC

31

Driver Design Specification

2. CIU04 and higher Allowable Values Default Value 0-2 2

4.9.2.3 [BAILEY]Debug Developers track down a CIU configuration problem using the debug parameter. It has four levels: 0. Ignore debug info 1. Check for BAD QUAILTY data 2. Enable trace info exception reports 3. Check for DRIVER BAD DATA Allowable Values Default Value 0 0-3

4.9.2.4

[BAILEY]ErrorMask

On occasions reply codes may be returned by the Bailey equipment, which effect the performance of the driver but are not critical to the operation of CITECT. One particular code 101 Busy- cannot respond at this time is the most common cause. This code maps to driver error 357 and it can be ignored by the driver using the ErrorMask. ErrorMask can be filled with 5 driver error codes separated by TAB, COMMA or SPACE, which the driver will ignore. Allowable Values Default Value 4.9.2.5 0 - 400 0,0,0,0,0

[BAILEY]FastInit

The driver will give higher priority to establishing and connecting analog points. This will result in pages displaying data faster (~12 seconds) the first time the page is displayed. But if you want digital data (For example alarm data) to have equal priority, set this parameter to 0. If you set the value to 0, then you should also set [Lan]WatchTime to at least 120 seconds to stop request timeout errors. In this case the first page may take a moment to update. Allowable Values Default Value 4.9.2.6 0 or 1 1

[BAILEY]MapPath

If the project being developed has many alarms, trends and points (> 2000) it may take the driver several minutes each time the IO server is started to establish a point table on the CIU. As only a few points are added or deleted each time the server is started a delay of several minutes while the whole point table is reestablished, can be difficult. This parameter enables CITECT to keep a copy of the last CIU point table on disk. Provided the CIU has not been restarted since the last time the server was communicating with it, the point table in the CIU and on the disk should be identical. The driver can therefore read the disk version and set up its index table to mirror the CIU

BaileySA1.DOC

32

Driver Design Specification

and go straight on line. The driver notes any differences between the disk copy and the new variable.dbf; different points are either established or deleted in the background to update the CIU point table Allowable Values Default Value 4.9.2.7 any directory or directory plus filename. If a filename is not includes then a default name Bailey_<channel number>. MAP will be used c:\temp\Bailey_<channel number>. MAP

[BAILEY]Primary

When using redundant CIU pairs, a #COM error can occur and exist for some time when a primary CIU is taken offline and then put back online again (for example during services or swaps). The delay is caused by the primary reestablishing its point table after it has gone online. The primary parameter tells CITECT to continue using the secondary CIU until the primary has established its point table. Note: BackgroundInit must be 1 and CIU must be > 0 for this function to work. Allowable Values Default Value 4.9.2.8 0 or 1 0 go online immediately

[BAILEY]Options

The CIU restart option. Refer to [1] page 2-6 point 2. Suggested setting: NCIU04 = 11, NCIU02/03 = 11 and NSPM01 = 10 Default Value 4.9.2.9 11

[BAILEY]ReqDelay

The millisecond delay for each read request. Default Value 4.9.2.10 60 (milliseconds

[BAILEY]Ring

Allows mapping of the ring numbers. Each of the ring numbers must be unique. Allowable Values Default Value 4.9.2.11 0 to 255, 0 to 255, 0 to 255, 0 to255, 0 to 255, 0 to 255, 0 to 255, 0 to255 0, 1, 2, 3, 4, 5, 6, 7

[BAILEY]WatchDog

The Watchdog time-out period = 2.5 seconds x Watchdog. Default Value 0 (seconds)

4.10

Driver Specific Errors

The following errors, listed in (hexadecimal) sequence, are specific to this protocol. Citect displays the error number and description for common protocol-specific errors. Uncommon errors

BaileySA1.DOC

33

Driver Design Specification

are not contained in the Citect error database, in which case Citect will only display the error number. You may require additional information to enable you to rectify an error. This information should be detailed in the documentation that accompanied the I/O Device (or network). Refer to [1] "Reply Codes" and "Module Bus Reply Codes". The driver offsets all errors generated by the Bailey module. The offset is 0x100 hexadecimal or 256 decimal. Driver Error Code (Hexadecimal) 0 (0x00) 1 (0x01) 257 (0x101) Mapped to (Generic Error label) No Error Waiting for Loop The command was started successfully. The NCIU is now waiting for a reply from the remote PCU used in the command. Improper Format The Command to the NCIU was not properly constructed. This usually indicates that the command contains too few or too many bytes. Block already established for another point This point has already been established by the computer using another index Tune block specification number is out of Range in Block Incompatible Data Type The data type is not specified correctly (e.g. reading TI as real) Tune block specification number is Not Tunable Status of point indicates Bad Quality. Busy - The unit cannot respond at this time Mode for command does not agree with current module mode Meaning of Error Code

2 (0x02)

258 (0x102)

5 (0x05)

261 (0x105)

40 (0x28)

40 (0x28)

41 (0x29)

41 (0x29)

42 (0x2A) 43 (0x2B) 101 (0x65) 102 (0x66)

42 (0x2A) 43 (0x2B) 357 (0x165) 358 (0x166)

BaileySA1.DOC

34

Driver Design Specification

4.11

Driver Error Help

The following entries should be included in the Citect ProtErr.DBF spec file. PROTOCOL BAILEY MASK 0 ERROR 28 MESSAGE Spec out of range Incompatible type Spec not tunable Bad quality warning Waiting for loop Improper format Illegal command Index already established Block already established another point Command too long Bad reply from BTM Export used As Import Repeat CIU restart command Undefined index REFERENCE ACTION COMMENT

BAILEY

29

BAILEY

2A

BAILEY

2B

BAILEY

101

BAILEY

102

BAILEY

103

BAILEY

104

BAILEY

105

BAILEY

106

BAILEY

107

BAILEY

108

BAILEY

109

BAILEY

10A

BaileySA1.DOC

35

Driver Design Specification

BAILEY

10B

Memory full Host communication error BTM not responding Import used as export Time-out of plant loop response Number out of range Illegal key Need a restart command Message active on loop Exception report specification list Reply too large Illegal station mode command Illegal Module number in command Time-out between bytes in command

BAILEY

10C

BAILEY

10D

BAILEY

10E

BAILEY

10F

BAILEY

110

BAILEY BAILEY

0 0

111 112

BAILEY

114

BAILEY

116

BAILEY

118

BAILEY

119

BAILEY

11A

BAILEY

11B

BaileySA1.DOC

36

Driver Design Specification

BAILEY

11C

Index already established (by another computer) Point type incompatible with command Watchdog time-out Checksum compare error Destination node off-line Callup command required CIU error CIU busy BTM offline Conflict with monitor mode Point type Destination ring off-line Destination node busy Destination ring busy Undefined message type for target module

BAILEY

11D

BAILEY

11E

BAILEY

11F

BAILEY

120

BAILEY

121

BAILEY BAILEY BAILEY

0 0 0

122 123 124

BAILEY

125

BAILEY BAILEY

0 0

126 127

BAILEY

128

BAILEY

129

BAILEY

164

BaileySA1.DOC

37

Driver Design Specification

BAILEY

165

Busy cannot respond at this time Mode for command incompatible with module mode Message data out of legal range Invalid block number Unconfigured block number Unreadable block Invalid function code for target module Incompatible function code and block number Insufficient memory to write block Module not responding *BAILEY error code Bailey Network 90, E93905-2, pages 9-1 to 9-7, page A-4

BAILEY

166

BAILEY

167

BAILEY

168

BAILEY

169

BAILEY

16A

BAILEY

16B

BAILEY

16C

BAILEY

16D

BAILEY

16E

BAILEY

FF

100

BaileySA1.DOC

38

Driver Design Specification

4.12

Debug Messages

The driver uses two forms of debug messages. The Bailey "Reply Codes" and "Module Bus Reply Codes" which are returned in the driver specific error code field of the device error message incremented by 0x100 hexadecimal and the trace messages. The trace messages has two forms. Trace of the transmitted message, which has the form: <CITECT time stamp> <Tag address> <Hexadecimal message transmitted><checksum> And a trace of the message received from the Bailey equipment in the form: <CITECT time stamp> <Tag address> <Hexadecimal message received> Note: the received message has had the checksum removed since the message has passed the checksum test. The <Tag address> has the form:

<Type><Index>, <Ring>, <Node>, <Module>, <Block.[.Sub]>

The <Hexadecimal message transmitted> has the form: Byte No 1 2 3END Data type Code Byte Description Command Code Key Depend on format of Command Code refer to [1] Chapter 2 Commands, COMMAND

The <Hexadecimal message received> has the form: Byte No 1 2END Data type Reply Code Description Reply from Bailey equipment. 0 = ON ERROR Depend on format of Command Code refer to [1] Chapter 2 Commands, REPLY

BaileySA1.DOC

39

Driver Design Specification

4.13
Number 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Stats Special Counters

Label TRANSMIT RECEIVED RX_INT POLL READ_EXCEPTIONS BAD_QUALITY MAX_INDEX INIT_UNIT GET_CACHE PUT_CACHE INITIALISING POINTS_DEFINED POINTS_ESTABLISHED READ_ERROR POINTS_NODATA WRITE_DEFINED WRITE_ERROR DCB POINTS_WRITE Purpose/Meaning of this counter The number of messages sent to the Bailey Equipment The number of messages received from the Bailey Equipment The number of time the receiver timer has expired The number of background poll messages sent to the Bailey Equipment The number of exception messages received from the Bailey Equipment The number of exception messages received from the Bailey Equipment whos status was bad The highest index number used in the point table The number of times the serial port has been reset The number of messages retrieved from the tune block cache The number of messages added to the tune block cache The number of initialising requests sent to the Bailey equipment The number of read points defined The number of read points established The number of read points which could not be established The number of read points which could be established but have not returned any data The number of write points defined The number of write points which could not be established The number of messages received from the IO server This count is divided into three groups: 1. write points established (count in 1s) 2. write points establishing (count in 1000s) 3. write points written to (count in 100000s) BAD_INDEX

19

Number of bad indexes returned in exception reports

BaileySA1.DOC

40

Driver Design Specification

4.14

Hints and Tips

4.14.1 Improving System Performance

4.14.1.1 Screen Update In communicating with the Bailey, Citect creates a Point Table identical to the Point Table in the Bailey. When the Bailey gets any change, it reports the change to Citect and Citect updates its Point Table, so data updates should be nearly instant. However, read and write points are only established when requested the first time. When accessing pages for the first time the update will be slow some improvements may be possible if the following are considered.

4.14.1.1.1

Request Delay

The default delay time between read requests is 60 milliseconds. If the screen update times are too high, reduce the delay in the [BAILEY]ReqDelay parameter. You can also increase the [BAILEY]Block parameter to allow Citect to read more data in each read operation. Remember for systems that are using Display Clients talking to an IO Server over the network. Reducing the ReqDelay to 0 on a Display Client will increase network traffic as the Display Client is requesting data from the I/O Server continuously. A ReqDelay of 0 is not recommended for networks.

4.14.1.1.2

Blocking

Blocking of similar data types also increases performance. If you block each data type (e.g. Digital, Real, etc.) together in your Variables Definitions, then the variables of each type are read faster. To block them together, you should try to keep Index numbers running in order (for each type). For example: PV1,0,5,6,199 PV2,0,5,6,728 SP3,0,5,6,199 (REAL, Read Only data types blocked together) WSP201,0,5,6,199 WPV202,0,5,6,728 WPV203,0,5,6,199 (REAL, Write Only data types blocked together) D401,0,5,6,236.BAD D402,0,5,6,173.VAL SS403,0,5,6,328.A (DIGITAL, Read Only data types blocked together) PV601,0,5,6,199.BAD

BaileySA1.DOC

41

Driver Design Specification

PV602,0,5,6,199.HL SP603,0,5,6,199.SPT (DIGITAL, Status values from REAL points)

n

By blocking data types together, you can keep ReqDelay at 60 and Block at 2, but you should still experiment to determine the optimum settings for your installation (if the response times of the system are inadequate). n The CPU Usage value should be monitored (shown on the Page General display of the Citect Kernel). If this value rises to unacceptably high levels, then increase the ReqDelay parameter. 4.14.1.2 Using multiple CIUs If you are using two ICT modules to improve performance on the system, be careful not to interlace tags in each ICT (e.g. don't have ICT1 talking to blocks 555, 559 and 580, while ICT2 is talking to 556, 560 and 577). While it won't actually stall the driver, it may affect the scan time of the processor, depending on how badly you interlace everything. Only use more than one ICT if you need to access more than 10000 indexes (not necessarily the same thing as tags) from the system, or provide redundancy. Also note that Citect prefers to have similar tag types grouped into indexes (e.g. all the RCM reads in index range say 5000-5999), so bear this in mind when trying to split things across two or more modules. 4.14.2 Using BR, BI and BD tags The BR, BI and BD tags use the READ BLOCK OUTPUT command to retrieve data from the Bailey DCS. This command is inefficient for the driver since it has to issue a command and wait for a reply from the DCS for each tag read. This command also increases the traffic on the DCS internal network, as the actual module in which the block resides must be asked for the output value. The tags were implemented to enable limited monitoring of a DCS using equipment, which is not capable of exception reporting such as a SPM or CPM. With the above in mind these tags can be used to read any output from any block using either a SPM or CIU type unit. One of the most common uses is to read the output of FC 129 the MSDD function code. The outputs for this FC reside in block N, N+1, N+2 and N+3. N is the block the FC is configured in. There is two ways to read these blocks. The preferred way is to configure several block in the control module with FC30 and FC45 to generate exception reports for blocks N, N+1 etc. and then include D and A tags in the project to read exception reports from the FC30 and FC45 blocks. The other way is to configure BR and BD tags in the project to read the N, N+1, N+2 and N+3 blocks directly. When using large numbers of BR, BI and BD tags it is important to consider the effect of the index field. The index field is used as an address by CITECT. Since the granularity of CITECT is measured in blocks which relates to16 digital tags The blocking parameter equates to Block *16 indexes. So the minimum number of indexes the driver will read during each request is 16 if Block = 1. This can be a problem when using the serial port module. The serial port module does not use an index table or exception reporting therefore each request is sent over the Bailey communication network to the module denoted in the address. This is a much slower operation than exception reporting so reading more tags than is necessary for the current page and associated trend or alarms can cause screen update delays. To over come this problem tags BR, BI and BD can be indexed at intervals of 16 therefore only one slow READ BLOCK OUTPUT operation will be performed per request. Alternatively all the BR, BI and BD tags per page can be grouped together, so that all the tags on the one page are updated in one or two requests. 4.14.3 Function Codes A function code is a function, which resides in the control module firmware. Blocks that are associated with a FC during configuration of a control module are data storage areas for each instantiation of the FC. This storage area is broken up into several sections, specifications, status and

BaileySA1.DOC

42

Driver Design Specification

output. The driver is capable of reading each of these sections. It can write to the status section and tuning parts of the specification section. The driver therefore operates independently of the FCs assigned to the blocks. Its only function is to read and write the bytes within the blocks. The format of these bytes is different for each FC and some tags have been included to help decode the status section of blocks associated with these FCs, for example MSDD (FC 129 Multi State Device Driver). If there is not a tag for the FC you wish to use and its status field (RCM) is different to the standard one either add another record into the Bailey.dbf file to handle the status section or use RCM to read in the status and decode it with cicode. 4.14.4 Indexing Tags The majority of tags listed above can be associated with a point in the CIU points database. The driver uses the index field when establishing a point in the CIU. This index is a unique number associated with one block in the DCS. All tags addressing the same block within the DCS should have the same index number. This will make the transfer of data more efficient and reduce network overheads 4.14.5 Time synchronisation The TIME tag variable assumes index 1 therefore if other tags are using index 1 they should be reassigned prior to using the Time synchronisation tag. The time set function acts as a time synchronisation tag. It is a long integer that contains a time in seconds since 1/1/70. (PC / DOS /UNIX time). The time synchronisations will not take effect until eight minutes has elapsed since the last CIU restart. Until this period has elapsed the sync command is illegal and returns a 0x03 bailey error and 0x103 diver error. The following code can be used to generate the LONG integer used by the time tag.
/* Takes the fields specified in the parameter list and converts */ /* them into a system time value. */ INT FUNCTION sys_time(INT year, INT month, INT day, INT hour, INT minutes, IN seconds) INT stime, sdate; stime = StrToTime(IntToStr(m_hour)+":"+IntToStr(m_minutes)+":"+IntToStr(m_seconds)); sdate = StrToDate(IntToStr(m_month)+"/"+IntToStr(m_day)+"/"+IntToStr(m_year)); return stime + sdate; END

Once the tag is assigned it is immediately sent to the bailey CIU. Time synchronisation will occur if the time sync option has been issued in the previous CIU RESTART. Set the appropriate options using the INI file OPTIONS command (the default is 27 try 59 to enable time synchronising). Note: The bailey accepts only the following years 87-99 and 0-48. 4.14.6 Troubleshooting

4.14.6.1 "Unknown Data Type" If the "Unknown Data Type" error (protocol generic error 3) occurs when you try to connect to an I/O Device, first check that the CTCMP.EXE and BAILEY.DLL files on the PC running Citect are the current version. Then check that your variables are properly addressed. This error can also be caused when two different variable tags try to read the same Bailey block.

BaileySA1.DOC

43

Driver Design Specification

4.14.6.2 "Driver is Not Responding" If the "Driver is Not Responding" error (protocol generic error 19) occurs, check that you have given each CIU on the loop a unique I/O Device Address. If no addresses are duplicated, try resetting the CIU and the Bus Transfer Module. Pull the modules out of the backplane to cause a power down reset. If the driver still does not respond, contact Bailey customer support.

4.14.6.3 General Error" n If a general error (protocol generic error 8) occurs during run time, Citect may be trying to read from a block that does not exist in the computer.

4.14.6.4 "Incompatible Types" n If the "Incompatible Types" error occurs during compilation, you could have allocated a single index number more than once in the database.

4.14.6.5

"Bad I/O Device Variable" n If the "Bad I/O Device Variable" error occurs during compilation, you could be using an out-of-date compiler. Check the version/release of the compiler and contact Citect Technical Support

BaileySA1.DOC

44

Driver Design Specification

5.

Basic Testing

5.1

Introduction

As this specification is written for a driver, which has been in service for may years this section is considered unnecessary. All modifications to the driver in the recent release have been field tested during commissioning of the driver at least three separate sites.

5.2

Procedure

Not applicable

BaileySA1.DOC

45

Driver Design Specification

6.

Performance Testing

6.1

Introduction

Limited performance testing has been carried out on this driver following recent modifications. Performance testing was not considered necessary as P Wong performed these during initial testing in 1992.

6.2

Calculating the Blocking Constant

The Block constant is 2.

BaileySA1.DOC

46

Driver Design Specification

7.

References

7.1

References

[1] Bailey Product Instruction E93-905-9, "Enhanced Computer Interface Unit Programmer's Reference Manual", Bailey Controls, Wickliffe, Ohio 44092. [2] Bailey Product Instruction E93-905-1 Serial Port Module (NSPM01), Bailey Controls, Wickliffe, Ohio 44092 [3] Electronic Documentation INFI 90, Elsag Bailey Process Automation.

BaileySA1.DOC

47

Driver Design Specification

8.

Appendix

Appendix A Initialization flow chart

START

READ PARMAETERS

INITSTATE = RESTART

LOAD MAPPOINTS

LOAD AND COMPARE PREVIOUS MAP

MAPPATH = NULL AND INITSTATE <> RESTART

DISCONNECT POINT LIST

N CIU RESTART

ERROR N CONNECT POINT LIST ERROR N ENVIRONMENT

ERROR N

ERROR N ONLINE

BaileySA1.DOC

48

Driver Design Specification

Appendix B Configuration flowchart

The following flow chart applies to each point whose index number is > 0 Configuration of a point in the CIU can occur: Once every cycle of the polling loop, During a read or write request from CITECT or During initialization (special redundancy case only)

START

REMOVED Y

DISESTABLISH POINT

END

CHANGED Y

DISESTABLISH POINT

DEFINED

DEFINED Y

PV, SP, CO, RI, A, SS, EMS, D, RCM, RMSC

ESTABLISH AND CONNECT POINT Y

MS, WSP, WCO, WRI, SM

ESTABLISH POINT Y

WA, WD Y

ESTABLISH REPORT

ESTABLISHED

ERROR Y

END
BaileySA1.DOC

49

Driver Design Specification

Appendix C Bailey Driver Execution flowchart

Front-end READ
START

TR, TI, TD

IN QUEUE

NOT ESTABLISHED

CONFIGURE

BR, BI, BD

IN QUEUE

REPLY

END

Front-end WRITE

START

IN QUEUE

BaileySA1.DOC

50

Driver Design Specification

BACK-END TRANSMITT
START

OUT QUEUE

BUILD COMMAND

IN QUEUE

BUILD COMMAND

COUNT++

COUNT%4 =0

CONFIGURE

COUNT%4 =1

READ EXCEPTION

COUNT%4 =2

READ MISC STATUS EXCEPTION

COUNT%4 =3

READ EXCEPTION REPORT SPECS

BaileySA1.DOC

51

Driver Design Specification

BACK-END CPU
START

READ

TR, TI, TD

CACHE

BR, BI, BD, MS

WRITE

TUNE

CACHE

OUT QUEUE

ERROR

REPLY

EXCEPTION

UPDATE POINT TABLE IMAGE

CONFIGURATION

END

BaileySA1.DOC

52