Citect for Windows Driver Specification Extract KINGFISH ... · Driver Design Specification KINGFISH.DOC 1 Citect for Windows Driver Specification Extract KINGFISH Driver Name: Comments

Driver Design Specification

KINGFISH.DOC 1

Citect for Windows Driver Specification Extract

KINGFISH Driver

Name: Comments Date

Bruce Kinchin 10/12/96 Stephen Burman 2/10/97 Stephen Burman 28/11/97 Stephen Burman 8/1/98 Stephen Burman 5/4/98


KINGFISH.DOC 2

Contents

1. TARGET DEVICE(S) AND PROTOCOL 4 1.1 Introduction 4 1.2 Device Manufacturer 4 1.3 Device Definition 4 1.4 Communications Method 5 1.5 Communications/Hardware Configuration 5

1.5.1 Wiring Diagrams 5 1.5.2 I/O Device Settings 8 1.5.3 Software Setup 8

1.6 Special Requirements 8 1.7 Maximum Request Length 8

2. USER INTERFACE 9 2.1 Introduction 9 2.2 Driver Name 9 2.3 Boards Form 9

2.3.1 Board Type 9 2.3.2 Address 9 2.3.3 IO Port 9 2.3.4 Special Opt 9

2.4 Ports Form 9 2.4.1 Baud Rate 9 2.4.2 Data Bits 9 2.4.3 Stop Bits 9 2.4.4 Parity 9 2.4.5 Special Opt 10

2.5 IO Devices Form 10 2.5.1 Protocol 10 2.5.2 Address 10

2.6 Pulldown lists Help 10 2.7 IO Device Variable Types 10 2.8 PROTDIR.DBF 11 2.9 Parameters and INI options 11

2.9.1 Standard Parameters 11

2.9.2 Driver Specific Parameters 12


KINGFISH.DOC 3

2.10 Driver Specific Errors 13 2.11 Driver Error Help 13 2.12 Debug Messages 14

2.12.1 Initialising 14

2.12.2 Reading data 15

2.12.3 Writing data 16

2.12.4 Requesting events 16

2.12.5 Error debug statements 17 2.13 Stats Special Counters 17 2.14 Functions to be used with cicode for obtaining event records from the driver event cache 18

2.14.1 Sample Cicode using event record handling functions 20 2.15 Hints and Tips 21

3. REFERENCES 22 3.1 References 22


KINGFISH.DOC 4

1. Target Device(s) and Protocol

1.1 Introduction This section defines the types of I/O Devices that are targeted by this driver.

1.2 Device Manufacturer Action Controls

1.3 Device Definition Series II RTU (Remote Terminal Unit). This device is used to move data between remote locations. The device can be defined as a master or slave. The purpose of the Master RTU is to manage data collection from slaves. SCADA systems talk to the master RTU, to gain data directly from it and from the slaves via Master memory registers. An RTU consists of a power supply module, a processor module and zero or more IO modules (Analog Input AI, Analog Output AO, Digital Input DI, and Digital Output DO). These modules sit on a back-plane.


KINGFISH.DOC 5

1.4 Communications Method This is a serial device, communicating using one of the following protocols A) Modbus B) Kingfisher Series 1 C) Kingfisher Series II D) DNP 3 The Citect KINGFISH driver supports only the Kingfisher Series II protocol.

1.5 Communications/Hardware Configuration

Kingfisher Series II RTU (Master)

RS-232 / RS 485:Kingfisher Series II RTU (Master)

Kingfisher Series II RTUs (Slaves)Kingfisher Series II RTUs (Slaves)

Single Master usedper com port

1.5.1 Wiring Diagrams

A computer can be connected to the Kingfisher CP-1 communications processor either through Port 1 (P1) or Port 2 (P2). Port 2 can either have an RS-232 or RS-485 connection. The connectors into the CP-1 module are RJ45.

CP-1 COMMUNICATION PROCESSOR

P1 (PORT 1)

P2 - RS232

P2 - RS485


KINGFISH.DOC 6

RS-232 connections

1 TX

3 RX

4 SG

2

3

5

RxD

TxD

SG

RS-232 DIGIBOARD or COMMPORT (DTE)

D Connector9-WAY

FEMALE

CP-1 MODULE

RJ 45

Connector

7

8 3 CTS

5 DCD

6 RTS

CTS

RTS


KINGFISH.DOC 7

RS-485 connections (Used with the P2-RS485)

1 TX

6 RX

6

4

+L

-L

RS-485 DIGIBOARD or COMMPORT (DTE)

D Connector9-WAY

FEMALE

CP-1 MODULE

RJ 45

Connector


KINGFISH.DOC 8

1.5.2 I/O Device Settings Comms settings configured in software (see section 3.5.3).

1.5.3 Software Setup Use Kingfisher Toolbox for Windows to setup RTU. Refer to section 3 of the RTU manual (“Series II RTU Technical Information). The Toolbox is used to set the following, properties of the RTU amongst others:

1) Comms settings 2) Memory reserved for PLC tasks 3) Network register blocks (used to store outstation slave RTU information in the master

RTU). Some configuration settings are downloaded to the RTU.

1.6 Special Requirements Kingfisher Toolbox for Windows: supplied by action controls. There is an optional database add on to the Toolbox which is useful for looking at Trend logs. If trending of historical data is to be used with the KINGFISH driver, then cicode must be used. The original cicode for trending of historical data for this driver was developed by CIT Melbourne.

1.7 Maximum Request Length 256 bytes


KINGFISH.DOC 9

2. User Interface

2.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 debug trace mes-sages and the Stats.Special counters are documented.

2.2 Driver Name KINGFISH

2.3 Boards Form

2.3.1 Board Type

COMX

2.3.2 Address NONE

2.3.3 IO Port

NONE

2.3.4 Special Opt

NONE

2.4 Ports Form

2.4.1 Baud Rate 300 OR 600, 1200, 2400, 4800, 9600, 14400, 19200

2.4.2 Data Bits

8

2.4.3 Stop Bits

1

2.4.4 Parity 0


KINGFISH.DOC 10

2.4.5 Special Opt

NONE

2.5 IO Devices Form

2.5.1 Protocol KINGFISH

2.5.2 Address

Address: MasterRTU or MasterRTU, ViaRTU or MasterRTU, ViaRTU, InitiatingRTU or MasterRTU, ViaRTU, InitiatingRTU, SystemID

The default value for MasterRTU, ViaRTU, InitiatingRTU and SystemID is 0, 0, 0xff and 0xae respectively. e.g. 1 or 1, 2, 0, 0xab

2.6 Pulldown lists Help The following entries should be included in the Citect Help.DBF spec file.

TYPE DATA FILTER PROTOCOL KINGFISH

2.7 IO Device Variable Types

IO Device Type Citect data type

Citect data type

Description/Special Usage/Limitations/ Valid Ranges

Analog Input 1 to 8 for module a

#AIa.b INTEGER

Analog Output 1 to 8 for module a

#AOa.b INTEGER

Digital Input bit 1 to 16 for module a

#DIa.c DIGITAL

Digital Output bit 1 to 16 for module a

#DOa.c DIGITAL

Registers 1 to 1024 #Rd INTEGER Bit 1 to 16 for Register for register d

#Rd.c DIGITAL


KINGFISH.DOC 11

for register d Where # is the RTU id 1 to 249 a is module address 1 to 64 b is the analog channel number 1 to 8 c is the bit number 1 to 16 d is the register address 1 to 1024 Analog values can be 16 bit signed INT, 32 bit signed LONG and 32 bit REAL. When reading analog values as REAL or LONG only odd number addresses can be used because each REAL or LONG takes up two locations.

2.8 PROTDIR.DBF

TAG FILE BIT_BLOCK MAX_LENGTH OPTIONS KingFish KingFish 1024 1024 0x04b*1 1 - OPT_DIGITAL, OPT_INTEGER, OPT_STRING, OPT_LONG, OPT_REAL

2.9 Parameters and INI options

2.9.1 Standard Parameters Block 128 Delay 0 (This driver has its own delay system, so KB Q2118 not

applicable regarding front end / back end drivers)

MaxPending 16 Polltime 0 (Interrupt driven) Timeout 2000 (2 Seconds) Retry 1 WatchTime 30000 (30 Seconds) WatchTime 30 (30 Seconds) TimeOut

This is also used as the cache time for read requests to the local RTU. The local RTU is the one which have the same RTU number as the MasterRTU.

WatchTime This is also used as the cache time for read requests to non local RTU.


KINGFISH.DOC 12

2.9.2 Driver Specific Parameters These parameters are placed in the section [kingfish] in the Citect.ini file. writeWaitMode Meaning When writing to a slave rtu via the kingfish driver there are two versions of

the write commands available. Using the first method the master wont up-date the data untill the slave confirms the update. Using the second method, the update will happen in the master immediately, so as to make transparent the long delays due to slow communication paths. The second method (writeWaitMode=1) is more suited to SCADA systems but will only work from firmware version 1.31c onwards. Change requested by Action Controls on 8/1/98.

Default 1 (Method 2) Range 0 = Method 1 1= Method 2 MaxFails Meaning The maximum permitted value of the network link Cfails register for an RTU.

If the value is greater, then GENERIC_INVALID_DATA (i.e. "Data not yet valid" ) messages are returned.

ReqDelay Meaning Each read request satisfied from the cache will be delayed this amount of

time to reduce the request rate. Measured in milliseconds. Note that the Screen Update Time can be determined using ReqDelay as follows:

Screen Update Time ≈ Number of requests * ReqDelay / MaxPending. Default 60 Range 1 to 2147483647 MaxEventCacheRecords Meaning The maximum of event records that can be cached in the driver, before the

driver will stop requesting trend records from the device. Default 1000 Range 1 to 4294967295 (limited by available memory) Log Meaning Indicates whether driver will log events as they are recieved by the driver to

a separate file, kingfish.dat, in the Windows directory. This option should only be set “on” for debugging purposes because there is no size limit to the file. The purpose of the logging function is to show raw event data as col-lected by the driver.

Default 0 (off) Range boolean: 0=logging off 1=logging on

Format of the Log file The following is a sample from a kingfish.dat file: 0, 0, Com1, 864842910, 0, 9819, 0x500e, 0x1, 0x1


KINGFISH.DOC 13

Field Number Field Name Field Description 1 iCurrentEventBatch Index within current trend file from king-

fisher;

2 iLog Index within current batch of trend records requested by driver

3 PortName Name of the port associated with trend record

4 DateTime Current time in seconds since 1970 in raw form (ie as Kingfisher RTU sent it rather than Universal Coordinate compensated time)

5 MS Millesconds additon to DateTime to get Millesecond accuracy

6 Value Value 7 Reference Reference Information field 8 RTU data source RTU number 9 Priority Priority of event

EventRequestSize Meaning The number of records the driver will request each time it requests event logs. Default 10 Range 1 to 255

2.10 Driver Specific Errors

Driver Error Code

(Hexadecimal)

Mapped to

(Generic Error label)

Meaning of Error Code

0x33 The driver is out of memory

0x34 GENERIC_INVALID_DATA The data is out of date

0x28 Bad sequence number from the device

2.11 Driver Error Help NONE


KINGFISH.DOC 14

2.12 Debug Messages

2.12.1 Initialising

Mon Sep 15 12:32:56 1997 00:17:10.427 Citect Startup Mon Sep 15 12:32:56 1997 00:17:10.442 Transmit-IDLE Length 9 AE 00 08 FF 00 02 22 A8 7C ......".| Mon Sep 15 12:32:56 1997 00:17:10.557 Receive-WAIT_RESPONSE Length 32 AE FF 1F 01 01 20 23 A0 30 61 09 0F 0C 1E 07 0F ..... #.0a...... 18 0C 00 02 00 01 00 00 00 00 00 00 00 93 CC 13 ................ Packet analysis for INITIALISATION debug messages Request AE 00 08 FF 00 02 22 A8 7C SYSTEM ID 1 0XaE default TARGET RTU 1 0x00 Master PLC NO. OF CHARS 1 0x08 Number of characters in message

excluding Sytem ID, INITIATING RTU 1 0xff Node number of driver VIA RTU 1 0x00 Viia no other RTU MESSAGE NUMBER

1 0x02 Sequence Number

FUNCTION CODE

1 0x22

0x22 = Function code 34 (See command REQUEST RTU STATUS in section 4.8.2)

ARGUMENT / DATA

CRC 2 0xA8 7C Note A8 = msb

Response AE FF 1F 01 01 20 23 A0 30 61 09 0F 0C 1E 07 0F ..... #.0a...... 18 0C 00 02 00 01 00 00 00 00 00 00 00 93 CC 13 ................ This packet wil not be analysed since the information contained within it is not used by the driver (See section entitled SEND RTU STATUS in section 4.8.2). N.b The command to RTU status request is followed by a sequence of request/response pairs whereby event records are obtained


KINGFISH.DOC 15

2.12.2 Reading data

Mon Sep 15 12:26:37 1997 00:10:52.064 Transmit-WAIT_RESPONSE Length 14 AE 00 0D FF 00 05 10 02 38 0A 30 0C B8 FF ........8.0... Mon Sep 15 12:26:38 1997 00:10:52.132 Receive-WAIT_RESPONSE Length 18 AE FF 11 01 01 50 11 02 38 0A 00 00 30 0C 00 00 .....P..8...0... 20 0D . Packet analysis for READ debug messages Request Mon Sep 15 12:26:37 1997 00:10:52.064 Transmit-WAIT_RESPONSE Length 14 AE 00 0D FF 00 05 10 02 38 0A 30 0C B8 FF SYSTEM ID 1 0xAE default TARGET RTU 1 0x00 Master PLC NO. OF CHARS 1 0x0D Number of characters in message

excluding Sytem ID, INITIATING RTU 1 0xFF Node number of driver VIA RTU 1 0x00 Viia no other RTU MESSAGE NUMBER

1 0x05 Sequence Number

FUNCTION CODE

1 0x10

0x10 = Function code 16 (See command GET MULTI DATA in section 4.8.2)

ARGUMENT / DATA

02 38 0A 30 0C

Number of Ids First ID Second ID

CRC 2 0xB8 FF Note A8 = msb

Response Mon Sep 15 12:26:38 1997 00:10:52.132 Receive-WAIT_RESPONSE Length 18 AE FF 11 01 01 50 11 02 38 0A 00 00 30 0C 00 00 20 0D . This is a response to a read request using the command SEND MULTI DATA (byte 7 is 11h = 17 = SEND MULTI DATA). For help on packet analysis, see examples in 5.12.1 and a description of this protocol command in section 4.8.2.


KINGFISH.DOC 16

2.12.3 Writing data

Packet analysis for WRITE debug messages Request Mon Sep 15 12:30:21 1997 00:14:35.528 Transmit-WAIT_RESPONSE Length 14 AE 01 0D FF 00 05 14 01 10 04 11 D7 8F 27 This is a write request using the command SET MULTI DATA (byte 7 is 14h = 20 = SET MULTI DATA). For help on packet analysis, see examples in 5.12.1 and a description of this protocol command in section 4.8.2. Response Mon Sep 15 12:30:21 1997 00:14:35.582 Receive-WAIT_RESPONSE Length 9 AE FF 08 01 01 50 00 91 12 This is a simple ACK. For help on packet analysis, see examples in 5.12.1 and a description of this protocol command in section 4.8.2.

2.12.4 Requesting events

Request Mon Sep 15 12:33:52 1997 00:18:06.967 TransmitTrend-WAIT_RESPONSE Length 14 AE 00 0D FF 00 04 50 04 00 0A 00 47 72 E5 This is a event request using the command REQUEST EVENT LOGGING (byte 7 is 50h = 80 = REQUEST EVENT LOGGING). For help on packet analysis, see examples in 5.12.1 and a description of this protocol command in section 4.8.2. Response Mon Sep 15 12:33:53 1997 00:18:07.193 Receive-WAIT_RESPONSE Length 134 AE FF 85 01 01 40 51 0E 00 0A 00 51 33 8C 74 F8 00 00 26 5B 50 0E 01 01 33 8C 74 F8 00 00 48 A1 50 0F 01 01 33 8C 75 02 00 00 26 5B 50 0E 01 01 33 8C 75 0C 00 00 26 5B 50 0E 01 01 33 8C 75 16 00 00 26 5B 50 0E 01 01 33 8C 75 20 00 00 26 5C 50 0E 01 01 33 8C 75 2A 00 00 26 66 50 0E 01 01 33 8C 75 34 00 00 26 6F 50 0E 01 01 33 8C 75 34 00 00 48 C9 50 0F 01 01 33 8C 75 3A 01 68 00 01 90 06 01 01 B1 68 This is a response to an event request using the command SEND EVENT LOGGING (byte 7 is 51h = 81 = SEND EVENT LOGGING). For help on packet analysis, see examples in 5.12.1 and a description of this protocol command0 in section 4.8.2.


KINGFISH.DOC 17

2.12.5 Error debug statements

Wed Sep 10 10:55:38 1997 00:02:14.675 Error: Data not yet valid READ 0019 Com1 KingFish Int 2FF1040:0[1].16 1 Generic 000025 Driver 00000052 (0x00000034) This is a sample error message. Error messages will be of this form and for this driver, will represent only a subgroup of the standard driver error codes.

2.13 Stats Special Counters

Number Label Purpose/Meaning of this counter

0 TX FRAME Number of frames transmitted by the driver

1 REQ BLOCK Number of blocks requested by the driver (when requesting block data)

2 REQ CHANGE Number of times the driver has requested “update registers”

3 RX INTERRUPT Number of interrupts (due to arrival of data)

4 READ CACHE Number of times the driver has replied with data from its internal cache of block data in response to a read request from Citect.

5 READ PLC Number of times driver has been required to request block data from the PLC in response to a request from Citect.

6 TOTAL DATA BLOCKS The total number of data blocks representing a particular RTU that are currently cached in the driver.

7 TOTAL QUEUES The total number of data block cache queues currently created in the driver (should equal the number of logical units).

8 WRITE The total number of write requests from Citect to the driver

9 LAST ERROR The error code for the last interaerror

10 RX FRAME Number of frames received

11 RX BLOCK Number of Data blocks received

12 RX CHANGE Number of update register items received

13 REFRESH CACHE Number of times a data block has been automatically requested by the driver in order to refresh its cache.

14 EVENT REQUEST STATE

State is either:

1: indicating the driver is in the process of uploading an event file (ie is making event requests),

or

0: indicating the driver is has finished uploading a trend file and is waiting till the next watchtime period to request another trend file (providing the internal event queue is not full).

15 EVENT REQUESTS MADE

Number of request made in the process of uploading the current event file


KINGFISH.DOC 18

16 EVENT RECORDS RECIEVED

Number of event records retrieved in the process of uploading the current event file

17 EVENT MAX QUEUE SIZE

The maximum size that the drivers internal queue of event records can grow to

18 EVENT MS TILL UPLOAD

The number of milleseconds remaining till the next watchtime pe-riod, when the driver will initiate another request if it is not cur-rently in the process of requesting an event file

19 EVENT NO IN LOCAL QUEUE

The number of event records in the driver’s local event queue

2.14 Functions to be used with cicode for obtaining event records from the driver event cache GetRTULogStatus() Purpose: To indicate whether there are records available for extraction

from the internal driver event cahch. Return Value: A value representing the number of records remaining in the

driver cache (LONG). Parameters: NONE GetRTUNextEvent() Purpose: To remove the event record from the front of the internal

driver event cache, and make it available for field data ex-traction using GetRTUEventField.

Return Value: A handle to the first event rect (0-65535) OR -1 if no events in internal queue (LONG)

Parameters: NONE GetRTUEventField(hEvent, fieldNumber) Purpose: To obain a field from the current extracted event record. Return Value: Selected event record field as a string (STRING) Parameters: hEvent - event handle (LONG) Range 1-10 fieldNumber - field number (LONG)

Associated Field Num-ber

Field Name Field Description Native Type (although always presented as a string from this function)

1 FIELD_TIMESTAMP Current time in seconds since 1970, compensated for Universal Coordinate Time (for use with TrnEventSetTable function)

UNSIGNED LONG

2 FIELD_MILLESECONDS Millesconds additon to DateTime to get Millesecond accuracy

UNSIGNED SHORT

3 FIELD_VALUE Value of event (eg Trend value) SHORT 4 FIELD_REFERENCE Reference Information field UNSIGNED SHORT 5 FIELD_RTU RTU number from which the event came BYTE 6 FIELD_PRIORITY Priority of event BYTE 7 FIELD_FLOAT 32 bit value based on FIELD_VALUE

and FIELD_MILLISECONDS REAL

8 FIELD_PORTNAME Portname describing port from which the event came.

STRING

9 FIELD_LONG 32 bit value based on FIELD_VALUE and FIELD_MILLISECONDS

LONG


KINGFISH.DOC 19

10 FIELD_RTU_EVENT_IDX Event Index from master RTU SHORT

StartEventRequests(portName, eventIndex) Purpose: To start event requests for a port, optionally from a specified

index. This function does not empty the internal driver event queue.

Return Value: Returns -1 if cannot find the port specified. Otherwise re-

turns 0. (LONG) Parameters: portName - Port name as defined in the Citect -

ports form. Is case sensitive (STRING).

eventIndex - (LONG) -1 = get the oldest records first or some value (>=0) (0-65535)to read from a specified index

EmptyEventQue() Purpose: To empty the internal driver event queue. Return Value: Always returns 0. StopEventRequests(portName) Purpose: To stop event requests for a port. This function does not

empty the internal driver event queue. Return Value: Returns -1 if cannot find the port specified. Otherwise re-turns 0. Parameters: portName - Port name as defined in the Citect

ports form. Is case sensitive (STRING). StartEventRequests(), EmptyEventQue(), StopEventRe-quests(portName) are functions designed to be used with cicode in order that 1) Redundancy can be handled. When a secondary IOServer comes online

after a primary IOServer failure, then it is necessary for the secondary to be able to specify a starting index for alarm and trend events. A sugges-tion is that the Primary regularly (e.g. every 100 records) write an update of the current event index to the RTU, so that it can be used as a perma-nent reference for the secondary in case of primary failure (it is important for the secondary to start requesting events close to the point of the last primary request as the Kingfishers internal event queue may be up to 65535 records long).

2) If a server is shutdown for maintenance, then when restarted, it can be set

from the kernal or a cicode file to start requesting close to where it left off on shutdown.


KINGFISH.DOC 20

2.14.1 Sample Cicode using event record handling functions

INT hEventFunction; INT hNextFieldFunction; INT hLogStatFunction; INT hStartEventFunction; INT hStopEventFunction; INT hEmptyEventQueFunction; FUNCTION Init() hEventFunction = dllOpen("kingfish","GetRTUNextEvent","J"); hNextFieldFunction = dllOpen("kingfish","GetRTUEventField","CJJ"); hLogStatFunction = dllOpen("kingfish","GetRTULogStatus","J"); hStartEventFunction = dllOpen("kingfish","StartEventRequests","JCJ"); hStopEventFunction = dllOpen("kingfish","StopEventRequests","JC"); hEmptyEventQueFunction = dllOpen("kingfish","EmptyEventQue","J"); TagRead("Tag1"); StartEventRequests("PORT1", -1); END INT FUNCTION EmptyEventQue() STRING sResult; INT emptyQueueStatus; sResult = DLLCall(hEmptyEventQueFunction, ""); emptyQueueStatus = StrToInt(sResult); RETURN emptyQueueStatus; END INT FUNCTION StartEventRequests(STRING portName, INT hStartEvent) STRING sResult; INT startStatus; sResult = DLLCall(hStartEventFunction, portName + "," + hStartEvent : ####); startStatus = StrToInt(sResult); RETURN startStatus; END INT FUNCTION StopEventRequests(STRING portName) STRING sResult; INT stopStatus; sResult = DLLCall(hStopEventFunction, portName); stopStatus = StrToInt(sResult); RETURN stopStatus; END INT FUNCTION GetRTUNextEvent() STRING sResult; INT hNextEvent; sResult = DLLCall(hEventFunction, ""); hNextEvent = StrToInt(sResult); RETURN hNextEvent; END STRING FUNCTION GetRTUEventField(INT hCurrentEvent, INT fieldNum) STRING sResult; sResult = DLLCall(hNextFieldFunction, hCurrentEvent : #### + "," + fieldNum : ####); RETURN sResult; END


KINGFISH.DOC 21

INT FUNCTION GetRTULogStatus() STRING sResult; INT logStatus; sResult = DLLCall(hLogStatFunction, ""); logStatus = StrToInt(sResult); RETURN logStatus; END FUNCTION Test() INT hNextEvent; STRING sResult; INT fieldNum; INT recNum; STRING testString; WHILE GetRTULogStatus() DO hNextEvent = GetRTUNextEvent(); TraceMsg(" "); FOR fieldNum = 1 TO 10 DO sResult = GetRTUEventField(hNextEvent, fieldNum); ErrLog("EventField "+ " " +hNextEvent : #### + " " + fieldNum : #### +" "+ sResult); IF fieldNum = 1 THEN testString=TimeToStr(StrToInt(sResult),4); ErrLog("Date "+ " " +hNextEvent : #### + " " + fieldNum : #### +" "+ testString); END END END END

2.15 Hints and Tips Limitations If the trend cache is full in the driver, and there are no other tags being displayed, then the driver will not request any more trend records even if the cache is emptied by cicode calls to RTUGetNextEvent(). This is because, the way the driver is written, the decision to request trend records is initi-ated by (a) data coming in, or (b)requests from Citect, or (c) an update request or update timeout occuring (once a tag is requested by Citect the driver tries to update that tag itself, regardless of Citect). If the buffer fills, then the driver stops requesting records and wont start again till (a) or (b) occurs. This problem is mitigated by (c). Once a tag is requested by Citect (but not unit initialisation) (c) will continually occur. So, in summary, once the first tag is specifically requested by Citect, trends will be regularly updated even if the buffer fills occasionly, regardless of what if any tags are showing. Therefore a workaround for this in cicode, would be to request some tag once at the start of the trend processing cicode.


KINGFISH.DOC 22

3. References

3.1 References Kingfisher Series II Technical Information Manual Action controls

Documents

Citect for Windows Driver Specification Extract KINGFISH ... · Driver Design Specification KINGFISH.DOC 1 Citect for Windows Driver Specification Extract KINGFISH Driver Name: Comments