0% found this document useful (0 votes)

322 views100 pages

CitectSCADA 7.20 User Guide-4

Uploaded by

Fabrice Fotso

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

322 views100 pages

CitectSCADA 7.20 User Guide-4

Uploaded by

Fabrice Fotso

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 100

Chapter: 15 Communicating with I/O Devices

Installing a Driver Pack

Determining Which Driver to Use

To connect a device to CitectSCADA, you will initially need to determine which driver is
necessary to support communication with the I/O Server. In most cases, you can use one
of the following methods:
l a native driver, engineered specifically for the device
l a generic driver, available for devices that support industry-standard protocols such
as Modbus or DNP
l an OPC Server, with communication taking place via a third-party application
initially check if a native driver is available. To do this, go to the Supported Devices
page in the Driver Reference Help and locate the device you are trying to connect to.
The list is sorted alphabetically by manufacturer name. (To access the Driver Reference
Help, select Driver Help from the Help menu in Citect Explorer and Project Editor.)
If the device is not included on the list, consider the communication capabilities of the
device to determine if it supports any industry-standard protocols, such as Modbus,
DNP, COMLI or SNMP. If this is the case, you may be able to use one of the generic
CitectSCADA drivers that support these standards.
Similarly, you can use OPC to connect a device to CitectSCADA, however this will
require the purchase of a third party application to establish an OPC Server. If you take
this approach, use an OPC Server application recommended by the manufacturer of the
device you are trying to connect.
If these options do not provide an appropriate solution, you can contact Technical Sup-
port for this product.

Note: Check the Citect Driver Web at http://www.Citect.com/driverweb for infor-

mation about driver updates and new driver pack releases.

Installing a Driver Pack

If a necessary driver is new, or has been recently updated, it may not be included among
those installed with your current version of CitectSCADA. If this is the case, you will
need to obtain a Driver Pack and install it separately. See the Citect Driver Web at
http://www.citect.com/driverweb.

301
Chapter: 15 Communicating with I/O Devices

You need to install a driver pack on the computer that will connect to the target device.
This computer needs to be configured as a CitectSCADA I/O Server. It needs to be also be
installed on any machines where the CitectSCADA project is compiled.
Before installing the driver pack, close your CitectSCADA runtime environment and
Citect Explorer. You need administrator permissions for the I/O Server PC.
To install a driver pack:

1. Save the driver pack to an appropriate location on the I/O Server PC.
2. Double-click the EXE file to launch the installation.
3. Follow the instructions provided by the installation Wizard.
4. You are prompted to select the CitectSCADA installation folder. If you installed Citect-
SCADA in a different folder to the default, browse to that location. An alert message
will alert you if you have selected the wrong folder.
5. Click Finish to complete the installation.
After you have installed a Driver Pack, the associated help will be automatically merged
into the Driver Reference Help.

Note: If you are installing a driver pack on an older version of CitectSCADA that pre-
cedes the initial release of the driver, the supporting help may not appear auto-
matically in the Driver Reference Help. If this is the case, you can locate the driver
help in the CitectSCADA bin directory. The help file will be named <driv-
ername>.chm.

The Driver Update Utility

The Driver Update Utility is a tool that determines whether an update is available for
the CitectSCADA drivers you have installed on a computer. It achieves this by scanning
a PC and comparing the locally installed drivers with those available on the Citect
Driver Web.
When a scan is finished, a merged list of drivers is displayed. Each will fall into one of
the following categories:
l Recommended Updates: drivers that you have installed for which there is a newer
version available.
l Newly Available: drivers that you do not have installed that were recently released.
l Installed And Current: drivers that you have installed that match the latest version
available.

302
Chapter: 15 Communicating with I/O Devices

l Unofficial Version Installed: drivers that you have installed that are newer than the
version available on the DriverWeb. This would usually mean that you are running a
tech preview or field test version, or you have a Hotfix installed.
Once you have viewed the list, you can download a driver update (or any of the new
drivers) directly from the Update Utility.
Installation
The Driver Update Utility operates independently to CitectSCADA and is installed sep-
arately. The installer is available in the Extras directory on the CitectSCADA installation
disk, or you can obtain a copy from the Citect DriverWeb at http://ww-
w.citect.com/driverweb.

Note: The Driver Update Utility needs an Internet connection to operate successfully.
It uses a secure 128-connection when connecting to the DriverWeb.

Using the Driver Reference Help

Each driver, whether it is installed with CitectSCADA or as part of a driver pack, is sup-
ported by the Driver Reference Help.
This where you will find the specific reference information related to each driver. This
information includes:
l the device(s) each driver supports
l the address used to identify and locate a device
l any necessary device setup information
l the information necessary to configure a device in your CitectSCADA project
l the data types each driver supports
l parameters you can use to customize a driver
l driver-specific errors
Much of this information you will need to establish communication with a device; some
of it is more suited to advanced engineering tasks and troubleshooting.
To access the Driver Reference Help, select Driver Help from the Help menu in Citect
Explorer and Project Editor.
If you familiarize yourself with the processes explained in Setting Up Communications,
you will be instructed on how to use this information to configure devices within a
CitectSCADA project.

303
Chapter: 15 Communicating with I/O Devices

Customizing Communication Using Citect.ini Parameters

UNINTENDED EQUIPMENT OPERATION

l Do not under any circumstances change or remove any of the undocumented Citect.ini
parameters.
l Before deleting sections of the Citect.ini file, confirm that no undocumented parameters
will be deleted.
Failure to follow these instructions can result in death, serious injury, or equip-
ment damage.

Note: Always seek the advice of Technical Support personnel regarding undoc-
umented features.

Citect.ini parameters can be used to tune the performance of a CitectSCADA driver and
perform runtime maintenance diagnostics.
You can customize the way CitectSCADA communicates with the a driver (and even
individual PLCs) by creating or editing the section of the Citect.ini file named after a spe-
cific driver, for example, [MODBUS].
There are some ini parameters that are common to every CitectSCADA driver, as well as
custom parameters unique to each driver.
See the Driver Reference Help (Help menu | Driver Help) for the ini parameters related
to each driver, and their default values.
When CitectSCADA starts at runtime, it reads configuration values from the Citect.ini
file that is stored locally. Therefore, any configuration settings needs to be included in
the Citect.ini file located on the computer acting as the I/O Server to the devices in the
system.
By default, CitectSCADA looks for the Citect.ini file in the CitectSCADA project\bin direc-
tory. If it can't find the file there, it searches the default Windows directory.

Using a Disk I/O Device

In addition to connecting to actual I/O devices, CitectSCADA supports the configuration
of disk I/O devices, which exist only within your computer. The value of each variable
in the disk I/O device is stored on your computer's hard disk.

304
Chapter: 15 Communicating with I/O Devices

Note: With the release of V7.20, a feature called persistence can be applied to I/O
devices in memory mode. Using a Persisted Memory I/O device is recommended as
an alternative to using a disk I/O device, as full synchronization is supported if a
server becomes unavailable for a period of time. See Persisted I/O Memory Modefor
more information.

Once configured, disk I/O devices appear exactly as any other I/O device in your system,
but are not connected to any field equipment. Disk I/O devices can contain any type of
variable supported by CitectSCADA, and you can configure them to emulate any sup-
ported I/O device. You can also specify a generic protocol for a disk I/O device.
A disk I/O device is useful when the status of your plant needs to be restored after a
planned or unplanned system shutdown. You can configure your system to continually
update a disk I/O device with the subset of variables that defines the status of your
plant. When you restart your system after a shutdown, CitectSCADA can restore this
status immediately.
You can also use disk I/O devices for storing predefined data that needs to be recalled
immediately when a process is necessary (for example, in a simple recipe system).

Note: If you create a RAM disk in the computer for the disk I/O device, you do not
need to create or copy the disk file to the RAM disk. CitectSCADA automatically
creates a disk file on startup. Do not set up your Disk I/O device on a RAM disk if
you want the data written to it to survive a power cycle of the Servers.

See Also
Disk I/O Device setup
Redundant Disk I/O Devices
Using Memory Mode

Disk I/O Device setup

To set up communications with a device, follow the basic steps given in the I/O Device
setup procedure below.
Sometimes you might need to edit the communications forms directly. They require the
following specific information.
l You do not need to complete a Boards dialog box.
l You do not need to complete a Ports dialog box.
l Complete the I/O Devices dialog box as follows.
Perform the setup by entering the following information:

305
Chapter: 15 Communicating with I/O Devices

Text Box Required information

I/O Device A name or your Disk I/O Device, for example: DISK_PLC. Each I/O
name Device needs to have a unique name in the CitectSCADA system.

I/O Device A unique number for the disk I/O Device (1-4095). Each I/O Device
number needs to have a unique number in the CitectSCADA system.

I/O Device The path and filename of the disk file, for example:
address
[RUN]:DSKDRV.DSK

If you are using redundant disk I/O Devices, specify the path to both
the primary file and the Standby file in the configuration of both disk
I/O Devices.

For example, if this is the primary disk I/O Device, enter:

Primary_File, Standby_File

If this is the Standby Disk I/O Device enter:

Standby_File, Primary File

Primary_File is the name (and path) of the primary disk I/O Device
file. You may use path substitution in this part of the field.

Standby_File is the name (and path) of the Standby Disk I/O Device
file. You may use path substitution in this part of the field.

Notes:

l If the specified disk I/O device file is not found, CitectSCADA

creates a new (empty) file with the specified filename.
l To use redundant disk I/O devices, you need to use a network
that supports peer-to-peer communication.
l Disk files need to have write permission (on both primary and
standby servers).
l The frequency with which CitectSCADA writes data to the disk I/O
device(s) is determined by the [DiskDrv]UpDateTime parameter.

I/O Device To use the CitectSCADAgeneric protocol, enter: GENERIC

protocol
- or -

To select a specific protocol supported by CitectSCADA, see the I/O

Devices online Help.

I/O Device You need to use: DISKDRV

port name

I/O Device Any useful comment.

comment

306
Chapter: 15 Communicating with I/O Devices

Text Box Required information

I/O Device If not using redundant disk I/O Devices, leave this property blank.
startup
mode If you are using redundant disk I/O Devices, use either:

Primary: Enable immediate use of this disk I/O Device

StandbyWrite: This disk I/O Device will remain unused until the com-
puter with the primary disk I/O device configured becomes inoperative.
Every write request sent to the primary disk I/O Device is also sent to
this disk I/O Device.

To use StandbyWrite mode, you need to also configure an I/O disk

device in the primary server. Both I/O Devices need to have the same
I/O Device name and number.

I/O Device Leave these properties blank.

Log Write,
Log Read,
Cache and
Cache Time

See Also
Redundant Disk I/O Devices
Disk I/O Device Errors

Redundant Disk I/O Devices

If using a network, you can configure a redundant disk I/O Device to minimize the poten-
tial for data loss (in the event the server becomes inoperative). This diagram illustrates
the use of redundant disk I/O Devices:

307
Chapter: 15 Communicating with I/O Devices

When the system is operating, CitectSCADA reads and writes runtime data to the disk
I/O Device configured in the primary server. It also writes runtime data to the disk I/O
Device configured in the standby server. (CitectSCADA maintains both disk I/O Devices
identically.)
If the primary server becomes inoperative, the Disk I/O Device in the standby server is
activated without interrupting the system. When the primary server becomes active,
CitectSCADA automatically returns control to the primary server, and copies the Disk
I/O Device from the standby server to the primary server. The Disk I/O Device in the
standby server reverts to its standby role.
To define a redundant disk I/O Device:

1. Configure a new disk I/O Device

2. Select StandbyWrite for the Startup Mode.
For redundant disk I/O Devices, you need to use Microsoft Networking (or another peer-
to-peer network), and the hard disk of the standby server (the directory where the disk
I/O Device file is stored) needs to be shared. Use Windows Explorer to set the directory to
shareable.
See Also
I/O Devices Properties
Performance Considerations
Disk I/O Device Errors

Disk I/O Device Errors

The following errors, listed in order, are specific to the CitectSCADADISKDRV driver

Errors Message

48 Error Opening DiskFile

49 Error in DiskFile Header

50 DiskFile Header contains invalid variable

51 DiskFile out of memory error

52 Read Error in DiskFile

53 Write Error in DiskFile

54 Seek Error in DiskFile

55 Error creatng queue

56 Error creating thread

57 Error creating event

308
Chapter: 15 Communicating with I/O Devices

See Also
Disk I/O Device Setup
Redundant Disk I/O Devices

Using Memory Mode

When configuring an I/O Device, you have the option to set them to memory mode. This
means that the I/O Device will be created in memory and its values stored in memory at
runtime.
Refer to I/O Devices Properties for more information on how to configure an I/O Device.
Devices using memory mode are not connected to any hardware and write their values
to a cache. The I/O Device values can be read by many processes. The difference between
a local variable and a device in Memory Mode is that an I/O Device in Memory Mode
will reside in the I/O Server's memory and will observe standard networking and redun-
dancy rules of a standard I/O Device.
Memory mode is useful when you are configuring a system for the first time, as you can
design and test your system before connecting a physical I/O Device.
An I/ODevice with Memory set to TRUE or FALSE will behave differently in instances
where Variable Tags share the same address.
For example:
Define a MODNET IODevice:
1 - INT1 (INT Tag)
2 - DIG1 (DIG Tag for bit0 of INT1)
3 - DIG2 (DIG Tag for bit1 of INT1)
At runtime the Display Client will show:
1. IODevice Memory mode = FALSE, at runtime setting DIG1 = 1, DIG2 = 1, INT1 = 3,
modifiyng DIG1 and/or DIG2 affects INT1.
2. IODevice Memory mode= TRUE, at runtime setting DIG1 = 1, DIG2 = 1, INT = 0 or
cached value, modifiyng DIG1 and/or DIG2 does not affect INT1.
In both instances the Override and Control Mode settings for each tag (INT1, DIG1,
DIG2) did not affect the other tag. Setting INT1 in Override or Control Inhibit mode did
not set DIG1 or DIG2 in Override or Control Inhibit mode.
As with local variables, values in an I/O Device using only memory mode are not
retained when you shut down. However, if you set the Persist field to TRUE in the in the
extended section of the I/O Devices Properties dialog their values will be retained. For
more information on local variables, refer to Configuring Local Variables.
See Also
I/O Devices Properties

309
Chapter: 15 Communicating with I/O Devices

Persisted I/O Memory Mode

Using Persisted I/O Memory Mode

With the release of V7.20, a feature called persistence can be applied to I/O devices.
When implemented, the tag cache for an I/O device is written to an XML file at a set
period, allowing the last available data to be reloaded following a shutdown.
Persistence is enabled using the Persist field in the extended section of the I/O Devices
Properties dialog.
You can also create a persisted memory I/O device using the Express Communications
Wizard. When this type of device is selected, the wizard creates a new I/O device with
the Address and Port Name properties left blank, Memory set to “TRUE”, and Persist
set to “TRUE”. The File Name field is left empty to allow runtime to generate a default
cache file name. This file will be located in the [DATA] directory.

Migrating Disk I/O devices

When applied to I/O Devices in memory mode, persistence provides an improved alter-
native to a disk I/O device, as synchronization is supported in scenarios where a server
becomes unavailable for a period of time.
Many customers use disk I/O devices to provide system-wide global variable tags that
are managed by I/O servers and are persisted to disk to maintain their latest values.
Disk I/O devices take advantage of the standard I/O system redundancy features, such
that, if one I/O server is unavailable, another can provide client(s) with tag values. They
also perform a level of synchronization by using features such as standby write and by
providing redundant paths to the persisted binary data files, so that, at startup of an I/O
server, the latest value can be read into the system from the latest modified data file.
However, there is no synchronization when network connections are inoperative and
regained, resulting in several scenarios in which redundant disk I/O devices can end up
with different values for the same tag. For this reason, it is recommended that data
assigned to disk I/O devices be migrated to the new persisted memory I/O mode avail-
able in V7.20.
To migrate disk PLC devices to persisted I/O memory mode:

1. Perform the procedures listed in Upgrading to CitectSCADA v7.20, as is appropriate.

2. On the I/O Device dialog, for disk I/O devices set Background Poll to TRUE and set
Persist to TRUE (the default setting).
3. Start the I/O server up and wait for a few minutes so that the background poll
updates every tag.
4. Shutdown the I/O server.

310
Chapter: 15 Communicating with I/O Devices

5. On the I/O Device dialog, for disk I/O devices set Background Poll back to FALSE, set
Memory to TRUE and clear out the Port Name field as it is not necessary for Memory
Mode.
6. Restart the I/O server to finish the migration to persisted memory I/O mode, with
your devices now containing your original values from the disk I/O device.
See Also
Using Memory Mode

Troubleshooting Device Communications

Debugging device communications involves the following processes:
l gathering system information about current communication status
l analyzing the available information to identify problems
The information needed to facilitate this is available from the following resources:
l hardware alarms
l driver errors
l log files (system, trace, debug and driver logs)
This information can be analyzed directly to identify problems, or you can use the Citect-
SCADA Kernel to perform low-level diagnostic and debugging operations.
There are also procedures you can follow to debug low-level communications protocols,
such as COMx and TCP/IP.
See also
Gathering communications information
Debugging communications

Gathering information about device communication

If you cannot establish communication with a device, check the following resources for
evidence of a problem:
l Hardware alarms
l CitectSCADA log files
l Driver errors
l Citect Kernel

311
Chapter: 15 Communicating with I/O Devices

Hardware Alarms
When an error occurs in a CitectSCADA operation, a hardware alarm is generated. Hard-
ware alarms are typically displayed on a dedicated page within a project, allowing an
operator to monitor the status of a system's infrastructure.
Hardware alarms will indicate if break in communications has occurred, if Cicode can't
execute, if a server becomes inoperative, and so on. If you are having problems com-
municating with a device, initially check the hardware alarms page for evidence of an
error.
See Hardware Alarms.

CitectSCADA log files

CitectSCADA supports a number of log files that track operational status during run-
time.
The primary log file, syslog.dat, contains a log of system information; from low-level
driver traffic and Kernel messages, to user-defined messages.
The Log Read and Log Write fields in the I/O Devices Properties dialog determine if log-
ging is enabled for each I/O device.
Driver logs are also available. These relate to the operation of a particular driver and are
named accordingly. For example, the OPC driver is logged in 'OPC.dat'.
For a description of the available log files and where they are stored, see Log files.

Driver errors
There are two types of driver errors that are logged to syslog.dat:
l generic
l driver-specific
Generic errors are common to many drivers, and are mapped to general hardware
errors.
Driver-specific errors are unique to a particular driver. A driver will convert a specific
error into a generic error so that it can be recognized by the hardware alarm system.
However, if further investigation is necessary, you can refer to a description of the orig-
inal error in the Driver Reference Help. This includes a description of the errors asso-
ciated with each driver.
See Driver Error Messages.

312
Chapter: 15 Communicating with I/O Devices

Citect Kernel
The Citect Kernel is a gateway into the internal workings of CitectSCADA at runtime,
and is provided for diagnostics and debugging purposes.
The Kernel can display several different diagnostic windows each providing an active
view of the CitectSCADA runtime system.
The Citect Kernel Driver window, launched via the Page Driver Kernel command, dis-
plays information about each driver in the CitectSCADA system. The statistics it
presents include read requests, physical reads, digital reads per second, register reads,
cache reads, error count, timeouts, and so on.
See Using the Citect Kernel.
See also
Debugging communications

Debugging I/O Devices and Protocols

Before commissioning any system, test communications between CitectSCADA and the
I/O Devices. Many people leave this last, only to uncover communication issues that
they cannot resolve.
The following information is provided to encourage you to test your communications
thoroughly before it becomes a time critical-element in the job. It will also help you to
debug communications and protocol conditions yourself.
See Also
Creating a communications test project
Debugging a COMx driver
Debugging a TCP/IP driver
Debugging a protocol driver using serial communications
Debugging proprietary board drivers
Contacting Technical Support

Debugging a COMx driver

A COMx driver is the board driver typically used for serial communications. Since ver-
sion 2.01, the COMx driver allows you to dump debug information.
Three files are produced for each com port: a write file, a read file and status file. The
debug files are configured by settings in the Citect.ini and are written and are written to
the path specified in [CtEdit]Logs.
The following Citect.ini entries are used:

313
Chapter: 15 Communicating with I/O Devices

Parameter Default Comments

WritePortName (no value) Port name as defined in the Ports form

WriteFileSize 1000 Size in KB

WriteDebugLevel 0 1 to enable debugging, 0 to disable

ReadPortName (no value) Port name as defined in the Ports form

ReadFileSize 1000 Size in KB

ReadDebugLevel 0 1 to enable debugging, 0 to disable

StatusPortName (no value) Port name as defined in the Ports form

StatusFileSize 1000 Size in KB

StatusDebugLevel 0 1 to enable debugging, 0 to disable

CharTimeOut 11 CharTimeOut specifies the maximum acceptable

time (in milliseconds) to elapse between the arrival
of two characters on the communication line. During
a ReadFile operation, the time period begins when
the first character is received. If the interval
between the arrival of any two characters exceeds
this amount, the ReadFile operation is finished and
any buffered data is returned. A value of zero indi-
cates that interval time-outs are not used.

PassIfAnyInitPortsPass 0 Set to 1 if you wish to start when a COMx port is

missing.

Example

[COMx]
WritePortName=PORT_1,PORT_2
WriteDebugLevel=1
WriteFileSize=2000
ReadPortName=PORT_1
ReadDebugLevel=1
ReadFileSize=1000
StatusPortName=PORT_2
StatusDebugLevel=1
StatusFileSize=10

The above example would:

l Log to "write" files up to 2000 kb of the data sent by the CitectSCADA driver to both
PORT_1 and PORT_2;
l Log to a "read" file 1000 kb of the data received by the CitectSCADA driver from
PORT_1; and
l Log up to 10 kb of status data from PORT_2 to a "status" file.
This would also result in the following text files being created:

314
Chapter: 15 Communicating with I/O Devices

l WPORT_1.dat
l WPORT_2.dat
l RPORT_1.dat
l SPORT_2.dat
In general, the format for the file names is "R", "W" or "S" followed by the Port name
requested, followed by ".dat". The file names represent the corresponding "Read", "Write"
and "Status" files.

File formats
The Write file will adopt the following format:

LINE 1 WRITE Debug file Started PORTNAME Debug Level 1 DOW MONTH DOM
HH:MM:SS.sss

LINE 2 HH:MM:SS.sss

LINE 3 Out W In X nBytes Y Status Z

LINES AA BB CC ..
4...

where:

W&X= Values of buffer pointers

Y= Number of bytes written

Z= Return status of the WriteFile

AA BB CC = Values in hex of each byte written

Example:

WRITE Debug file Started PORT1_BOARD1 Mon Dec 15 16:07:.998

16:07:09.810
Out 0 In 8 nBytes 8 iStatus 997
0e 02 00 00 10 00 00
16:07:10.802
Out 8 In 16 nBytes 8 iStatus 997
0e 02 00 00 00 10 00 00
..

The Read file will adopt the following format:

315
Chapter: 15 Communicating with I/O Devices

LINE 1 READ Debug file Started PORTNAME Debug Level 1 DOW MONTH DOM
HH:MM:SS.sss

LINE 2 HH:MM:SS.sss

LINE 3 Out W InRx X nBytes Y Status Z

LINES AA BB CC ..
4...

where:

W&X= Values of buffer pointers

Y= Number of bytes read

Z= Number of characters remaining in the buffer

AA BB CC = Values in hex of each byte written

Example

READ Debug file Started PORT1_BOARD1 Mon Dec 15 16:07:07.998

16:07:09.830
Out 0 In 0 nBytes 8 iStatus 0
0e 02 00 00 00 10 00 00
16:07:10.822
Out 0 In 8 nBytes 8 iStatus 0
0e 02 00 00 00 10 00 00

The Status file will adopt the following format:

STATUS Debug file Started PORTNAME Debug Level 1 DOW MONTH DOM
LINE HH:MM:SS.sss
1

HH:MM:SS.sss
LINE
2

modemStatus X
LINE
3

Example

316
Chapter: 15 Communicating with I/O Devices

STATUS Debug file Started PORT_1 Debug Level 1 Wed Nov 05

15:28:55.310
15:29:55.950
modemStatus 34
..

More parameters might be added later, so check the COMx information and the Citect
Knowledge Base regularly.
See Also
Debugging a TCP/IP driver

Debugging a TCP/IP driver

A TCP/IP driver is the low-level driver that is used for any TCP/IP communications. It
might be over Ethernet, Token Ring or Arcnet. This driver communicates between Citect-
SCADA and Winsock, so it uses the normal networking functionality of Windows. The
parameters used for TCP/IP are:
l [TCPIP]Log
Dumps the traffic between the CitectSCADA TCPIP.DLL and Winsock to a text file
called TCPIP.DAT in your Logs directory. The size of the log is governed by the Logs-
Size parameter
Allowable Values:
1 - Enables logging
0 - Disables logging
Default value = 0
l [TCPIP]LogSize
Sets the default maximum size (in kilobytes) of the TCP/IP driver's log file before
wraparound occurs.
Allowable Values: any integer
Default value: 200
l [TCPIP]LogTxRx
Log actual data Tx & Rxs besides setup info.
Allowable Values:
1- Enables logging of Tx & Rx
0 - Disables logging
Default value -= 0
l [TCPIP]NoBufferSleepTime
Sleep time in ms to wait AFTER getting a WSAENOBUFS (no system buffers mes-
sage) before reading another buffer. There is no need to adjust this.
Default value: 0
l [TCPIP]PortName
PortName to log.

317
Chapter: 15 Communicating with I/O Devices

Default value: * (by default every port is traced)

l [TCPIP]Timeout
Defines the timeout period between connection retries.
Default value: 1000 (ms)
l [TCPIP]PortName.MulticastAddress
This parameter allows you to implement the TCPIP driver option "-Maa.bb.cc.dd"in
the Citect.ini file. This may be necessary if you have run out of characters in the Spe-
cial Options field of the Ports Form, which is limited to 16 characters.
You need to specify the following in the Citect.ini file:
[TCPIP]PortName.aaa.bbb.ccc.ddd
where:
PortName = the name of the port as entered in the Ports Form
aaa.bbb.ccc.ddd = the multicast Class D IP address
See TCP/IP driver special options reference.

Procedure for debugging TCP/IP

Use the following steps for debugging:
1. Check if you can PING your target I/O Device. If you can't, CitectSCADA cannot talk
to it. To do this open up a Command Window and type PINGaaa.bbb.ccc.ddd where
a.b.c.d is the IP address of the I/O Device you are trying to connect to. If PING does
not work, you need to go back to your Windows Networking and fix that.
2. Keep using your Simple As Possible Project (SAPP).
3. Delete any old tcpip.dat files.
4. Set the Debug=1 and Log=1 parameters in your Citect.ini file.
5. Start the project. From the information in the maximized Main window of the Kernel
and the TCP/IP Debug window, you can see if CitectSCADA is sending requests to
your I/O Device to initialize communications with it.
If there are no requests being sent, your software is improperly configured, and check
that there were no errors on startup of CitectSCADA. If there were errors on startup, look
them up in the Help. Also check that your computer is an I/O Server (and that it
matches the one in your project). To do this run the Computer Setup Wizard, and con-
figure the computer for a standalone configuration.
If there are requests, you can see communications between CitectSCADA and Winsock in
a separate window, which displays the requests made by CitectSCADA to connect to the
I/O Device and the corresponding response from the I/O Device. Any errors have a Win-
sock Error code that you can look up in the Microsoft Knowledge Base. If you see a Con-
nection OK message, CitectSCADA will be able to come online.
See Also
Debugging a protocol driver using serial communications

318
Chapter: 15 Communicating with I/O Devices

Debugging a protocol driver using serial communications

To debug a protocol driver that uses serial communications, do the following:
1. Keep using your Simple As Possible Project (SAPP).
2. Set the "DebugStr=* all" for your protocol.
3. Backup and delete both the syslog.dat and syslog.bak files. The system will recreate a
fresh version of this file the next time CitectSCADA is started.
4. Start the project. From the information you can see in the maximized Main window
of the kernel be able to see if CitectSCADA is sending requests to your I/O Device to
initialize communications with it.
If there are no requests being sent then your software is improperly configured, and
check that there were no errors on Startup of CitectSCADA. If there were errors on
startup look them up in the Online Help. Also check that your computer is an I/O Server
(and that it matches the one in your project). To do this run the Computer Setup Wizard,
and configure the computer for a standalone configuration.
If there are requests being sent but no reply, then CitectSCADA is trying to communicate.
When CitectSCADA is sending requests but getting no reply, these are the most common
causes:
l The request CitectSCADA is sending is not getting to the I/O Device - Check the
Address field in the I/O Devices form, and verify that it is correct. If the I/O Device is
one that needs a unique identifier (such as a node address), or you need some type of
routing path, then verify that it is correct.
Check that you have the same parameters in the Ports form that the I/O Device is
using. If you have 8 data bits and the I/O Device uses 7 data bits, communications
will not work.
Check that your cable is OK. The easiest way to do this is to create a new project and
use the Loopback protocol. You can use this to verify the Tx and Rx lines' integrity
by placing a jumper on these lines. Initially test this with a jumper between pins 2
and 3 on your PC. Then plug in your cable and test again with the jumper between
the Tx and Rx lines. Keep moving the jumper until it is at the end of your com-
munications bus. You can find more information on using the Loopback protocol in
the Citect Knowledge Base.
Even if the Loopback protocol shows no errors, your cable might still be responsible
for the loss of communications. CitectSCADA usually places a far higher constant
load on serial communications than programming software does, this usually means
that CitectSCADA will require much more stringent handshaking than the pro-
gramming software. So it is possible that the cable you use to program your I/O
Device works fine for programming, but not for CitectSCADA. Check the Wiring Dia-
gram for your Protocol in the help.

319
Chapter: 15 Communicating with I/O Devices

Another major cause of improper cable connections is 9-pin to 25-pin converters.

Many of these converters are made specifically for serial mice. These typically only
use the Tx, Rx and Ground signals. If you use one of these converters they do not
support any handshaking and will most likely not work for your Protocol.
If the above checks OK, use the parameters for COMx (as mentioned above) to create
log files. Examine these log files and verify that what CitectSCADA thinks it is send-
ing is actually what it is sending. The log files produced by using these parameters
get their information from a lower level than CitectSCADA and show you exactly
what is going through the COMx driver.
l The Response from the I/O Device is not getting to CitectSCADA - This is unlikely
and usually caused by cabling that is damaged, has insufficient bandwidth, or is con-
nected improperly.. Check your cabling as above. Also, check that you are specifying
everything you need within CitectSCADA. Many protocols require CitectSCADA to
send a unique identifier in its request packet. If this identifier is incorrect then the
response cannot get back to CitectSCADA.
l The I/O Device does not understand the Request - Every CitectSCADA protocol can
check if an I/O Device is running. Typically the protocol attempts to read data from
the I/O Device, usually a status register or other register that is there. However, many
pseudo-standard protocols, such as Modbus, do not conform to the exact spec-
ification for that protocol. Many protocols supplied with CitectSCADA have some
extra parameters to allow you to choose the specific initialization request from Citect-
SCADA. These can be found in either the Online Help or the Knowledge Base. Check
with the manufacturer of your I/O Device to confirm that it will respond to the
request that CitectSCADA sends. If you are unsure of the request being sent for initial-
ization, use DebugStr=* to get the actual variable address that CitectSCADA is asking
for in its initialization.
Check the protocol you are using. CitectSCADA may have many different protocols
for communicating to an I/O Device. PLCs such as the AB PLC5 can use different
serial protocols, depending on the method you are trying to use. Make sure you are
using the correct one. If you are unsure, try the other possible protocols.
l The I/O Device is not functioning properly - There is usually some sort of software
from the I/O Device manufacturer that can be used to diagnose any problems with
the I/O Device.
See Also
Debugging proprietary board drivers

320
Chapter: 15 Communicating with I/O Devices

Debugging proprietary board drivers

Proprietary board drivers (such as the Allen Bradley KTX card, Modicon SA85 card,
Siemens TIWAY card, and so on) have their own low-level drivers. Each driver has
debugging parameters to make it easier to debug device behavior. Check the Citect-
SCADA Knowledge Base and Help for parameters. The Knowledge Base has articles
describing how to debug these board drivers.
The debugging process is exactly the same as with a serial connection:
1. Keep using your Simple As Possible Project (SAPP).
2. Set any debugging parameters for the protocol and board drivers.
3. Start CitectSCADA with clean log files.
4. Find any errors and then look them up in the manufacturer's documentation.

Serial Port Loop-Back Test

You can use the serial port loop-back test to test your serial hardware configuration. This
test can be used with any COM port, whether it is local, or on a multi-port serial board
(such as a Digiboard). The test can be performed internally or externally with loop-back
cable attached.
See Also

Test Setup

Serial Port Loop-Back Cable

Test setup
1. Do not configure any other protocols. Temporarily delete other boards and units
while performing this test.
2. Configure a unit for each port to be tested. Make the I/O Devices form look as follows:
l Name: <unique name for the I/O Device>
l Number: <unique network number for the I/O Device>
l Address: NA
l Protocol: LOOPBACK
l Port Name: <the "Port Name" in the Ports form>
3. The following Citect.ini options are supported:

321
Chapter: 15 Communicating with I/O Devices

l [LOOPBACK]

LoopBack - Set this to 1 if internal loop-back is to be performed (make sure this is

deleted after running the test). When set to 0, a loop-back connector which ties pins 2
and 3 together is necessary at each port.

Note: The COMx driver does not support internal loop-back. The external loop-
back is the default mode.

Size - Sets the maximum frame size. The length of each frame transmitted is random
between 1 to 'Size'-1. The default size is 512.
4. Start up CitectSCADA. Each port will transmit a frame of random length. This proc-
ess is repeated when the entire frame is received.
5. Open the kernel, type "page driver" and press Enter. Type V to set the display mode
to 'verbose'. The following statistics appear:
l Number of characters transmitted.
l Number of frames transmitted.
l Number of characters received.
l Elapsed time in milliseconds.
l Characters received per second.
l Start time in milliseconds.
l Total number of errors.
l Error code of last detected error.

Note: The total number of errors should be 0. If the number of errors reported is
not zero, your serial hardware is not operating properly.

Serial port loop-back cable

The diagram below shows the loop-back connections to use with RS-232.

322
Chapter: 15 Communicating with I/O Devices

The diagram below shows the loop-back connections to use with RS-422 or RS-485.

Contacting Technical Support

If your debugging efforts do not succeed within a reasonable amount of time, contact
Technical Support for this product and provide the following information:
l a Solution Request which you can obtain through Technical Support.
l syslog.dat, syslog.bak, tcpip.dat, or COMx log files.
l A copy of the SAPP, and the Citect.ini file.
See Getting Technical Support.

323
Chapter: 15 Communicating with I/O Devices

Performance Considerations
Many external factors influence the performance of control and monitoring systems. The
capabilities of the computer, the I/O Device(s), and the communication pathway between
them are obvious factors. The faster they can transfer data, the faster your system oper-
ates. (CitectSCADA always attempts to maintain a data transfer rate as fast as the I/O
Device hardware can support.) The data transfer rate is hardware dependent: once you
have installed the hardware, your ability to influence this characteristic is limited.
However, there is one area where you can directly affect the performance of your run-
time system: the arrangement of data registers in the I/O Device(s).
See Also
Caching data
Grouping registers
Remapping variables in an I/O Device

Caching data
On large networked systems with many clients, you can improve communications turn-
around time by using memory caching.
When caching is enabled, data that is read from an I/O Device is stored temporarily in
the memory of the I/O Server. If another request is made (from the same or another
client) for the same data within the cache time, the CitectSCADA I/O Server returns the
value in its memory, rather than rereading the I/O Device. Data caching results in faster
overall response when the same data is necessary by many clients.
A cache time of 300 milliseconds is recommended. Avoid using long cache times (in
excess of 1000 milliseconds), as this may negatively impact the timely delivery of infor-
mation to the system.

Note: Do not use data caching for disk I/O devices as they implement a cache them-
selves.

How data caching works

Data caching prevents unnecessary rereads of I/O Device data within a short period of
time. Unnecessary reads can be generated when more than one client requests the I/O
Server to read data from a PLC or similar I/O Device within a short (typically 300 ms)
period of time.

324
Chapter: 15 Communicating with I/O Devices

Normally, upon request from a client, an I/O Server reads status data from an I/O
Device, and passes it back to the requesting client.
If the server receives subsequent requests from other clients before the original data is
returned to the first client, it optimizes the read by automatically sending the original
data back to requesting clients. (Page General Blocked Reads shows this count).
If a client requests the same data immediately after the server returned the data to a
client, the server rereads the device unnecessarily.
Setting the data cache time to 300 ms (or similar) prevents identical repetitive reads
within that cached time frame. If further clients request the identical data from the same
server up to 300 ms after the server has sent that data to an earlier client, the cached
data on the server is sent immediately in response to the subsequent requests.

Note: Multiple clients don't have to be separate CitectSCADAs on a network. They

may be the alarms and trend clients in the same computer, so this optimization will
affect even a single node system.

CitectSCADA also uses read-ahead caching. When the data in the cache is getting old
(close to the cache time), the I/O Server will re-request it from the I/O Device. This opti-
mizes read speed for data that is about to be re-used (frequent). To give higher priority to
other read requests, the I/O Server requests this data only if the communication channel
to the I/O Device is idle.

Keeping a persistent record of the data

To keep a persistent copy of cached device data, you can save the I/O Server's cache to
disk. For every [IOServer]SavePeriod, the data is saved to s, one for each cached device.
Saving the data to disk will, in most circumstances, allow you to shut down and restart
the I/O Server without having to contact each I/O Device again to get its current values.
Instead, you can read the values from the device's persistence cache.

Note: When read-through caching is enabled for a remote or scheduled I/O Device,
the persistence cache for that device is saved to disk when the active I/O Server dis-
connects from the device. This occurs regardless of the value set in [IOServer]S-
avePeriod. You can enable read-through caching by setting the parameter
[Dial]ReadThroughCache.

Analog status common to more than one Graph-

Digital status unique to Graphics Page 2
ics Page

326
Chapter: 15 Communicating with I/O Devices

Analog trends (for data logging) on largest time-

base (for example 10 secs)

Digital status unique to Graphics Page n

Digital status common to more than one Graph- Analog trends (for data logging) on smallest
ics Page timebase (for example 1 sec)

All other digital status, for example for logging. Analog alarms

Analog status unique to Graphics Page 1

Analog status unique to Graphics Page 2

While memory constraints and the existing PLC program might impose limitations,
grouping registers into discrete blocks, even if they are not consecutive blocks, will
improve system performance.
When designing your system, allow several spare registers at the end of each block for
future enhancements.
See Also
Remapping variables in an I/O Device

Remapping variables in an I/O Device

Some PLCs allow you to remap (or copy) an I/O Device variable to another register
address. CitectSCADA allows you to remap to:
l Group registers more efficiently to increase performance.
l Allow CitectSCADA to interpret a variable type (for example, an analog variable) as a
different variable type (for example, a digital variable). For example, you can create
additional digital addresses if an I/O Device has run out of digital addresses.
To remap a variable in your PLC, you need to design (or modify) the logic in the PLC to
associate both addresses. CitectSCADA can then read or write the variable to and from
the remapped address instead of the physical address.

327
Chapter: 15 Communicating with I/O Devices

You can also reassign one type of variable (for example, an integer) to another type of
variable (for example, a digital variable).

328
Chapter: 15 Communicating with I/O Devices

To remap in CitectSCADA, first create the variables in your project as you would nor-
mally. Then you can set up the remapping, specifying that any variable with an address
in the desired range will be remapped. The I/O Server will redirect the addresses at run-
time as per the remapping instruction.

Note: Not every PLC and/or CitectSCADA driver supports remapping. It is not rec-
ommend unless necessary. Contact Schneider Electric (Australia) Pty. Ltd. Support if
you need to evaluate whether the PLC and/or driver support remapping.

To remap a variable in CitectSCADA:

1. Open Project Editor.

2. Choose Communication | Remapping. The Remapping dialog box appears.

Option Description

CitectSCADA variable The first remapped (CitectSCADA) variable defined in the var-
iable tags database (using the Tags dialog box); for example:
Motor_1_Run.

(79 characters maximum). Alternatively, use the direct <Unit

Name>|<Address>| format (using values specific to your I/O
Device); for example: IODev|X1|.

The address entered here is remapped. At runtime the I/O

329
Chapter: 15 Communicating with I/O Devices

Option Description

Server will read/write data through the physical address

instead.

Length The number of remapped variables. CitectSCADA reads

enough physical variables to remap this number of variables
(10 characters maximum).

The length needs to be less than the maximum request length

of the protocol. The protocol overview displays the maximum
request length of the protocol.

Physical Variable The first physical variable in the PLC, for example: ReMa-
pIntV7. (79 characters maximum).

This variable does not need to be defined in the variable tags

database. You can use the <Unit Name>|<Address>| format
(using values specific to your I/O Device). For example,
IODev|V7|.

Remap Read Determines whether to perform the remapping for reads. Set
to TRUE or FALSE.

FALSE - Read normal (not remapped) variables. The actual

address of the CitectSCADA variables will be read directly
from the I/O Device, instead of through the Physical Variable.
(Use this mode if your I/O Device does not support remap
reads.)

TRUE - Read remapped variables (through the physical var-

iable).

Remap Write Determines whether to perform the remapping for writes. Set
to TRUE or FALSE.

FALSE - Write to normal (not remapped) variables. The actual

address of the CitectSCADA variables will be written directly in
the I/O Device, instead of through the physical variable. (You
need to use this mode if your I/O Device does not support
remap writes.)

TRUE - Write to remapped variables (through the physical var-

iable).

Comment Any useful comment (48 characters maximum).

3. Complete the dialog box, and then click Add.

Note: To determine if the device supports remapped reads or writes, see the I/O
Device data type Help.

330
Chapter: 15 Communicating with I/O Devices

Variable Tag Name Motor_1_Running_Feedback

Data Type Digital

I/O Device Name Area1

Address M1

Variable Tag Name Motor_1_Overload

Data Type Digital

I/O Device Name Area1

Address M3

Variable Tag Name Motor_4_ Running_Feedback

Data Type Digital

I/O Device Name Area1

Address M4

331
Chapter: 15 Communicating with I/O Devices

Variable Tag Name Motor_4_ Running_Feedback

Data Type Digital

I/O Device Name Area1

Address M16

Notice that the address M2 is not used. Skipping addresses does not affect performance.
Remapping database
The remapping is defined as follows.

CitectSCADA Variable Area1|M1|

Length 16

Physical Variable Area1|R10|

Remap Read True

Remap Write False

The physical variable is an integer data type; it does not need to be defined in the var-
iable tags database (but it can be).

Advanced Driver Information

This section provides advanced information about drivers.
See Also
Variable (Digital) Limitations
Validating distributed project data for tag-based drivers
Write Delay Issue

Variable (digital) limitations

Devices often have memory areas that are of a designated data type, like Byte, Integer, or
Word. Some protocols do not support the reading and writing of data in these memory
areas using a different data type. This situation is most common in the case of reading
and writing of individual bits within the data types like Bytes, Integers, and Words.

332
Chapter: 15 Communicating with I/O Devices

In this case, reading individual bits within these larger data types is done by reading the
designated data type and getting the CitectSCADA driver to sub-divide it into individual
bits. Writing to bits within the larger data types is more complicated, as writing to one
bit within the larger data type will at the same time overwrite the other bits within that
same data type. To prevent overwriting existing bits when writing a new bit value, a
'read-modify-write' scenario can be used to write to a bit within the larger data type.
Using this approach, the CitectSCADA driver will read the larger data type, modify the
appropriate bit within the larger data type, and then write the larger data type back to
the device.
While the 'read-modify-write' approach is necessary to avoid overwriting existing bits in
the registers of larger data types, it can create an issue if the device being written to is
also configured or programmed to modify these same registers. For example, if a PLC
device modifies the registers of one of its larger data types after the CitectSCADA driver
has read these same registers, but before CitectSCADA has written the modified value,
the changes made by the PLC will be overwritten. This outcome can be avoided if Citect-
SCADA and any devices using these data types are configured so that only one or the
other has write access at any given time.
This 'read-modify-write' method has a serious operational concern: if the device modifies
the larger data type after the CitectSCADA driver has read it, but before CitectSCADA
has written the new value, any changes made by the device are overwritten. This issue
could be serious in a control system, and it is recommended that the device and Citect-
SCADA be configured so that only one of these systems writes to the data types of this
kind.

UNINTENDED EQUIPMENT OPERATION

When the read-modify-write method will be used to alter a data type's bit values, configure
your system so that Citect and the host device do not have simultaneous write access to the
affected memory ranges.

Failure to follow these instructions can result in death, serious injury, or equip-
ment damage.

Consider the following example:

1. The initial state of a PLC register is 0x02h.
2. The CitectSCADA driver reads the value of this register (effectively making a copy) in
preparation for a change to bit 3.
3. However, before the driver writes its change back to the PLC, the PLC code changes
the value of bits 0 and 4 of this register to 0x13h.

333
Chapter: 15 Communicating with I/O Devices

4. The CitectSCADA driver then changes bit 3 of its copy of the register to 0x0Ah. When
it writes to the PLC, it overwrites the PLC's copy of the whole register (not just the
changed bit). Because the PLC code modified bits 0 and 4 in the interval between
CitectSCADA's read and write, these changes are overwritten.

Validating distributed project data for tag-based drivers

CitectSCADA uses numeric index values to uniquely identify the variable tags in a
project. They are used as a reference point when requesting data from the I/O Server for a
tag-based driver.
These index values are automatically generated when a project is compiled. Cir-
cumstances may arise where a distributed project has index values that represent dif-
ferent tag addresses on different computers. For this reason, CitectSCADA has a number
of automatic checks in place that validate a project's tag index values and flag any dis-
crepancies.
An initial security check takes place on client machines at a unit level, allowing a tag
index mismatch to be isolated to a particular client before any requests are sent to the I/O
Server. This confirms that the unit address, the unit type, the raw data type and the tag
address match for index values across the client and server machines. Any dis-
crepancies found are flagged by a hardware alarm on the client machine.
Each page is also checked to confirm that it was compiled against the current version of
the variables database. There is also a check performed whenever a tag-based driver
loads the variable database to test whether it matches the current tag addresses. The
parameter TagAddressNoCase allows you to adjust the case-sensitivity of these checks.
In addition, CitectSCADA will also check if a project is currently running on the local
machine when a compile is attempted, as this is one of the circumstances that may lead
to mismatched index values.
If the project uses a tag-based driver and is currently in runtime, CitectSCADA will stop
the compiler and generate an error in the error database noting that Citect32.exe was still
running. The .ini parameter [General]CitectRunningCheck allows you to override this fea-
ture, however it is recommended that you leave it enabled so that your tag index values
are assigned as intended.

Write delay effects

CitectSCADA performs writes to the I/O Device asynchronously (that is, when you write
to the I/O Device, the write takes time to get to the I/O Device, during which Citect-
SCADA continues to perform other operations). If the other Cicode assumes that the
write has completed immediately, you might encounter some side effects such as incon-
sistencies in the value of a variable tag across two Cicode threads.

334
Chapter: 15 Communicating with I/O Devices

If you have the following Cicode:

PLC_VAR = 1234;
Prompt("Variable is " + PLC_VAR : ####);

the first line is a write to the PLC.

When CitectSCADA executes the first line, it generates a request to the I/O Server to write
the value 1234 into the PLC variable PLC_VAR. CitectSCADA then executes the next line of
Cicode before the PLC write is completed. CitectSCADA does this so that the Cicode is
not stopped while waiting for a slow I/O Device. As the write to the PLC has not com-
pleted, you might think that the next line of Cicode will display the last value of PLC_VAR
and not the value 1234. However, this Cicode will display the correct value (1234)
because whenever CitectSCADA writes to the PLC, it first updates its local copy of the
variable: any following Cicode will get the correct value.
Sometimes this solution will not work as CitectSCADA might keep multiple copies of an
I/O Device variable, and only update the one associated with the current Cicode. The
other variables will contain the old value of the I/O Device variable until they are
refreshed (with a read from the I/O Device). There is a separate data area for each dis-
play page, Cicode file, for alarms, trends and reports. If you write to an I/O Device var-
iable from a page keyboard command, the copy of the I/O Device variable associated
with that page will be updated; however, the copy associated with other pages and the
Cicode functions is not updated until the next read (as determined by the [Page]ScanTime
parameter). If you call a Cicode function that assumes the write has completed, it will
get the last value.
The workaround is to write to the I/O Device variable in the Cicode function. Every
Cicode function shares the same I/O Device variables, so the writes will operate as
expected.

FUNCTION
TestFunc(INT nValue)
PLC_VAR = nValue;
END

Another side effect of the delays inherent in asynchronous writes to I/O devices is that
you might assume that CitectSCADA has successfully written to the I/O Device, when in
fact the write operation might not yet have been completed or even attempted. In such
cases, it is still possible that a hardware- or configuration-based error will prevent the
success of the write operation. While such an unsuccessful write operation will generate
an error, your Cicode cannot be notified or use the IsError() function because the Cicode
has continued to execute past the initial I/O device write command. Therefore, when it is
important to check the success of a write operation before allowing code execution to con-
tinue, you might insert the function TagRead() after the write and then verify the value of

335
Chapter: 15 Communicating with I/O Devices

the variable. TagRead() forces Cicode to re-read the I/O Device variable so that you can
check the new value. TagRead() is a blocking function. It blocks the calling Cicode task
until the operation is complete.

PLC_VAR = 1234;
sTestStr = TagRead("PLC_VAR");
IF sTestStr <> 1234 THEN
Prompt("Write not completed");
END

Here the data will be read from the physical PLC, not from the I/O Server cache, as the
I/O Server will invalidate any cached data associated with a PLC write. This will allow
you to test for a completed write. Please be aware that other Cicode tasks running at the
same time will not be waiting on the TagRead, so they might see the old or new value,
depending on if they are using the same copy of the PLC variable. You can also stop
CitectSCADA from writing to the local copy of the variable by using the function Code-
SetMode(0, 0).

Communicating with Remote Devices via Modems

A dial-up remote I/O Device is one which is connected to CitectSCADA through a PSTN
(Public Switched Telephone Network), and is accessible through pre-selected and pre-con-
figured modems.
Once connected, CitectSCADA can write to, and read from, dial-up remote I/O Devices
just as it does with any other I/O Device: local or remote.
Communications can be:
l On request: initiated by CitectSCADA using IODeviceControl() or by the remote I/O
Device (for instance, to report an alarm condition).
l Periodic: for instance, to transfer the logged events for a period.
l Persistent: for instance, to monitor and control the water level at a remote dam.
The only limiting factor would be an inability to connect a modem to an I/O Device due
to incompatible communications capabilities. Many I/O Devices have fixed settings and
can only communicate at a pre-set rate determined by the manufacturer. If a modem can-
not match these settings, communication cannot be established.
To make communications setup easier, you can connect dial-up remote I/O Devices with
identical communications to the same modem and port. Where I/O Devices are con-
nected to the same modem, CitectSCADA can communicate with each I/O Device one
after the other using the same phone connection, rather than hanging up and re-dialing.
This reduces the number of necessary telephone calls and increases the speed and effi-
ciency of communications.

336
Chapter: 15 Communicating with I/O Devices

You need to have at least one modem at the I/O Server end, and at least one at the I/O
Device end.
See Also
Modems at the I/O Server
Modems at the I/O Device
I/O Device constraints for multi-dropping
Configuring multidrop remote I/O Devices
I/O Server redundancy for dial-up remote I/O Devices
Troubleshooting dial-up remote I/O Device communications

Modems at the I/O Server

To decide how many modems to use at the I/O Server end, decide what function each
modem will perform. A single modem can do any one of the following functions:

Dial- Makes calls to remote I/O Devices in response to a CitectSCADA request; for
out example, scheduled, event-based, operator request, and so on. Also returns
calls from remote I/O Devices.

Dial- Only receives calls from remote I/O Devices, identifies the caller, then hangs up
in immediately so it can receive other calls. CitectSCADA then returns the call
using a dial-back or dial-out modem.

Dial- Only returns calls from remote I/O Devices.

back

Dial- Receives calls from remote I/O Devices and makes scheduled calls to remote I/O
in Devices.
and
dial-
out

Dial- Receives and returns calls from remote I/O Devices.

in
and
dial-
back

Your modem setup depends on your system requirements. When making your decision,
consider the following guidelines:
l If you need to communicate with multiple remote I/O Devices at once, you will need
a separate modem for each I/O Device. Otherwise you'll have to wait as I/O Devices
are contacted one after the other, and incoming calls may be held up.
l If you have scheduled requests to I/O Devices and you also need to urgently return
calls from remote I/O Devices that dial in, you will need at least one modem for each

337
Chapter: 15 Communicating with I/O Devices

of these functions. For example, if you have a large number of remote I/O Devices
and you require fast responses by CitectSCADA, provide an additional modem at the
I/O Server. This would reduce the chances of it being engaged when an I/O Device
dials in (say, with an urgent alarm).
l In a big system with many remote I/O Devices or a system where calls from remote
I/O Devices can be time sensitive, it's a good idea to dedicate at least one modem to
Dial-Back. This will give you quick responses to Dial-In calls (from remote I/O
Devices). It also means your dial-out schedules won't be disrupted (if you use the
same modem for returning calls and scheduled calls, the scheduled calls are forced to
wait until the dial-back call is complete).
See Also
Modems at the I/O Device
Example configurations for modems at the I/O Server

Modems at the I/O Device

You can have multiple I/O Devices connected to a single modem if they have the same
communication requirements (phone number, baud rate, data bits, stop bits, and parity).
A separate port and modem needs to be used for each remote I/O Device with different
communication requirements.
When deciding how many modems to use, consider the following:
l Once an I/O Device has been contacted, the connection can be retained for other I/O
Devices in the group. If the I/O Server needs to request data from another I/O Device
with the same communication details, it will wait until the current request has been
completed, then it will use the same connection to make the second request.
l You can configure your modem to initiate telephone calls (call CitectSCADA), and/or
receive telephone calls. This is done independently of CitectSCADA.

Note: Wherever your modem is, you need to verify that its Data bits, Parity, Stop
bits, and Serial Port Speed settings are compatible with the remote I/O Device as
defined by the device's manufacturer or your communications link will not work.

Example configurations for modems at the I/O Server

The examples below demonstrate how to set up the modems at your I/O Server to accom-
modate different combinations of I/O Devices.
Example 1

338
Chapter: 15 Communicating with I/O Devices

All your remote I/O Devices have the same communication requirements (data bits, stop
bits, parity, and baud rate) - 19200 8 E 1.
You don't expect any important calls from your I/O Devices, or you only have a few
remote I/O Devices. This means you can use a single modem at the I/O Server end. This
modem would be set up to answer and return incoming calls and make scheduled and
other CitectSCADA initiated calls.
To configure your modem, define it in Windows. Assuming that the logical modem is
called 'Standard Modem', configure it as follows:

Port Modem Name Max. Speed Data Bits Par- Stop

ity Bits

Standard Modem 19200 8 E 1

COM1

You would then configure it in CitectSCADA as a dial-out modem and dial-in modem:

Modem Name Dial-out Dial-in Dial-back

Standard Modem TRUE TRUE FALSE

Example 2
In this example, your I/O Devices use a total of two different communication spec-
ifications - 9600 7 O 1 and 19200 8 E 1.
You don't expect important calls from I/O Devices or you have only a few I/O Devices.
This means you can get by with a single modem at the I/O Server end. This modem has
to receive and return calls from I/O Devices as well as initiate calls (dial out) to I/O
Devices.
To configure your modem, you need to first define it in Windows (through the Windows
Control Panel). Remember, you're not just defining the physical modem here. You have
to define a separate Windows (virtual) modem for each communication specification.
So far, this gives you two virtual modems - one for 9600 7 O 1 and one for 19200 8 E 1.
However, Windows won't let you define both of these modems as dial-in. It only lets you
define one dial-in modem per port. If you choose the first, it won't be able to receive calls
with the second, and vice versa.
This means you have to set up a separate virtual modem that can answer calls no
matter which communication specification is used. This modem would be set with a
generic communication specification of 9600 8 N 1.

339
Chapter: 15 Communicating with I/O Devices

So in Windows, you'll end up with three logical modems (two for Dial-Out and one for
Dial-In). Assuming that the logical modems are called 'Standard Modem' to 'Standard
Modem #3', you would configure them as follows:

Port Modem Name Max. Data Bits Par- Stop

Speed ity Bits

Standard Modem 9600 7 O 1

COM1

Standard Modem 19200 8 E 1

COM1 #2

Standard Modem 9600 8 N 1

COM1 #3

You would then configure the modems in CitectSCADA as follows.

Modem Name Dial-out Dial-in Dial-back

Standard Modem TRUE FALSE FALSE

Standard Modem #2 TRUE FALSE FALSE

Standard Modem #3 FALSE TRUE FALSE

Example 3
In this example, there are five different communications frameworks - 9600 7 O 1, 19200
8 E 1, 4800 8 N 1, 9600 8 N 1, and 19200 8 N 1.
If you expect important calls from I/O Devices or you have many I/O Devices, you
would set up three modems at the I/O Server end:
l One on COM3 dedicated to receiving calls from 9600 7 O 1 I/O Devices.
l One on COM2 for dialing out to 4800 8 N 1, 9600 8 N 1, and 19200 8 N 1 I/O
Devices.
l One on COM1 for dialing out to 9600 7 O 1 and 19200 8 E 1 I/O Devices.
The two dial-out modems would return calls as well as initiate calls in response to
scheduled requests, and so on.

340
Chapter: 15 Communicating with I/O Devices

To configure your modems, you need to first define them in Windows (through the Win-
dows Control Panel). Remember, you're not just defining the physical modem here. You
have to define a separate Windows (virtual) modem for each communication frame-
work.
Assuming that the logical modems are called 'Standard Modem' to 'Standard Modem
#6', you would configure them as follows:

Port Modem Name Max. Data Bits Par- Stop

Speed ity Bits

Standard Modem 9600 7 O 1

COM1

Standard Modem 19200 8 E 1

COM1 #2

Standard Modem 4800 8 N 1

COM2 #3

Standard Modem 9600 8 N 1

COM2 #4

Standard Modem 19200 8 N 1

COM2 #5

Standard Modem 9600 7 O 1

COM3 #6

You would then configure the modems in CitectSCADA as follows:

Modem Name Dial-out Dial-in Dial-back

Standard Modem TRUE FALSE FALSE

Standard Modem #2 TRUE FALSE FALSE

Standard Modem #3 TRUE FALSE FALSE

Standard Modem #4 TRUE FALSE FALSE

341
Chapter: 15 Communicating with I/O Devices

Standard Modem #5 TRUE FALSE FALSE

Standard Modem #6 FALSE TRUE FALSE

Example 4
In this example, your I/O Devices use three different communication frameworks: 9600 7
O 1, 19200 8 E 1, and 9600 8 N 1. However, in this example, you are expecting impor-
tant calls from I/O Devices, so you need a modem dedicated to returning calls.
Here you need to configure your modems like this:
l One modem on COM1 to dial remote I/O Devices (for scheduled calls, and so on).
l One modem on COM2 to receive calls from remote I/O Devices.
l One dedicated modem on COM3 to return these calls.
To configure your modems, first define them in Windows (through the Windows Control
Panel). Remember, you're not just defining the physical modem here: you need to define
a separate Windows (virtual) modem for each communication framework. This means
you have to configure:
l Three logical modems on the port to which the physical dial-out modem is attached.
l One logical modem on the port to which the physical dial-in modem is attached.
l Three logical modems on the port to which the physical dial-back modem is
attached.
Assuming that the necessary total of seven logical modems are called 'Standard Modem'
through to 'Standard Modem #7', configure these modems as follows:

Port Modem Name Max. Data Bits Par- Stop

Speed ity Bits

Standard Modem 9600 7 O 1

COM1

Standard Modem 19200 8 E 1

COM1 #2

Standard Modem 9600 8 N 1

COM1 #3

Standard Modem 9600 8 N 1

COM2 #4

342
Chapter: 15 Communicating with I/O Devices

Standard Modem 9600 7 O 1

COM3 #5

Standard Modem 19200 8 E 1

COM3 #6

Standard Modem 9600 8 N 1

COM3 #7

You would then configure the modems in CitectSCADA as follows:

Modem Name Dial-out Dial-in Dial-back

Standard Modem TRUE FALSE FALSE

Standard Modem #2 TRUE FALSE FALSE

Standard Modem #3 TRUE FALSE FALSE

Standard Modem #4 FALSE TRUE FALSE

Standard Modem #5 FALSE FALSE TRUE

Standard Modem #6 FALSE FALSE TRUE

Standard Modem #7 FALSE FALSE TRUE

I/O Device constraints for multi-dropping

If you are multi-dropping off a single modem, use your I/O Devices to issue the caller ID,
not the modem. This is because using the modem to issue the ID will send the same ID
no matter which I/O Device the call is relevant to. This makes it difficult to identify the
I/O Device that triggered the call.
By using the I/O Device to issue the ID, the I/O Server will receive a unique caller ID for
each I/O Device. However, not every I/O Device is capable of issuing caller IDs. If multi-
dropping, use I/O Devices that can issue caller IDs.
To configure dial-up remote I/O Devices for communication with CitectSCADA:

343
Chapter: 15 Communicating with I/O Devices

1. Run the Express Communications Wizard.

2. Complete the wizard, selecting the relevant I/O Server, then the I/O Device, creating
each new instance when necessary.
3. On the Scheduling page of the wizard, select the Connect I/O Device to PSTN check
box.
4. Select an appropriate schedule for CitectSCADA to communicate with the remote I/O
Device. (For a persistent connection - whenever CitectSCADA is running - select On
Startup.) For example (all based on a Synchronize at time of 10:00:00):
l If you enter 12:00:00 in the Repeat every field, and start your project at 9 a.m., the
I/O Server will communicate with the I/O Device at 10 a.m., then once every 12
hours after that; that is, 10 p.m., then again at 10 a.m. of the following day, and so
on.
l If you enter 12:00:00 and start your project at 4 p.m., the I/O Server will com-
municate with the I/O Server at 10 p.m., then again at 10 a.m., of the following
day, and so on. CitectSCADA will assume that communications were established
at 10.a.m., so will continue as if they had been, communicating once every 12
hours after 10 a.m.
l If you enter 3 days and start your project at 9 a.m. on a Wednesday, the I/O Server
will communicate with the I/O Device at 10 a.m., then once every 3 days after
that; that is, 10 a.m. on the following Saturday, then at 10 a.m. on the following
Tuesday, and so on.
l If you enter the 6th of December in the Repeat every field and start your project
during November, the I/O Server will communicate with the I/O Device at 10 a.m.
on December 6, then again on December 6 of the following year, and so on.
5. Select On Startup for a persistent connection. To disconnect a persistent connection,
call the IODeviceControl() function with type 8.
6. Type in the phone number necessary for CitectSCADA to dial the remote modem
attached to the remote I/O Device. Include any pre-dial numbers necessary to obtain a
connection to an outside PSTN line (dial tone) before dialing (for example, 0 (zero)) -
if appropriate.
7. On the next wizard page, if the device is configured to dial-in to CitectSCADA, create
a unique identifying caller name for the remote I/O Device so that it can be identified
by CitectSCADA.
8. Follow the instructions on the next page of the wizard and click Finish.
See Also
Configuring multidrop remote I/O Devices

344
Chapter: 15 Communicating with I/O Devices

Configuring multidrop remote I/O Devices

Multidropping remote I/O Devices from the same remote modem enables CitectSCADA
to communicate with each I/O Device one after the other, using the same phone con-
nection, rather than hanging up and re-dialing.
Although you can configure multidrop remote I/O Devices using the Express Com-
munications Wizard, we recommend that you do it manually. The wizard would create
a new port for each I/O Device. This would mean you couldn't have any more than 255
I/O Devices.
1. Run the Express Communications Wizard to configure the first device.
2. Configure every other I/O device manually.
3. Open the Citect Project Editor.
4. Select Communications | I/O Server and scroll to the I/O Server that will be com-
municating with the I/O Device.
5. Select Communications | I/O Devices.Complete the dialog box.
6. To increase the efficiency and capacity of your system you can allocate the same port
name to I/O Devices with the same communication settings.

Note: If you are multi-dropping and you want to be able to dial in to the I/O
Server, use your I/O Devices to issue the caller ID, not the modem. This is because
using the modem to issue the ID will send the same ID no matter which I/O
Device the call is relevant to. This makes it difficult to identify the I/O Device that
triggered the call.

By using the I/O Device to issue the ID, the I/O Server will receive a unique caller ID for
each I/O Device. However, not every I/O Device are capable of issuing caller IDs. If
multi-dropping, use I/O Devices that can issue caller IDs.
To set up a modem connected to your dial-up remote I/O Devices:
You can connect multiple I/O Devices to the same modem. This means CitectSCADA
can communicate with these I/O Devices one after the other using the same phone con-
nection, rather than hanging up and re-dialing. This will reduce the number of necessary
telephone calls and increase the speed and efficiency of communications.
1. Connect the modem to a PC with a telephony program installed (for example Hyper-
Terminal or PhoneDialer). This is where you will configure the modem to answer
calls from CitectSCADA and/or initiate calls.
2. If the modem is necessary to make calls to CitectSCADA, configure it to initiate the
phone call to a pre-determined CitectSCADA I/O Server Dial-In type modem (fol-
lowing manufacturer instructions).

345
Chapter: 15 Communicating with I/O Devices

3. Depending on your hardware either the modem or an intelligent PLC can be respon-
sible for initiating calls to CitectSCADA and identifying the caller. Whichever is
responsible needs to have a caller ID set. The caller ID can be any combination of
alpha-numeric characters and/or the character '_' (underscore).
Some modems have dip-switch settings, and some have initiation strings which can
include auto-dial-up numbers that are stored within the modem's non-volatile mem-
ory. Consult the manual provided with the modem for exact details.
You can use either the Express Communications Wizard or the I/O Devices form to
set the caller ID for an I/O Device.
If multi-dropping off a single modem, use your I/O Devices to issue the caller ID, not
the modem. This is because using the modem to issue the ID will send the same ID
no matter which I/O Device the call is relevant to, making it difficult to identify
which I/O Device triggered the call.
By using the I/O Device to issue the ID, the I/O Server will receive a unique caller ID
for each I/O Device. However, not every I/O Device is capable of issuing caller IDs. If
you are multi-dropping, use I/O Devices that can issue caller IDs.
4. Set the modem's Data bits, Parity, Stop bits, and Serial-Rate to match manufacturer
specifications for communication with the I/O Devices.
Some modems do not allow you to manipulate their communications settings via
methods such as extended AT commands or dip switches. If this is the case, the only
way of setting the necessary values is to communicate with the modem using the
values (for example, via HyperTerminal). Once this is done, the modem remembers
the last values used to communicate with its serial port.
5. Connect the modem to the I/O Devices.
To configure a modem at the I/O Server you need to set it up in Windows and then set it
up in CitectSCADA.
If every one of your I/O Devices are the same, you only have to do this once for each
modem. However, if your I/O Devices talk using different communication specifications
(data bits, parity, stop bits, and serial-rate), your modem has to be able to talk using each
of these details as well. To set this up, you have to create a modem in Windows and
CitectSCADA for each specification. (See Example configurations for modems at the I/O
Server)
To set up a modem in Windows

1. Each modem connected to a CitectSCADA I/O Server PC needs to FIRST be con-

figured within Windows using Start | Settings | Control Panel | Phone and Modem
Options.
2. Select the Modems tab, and click Add to launch the Install New Modem wizard.
3. Check the box labeled Don't detect my modem; I will select it from a list, then click
Next.

346
Chapter: 15 Communicating with I/O Devices

4. Select Standard Modem Types in the list of manufacturers.

Note: Do not select a brand name modem from the Manufacturers list, even if the
name of the modem you're installing is included in the list. Do not click Have
Disk.

5. Select the Standard xxxx bps modem rate from the list of models to exactly match
the bit per second rate of the I/O Device that is going to be communicating via this
modem. Check the device to determine the device communication rate. If you are still
unsure, select the 9600 bps model. This can be changed later if necessary.
6. Do not click Have Disk. Click Next.
7. Select the COMx Port that the modem is connected to. Click Next.
8. Click Finish. Windows displays the modem in the list of modems on the Modems
Properties form.
9. No option was given for the selection and setting of the Data bits, Parity, or Stop bits
information. The Modems wizard automatically defaults to 8-none-1 for Standard
Modem types. To change these settings to match the Data bits, Parity, Stop bits
requirements of the remote I/O Device, select a modem in the list, then click the Prop-
erties button.
10. Click the Advanced tab and click Change Default Preferences.
11. Click the Advanced tab at the next dialog to gain access to the Data bits, Parity, Stop
bits settings for the modem.
12. Change the Data bits, Parity, and Stop bits settings using the drop-down options, so
that they exactly match those being used by the remote I/O Device and its remote
modem. Don't change any advanced settings. (The default is Hardware flow control.)
13. Click OK. If a modem of the same rate is installed to the same port as an existing
modem, Windows asks for confirmation that you want to install the same thing more
than once. Click Yes to install a duplicate copy of the modem.
14. Preconfigure the modem(s) to be used at the remote dial-up I/O Device(s). These will
be used to test modem configuration settings in the next step.
15. With CitectSCADA not running, confirm that the local and remote modems will prop-
erly communicate with each other by using a terminal communications program
such HyperTerminal or PhoneDialer (both supplied with Windows).
Once the modem(s) are set up and tested with proven communications in Windows,
they can then be set up in CitectSCADA.
To set up a modem in CitectSCADA:
Before completing this procedure, verify that you have set up your modem in Windows
(as described above).

347
Chapter: 15 Communicating with I/O Devices

1. Open the Citect Project Editor.

2. Select Communications | I/O Server and scroll to the I/O Server the modem is
attached to.
3. Select Communications | Modems. The Modem Properties dialog will appear.

Option Description

Server Name (16 The name of the I/O Server to which the modem is attached.
Chars.)

Modem Name (64 The name of the modem you are configuring (as it appears in the
chars.) Windows Control Panel | Phone and Modem Options).

Comment (48 Any useful comment.

Chars.)

Use this modem to Determines whether this modem will be used to initiate calls from
make outgoing calls the I/O Server to a dial-up remote I/O Device. (Dial-Out)

This may include calls that are scheduled, event driven, or in

response to I/O Devices that dial in.

Use this modem to Determines whether this modem will be used to receive calls from
answer incoming a dial-up remote I/O Device. (Dial-In)
calls

The following fields are implemented with extended forms (press F2).

Use this Determines whether this modem will be used to initiate calls from the
modem to I/O Server to a dial-up remote I/O Device in response to a call received
call back I/O from the I/O Device. (Dial-Back)
Devices

4. Complete the dialog box.

Note: CitectSCADA allows you to set up a maximum of 256 modems on the I/O
Server for communication with remote dial-up I/O Devices. Before it can suc-
cessfully establish communication, any targeted remote I/O Devices need to also
be properly configured within CitectSCADA on the I/O Server.

348
Chapter: 15 Communicating with I/O Devices

I/O Server redundancy for dial-up remote I/O Devices

You can change the number of rings the I/O Server will wait before answering the call
(using the [Dial]RingCount parameter). If you are using redundant I/O Servers, the pri-
mary I/O Server will be called by default. However, by setting [Dial]RingCount to a dif-
ferent value on each of the I/O Servers, you can make the standby I/O Server answer the
call if the primary does not.
Consider the following setup:

If you set the ring count to 3 on IOServer1 and 4 on IOServer2, IODev_1 will attempt to
call IOServer1. If IOServer1 has not answered the call after 3 rings, IOServer2 will
answer it.
See Also
Troubleshooting dial-up remote I/O Device communications

Troubleshooting dial-up remote I/O Device communications

The challenges most often encountered when using a dial-up remote I/O Device involve
communications speed, parity, and control signals from the connected equipment. If
changing the speed and parity does not resolve a communications interruption, evaluate
the modem's answering codes and command echoing.

349
Chapter: 15 Communicating with I/O Devices

Following is a list of settings that might be helpful in resolving dial-up communications

interruptions. (Since not every modem supports the same in commands in the same
way, this is only a guide. Consult the modem manual for exact details.)
On the modem at the PC end

ATV1 //Enables long-form (verbose) result codes

ATQ0 //Result codes are sent on the RS-232 connection
ATE0 //Commands sent from the computer are not echoed back to the RS-232 connection
AT&C1 //DCD will follow carrier on the line
AT&K0 //Handshaking OFF
ATW0 //Upon connection, only DTE speed is reported
AT%C0 //Compression OFF
AT&D0 //DTR always on

If the modem at the PC end is configured so that calls are automatically answered even
when your CitectSCADA project is off, data being reported from the I/O devices may be
lost. Therefore, it is recommended that you turn off the PC modem's auto-answer feature
before taking your project offline. To do this, set the following parameter to zero:

ATS0 = 0 // Auto answer OFF

Be aware, however, this will also impact applications that might use the modem other
than CitectSCADA, as the modem cannot answer a call while CitectSCADA is not driv-
ing its functionality.
On the modem at the I/O Device end

ATV0 //Enables short-form result codes

ATQ1 //No result codes are sent on the RS-232 connection
ATE0 //Commands that are sent from the computer are not echoed
back to the RS-232 connection
AT&C1 //DCD will follow carrier on the line
AT&K0 //Handshaking OFF
ATW0 //Upon connection, only DTE speed is reported
AT%C0 //Compression OFF
AT&D0 //DTR always on
ATS0 //Set to greater than 0 (sets the number of rings necessary before the modem
answers
an incoming call).

Alternative (backward compatibility) method of persistent connection

If you are setting up your modem to dial a dial-up remote I/O Device, follow the pro-
cedures described in Communicating with Dial-up Remote I/O Devices. This method is
available for backward compatibility.

350
Chapter: 15 Communicating with I/O Devices

Scheduled Communications
CitectSCADA allows you to schedule communications with your I/O Devices (regardless
of the type of connection: modem, radio link, etc.). For example, if you have multiple I/O
Devices on a single network or line, you can schedule reads so that the important I/O
Devices are read more often than less important I/O Devices. Alternatively, a water sup-
plier with radio link connections to dam level monitors might schedule hourly level
reads from CitectSCADA in order to conserve band-width.
See Also
Specifying a schedule
Writing to the scheduled I/O Device
Reading from the scheduled I/O Device

Specifying a schedule
To configure scheduled communications with an I/O Device, you need to flag it as a
"Scheduled" device. This is done using the Express Communications Wizard. If your I/O
Device is not capable of scheduled communications, the scheduling options will not be
presented by the wizard.

Note: Scheduled communications will not work for drivers that are designed to han-
dle Report-By-Exception protocols. For communicating with your I/O Device outside
of schedule use the IODeviceControl function.

To schedule communications with an I/O Device:

1. Select the Project Editor (or press the Project Editor icon).
2. Choose Communication | Express Wizard or open Citect Explorer.
3. Double-click the Express I/O Device Setup icon in the Communications folder of the
current project.
4. Follow the instructions to work through the screens, selecting the relevant I/O Device,
and so on. When the scheduling screen displays, check the Connect I/O Device to
PSTN box, even if your I/O Device is not connected via a modem (but leave the
Phone number to dial and Caller ID fields blank).
5. Fill out the schedule fields to achieve the desired schedule. For example (all based on
a Synchronize at time of 10:00:00).
If you enter 12:00:00 in the Repeat every field, and start your project at 9 a.m., the I/O
Server will communicate with the I/O Device at 10 a.m., then once every 12 hours after
that, i.e. 10 p.m., then again at 10 a.m. of the following day, etc.

351
Chapter: 15 Communicating with I/O Devices

l If you enter 12:00:00, and start your project at 4 p.m., the I/O Server will com-
municate with the I/O Server at 10 p.m., then again at 10 a.m. of the following
day, etc. i.e. it will assume that communications were established at 10 a.m., so it
continues as if they had been, communicating once every 12 hours after 10 a.m.
l If you enter 3 days, and start your project at 9 a.m. on a Wednesday, the I/O
Server will communicate with the I/O Device at 10 a.m., then once every 3 days
after that, i.e. 10 a.m. on the following Saturday, then at 10 a.m. on the following
Tuesday, etc.
l If you enter the 6th of December in the Repeat every, and start your project during
November, the I/O Server will communicate with the I/O Device at 10 a.m. on
December 6, then again on December 6 of the following year, and so on.
6. Select On Startup for a persistent connection. To disconnect a persistent connection,
you need to call the IODeviceControl() function with type 8.
7. If your I/O Device is not connected via a modem, you need to go to the Ports form
(select Ports from the Communication menu) and change the Port number to the
actual number of the COM port.
See Also
Writing to the scheduled I/O Device

Writing to the scheduled I/O Device

Whenever an I/O Device is actively communicating (as per its schedule), you can write
to it directly. However, if you try to write to it when it is not communicating, your write
request will be queued until it is. For example, you might decide to schedule one write
per hour. If someone at a Control Client changes a tag's value during that hour, that
change will not be written to the I/O Device until the hour has expired.
As write requests are not written to the I/O Device until it is communicating, confirm
that pending writes have been completed in full before shutting down.

Note: Don't control hardware using a scheduled I/O Device, as the exact state of the
hardware may not be known. Although you can read the state from the cache, it may
have changed since the cache was created.

UNINTENDED EQUIPMENT OPERATION

Do not use a scheduled I/O device to control hardware in a system managed by CitectSCADA.

Failure to follow these instructions can result in death, serious injury, or equip-
ment damage.

352
Chapter: 15 Communicating with I/O Devices

See Also
Reading from the scheduled I/O Device

Reading from the scheduled I/O Device

When the I/O Server initiates communication with the I/O Device, it immediately writes
any queued write requests, then reads the I/O Device's tags. These values are then stored
in a cache so that you can still access them between communications.

Note: Because the I/O Server reads tags on initiation of communication, the license
point count is increased, even though some of the tags read may not actually be
used.

Keeping data up-to-date during prolonged connections

Normally, communication is terminated as soon as every read and write request is com-
plete. Sometimes, however, you may want to prolong the communication (for example
by calling the IODeviceControl() function with Type 7).
In this situation (if Read-Through Caching is disabled), when client computers request
device data from the I/O Server, it retrieves the data from its cache, not from the I/O
Device. This occurs even though the I/O Server maintains a connection to the device.
To retrieve fresh data from the I/O Device, you can force a periodic read using Cicode, or
change the cache timeout by setting the IODeviceControl() function to Type 11.
For example:

INT hTask;
// Initiate communications and read tags.
// Sleep time will depend on how fast your
// modems connect.
FUNCTION
DialDevice(STRING sDevice)
INT bConnected = 0;
INT nRetry = 5;
hTask = TaskHnd("");
IODeviceControl(sDevice, 7, 0);
Sleep(20);
WHILE bConnected <> 1 AND nRetry > 0 DO
bConnected = IODeviceInfo(sDevice, 18);
nRetry = nRetry - 1;
Sleep(10);
END
IF bConnected = 1 THEN
WHILE TRUE DO
Sleep(2);
IODeviceControl(sDevice, 16, 0);

353
Chapter: 15 Communicating with I/O Devices

END
END
END
// Kill the read task and terminate the connection.
FUNCTION
HangupDevice(STRING sDevice)
TaskKill(hTask);
IODeviceControl(sDevice, 8, 0);
END

You can also force the I/O Server to read data directly from an I/O Device by enabling
Read-Through Caching. With [Dial]ReadThroughCache set, while the I/O Server is con-
nected to a device it will supply data to requesting clients directly from the device. The
cache is not updated during this time, but is refreshed with the most recent device data
just before the server disconnects.

Note: If using modems, you might need to adjust or deactivate the inactivity timer in
your modems to stop them from disconnecting while no data is being read. The inac-
tivity timer is controlled by the S30 register. If your modem doesn't support this reg-
ister, please consult your modem's manual.

Avoiding unnecessary multiple reads of I/O Device data

To avoid unnecessary reads of an I/O Device, you can use data caching to temporarily
store data read from the device in the memory of the I/O Server. This means that if the
I/O Server receives more than one request for device data in a short time period, instead
of contacting the I/O Device a second time and reading identical data, it can retrieve the
data from the cache.

354
Chapter: 16 Tagging Process Variables
You need to assign a variable tag to each I/O Device variable that CitectSCADA uses in
your runtime system. To define your variable tags, you declare them in the variable tag
database. The variable tag becomes a label, used to reference the data value of the I/O
Device register at the specified address. Using labels has several benefits:
l You do not have to remember the address every time you want to use the variable.
You use the tag name, which has to be logical and descriptive, and therefore less con-
fusing.
l The address in the I/O Device is defined only once. If you change the address, you
only need to update the variable tag definition, not every instance in your con-
figuration.
l You can scale the raw data to an appropriate range in the same declaration.
l You can access extended data value, quality and timestamp information.
You need to define your variables as a specific data type. The most common variables
supported by I/O Devices are digital and integer. CitectSCADA also supports real, string,
byte, bcd, long, and longbcd data types.
After you have defined your variable tags, you can use them to:
l Display objects on a graphics page.
l Store data for trending and analysis. (See Trending Data.)
l Monitor Alarms. (See Configuring and Processing Alarms.)
l Control equipment and processes. (See Defining Commands and Controls.)
l Store data in memory (See Configuring Local Variables.)
The most common variables supported by I/O Devices are digital and integer variables,
although some I/O Devices support other numeric variables and strings.
See Also
Tag name syntax
Tag Extensions
Tag Data Types
Using structured tag names
Configuring Local Variables
Configuring Variable Tags
Formatting numeric variables
Using arrays

355
Chapter: 16 Tagging Process Variables

Tag Naming
CitectSCADA puts a couple of restrictions on the names of variable tags:
l Tags are restricted to using a specific syntax. See Tag name syntax.
l Do not give Tags the same name as Cicode functions within the project or within any
included projects. An error will result during compilation if a tag has the same name
as a Cicode function and is placed on a graphic page. See Defining Variable Tag
Names for a list of restrictions on naming.
In addition, using a tag naming convention will make your project easier and faster to
design, configure, commission, and maintain. See Using structured tag names for rec-
ommendations about naming conventions.

Tag name syntax

CitectSCADA tags (variable tags, alarm tags and trend tags) need to have the following
syntax:

[<alpha> | '_'] *[<alpha> | <digit> | '\' | '_']

That is, the tag name needs to begin with either an alpha character (A-Z or a-z) or the
underscore character (_). Any following characters needs to be either alpha characters
(A-Z or a-z), digit characters (0 - 9), backslash characters (\), or underscore characters (_).
The use of any other characters will result in a compiler error.
For example, '_MyTag123' and 'my\New\Tag' are both valid tag names, whereas '\Ne-
wTag\' is invalid.
Tag names that begin with a numeric character, such as '12TagName', are only valid if
the INI parameter [General]TagStartDigit is set to 1 (the default value is zero).

Note: The name of an Alarm Tag needs to follow this syntax but the Alarm Name
does not.

356
Chapter: 16 Tagging Process Variables

Using structured tag names

The following naming convention is recommended for a system, to obtain maximum
benefit when using features such as Genies and Super Genies. (If you are already using a
naming system that differs from the following convention, you can still use Genies and
Super Genies supplied with CitectSCADA by modifying the Genies that you want to
use.)
Each tag name can contain up to 79 characters. To establish a convention, you need to
divide the characters in the tag name into sections that describe characteristics of the tag,
for example, the area where the tag is located, the type of variable, and any specific attrib-
utes. Four basic sections are suggested for a CitectSCADA naming convention:

Area_Type_Occurrence_Attribute

Area
The Area section identifies a plant area, number, or name. If you use a prefix that iden-
tifies tags within a particular area, you can easily duplicate CitectSCADA functions
within the area. For example, if you have three boilers with the same controls on each
boiler, you can configure the tags for boiler number one, and copy the tags to boilers two
and three. You then only need to change the area section in the tag names to the area of
the second and third boiler. The remainder of the tags remain unchanged, for example:

Boiler 1 Boiler 2 Boiler 3

B1_TIC_101_PV B2_TIC_101_PV B3_TIC_101_PV

If you do not need this facility, you can omit the Area section of the Tag Name to reduce
the number of characters in the tag.

Type
The Type section identifies the Type of parameter, process equipment, or control hard-
ware. The ISA standard naming system is recommended.

Variable Tag Meaning

B1_TIC_101_PV Temperature indicating controller

B1_FIC_101_PV Flow Indicating controller

357
Chapter: 16 Tagging Process Variables

B1_PUMP_101_PV Pump

B1_VALVE_101_PV Valve

Occurrence
The Occurrence section identifies the loop number.

Variable Tag Meaning

B1_TIC_101_PV Temperature Indicating Controller 101

B1_TIC_102_PV Temperature Indicating Controller 102

B1_PUMP_101_PV Pump 101

B1_PUMP_102_PV Pump 102

Attribute
The Attribute section identifies the attribute or particular parameter that is associated
with the loop.

Variable Tag Meaning

B1_TIC_101_PV Process Variable

B1_TIC_101_SP Setpoint

B1_TIC_101_OP Output

B1_TIC_101_P Gain or proportional band

B1_TIC_101_I Integral

B1_PUMP_101_CMD Command signal to start pump

B1_PUMP_101_M Auto/Manual mode

B1_TIC_101_V Value (running/stopped)

358
Chapter: 16 Tagging Process Variables

Recommended Attributes
Genies and Super Genies supplied with CitectSCADA use the following attribute con-
vention. If you follow this convention, you can use the Genies without having to modify
them.

Mnemonic Discrete Control / Monitoring Data Range

Type

_CMD Command Signal to Start Device Digital 0 = Off, 1

= On

_M Control Mode Digital 0=Man,

1=Auto

_V Value Digital 0=Off,

1=On

_FAIL Device Failure Digital 1=OK,

0=Failed

FAULT Device Fault Digital 1=OK,

0=Fault

Mne- Process Alarms Data Range

monic Type

_ALM General Alarm Digital 0=Active, 1=InActive

_HHALM High High Alarm Digital 0=Active, 1=InActive

_HALM High Alarm Digital 0=Active, 1=InActive

_LALM Low Alarm Digital 0=Active, 1=InActive

_LLAM Low Low Alarm Digital 0=Active, 1=InActive

_DALM Deviation Alarm Digital 0=Active, 1=InActive

_DLALM Deviation Low Alarm Digital 0=Active, 1=InActive

_DHALM Deviation High Alarm Digital 0=Active, 1=InActive

_HHTRIP High High Alarm Trip Point Analog

359
Chapter: 16 Tagging Process Variables

_HTRIP High Alarm Trip Point Analog

_LTRIP Low Alarm Trip Point Analog

_LLTRIP Low Alarm Trip Point Analog

_DTRIP Deviation trip Point Analog

_LDTRIP Low Deviation Trip Point Analog

_HDTRIP High Deviation Trip Point Analog

_HHhyst High High Alarm Hysteresis Analog

_Hhyst High Alarm Hysteresis Analog

_Lhyst Low Alarm Hysteresis Analog

_LLhyst Low Low Alarm Hysteresis Analog

_LDhyst Low Deviation Alarm Hysteresis Analog

_HDhyst High Deviation Hysteresis Analog

Mnemonic Analog Control / Monitoring Data Range

Type

_PV Process Variable Analog

_SP Setpoint Analog

_RSP Remote Setpoint Analog

_OP Output Analog

_OPM Output Mode Digital 0=Manual,

1=Auto

_SPM Setpoint Mode Digital 0=Local,

1=Remote

_P Gain (Proportional Band) Analog

360
Chapter: 16 Tagging Process Variables

_I Integral (Reset) Analog

_D Derivative (Rate/Preact) Analog

_KP Gain Modifier Analog

_KI Integral Modifier Analog

_KD Derivative Modifier Analog

_SPTK Setpoint Track Mode Digital 0=OFF,

1=Track

_OPTK Output Track Mode Digital 0=OFF,

1=Track

_SPB Setpoint Bias Analog

_SPR Setpoint Ratio Analog

_DEV Deviation

_TOT Totalizer Value Analog

_COUNT Counter Value Analog

_CRESET Counter Reset Command Digital 0=Counting,

1=Reset

_CLIMIT Counter Preset Limit Analog

_TIME Timer Value Analog

_TRESET Timer Reset Command Digital 0=Timing,

1=Reset

_EXP Timer Expired Digital

_TLIMIT Timer Limit Analog

_CALC1 Calculation Result 1 Analog

_LINZ1 Linearized Signal 1 Analog

_Q Data Quality Flag Digital 1=OK, 0=BAD

361
Chapter: 16 Tagging Process Variables

Note: To keep the tag names shorter you can omit the underscore, but you would sac-
rifice readability; for example: B1TIC101PV instead of B1_TIC_101_PV.

Tag Extensions
A variable tag is a representation of data elements. Each element provides access to a
view of the data value for the tag.
Each variable tag can be used on its own or by referencing a particular element to access
the following information:

Element Description

.field The field element, which represents the latest field data received from the device
(see Reading Tag Values).

.valid The valid element, which represents the last field data which had ‘Good’ quality
(see Reading Tag Values).

.override The override element, which represents the overridden tag value (see Controlling
and Overriding Tag Values).

.overridemode The override mode, which is used to set the override behavior of the tag (see Over-
ride Mode).

.controlmode The control mode, which is used to set the control inhibit mode of the tag (see Con-
trol Inhibit Mode).

.status The tag status element, which is used to represent the current status of the tag
(see Tag Status).

The tag and each element have items that can be referenced to access the following infor-
mation:

Item Description

v The value, which will access the data value of the tag or element.

vt The value timestamp, which will access the timestamp of when the value last
changed.

q The quality, which will access the quality of the value , either GOOD, UNCERTAIN or
BAD. You can access further detail from the quality using the Cicode Quality func-
tions.

qt The quality timestamp, which will access the timestamp of when the quality last
changed.

The timestamp, which will access the timestamp of when the tag or element was
t
last updated.

The tag reference syntax is:

362
Chapter: 16 Tagging Process Variables

[Cluster.]Tag[.Element][.Item][ [n]], where

Cluster The optional cluster name.

Tag The tag name or SuperGenie association.

Element The optional element name. If the element name is not specified, the requested ele-
ment will be determined at runtime.

Item The optional item name. If the item name is not specified, the whole element is ref-
erenced.

n The optional array index if the tag is defined as an array.

The array index is at the end of the reference (MyArray.v[n], MyArray.Field[n], MyAr-
ray.Field.v[n]). There is only a single quality and timestamp for each array, each member
will return the same quality and timestamp.

Note: Consider the impact on network traffic when configuring tag extensions, as the
distribution of quality and value timestamps increases the amount of data being sent
between servers.

You can access Tag data in the following ways:

1. Reference the tag data by using only the tag name, for example ‘MyTag’ (unqualified
tag reference). This will provide default access to the Field element information, unless
the tag is in one of the override modes.
2. Reference the tag data by using the tag name and the item name, for example
‘MyTag.q (unqualified tag reference). This will provide access to the item information for
the tag, either default from Field or Override element.
3. Reference the tag data by using the tag name and the element name, for example
‘MyTag.Field’ (qualified tag reference). This reference will provide access to the specific
tag element information.
4. Reference the tag data by using the tag name, element name and the item name, for
example ‘MyTag.Field.vt’. This reference will provide access to the specific tag element
item (qualified tag reference).
You can also access alarm data similar to tag data. See Using Alarm Properties as Tags.
Controlling Tag Extension behavior

By default, the tag data referenced without an element will provide access to the data
value when the value is of quality is good and an error (#BAD, #COM, etc) when the
quality is bad. The configuration parameter PageIgnoreValueQuality can be used to
change this behavior, including automatically changing the background color of text and
number graphics objects on a page with changes in quality of the tag.

363
Chapter: 16 Tagging Process Variables

The Tag Extensions behavior is controlled by several citect.ini file settings which are
described in the .Parameter Help file. For each of these settings there is a corresponding
setting in the parameters database (param.dbf). A citect.ini file setting specifies behavior
for a particular machine and a parameter database setting is applied system-wide. The
citect.ini file setting can be entered using the Computer Setup Editor, the parameter data-
base settings are configured in the CitectSCADA Project Editor from the System, Param-
eter menu.

Note: By default, the TagSubscribe Cicode function is set to retrieve "lightweight" tag
values that exclude quality and value timestamps. If you need a subscription to
retrieve timestamp data, you need to set the "bLightweight" argument to 0 (false).

See Also
The Quality Tag Element
Reading and Writing Tags
Tag Data Types
Controlling and Overriding Tag Values

The Quality Tag Element

The majority of data which is contained within the variable tag is represented as an ele-
ment which includes the items "Value", “ValueTimestamp”, “Quality”, “Qual-
ityTimestamp” and "Timestamp". With the exception of "Quality" these items are
absolutes of a single value. However the 'Quality" item has several layers of information
within it. These layers of information are covered by the following categories:
The primary layer identifies the General Quality Values.

Cicode label
Value Description
name

QUAL_BAD 0x00 Value is not useful for reasons indicated by the Substatus Bit
Field.

QUAL_UNCR 0x01 The Quality of the value is uncertain for reasons indicated by the
Substatus Bit Field.

QUAL_GOOD 0x03 The Quality of the value is Good.

These can be accessed from a text object on a graphics page at runtime or with Cicode
using the QualityGetPart Cicode function and the necessary Part parameter.
Within each of these quality values is a second, substatus layer, and a third extended
substatus layer. These layers of information listed below can also be accessed using the
QualityGetPart Cicode function.

364
Chapter: 16 Tagging Process Variables

l QUAL_BAD Substatus Values

l QUAL_UNCR Substatus Values
l QUAL_GOOD Substatus values
There is also the additional informational value of "Quality Limit" and "Tag Status"
accessed using the QualityGetPart Cicode function or the appropriate function shown
below.
Quality Limit

Cicode label
Value Description
name

QUAL_LIMITED_ 0x0 The value is free to move up and down.

NOT_LIMITED

QUAL_LIMITED_ 0x1 The value has ‘pegged’ at some lower limit.

LOW

QUAL_LIMITED_ 0x2 The value has ‘pegged’ at some high limit.

HIGH

QUAL_LIMITED_ 0x3 The value is a constant and cannot move.

CONSTANT

Quality Tag Status

Cicode label
Value Description
name

QTS_OVERRIDE 0x01 The tag is in Override mode.

QTS_CONTROL_ 0x02 The tag is in Control Inhibit Mode.

INHIBIT

QUAL_BAD Substatus Values

Use the the QualityGetPart Cicode function and the necessary Part parameter to return
the details of a QUAL_ BAD tag. The following table identifies the possible information
that will be returned.

Cicode label
Value Description
name

QUAL_BAD_NON_ 0x00 The value is bad but no specific reason is known.

SPECIFIC

QUAL_BAD_CON- 0x01 There is some server-specific problem with the configuration.

FIGURATION_ For example, the item in question has been deleted from the
ERROR configuration.

QUAL_BAD_NOT_ 0x02 The input is necessary to be logically connected to something

CONNECTED but is not. This quality may reflect the fact that no value is avail-
able at this time, for reasons like the value may not have been
provided by the datasource.

365
Chapter: 16 Tagging Process Variables

Cicode label
Value Description
name

QUAL_BAD_ 0x03 An inoperative device has been detected.

DEVICE_FAILURE

QUAL_BAD_SEN- 0x04 An inoperative sensor has been detected (the ‘Limits’ field can
SOR_FAILURE provide additional diagnostic information in some situations).

QUAL_BAD_ 0x05 Communication has been lost, however, the last known value is
LAST_KNOWN_ available. The age of the value may be determined from the
VALUE TIMESTAMP in the OPCITEMSTATE.

QUAL_BAD_ 0x06 Communication has been lost. There is no last known value
COMM_FAILURE available.

QUAL_BAD_OUT_ 0x07 The block is off scan or otherwise locked. This quality is also
OF_SERVICE used when the active state of the item or the group containing
the item is InActive.

QUAL_BAD_WAIT- 0x08 After items are added to a group, it may take some time for the
ING_FOR_INI- server to actually obtain values for these items. In such cases,
TIAL_DATA the client might perform a read (from cache), or establish a
ConnectionPoint based subscription and/or execute a refresh
on such a subscription before the values are available. This sub-
status is only available from OPC DA 3.0 or newer servers.

See Also
QUAL_EXT Substatus Values
QUAL_GOOD Substatus Values
QUAL_UNCR Substatus Values
The Quality Tag Element

QUAL_UNCR Substatus Values

Use the the QualityGetPart Cicode function and the necessary Part parameter to return
the details of an UNCERTAIN quality tag. The following table identifies the possible
information that will be returned.

Cicode label
Value Description
name

QUAL_UNCR_ 0x00 The value is uncertain but no specific reason is known.

NON_SPECIFIC

QUAL_UNCR_ 0x01 Whatever was writing this value has stopped doing so. Regard
LAST_USABLE_ the returned value as ‘stale’. This differs from a BAD value with
VALUE Substatus 5 (0x14) (Last Known Value). This status is asso-
ciated specifically with a detectable communication error on a
‘fetched’ value and indicates the failure of some external source
to ‘put’ something into the value within an acceptable period of
time. The age of the value can be determined from the TIMES-

366
Chapter: 16 Tagging Process Variables

Cicode label
Value Description
name

TAMP in OPCITEMSTATE.

QUAL_UNCR_ 0x04 Either the value has ‘pegged’ at one of the sensor limits (in
SENSOR_NOT_ which case, set the limit field to 1 or 2) or the sensor is other-
ACCURATE wise known to be out of calibration via some form of internal diag-
nostics (in which case,set the limit field to 0).

QUAL_UNCR_ 0x05 The returned value is outside the limits defined for this param-
ENG_UNIT_ eter. In this case the Limits field indicates which limit has been
EXCEEDED exceeded but does NOT necessarily imply that the value cannot
move farther out of range.

QUAL_UNCR_ 0x06 The value is derived from multiple sources and has less than the
SUBNORMAL necessary number of Good sources.

See Also
QUAL_EXT Substatus Values
QUAL_GOOD Substatus Values
QUAL_BAD Substatus Values
The Quality Tag Element

QUAL_GOOD Substatus Values

Use the the QualityGetPart Cicode function and the necessary Part parameter to return
the details of a GOOD quality tag. The following table identifies the possible information
that will be returned.

Cicode label
Value Description
name

QUAL_GOOD_ 0x00 The value is good. There are no special conditions.

NON_SPECIFIC

QUAL_GOOD_ 0x06 The value has been Overridden. Typically this is means the input
LOCAL_OVER- has been disconnected and a manually entered value has been
RIDE "forced".

See Also
QUAL_EXT Substatus Values
QUAL_BAD Substatus Values
QUAL_UNCR Substatus Values
The Quality Tag Element

367
Chapter: 16 Tagging Process Variables

QUAL_EXT Substatus Values

Use the the QualityGetPart Cicode function and the necessary Part parameter to return
the details of a BAD or UNCERTAIN quality tag. The following table identifies the pos-
sible information that will be returned.

Cicode label
Value Description
name

QUAL_EXT_ 0x00 There is no specific extended substatus value.

NON_SPECIFIC

QUAL_EXT_ 0x01 The device is a scheduled device that is offline and no cache
SCHEDULED_ value is available.
OFFLINE

QUAL_EXT_ 0x02 The tag configuration is invalid.

INVALID_TAG

QUAL_EXT_ 0x03 The value of the tag is invalid.

INVALID_DATA

QUAL_EXT_ 0x04 An internal software error occurred in the device driver.

SOFTWARE_
ERROR

QUAL_EXT_ 0x05 Too many devices are attached.

TOO_MANY_
DEVICES

QUAL_EXT_ 0x06 Communication is not initialised.

COMM_NO_INIT

QUAL_EXT_ 0x07 Bad communication.

COMM_BAD

QUAL_EXT_ 0x08 Tag address is out of range.

TAG_OUT_OF_
RANGE

QUAL_EXT_ 0x09 Tag is not readable.

WRITE_ONLY

QUAL_EXT_ 0x0A Write operation is not authorised.

WRITE_PRO-
TECTED

QUAL_EXT_NO_ 0x0B No cluster is specified within a system or for a given tag.

CLUSTER_SPEC-
IFIED

QUAL_EXT_ 0x0C The requested cluster is not known or no clusters are available.
CLUSTER_NOT_
FOUND

368
Chapter: 16 Tagging Process Variables

Cicode label
Value Description
name

QUAL_EXT_ 0x0D The requested cluster is disabled.

CLUSTER_DIS-
ABLED

QUAL_EXT_SES- 0x0E Cannot connect to the requested session.

SION_NOT_CON-
NECTED

QUAL_EXT_ 0x0F Tag could not be resolved.

TAG_RESOLVE_
TIMEOUT

QUAL_EXT_ 0x10 Tag element value not replicated to every redundant DataSource.
VALUE_NOT_
REPLICATED

QUAL_EXT_ 0x11 Tag element value is “stale.

STALE

QUAL_EXT_ 0x12 Unsuccessful communication between DataSource and PLC.

COMM_DEV_
BAD

QUAL_EXT_ 0x13 Invalid element used for referencing to a tag.

INVALID_ARGU-
MENT

QUAL_EXT_ 0x14 Tag element value is out of range.

VALUE_OUT_
OF_RANGE

See Also
QUAL_BAD Substatus Values
QUAL_GOOD Substatus Values
QUAL_UNCR Substatus Values
The Quality Tag Element

Reading and Writing Tags

CitectSCADA represents an I/O Device variable monitored or controlled by the system
as a tag variable. You create a tag variable in the Project Editor specifying the tag var-
iable name, data type, address, deadband and other attributes. After the tag variable has
been created, you can reference it using the tag name. The tag name reference provides
access to the value of the tag variable.
This functionality is available to be read from a tag with a text object on a graphics page
and can be read, and in some cases written to, using Cicode functions or CtAPI func-
tions.

369
Chapter: 16 Tagging Process Variables

Tag Extensions provide the following additional functionality:

l Access to the tag value quality and timestamp.
l Extended data associated with a variable tag.
l Make this data available to CitectSCADA client components: Control Client, Trend
Server, Alarm Server, Report Server, Cicode and CtAPI.
l Be able to override and prohibit writing to the tag variable value.
l Be able to display and trend the tag values even if their quality is not “Good”.
l Be able to have the real PLC quality and timestamp in CitectSCADA and to make it
available.
l Have Persistence and Replication of the tag data.
Each DataSource owns a local tag data cache. This cache is periodically saved to disk,
thus, maintaining last known value (LKV) for each tag. When a DataSource is restarted
its local tags are initialised to their corresponding LKVs, unless the tags have never been
cached before – in which case they are initialised to the default values.
Tag data from the DataSource cache is periodically saved to disk. When the time comes
to save the file, a temporary file is used, which after it is written simply gets renamed to
the original file name. This is done to avoid partial master file updates or corruption. If
the DataSource is shutdown abruptly, some tag value changes that are waiting to be per-
sisted to disk may get lost. The Field data are currently saved to disk.
The Tag cache file is saved in an XML format, as shown here, preserving the necessary
information about each tag’s value, quality, and timestamp. On load the original per-
sisted quality is substituted by BadLastKnown quality value. The file is saved in the
CitectSCADA Data directory using the name format of:
<ClusterName>.<IOServerName>.<IODeviceName>.cache
If during the file load the schema validation is unsuccessful, the entire file is considered
invalid and the tags LKVs are lost. If during the file load a particular tag’s value, qual-
ity, or timestamp is invalid, the corresponding invalid entry is simply ignored (and
logged as such). Persistence is configurable within the extended section of the Citect-
SCADA I/O Devices properties dialog.

Minimum Update Rate

The DataSource will send tag update value notifications to subscription clients after a
pre-defined period of time expires. The configuration of the minimum update rate period
is performed via the IODevice configuration dialog. Devices that are configured for
redundant operation needs to have minimum update rate set according to the rules spec-
ified in the table below.

370
Chapter: 16 Tagging Process Variables

Primary Device Standby Device

Compilation
Minimum Update Rate Minimum Update Rate
Result
Value/Staleness Period Value Value/Staleness Period Value

Blank (Default) Blank (Default) OK

Blank (Default) Value Defined Error

Value Defined Blank (Default) OK

Value Defined Same value as primary OK

Value Defined Value is different than on primary Error

Stale Tag Values

When an I/O Data Consumer does not get a tag element value update from the Data-
Source for a specific period of time, as specified by the Staleness period, the tag element
value is considered to be “stale”. The Extended Quality Substatus QUAL_EXT_STALE
will indicate this condition. Processing of staleness period for tags is performed on the
client side of the connection.
Configuration can be performed on the server using the IODevice properties dialog, or
on the client using Citect.ini parameters.
Staleness Period

The Staleness Period represents the total number of seconds that will elapse after the last
update before extended quality of the tag element is set to “Stale”. It can be configured
on both the server and client. The server configuration is specified in the table above. For
client configuration details refer to the ClientStalenessPeriod parameter.
Staleness Period Tolerance

Staleness Period Tolerance represents the percentage of the staleness period within a
total of which time a check or stale client tag elements will be performed. The default
value is 10%, which caters for a large number of configuration scenarios. You can reduce
or increase the tolerance as necessary by your particular scenario by configuring this
value in the client machine’s using the ClientStalenessPeriodTolerance parameter. This
parameter is not available for server configuration.
Example:
In order to reduce CPU load on the client machine,the default Staleness Period Tolerance
is 10%. This means that if staleness period is set to 600 seconds, a check for stale client
tag elements will be performed every 60 seconds.

XML DataSource Schema

371
Chapter: 16 Tagging Process Variables

<?xml version="1.0" encoding="utf-8"?>

<xs:schema
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="http://www.schneider-ele-
tric.com/Platform/PSI/DataSource/PersistenceCache/V1/"
xmlns:dsps="http://www.schneider-
electric/Platform/PSI/DataSource/PersistenceCache/V1/"
elementFormDefault="qualified"
targetNamespace="http://www.schneider-elec-
tric.com/Platform/PSI/DataSource/PersistenceCache/V1/">

<xs:simpleType name="DataType">
<xs:restriction base="xs:string">
<xs:enumeration value="Boolean" />
<xs:enumeration value="SByte" />
<xs:enumeration value="Byte" />
<xs:enumeration value="Char" />
<xs:enumeration value="Double" />
<xs:enumeration value="Int16" />
<xs:enumeration value="Int32" />
<xs:enumeration value="Int64" />
<xs:enumeration value="Single" />
<xs:enumeration value="String" />
<xs:enumeration value="UInt16" />
<xs:enumeration value="UInt32" />
<xs:enumeration value="UInt64" />
<xs:enumeration value="Decimal" />
<xs:enumeration value="DateTime" />
</xs:restriction>
</xs:simpleType>

<xs:simpleType name="ElementName"
<xs:restriction base="xs:string">
<xs:enumeration value="" />
<xs:enumeration value="Field" />
<xs:enumeration value="Valid" />
<xs:enumeration value="Override" />
<xs:enumeration value="OverrideMode" />
<xs:enumeration value="ControlMode" />
<xs:enumeration value="Status" />
</xs:restriction>
</xs:simpleType>

<xs:complexType name="DataSource">
<xs:sequence minOccurs="1" maxOccurs="1">
<xs:element name="properties" type="PropertyCollection">
<xs:unique name="UniquePropertyName">
<xs:selector xpath="dsps:property" />
<xs:field xpath="@name" />
</xs:unique>
</xs:element>
<xs:element name="tags" type="TagCollection">
<xs:unique name="UniqueTagName">

372
Chapter: 16 Tagging Process Variables

<xs:selector xpath="dsps:tag" />

<xs:field xpath="@name" />
</xs:unique>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="PropertyCollection">
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element name="property" type="Property" />
</xs:sequence>
</xs:complexType>

<xs:complexType name="TagCollection">
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element name="tag" type="Tag" />
</xs:sequence>
</xs:complexType>

<xs:complexType name="Property">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="name" type="xs:string" use="necessary" />
<xs:attribute name="type" type="DataType" use="necessary" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>

<xs:complexType name="TagElement">
<xs:sequence minOccurs="1" maxOccurs="1">
<xs:element name="v" type="Value" />
<xs:element name="q" type="Quality" />
<xs:element name="t" type="xs:dateTime" />
<xs:element name="qt" type="xs:dateTime" />
<xs:element name="vt" type="xs:dateTime" />
</xs:sequence>
<xs:attribute name="name" type="ElementName" use="necessary" />
</xs:complexType>

<xs:complexType name="Value">
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="item" type="xs:string" />
</xs:sequence>
<xs:attribute name="type" type="DataType" use="necessary" />
<xs:attribute name="size" type="xs:positiveInteger" use="necessary" />
</xs:complexType>

<xs:complexType name="Quality">
<xs:sequence minOccurs="1" maxOccurs="1">
<xs:element name="generic" type="xs:integer" />
<xs:element name="specific" type="xs:integer" />
</xs:sequence>
</xs:complexType>

373
Chapter: 16 Tagging Process Variables

<xs:element name="datasource" type="DataSource" />

</xs:schema>

Reading Tag Values

The data received from the field is represented by the Field and Valid tag elements.
l The Field element represents the latest tag field data received from the device.
l The Valid element represents the last field data which had “Good” quality.

Note:The Valid tag element initially has bad quality. The quality will only become
good when the first read request is successfully finished for the tag, which will only
occur when the IO device is online and either background polling is enabled, the tag
has been subscribed to, or a TagRead has beeninitiated.

You can access these elements by using a qualified tag reference (a tag referenced by the
tag name and the element name, for example ‘MyTag.Field’).. The following tables
describe each of these elements.
Field tag element

CitectSCADA
Reference Syntax Description
Data type

TagName.Field INT Implied value of Field element

REAL
STRING

TagName.Field.V INT Value

REAL
STRING

TagName.Field.VT TIMESTAMP Timestamp of when the value

last changed

TagName.Field.Q QUALITY Quality

TagName.Field.QT TIMESTAMP Timestamp of when the quality

last changed

TagName.Field.T TIMESTAMP Timestamp of when the element

was last updated

374
Chapter: 16 Tagging Process Variables

Valid tag element

CitectSCADA
Reference Syntax Description
Data type

TagName.Valid INT Implied value of Valid element

REAL
STRING

TagName.Valid.V INT Value

REAL
STRING

TagName.Valid.VT TIMESTAMP Timestamp of when the value

last changed

TagName.Valid.Q QUALITY Quality

TagName.Valid.QT TIMESTAMP Timestamp of when the quality

last changed

TagName.Valid.T TIMESTAMP Timestamp of when the element

was last updated

If you determine that the tag value is incorrect because of a sensor or communication
becoming inoperative, the tag value may need to be overridden. The Override tag ele-
ment is used to store the overridden tag value. For further information refer to Con-
trolling and Overriding Tag Values.

Writing Tag Values

The tag elements which have read/write access can be modified. However, these ele-
ments can only be updated as a whole; writes to an individual element item is not
allowed.
The following table shows the result of writing to each of the tag elements:

Element Name Write allowed Write Result

Not specified (unqualified Yes Write to the Field element and propagate
tag reference) the value to the I/O Device.

Field Yes Write to the Field element and propagate

the value to the I/O Device.

Valid No Will not succeed

Override Yes Write to the Override element

Override Mode Yes Write to the Override Mode element.

375
Chapter: 16 Tagging Process Variables

Element Name Write allowed Write Result

See the appropriate function references

for the available override mode values.
Note: When the tag is in Override mode,
an unqualified tag reference will refer to
the Override element

Control Mode Yes Write to the Control Mode element

The Value item can be one of the fol-
lowing:
0 – Control inhibit mode is Off.
1 – Control inhibit mode is On.
Note: When Control inhibit mode is On,
writing to the Field element is prohibited.

Tag Status No Will not succeed

If you determine that the tag value is incorrect because of a sensor or communication
interuption, the tag value may need to be overridden. The Override element tag element
is used to store the overridden tag value. For further information refer to Controlling and
Overriding Tag Values.

Controlling and Overriding Tag Values

Tag extensions in CitectSCADA allow you to control the ability of a tag to be written to,
or to override a value read from a tag if it is considered to be incorrect due to some loss
of communication with the PLC.
These functions are managed by setting the tag into Control Inhibit Mode or Override
Mode.

Control Inhibit Mode

PERFORMING A CONTROL OPERATION WHICH DOES NOT IN FACT OCCUR.

When the tag is put into the control inhibit mode, writing to the Field element value is pro-
hibited. If the system is configured in such a way that it does not give the operator any indi-
cation that the tag is in the control inhibit mode, the operator may assume that he is
performing a control operation which does not, in fact, occur.

Configure the system in such a way that it provides a visual indication to the operator that a
tag is in the control inhibit mode.

Failure to follow these instructions can result in death, serious injury, or equip-
ment damage.

376
Chapter: 16 Tagging Process Variables

To provide a visual indication to the operator that a tag is in the control inhibit mode
the following can be done:
Set any of the following Citect.ini parameters in such a way that control inhibit mode
will be indicated by changing the background color or overlaying the numeric or text
graphics objects and symbol set objects with a dithered pattern:
[Page]ControlInhibitDitheringColor
[Page]ControlInhibitDitheringDensity
[Page]ControlInhibitTextBackgroundColor
and set [Page]IgnoreValueQuality parameter to a value of 0 or 2.
or
Use the Control Mode element value (0 if the tag is not in the control inhibit mode or 1
otherwise)
or
Use the Field element quality Tag Status ControlInhibit bit (1 if the tag is in the control
inhibit mode or 0 otherwise)
Control Mode

Control inhibit mode allows you to prohibit writing to the Field tag element. Setting a tag
in Control inhibit mode is applied system wide. Writing to the Field element will be pro-
hibited for each of the I/O Data Consumers.
Control inhibit mode is controlled by the “Control Mode” element which is described in
the following table.

CitectSCADAData
Reference Syntax Description
type

TagName.ControlMode INT Value of Control Mode element

TagName.ControlMode.V INT Value

Allowed values are:
0 – Control inhibit mode is Off.
1 – Control inhibit mode is On.
Default value: 0.

TagName.ControlMode.VT TIMESTAMP Timestamp of when the value last changed

TagName.ControlMode.Q QUALITY Quality. The Control Mode quality is QUAL_

GOOD if the tag was put into the Control
inhibit mode on the primary server and it
was propagated to redundant servers.
Otherwise the general quality status will be
QUAL_UNCR and the extended susbstatus
will be QE_NOT_REPLICATED to indicate

377
Chapter: 16 Tagging Process Variables

CitectSCADAData
Reference Syntax Description
type

that not every redundant server is aware of

the fact that the tag is in Control inhibit
mode.

TagName.ControlMode.QT TIMESTAMP Timestamp of when the quality last

changed

TagName.ControlMode.T TIMESTAMP Time of when the tag was put in or out of

the Control inhibit mode. (equal to 0 at
start up)

Note: The quality of tags referenced by items, ex. Tag1.v or Tag1.Field.t, is GOOD
and its timestamps are 0 (INVALID TIMESTAMP). Therefore they give no visual
indication of any not good quality, error or change in handling state such as control
inhibit or override mode regardless of the setting used for the [Page] Ignore-
ValueQuality parameter.

Override Mode

PERFORMING A CONTROL OPERATION BASED ON INACCURATE DATA.

When the tag is put into the override mode, the default tag element value will be equal to the
Override element value instead of the Field element value. If the system is configured in such
a way that it does not give the operator any indication that the tag is in override mode, the
operator may assume that he is seeing the Field element value (live data) and consequently
may operate the plant inappropriately.

Configure the system in such a way that it provides a visual indication to the operator that a
tag is in override mode.

Failure to follow these instructions can result in death, serious injury, or equip-
ment damage.

To provide a visual indication to the operator that a tag is in the override mode the fol-
lowing can be done:
Set any of the following citect.ini parameters in such a way that override mode will be
indicated by changing the background color or overlaying the numeric or text graphics
objects and symbol set objects with a dithered pattern:
[Page]OverrideDitheringColor
[Page]OverrideDitheringDensity

378
Chapter: 16 Tagging Process Variables

[Page]OverrideTextBackgroundColor`
and set [Page]IgnoreValueQuality parameter to a value of 0 or 2.
or
Use the Override Mode element value (0 if the tag is not in the Override Mode or 1,2,3,4
otherwise)
or
Use the default or override element quality Tag Status Override bit (1 if the tag is in the
override mode or 0 otherwise)
Using Override Mode

If you determine that the tag value is incorrect because of a sensor or communication
interuption, the tag value may need to be overridden. The Override tag element is used
to store the overridden tag value.
You can put the tag into the Override Mode which will cause each unqualified tag ref-
erence (a tag referenced only by the tag name, for example ‘MyTag’).in every I/O Data
Consumer (Control Client, Trend Server, Alarm server, etc) to return the Override ele-
ment.The quality of the tag will indicate that the tag is in override mode.
Tag override is controlled by the Override and Override Mode tag elements. The Over-
ride element contains the override value and the Override Mode tag element is used to
set the specific override mode.
The following tables describe each of these elements:
Override tag element

CitectSCADA
Reference Syntax Description
Data type

TagName.Override INT Implied value of Override element

REAL
STRING

TagName.Override.V INT Value

REAL
STRING

TagName.Override.VT TIMESTAMP Timestamp of when the value last

changed

TagName.Override.Q QUALITY Quality. The Override value has “Good”

quality except when it is out of range

TagName.Override.QT TIMESTAMP Timestamp of when the quality last

changed

TagName.Override.T TIMESTAMP Timestamp of when the element was

last updated

379
Chapter: 16 Tagging Process Variables

Note: The quality of tags referenced by items, ex. Tag1.v or Tag1.Field.t, is constantly
GOOD and its timestamps are constantly 0 (INVALID TIMESTAMP). Therefore they
give no visual indication of any not good quality, error or change in handling state
such as control inhibit or override mode regardless of the setting used for the [Page]
IgnoreValueQuality parameter.

Override Mode tag element

CitectSCADA
Reference Syntax Description
Data type

TagName.OverrideMode INT Value of Override Mode element

TagName.OverrideMode.V INT Override Mode Value. See the appropriate

function references for the available over-
ride mode values.

TagName.OverrideMode.VT TIMESTAMP Timestamp of when the value last changed

TagName.OverrideMode.Q QUALITY The Override Mode quality is QUAL_GOOD if

the tag was put into the Override mode on
the primary server and it was propagated
to any redundant servers. Otherwise the
general quality status will be QUAL_UNCR
and the extended substatus will be QE_
NOT_REPLICATED to indicate that some
redundant servers are unaware of the fact
that the tag has been overridden.

TagName.OverrideMode.QT TIMESTAMP Timestamp of when the quality last

changed

TagName.OverrideMode.T TIMESTAMP Time when the tag was put in or out of Over-
ride mode. (equal to 0 at start up)

Override Modes

Override
Mode Description
Value

0 The Override Mode is Off.

1 The tag is in Static Override Mode and the Override value is initially set to the
value of the tag’s Field element.

2 The tag is in Static Override Mode and the Override value is initially set to the
value of the tag’s Valid element.

3 The tag is in Static Override Mode and the Override will remain at the previously
set value of the tag's Override element.

4 The tag is in the Dynamic Override Mode and the Override value will continually
track the value of the tag's Valid element. The ability to write to the value of the
tag’s Override element is disabled in this mode.

380
Chapter: 16 Tagging Process Variables

Tag Status
The Tag Status element is used to represent the current status of the tag. The value of
this element is affected only for those tag operations that involve a physical device (for
example, writing to the Field element will affect the status element, but writing to the
Control Mode will not). Tag Status element is reset after I/O Server restart. The element
value contains a set of bit flags.
The following table describes the Tag Status element:

CitectSCADA
Reference Syntax Description
Data type

TagName.Status INT Value of Tag Status element

TagName.Status.V INT Value

A set of bit flags representing
the following data:
- 0x1: Read Pending.
- 0x2: Write Pending.
- 0x4: Write Successful.
- 0x8: Write Unsuccessful.
Default value: 0.

TagName. Status.VT TIMESTAMP Timestamp of when the value

last changed

TagName.Status.Q QUALITY Quality

TagName.Status.QT TIMESTAMP Timestamp of when the quality

last changed

TagName.Status.T TIMESTAMP Timestamp of when the element

was last updated

Tag Data Types

Tags in CitectSCADA hold data values that can be defined as one of the following data
types.

Data Type Variable Size Allowed Values

BCD Binary- Coded Decimal 2 bytes 0 to 9,999

BYTE Byte 1 byte 0 to 255

381
Chapter: 16 Tagging Process Variables

Data Type Variable Size Allowed Values

DIGITAL Digital 1 bit or 1 0 or 1

byte

INT Integer 2 bytes -32,768 to

32,767

UINT Unsigned Integer 2 bytes 0 to 65,535

LONG Long Integer 4 bytes -

2,147,483,648
to
2,147,483,647

ULONG Unsigned Long Integer 4 bytes 0 to

(Only for display on a screen.Arit- 4,294,967,295
hmetic operations are not sup-
ported. )

LONGBCD Long Binary- Coded Decimal 4 bytes 0 to

99,999,999

REAL Floating Point 4 bytes -3.4E38 to

3.4E38

STRING String 256 bytes ASCII (null ter-

(maximum) minated)

Tag values can be used with the Cicode Variable data types.
A Cicode variable of INT data type can be used to store Tag data types: BCD, BYTE, DIG-
ITAL, INT, UINT, LONG, ULONG and LONGBCD.
A Cicode variable of the QUALITY or TIMESTAMP data type can be used to store the
Tag quality and timestamp items.
See Also
Cicode Variable Data Types

Configuring Variable Tags

To configure a variable tag:

1. Start Citect Explorer.

2. Click Variable Tags, or choose Tags | Variable Tags. The Variable Tags form dis-
plays.

382
Chapter: 16 Tagging Process Variables

3. Enter the properties of the variable tag.

4. Click Add to append a new record, or Replace to modify a record.
At a minimum you need to enter the Variable Tag Name, I/O Device Name, Data
Type, and Address fields.
You can paste any existing variable tag into forms in your project.
To select an existing variable tag:

1. Open the Project Editor.

2. Choose Edit | Paste Tag.
To configure a digital tag:

1. Open the Project Editor.

2. Click Variable Tags, or choose Tags | Variable Tags.
3. Complete the properties in the Variable Tags dialog box that appears, using DIG-
ITAL as the Data Type.
4. Click Add to append a new record, or Replace if you have modified a record.
You need to at least enter the Variable Tag Name, I/O Device Name, Data Type, and
Address fields. Leave the following properties blank:
l Raw Zero Scale, Raw Full Scale
l Eng Zero Scale, Eng Full Scale
l Eng Units, Format
To configure an analog tag:

1. Start the Project Editor.

2. Click Variable Tags or choose Tags | Variable Tags. The Variable Tags form
appears.
3. Enter the properties, using INT (or Real, BCD, Long, LongBCD) as the Data Type.
4. Click Add to append a new record, or Replace to modify a record.
You need to at least enter the Variable Tag Name, I/O Device Name, Data Type, and
Address fields.
See Also
Variable Tag Properties
Formatting numeric variables

Variable Tag Properties

You can use this dialog for Configuring Variable Tags. Variable tags have the following
properties:

383
Chapter: 16 Tagging Process Variables

Variable Tag Name

You can use any name for a tag (79 characters) provided it follows the Tag name syntax
and isn't the same as the name of a Cicode function within the project or any included
projects (see Defining Variable Tag Names for a list of restrictions on naming). If you
have many tags, use a naming convention (see Using structured tag names). This makes
it easier to find and debug your tags.When the tag name is referenced on a graphics
page, Cicode, etc., it can be used with or without a specific tag element or item.
If you are using distributed servers, the name needs to be unique to the cluster (for exam-
ple, you cannot have the same variable tag name in more than one cluster).
Cluster Name
The name of the cluster to which the tag applies (16 characters). Select a cluster name
from the list of available clusters as defined under Cluster Definitions.
Data Type
The type of I/O Device variable (16 characters). I/O Devices support several data types
that are used to exchange data with CitectSCADA. Because of the lack of an industry
standard, most I/O Device manufacturers use individual naming conventions for their
I/O Device variables. However, every variable corresponds to one of the Tag data types.

Note: If you do not specify a range for your tag, then an out of range alert message
will be generated if you write a value which is outside the range of the type.

You need to specify the correct data type that corresponds to the data type of the I/O
Device variable you are configuring. Each data type has a unique address format. You
need to use this format when you are specifying the address of the variable (as the
Address property).
You will want to verify that you only use data types that are valid for your I/O Device. If
you do not specify a data type, the variable will be treated as 16-bit integer.
CitectSCADA supports concatenation of I/O Device registers. For example, you can
define a real data type (in CitectSCADA) as two contiguous int data types (in the I/O
Device). CitectSCADA reads across the boundary of the two ints and returns a real.
If you use concatenation of registers, the address of the variables needs to be on odd
boundaries or even boundaries. You cannot mix address boundaries. For example, V1,
V3, V5 are valid addresses.
Be careful when using this feature: the I/O Device needs to maintain the integrity of the
second register. (If the I/O Device writes to the second int, the value of the real could be
corrupted.) The structure of some I/O Devices might not support this feature, and might
therefore behave unpredictably.

384
Chapter: 16 Tagging Process Variables

UNINTENDED EQUIPMENT OPERATION

Do not mix the use of odd and even variable addresses as boundaries when you are con-
catenating registers.

Failure to follow these instructions can result in death, serious injury, or equip-
ment damage.

String variables
While numeric variables are more common, some I/O Devices also support ASCII
strings. You can use strings to store text data (for example, from a bar code reader).
All strings needs to be NULL-terminated in the I/O Device. CitectSCADA uses the NULL
character to check for the end of a string, and if no NULL character is present, Citect-
SCADA reads (and displays) any extra characters in memory, after the end of the string.
When you are using a disk I/O Device, you can also specify a string data type for storage
of recipes, or for operator display information.
Not every I/O Device supports strings. However, if your I/O Device does support integer
data types, CitectSCADA can use these integer registers to store ASCII strings in your I/O
Device. CitectSCADA strings can only be stored in contiguous blocks (consecutive reg-
isters), and are stored as an array.

Note: Non printable characters within string tag values will be substituted with
spaces e.g. string [ 0x01, 0x41, 0x10, 0x42 ] will appear as " A B", so cache loading
continues to operate.

To display the data types for an I/O Device, double-click the I/O Devices book from the
Help, select your I/O Device from the list, and then select the Data Types topic.
I/O Device Name
The name of the I/O Device where the variable is stored (31 characters). If using I/O
Device redundancy, you need to specify the primary I/O Device name here, not the
standby.
Address
The register address in the I/O Device where the variable is stored (254 characters). The
format and prefix of an address will depend on the protocol configured for the I/O
Device, which can be determined by checking the Protocol field on the I/O Devices form
in Project Editor.
Raw Zero Scale / Raw Full Scale

385
Chapter: 16 Tagging Process Variables

The unscaled (raw) values (of the variable) that represent the zero point and full scale
point for the data (11 characters). The raw values are the values that CitectSCADA reads
from the I/O Device.
Eng Zero Scale / Eng Full Scale
The scaled values that CitectSCADA calculates from the raw values (11 characters). The
Raw Zero Scale is scaled to the Eng Zero Scale and the Raw Full Scale is scaled to the
Eng Full Scale. These properties are represented in engineering units and are used as the
upper and lower limits of trends and bar graphs.
Most I/O Devices return an integer to indicate the value of an analog input. To return a
usable value, the I/O Device converts an input signal (usually 4-20 mA) to a raw scale
variable, usually (but not always) in the range 6400 to 32000.
To present this variable as a meaningful value, you can specify a scaling calculation.
CitectSCADA then scales every value accordingly, as in the following diagram.

The scaled value of the variable (engineering value), not its raw value, is used through-
out the system.
The scaling properties are optional. If you do not specify scaling, Eng Zero Scale defaults
to Raw Zero Scale, and Eng Full Scale defaults to Raw Full Scale; that is, no scaling
occurs.
A value that is below the specified Raw Zero Scale or above the specified Raw Full Scale
causes an "Out of Range" alert message in your runtime system.
Eng Units

386
Chapter: 16 Tagging Process Variables

(8 characters.) The engineering units that the value represents (for example %, deg,
mm/sec, etc.). This property is optional. If you do not specify engineering units, no engi-
neering units are used.
Format
(11 characters). The display format of the value (of the variable) when it is displayed on
a graphics page, written to a file, or passed to a function (that expects a string). This
property is optional. If you do not specify a format, the format defaults to ####.##.
Deadband
(11 characters). A deadband allows the value of a variable tag to fluctuate within a
defined threshold without updates being sent through the system. This may be useful if
a tag produces many small, insignificant value changes. The threshold is represented as
a percentage of the tag's engineering range. The default value is 0 (zero), which captures
every value change.
For example, if a variable tag has an engineering range of zero to 10000, a deadband of 1
would mean a change in value would have to be greater than 100 (or 1 percent of the
range) to be recognized. If the current value was 5600, the tag in the PLC would have to
change to a value greater than 5700 or less than 5500 before an update would be sent
through the system.
Comment
Any useful comment (48 characters).
Linked
The Linked field in the status line of the Variable Tags form reads either Yes or No and
indicates whether or not the variable tag is linked to an external data source. When you
program an I/O Device using software other than CitectSCADA, an external data source
is used to store tag data. Linked variable tags are updated whenever external tag data
changes, meaning you do not need to enter the information again in CitectSCADA.

Defining Variable Tag Names

You cannot use certain reserved words when defining your tag name variables. You can-
not use:

387
Chapter: 16 Tagging Process Variables

l Reserved words such as:

& * ** -

/ + < <=

>= <> = >

ACTION AND ANY_NUM ARRAY

BOOL CASE CON- CONSTANT

FIGURATION

DATE DATE DINT DO

DUT DWORD ELSE EN

END_CASE END_CON- END_FOR END_IF

FIGURATION

END_PRO- END_VAR END_WHILE ENO

GRAM

EXIT FALSE FOR FUNCTION

IF INT INT MOD

NOT OF OR PROGRAM

REAL REPEAT STRING STRING

TASK TIME TIME TO

TRUE TRUE UNTIL VAR_EXTER-

NAL

VAR_GLOBAL VAR_IN_OUT VAR_INPUT VAR_OUTPUT

WHILE WORD XOR

l Cicode function names. See Functions Reference for an entire list of Cicode functions.
Using reserved words or Cicode function names may cause a syntax error.

388
Chapter: 16 Tagging Process Variables

Formatting numeric variables

The value of a numeric variable (number) can be displayed on a graphics page or
written to a file in many different formats (for example, 24, 0024, 24.000, or 24.0%).

Format specifiers
Format specifiers are keyboard characters that you use to define the format for the
numeric variable. The specifiers that you can use are:

Specifier Description Function

# The hash character The number of characters to display

0 Zero Padding

- Minus Justification

. Period Decimal notation

EU Engineering units

S Exponential notation

Specifying the number of digits

The hash character (#) specifies how many digits CitectSCADA displays. every numeric
variable displays to the right of an animation point, for example:
Format: ####
In this example, CitectSCADA displays at least four digits (or spaces) to the right of the
animation point. If the number contains more than four digits, the first digit is located at
the animation point. The following figure illustrates several numbers in the above for-
mat.

389
Chapter: 16 Tagging Process Variables

Padding with zeros

When a number contains fewer digits than your format specifies (5 or 75 in the above
example), CitectSCADA only displays the meaningful digits. You can use the padding
character, zero (0), as the second character in the format string, to fill the number with
zeros, for example:
Format:#0##
This format string displays:

Changing justification
By default, numeric variables are right-justified (within their field). You can change the
default justification by using a minus (-) sign as the second character in the format
string, for example:
Format: #-###
This format string displays:

Specifying decimal notation

To specify decimal notation, use a period (.), for example:
Format: ###.##
In this example, CitectSCADA displays three digits before the decimal point and two dig-
its after. If the variable is 12.3, CitectSCADA displays 12.30.

390
Chapter: 16 Tagging Process Variables

All numbers are automatically rounded, i.e. 12.306 displays as 12.31.

Specifying engineering units

You can specify engineering units (such as %, deg, rpm, M, mm/sec, etc.) when you
define a variable tag. To include these units in the format of the number, type EU in the
appropriate position.
Format: ####.##EU

Note: If you do not specify an engineering unit for the variable, only the number is
displayed (or logged).

Specifying exponential notation

To specify exponential notation, include the exponential character (s), for example:
Format: #s###
In this example, CitectSCADA displays the number in exponential notation format, for
example: 1.234e+012.

Combining format specifiers

You can combine format specifiers, for example:
Format: #0-###.##EU
This format string displays six digits before the decimal point and two digits after. The
number is left justified, padded, and displayed with engineering units (if specified).

Using shortform notation

As an alternative to the hash (#) notation, you can use shortform notation. With short-
form notation, you use a number to specify the format of the numeric variable, for exam-
ple:
Format: 3.2
This format string displays three digits before the decimal point and two digits after.
This format string is equivalent to the ###.## format specification. You can also include
engineering units with shortform notation, for example:
Format: 6.0EU
This format string displays six digits before the decimal point and no digits after. The
number is displayed with engineering units (if specified). This format string is equiv-
alent to the ######EU format specification.

391
Chapter: 16 Tagging Process Variables

You cannot use padding or left justification with shortform notation.

Note: If the value of a numeric variable is extremely large, it is displayed in expo-

nential notation (for example 1.2345E012).If no format is specified for a variable, the
default ####.# (or 4.1) is used.

Variable Tag Name Conveyor_Speed

Address V500[5]

Here, five register addresses are referred to by the variable tag Conveyor_Speed.

392
Chapter: 16 Tagging Process Variables

Referring to array variables

Each entry of an array is referred to by an index. You can extract individual variables
(from the array) by specifying the tag name and index:

<Tag Name>[Index]

For example, to refer to the third variable of the array in the above example (Conveyor
3), use the following syntax:

Variable Tag Conveyor_Speed[2]

The index of the first entry of an array is always 0 (zero). In this example, Conveyor_
Speed[0] is the first entry of the array (Conveyor 1), and Conveyor_Speed[4] is the last
entry (Conveyor 5).
Note the following when using arrays:
l Do not define large arrays, because each time an individual array entry is requested,
CitectSCADA reads the entire array from the I/O Device. With large arrays, system
performance could be reduced.
l The size of the array needs to be less than the maximum request length of the pro-
tocol. The I/O Device description help topic (for your I/O Device) displays the max-
imum request length of the protocol.
l declare digital arrays on a 16 bit boundary. CitectSCADA rounds each digital array
down to the nearest 16 bit boundary. Consequently, digitals in the array are changed.
For example, if you declare an array Test to start at bit 35, and CitectSCADA starts
the array at bit 32. The index to the array also starts at bit 32; Test[0] refers to bit 32,
not bit 35.
l Each individual array entry has its own data value for the field, valid and override
elements, but the entries within an array share the override and control mode ele-
ments, quality and timestamps. Reading the quality or timestamp for an indexed
array entry will return the quality or timestamp for the entire array. Writing to the
value for an indexed array entry will change the timestamps and quality for the
entire array. Changing the override mode and the control mode for an array entry
will change it for the entire array.
See Also
Tag Extensions

393
Chapter: 16 Tagging Process Variables

String arrays
If you are using a CitectSCADA string data type, you need to specify an array of integer
data types. One int register stores two string characters.
To calculate the size of an array (for string data types), use the following formula:

The last element of the array is always used to store the null character '\0'. This char-
acter marks the end of the string.
To store the word "Recipe", you need to specify an array with 4 elements, for example:

Variable Tag Name Recipe_Tag

Address V500[4]

Two characters are stored in each register, i.e:

You can then refer to the entire string by specifying the tag:

For example:

Variable Tag Recipe_Tag

To store the word "Recipes", you would also specify an array with 4 elements. The char-
acters are stored as follows:

394
Chapter: 16 Tagging Process Variables

Note: If your I/O Device supports string data types, you need to specify the address
in the format determined by the I/O Device you are using.

Configuring Local Variables

Local variables allow you to store data in memory when you start your runtime system.
They are created each time the system starts, and therefore do not retain their values
when you shut down. Local variables may be of any data type supported by Citect-
SCADA, including two-dimensional arrays of standard CitectSCADA types.
Local variables are useful when you need each process to have a separate copy of the
data. Each process has its own copy of each local variable configured in the project, and
the values in a local variable are available only to the process that wrote them.
To configure a local variable:

1. In Project Editor, select Tags | Local Variables. The Local Variables dialog displays.
2. In the Name field, enter a name for the local variable. Variable names cannot include
the '-', '/', '%' or <space> characters.
3. In the Data Type field (16 characters), select one of the following supported data
types:

Data Type Variable Size Allowed Values

BCD Binary- Coded Dec- 2 0 to 9,999

imal bytes

395
Chapter: 16 Tagging Process Variables

BYTE Byte 1 0 to 255

byte

DIGITAL Digital 1 bit 0 or 1

or 1
byte

INT Integer 2 -32,768 to 32,767

bytes

UINT Unsigned Integer 2 0 to 65,535

bytes

LONG Long Integer 4 -2,147,483,648 to

bytes 2,147,483,647

LONGBCD Long Binary- 4 0 to 99,999,

Coded Decimal bytes

REAL Floating Point 4 -3.4E38 to 3.4E38

bytes

STRING String up to ASCII (null terminated)

256
bytes

Numeric and digital variables have a default value of 0 and string variables default to ""
(empty string). If you do not specify a data type, the local variable will be treated as 16-
bit integer.
4. In the Array Size field (8 characters), enter the size of the array (number of elements)
used to store the local variable. The array will be of the data type specified in the
Data Type field. The array can be one or two-dimensional. Up to 32766 elements can
be used, which, for a two dimensional array, means that the size of the first dimen-
sion multiplied by the size of the second is less than or equal to 32766. When spec-
ifying a multi-dimensional array, separate the dimensions with a comma, for
example "20,30"."
5. In the Zero Scale field (11 characters), enter the value of the local variable that rep-
resents the zero point for the data. The zero scale value is used as the lower limit for
trend and bar graphs, and values below the zero scale value will cause an "Out of
Range" alert message in the runtime system.
6. In the Full Scale field (11 characters), enter the value of the local variable that rep-
resents the full scale point of the data. The full scale value is used as the upper limit
for trend and bar graphs, and values above the full scale value will cause an "Out of
Range" alert message in the runtime system.

396
Chapter: 16 Tagging Process Variables

7. In the EngUnit field, enter the engineering units that the value represents (for exam-
ple %, deg, mm/sec, etc.). This property is optional. If you do not specify engineering
units, no engineering units are used.
8. In the Format field, Enter the display format of the value (of the variable) when it is
displayed on a graphics page, written to a file, or passed to a function (that expects a
string). This property is optional. If you do not specify a format, the format defaults to
####.#.
9. In the Comment field, enter any useful comment. This property is optional and is not
used at runtime.
10. Click Add.
See Also
Configuring Variable Tags

397
Chapter: 16 Tagging Process Variables

398
Chapter: 17 Linking, Importing, and Exporting Tags

Because I/O Devices are often programmed independently of CitectSCADA, you can
import, or link to, every the tag in an external data source. This means that you only
have to define tag information once when you program your I/O Devices. You do not
have to re-enter the same information again in CitectSCADA. Because the necessary infor-
mation is already saved in an external data source, you can just import it or link to it.
There are two types of tags in the CitectSCADA variable database - linked tags and non-
linked tags. When performing a tag import from Citect Explorer, only non-linked tags are
updated. Linked tags remain unchanged. When performing a refresh or auto-refresh,
only linked tags are updated. Non-linked tags remain unchanged. When performing a
synchronization (Live Update), every tag for the I/O device are updated and linked.
CitectSCADA also lets you export tags to an external file, specifying the destination and
format of your choice. You might then import this file into a third-party I/O Device pro-
gramming package database, or simply use it as a backup.

Note: The simultaneous update of a tag name and its fields is only supported when
importing via OFS. In every other case, if you attempt to simultaneously update a
tag's name and fields, only the name will be updated. In this case update a tag name
in a separate operation from updating its fields.

See Also
Linking tags
Importing tags
Exporting tags
Unity Support Matrixes

Linking tags
Linking is an I/O Device specific operation. When you add an I/O Device record in Citect-
SCADA (using the Express Communications Wizard), you can choose to link it to an
external data source. The external data source is where the tag data was saved when the
actual I/O Device was programmed. If you link to the external data source, CitectSCADA
automatically creates variable tag records for every tag in the I/O Device.

399
Chapter: 17 Linking, Importing, and Exporting Tags

These variable tag records are dynamically linked to the tags in the external data source.
CitectSCADA is updated whenever one of the external tags is changed. For example, you
might program your I/O Devices, configure your project, then add some new tags or edit
existing tags. In this situation, CitectSCADA is automatically updated with your
changes.
This update occurs when you attempt to read the changed tags in CitectSCADA (for
example you compile your project, display the tag using the Variable Tags dialog box,
modify or paste the tag, or perform a manual refresh, etc.). For example, if you change
the address of a tag using a third party I/O Device programming package, the external
data source is changed. Then, when you display the variable tag record or compile your
project in CitectSCADA, the change is copied from the external database to Citect-
SCADA's variable tags database.
You can tell if a tag is linked because the status line at the bottom of the Variable Tags
form will read Linked: Yes. If it is linked and you change a field, your change will not
be overwritten when the link is next refreshed. Generally, however, any field which takes
its value from the external data source is disabled.

Note: Some properties defined for the external tags will not be relevant to Citect-
SCADA. Also, some will not be in a format that CitectSCADA can read. Each I/O
Device has an associated format file in CitectSCADA. It is this file that determines
what information is copied to CitectSCADA's variable tags database and how this
information is to be converted. In most cases, you will not have to edit this file.

Note the following for Citect tags linked to Unity tags:

1. The addition of a new tag on either side, will result in the addition of a new tag on
the other side.
2. The deletion of an existing tag on either side, will result in the deletion of the cor-
responding tag on the other side.
3. The modification of an existing tag on either side, will result in the modification of
the corresponding tag on the other side.
4. The delete operation in either Unity or Citect will take precedence over other oper-
ations (such as modify).
5. If there is some contention between the Unity database and the Citect database for the
same tag, that is modifications are done from both databases at the same time, the
Unity database item will take precedence over the Citect database item.
6. The linked I/O Device live update synchronization will be triggered in the following
cases:
1. Unity configuration update.

400

DNPR Users Guide
No ratings yet
DNPR Users Guide
85 pages
Citect SCADA 6 (1) .10 Modbus Driver Help
No ratings yet
Citect SCADA 6 (1) .10 Modbus Driver Help
28 pages
CitectSCADA Technical Reference
No ratings yet
CitectSCADA Technical Reference
375 pages
PSDIRECT Users Guide Rev 2.2.1
No ratings yet
PSDIRECT Users Guide Rev 2.2.1
34 pages
PSDIRECT Driver Specification Rev 2.5.0
No ratings yet
PSDIRECT Driver Specification Rev 2.5.0
46 pages
Cicode Reference PDF
No ratings yet
Cicode Reference PDF
716 pages
Compiling and Running A System
No ratings yet
Compiling and Running A System
33 pages
PSDIRECT Driver Specification 2.6
No ratings yet
PSDIRECT Driver Specification 2.6
55 pages
Introduction - The CitectSCADA Environment
No ratings yet
Introduction - The CitectSCADA Environment
10 pages
CitectSCADA User Guide
No ratings yet
CitectSCADA User Guide
733 pages
Upgrading To CitectSCADA Version 6
No ratings yet
Upgrading To CitectSCADA Version 6
6 pages
Installation Guide
No ratings yet
Installation Guide
64 pages
CSV7.0 Qs Eng PDF
No ratings yet
CSV7.0 Qs Eng PDF
75 pages
Quickstart Tutorial V70 PDF
No ratings yet
Quickstart Tutorial V70 PDF
75 pages
Installation Guide
No ratings yet
Installation Guide
89 pages
DNP Driver Spec
No ratings yet
DNP Driver Spec
53 pages
CitectSCADA User Guide
No ratings yet
CitectSCADA User Guide
1,100 pages
CitectSCADA 7.20 User Guide-1
No ratings yet
CitectSCADA 7.20 User Guide-1
100 pages
CitectSCADA User Guide
No ratings yet
CitectSCADA User Guide
1,100 pages
PELCO Camera Integration Guide
No ratings yet
PELCO Camera Integration Guide
65 pages
PELCO Camera Integration Guide PDF
No ratings yet
PELCO Camera Integration Guide PDF
65 pages
PSDIRECT Driver Specification Rev 2.4.2
No ratings yet
PSDIRECT Driver Specification Rev 2.4.2
44 pages
Time-stamped Data Retrieval in SCADA
No ratings yet
Time-stamped Data Retrieval in SCADA
1 page
Important Notification - MODNET Driver
No ratings yet
Important Notification - MODNET Driver
2 pages
Citect SCADA Assignment1
No ratings yet
Citect SCADA Assignment1
11 pages
Citectscada Networks: Citect Pty LTD 3 Fitzsimmons Lane Gordon NSW 2072 Australia
No ratings yet
Citectscada Networks: Citect Pty LTD 3 Fitzsimmons Lane Gordon NSW 2072 Australia
0 pages
CitectSCADA User Guide
No ratings yet
CitectSCADA User Guide
1,393 pages
SITIA
No ratings yet
SITIA
14 pages
Product SIPROTEC Tools V01.90
No ratings yet
Product SIPROTEC Tools V01.90
10 pages
CitectSCADA Cicode Reference
100% (1)
CitectSCADA Cicode Reference
1,355 pages
CitectSCADA Cicode Reference
100% (2)
CitectSCADA Cicode Reference
1,355 pages
Citect-Quickstart Tutorial Programming
100% (1)
Citect-Quickstart Tutorial Programming
67 pages
Citect SCADA Cicode 2016 - Study Guide
No ratings yet
Citect SCADA Cicode 2016 - Study Guide
13 pages
CitectSCADA Cicode Reference
100% (2)
CitectSCADA Cicode Reference
908 pages
CitectSCADA 6.10 SPK A Release Notes
No ratings yet
CitectSCADA 6.10 SPK A Release Notes
13 pages
CitectVBA Reference Guide
No ratings yet
CitectVBA Reference Guide
197 pages
Multi-Monitor Setup for SCADA Users
No ratings yet
Multi-Monitor Setup for SCADA Users
100 pages
Configuration Manual For SCADA: Citect
No ratings yet
Configuration Manual For SCADA: Citect
18 pages
Citect OPC Server PDF
No ratings yet
Citect OPC Server PDF
18 pages
Product SIPROTEC Tools V01.60
No ratings yet
Product SIPROTEC Tools V01.60
9 pages
CitectSCADA v7.1 - CitectVBA Reference Guide
No ratings yet
CitectSCADA v7.1 - CitectVBA Reference Guide
195 pages
Citect SCADA IODevice & Tags Guide
No ratings yet
Citect SCADA IODevice & Tags Guide
1 page
IEC61850 Driver Help PDF
No ratings yet
IEC61850 Driver Help PDF
34 pages
GFS-154B M04 Connecting To IO
No ratings yet
GFS-154B M04 Connecting To IO
17 pages
CitectVBA Reference Guide
No ratings yet
CitectVBA Reference Guide
199 pages
GFS-154B M06 Configuring IO Drivers and OPC Servers
No ratings yet
GFS-154B M06 Configuring IO Drivers and OPC Servers
30 pages
CitectSCADA Basic Configuration v6.0
100% (1)
CitectSCADA Basic Configuration v6.0
318 pages
1 SCADA Courses
No ratings yet
1 SCADA Courses
20 pages
CitectSCADA V7.30 Whats New
No ratings yet
CitectSCADA V7.30 Whats New
2 pages
Installation Guide PDF
No ratings yet
Installation Guide PDF
91 pages
CitectSCADA 7.0 Service Pack 3 - Release Notes
No ratings yet
CitectSCADA 7.0 Service Pack 3 - Release Notes
32 pages
Citect SCADA (Description)
No ratings yet
Citect SCADA (Description)
1 page
Time Stamped Alarms in Citect
100% (1)
Time Stamped Alarms in Citect
4 pages
CitectSCADA Batch User Guide
No ratings yet
CitectSCADA Batch User Guide
320 pages
Convert Your Windows Server 2008 R2 To A Workstation
No ratings yet
Convert Your Windows Server 2008 R2 To A Workstation
25 pages
Aindumps 2023-Aug-05 by Kevin 224q Vce
No ratings yet
Aindumps 2023-Aug-05 by Kevin 224q Vce
13 pages
User Manual: Single Board Computer
No ratings yet
User Manual: Single Board Computer
71 pages
Kdump White Paper
No ratings yet
Kdump White Paper
12 pages
Sun t5120-t5220 v4
No ratings yet
Sun t5120-t5220 v4
70 pages
Lisa LCD Quick Start Guide
No ratings yet
Lisa LCD Quick Start Guide
10 pages
FDS-0001-EN-DES-439-R000-REV01-0-Fire Detection Systems Fundamentals XLS140-XLS3000 Sys Progrm - Commission and Implm PDF
No ratings yet
FDS-0001-EN-DES-439-R000-REV01-0-Fire Detection Systems Fundamentals XLS140-XLS3000 Sys Progrm - Commission and Implm PDF
2 pages
Boot DLC v3.1 from USB Guide
No ratings yet
Boot DLC v3.1 from USB Guide
7 pages
How To Edit Boot Camp Info - Plist
No ratings yet
How To Edit Boot Camp Info - Plist
9 pages
IM 022 VxWorks Rev1.3 PDF
No ratings yet
IM 022 VxWorks Rev1.3 PDF
42 pages
Firmware Engineer Opportunity
No ratings yet
Firmware Engineer Opportunity
2 pages
(Eng) Manuale Tft700 Tft701 Tft702
No ratings yet
(Eng) Manuale Tft700 Tft701 Tft702
12 pages
Chs LM Module3 q1 q2
No ratings yet
Chs LM Module3 q1 q2
152 pages
Aircraft Maintenance Systems Guide
No ratings yet
Aircraft Maintenance Systems Guide
22 pages
Bios PDF
No ratings yet
Bios PDF
10 pages
Topic 4 Operating Systems and File Management
No ratings yet
Topic 4 Operating Systems and File Management
64 pages
Contents Sony Ericsson W300I
No ratings yet
Contents Sony Ericsson W300I
71 pages
Ilp Pat Test Unix
No ratings yet
Ilp Pat Test Unix
6 pages
Asus Tablet Rooting Guide
No ratings yet
Asus Tablet Rooting Guide
5 pages
Debug 1214
No ratings yet
Debug 1214
4 pages
Fault Alarm Robicon PDF
50% (2)
Fault Alarm Robicon PDF
32 pages
BaiOMC - v11.0 Data Sheet-01
No ratings yet
BaiOMC - v11.0 Data Sheet-01
6 pages
Gain Administrator Access in Windows Without A Password
No ratings yet
Gain Administrator Access in Windows Without A Password
27 pages
XM125 Software User Guide 7
No ratings yet
XM125 Software User Guide 7
13 pages
Service Manual Bellavista 1000 V19 02
100% (3)
Service Manual Bellavista 1000 V19 02
139 pages
Lite Midterm Exam Pointers
No ratings yet
Lite Midterm Exam Pointers
12 pages
Cisco Router 1941 Series Manual Installation and Configuration
100% (2)
Cisco Router 1941 Series Manual Installation and Configuration
116 pages
LPFC - Emulex Lightpulse Solaris Hba Driver Chapter 1 - Introduction
No ratings yet
LPFC - Emulex Lightpulse Solaris Hba Driver Chapter 1 - Introduction
42 pages
Lenovo ThinkCentre M91p Tower User Manual
0% (1)
Lenovo ThinkCentre M91p Tower User Manual
142 pages
Quectel EC2x&EG9x&EM05 DFOTA User Guide V1.0 PDF
No ratings yet
Quectel EC2x&EG9x&EM05 DFOTA User Guide V1.0 PDF
17 pages