Professional Documents
Culture Documents
Citect Scada 6110 Modbus Driver Help PDF
Citect Scada 6110 Modbus Driver Help PDF
Modbus Driver
The Modbus driver Help is designed to assist you in setting up and configuring communication
with a Modbus system. This process involves the following steps:
You'll find additional information in the Advanced Configuration and Maintenance and
Troubleshooting sections to help you resolve communication or configuration errors.
About Modbus
The Modbus protocol supports serial communication with many I/O devices (including the
Modicon 484, 584, 884, and 984 programmable controllers).
The Modbus protocol differs from the Modbusa protocol only in the data framing technique used:
the Modbus protocol is RTU-based while the Modbusa protocol is ASCII-based.
The Modbus protocol also supports the Siemens TI 405 PLC, and the Moore Industries
IOExpress Data Collection Units. Other PLCs might also be supported; contact Citect Technical
Support for details.
The maximum request length for the Modbus protocol is 2000 bits.
Notes
Some non-standard PLCs support the Modbus protocol. However, some of these I/O devices do
not support the Modbus protocol correctly. When CitectSCADA tries to communicate with these
I/O devices, you might get errors on startup or during communication.
To handle these non-standard I/O devices, the Modbus protocol has some special options to
change its operation:
1. On startup, CitectSCADA tries to read some digital inputs to verify that the PLC does
exist. If CitectSCADA cannot read these bits, it assumes the PLC is bad, and remains off
line. Some non-standard I/O devices do not support digital bits, so this command fails.
With the [MODBUS]InitType parameter, you can change the type of variable the Modbus
protocol tries to read on startup, to allow communication to start.
2. The standard Modbus driver allows reading of 2000 bits in one request. Some non-
standard I/O devices do not support such large reads. You can change the maximum
read size with the [MODBUS]MaxBits parameter. (The default is 2000.)
You must also change the MAX_LENGTH field for the Modbus protocol (in the
\CITECT\BIN\PROTDIR.DBF file) to the same value. You must re-compile your project
after changing this option. Note that if you reinstall CitectSCADA, the PROTDIR.DBF file
is overwritten and you must repeat the change.
3. Some I/O devices that operate over radio modems also require the padding of protocol
messages. The padding characters wake the radio modem to allow the rest of the
message to be transmitted. Set the [MODBUS]Pad parameter to the number of
characters to pad, and the [MODBUS]PadChar parameter to the ASCII code of the
character to pad. For example, to pad 20 0xFF characters to the start of the message,
set:
[MODBUS]
Padd=20
PadChar=255
4. In the Modbus protocol, LONG data types default to a simplified implementation, with a
shortened range of 0 to 655,359,999. To increase the LONG data type to the full range,
set the [MODBUS]LongDataType parameter to either 1 or 3.
As a LONG is composed from two registers, the register order used by CitectSCADA
must match the order used by the PLC. Refer to the help accompanying the [MODBUS]
LongDataType parameter to determine the appropriate value.
Any computer you install the driver pack on must have CitectSCADA installed.
No special setup is required required for this protocol: only the included CitectSCADA driver
(modbus.dll) is used.
Before installing the driver pack, close your CitectSCADA runtime environment and Citect
Explorer. You need administrator permissions for the I/O server PC.
1. Save the Modbus 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. You are prompted to select the
CitectSCADA installation folder. By default, this is C:\Program
Files\Citect\CitectSCADA. If you installed CitectSCADA in a different folder,
browse to that location. An error message will warn you if you select the wrong folder.
4. Click Finish to complete the installation.
This section provides an overview of the Ethernet connection, as well as describing the
hardware setup procedure.
Overview
The TCP/IP method of communication to devices supporting Modbus/TCP uses the Modnet
protocol over Ethernet. Using this method you can connect to single or multiple PLCs as in the
following diagram:
You can use the same Ethernet card that is being used for CitectSCADA communication for
PLC communication, though this might degrade performance.
Set up your specific Ethernet card as required and confirm basic network communications
before configuring communications for the Modnet driver. Refer to the documentation
accompanying your hardware for instruction.
You must also set up the TCP/IP protocol on your CitectSCADA computer. The Modnet protocol
supports TCP/IP communication with the Modicon TSX Quantum PLC and most Modbus/TCP
compatible devices.
This protocol requires only Winsock TCP/IP software to be installed in your computer. This
protocol does not require any software from Modicon.
To use any CitectSCADA TCP/IP protocols, the Windows TCP/IP protocol driver must first be
installed and set up by:
This section provides an overview of the serial connection, as well as describing the hardware
setup procedure.
Overview
Many I/O devices use Modbus ASCII or Modbus RTU to communicate. The setup of these
devices is identical with the exception of the I/O Device Protocol you specify in the I/O Devices
dialog box:
z Modbus ASCII devices use the Modbusa driver, so you must specify MODBUSA.
z Modbus RTU devices use the Modbus driver, so you must specify MODBUS.
Communication is via the Modbus port on the PLC. Using this method you can connect to single
or multiple PLCs as shown here:
Wiring Diagrams
Use the following serial wiring diagrams to help you wire your Modbus devices correctly.
Serial wiring diagram 1
You must set your PLC to the communication setting you want. The default hardware settings
for the device are as follows:
Setting Value
Baud Rate 19200
Data Bits 8
Stop Bits 1
Parity 2 (even)
These settings are recommendations only. If you use the Communications Express Wizard,
these default settings are configured in your project automatically, though your hardware might
support other values. If you set the baud rate, data bits, stop bits or parity to another value, you
must manually set the new value(s) in your project.
You must also set the following configuration options on the Modbus port on the PLC:
z Station number.
z RTU mode (if this is not selected, you must use the Modbusa protocol).
z Delay time to 1.
See Also
Setting up Communications
Before configuring your CitectSCADA project, first you should establish and confirm
communications between CitectSCADA and the devices in your Modbus system by creating a
test project. This allows you to test the communication path in isolation, and ensures that
CitectSCADA can bring your devices online.
CitectSCADA will not communicate with an I/O device if there is no reason to read or write data.
Therefore, you must define and implement some variable tags within your CitectSCADA project
to initiate a read request and verify that the communication channel is functioning correctly. This
requires you to create a test project.
When creating a test project, try to keep things as simple as possible, so that you can easily
identify any communication errors. For example, you might design your test project to do nothing
more than use an integer variable to display a number on a graphics page.
You should build your test project on the CitectSCADA I/O server that will connect to the
Modbus system.
After confirming communications using your test project, it can be set aside for testing other
communications later.
Adding a device to your CitectSCADA project provides the information required about the
device's location, communication method, connection port, and so on. This information is stored
in the CitectSCADA project database.
Usually the Express Communications Wizard is sufficient to set up your communications; the
settings it implements for each device have been pre-configured for preferred operation. If,
however, your device connection needs are complex, you can configure communications
manually by using the CitectSCADA communication forms.
Using the Express Communications Wizard enables you to configure a device quickly and easily
using preconfigured settings.
Usually the Express Communication Wizard is sufficient to set up communication with a device.
However, if the device configuration is unusual, you can manually enter information into the
required dialog boxes in Project Editor.
The settings you specify using the Boards, Ports, and I/O Devices dialog boxes depend on the
type of communication method used. Choose the appropriate section:
This section describes how to manually configure communications for an Ethernet connection by
using the Boards, Ports, and I/O Devices dialog boxes.
Before configuring your Ethernet connection, make sure that you have installed and set up
TCP/IP on your machine.
Complete the communications dialog boxes for the devices using Modbus within the network
environment using the Modbus protocol with the information specified.
Use the table below to enter the correct information in the Boards dialog box.
Use the table below to enter the correct information in the Ports dialog box.
Use the table below to enter the correct information in the I/O Devices dialog box.
This section describes how to manually configure communications for a serial connection by
using the Boards, Ports, and I/O Devices dialog boxes.
Use the table below to enter the correct information in the Boards dialog box.
Use the table below to enter the correct information in the Ports dialog box.
Use the table below to enter the correct information in the I/O Devices dialog box.
You must add a separate variable tag to your CitectSCADA project for each data-point (memory
register) on the I/O devices you want to communicate with. Define your CitectSCADA variable
tags by using the Variable Tags dialog box:
For CitectSCADA to compile correctly, you must include appropriate values for the following
fields:.
Field Value
Variable Tag A unique name per project for the variable tag (up to 79 alphanumeric characters in Version 6, 32
Name characters for earlier versions). This can be used by CitectSCADA graphic pages and in Cicode where
defined.
Data Type Type of variable. Select from the menu. It must be one of the predefined types used in CitectSCADA.
I/O Device Name of an I/O device defined in the I/O Devices dialog box, which identifies the controller for the device
Name using Modbus.
Address The name of a predefined Modbus system PLC tag.
CitectSCADA does not display compile errors if an invalid address is entered in the Variable Tag
dialog box. Variable tag values that have an invalid address display as "#COM" at runtime on
the graphic pages where they are inserted.
Data types
This section describes the correct data types to use; the data types you use depend on the type
of connection:
You must use the correct data types when defining your variables for your CitectSCADA project.
The table below show the data types for configuring an Ethernet connection.
Valid
CitectSCADA Data
Data Types Address Address Format
Type
Range
Output Coils 00001 - Valid address (e.g. 01000) DIGITAL
099999
Input Status 10001 - Valid address (e.g. 13000) DIGITAL
19999
Input Registers 30001 - Valid address (e.g. 31350) INT/ REAL/ LONG/
399999 BCD/ LONGBCD
Input Registers 30001 - Valid address.b where b is the bit number DIGITAL
(DIGITAL) 399999 between 1 and 16 inclusive(e.g. 32300.2)
Input Registers 30001 - SValid address where S denotes the STRING STRING
(STRING) 399999 data type (e.g. S300206)
(For use with Modnet
version 3.00B and later)
Output Registers 40001 - Valid address (e.g. 41190) INT/ REAL/ LONG/
499999 BCD/ LONGBCD
Output Registers 40001 - Valid address.b where b is the bit number DIGITAL
(DIGITAL) 499999 between 1 and 16 inclusive (e.g. 40001.4)
Output Registers 40001 - SValid address where S denotes the STRING STRING
(STRING) 49999 data type (e.g. S40020)
(For use with Modnet
version 3.00B and later)
Input Registers 300001 - OValid address (e.g. O326750) LONG/ LONGBCD/
Odd address (for use 399999 REAL
with Modnet version
3.00B and later)
Input Registers 300001 - EValid address (e.g. E345999) LONG/ LONGBCD/
Even address (for use 399999 REAL
with Modnet version
3.00B and later)
Output Registers
Examples:
The table below show the data types for configuring a serial connection:
Examples
Note: In the Modbus protocol, LONG data types default to a simplified implementation, with a
shortened range of 0 to 655,359,999. To increase the LONG data type to the full range, set
[MODBUS]LongDataType to either 1 or 3.
See Also
Citect.ini parameters are used to tune the performance of the CitectSCADA Modbus driver
and to perform runtime maintenance diagnostics.
You can customize the way CitectSCADA communicates with the Modbus system (and even
individual PLCs) by creating or editing the [MODBUS] section of the citect.ini file for your
project.
There are some common CitectSCADA driver settings as well as custom CitectSCADA Modbus
driver settings.
When CitectSCADA starts at runtime, it reads configuration values from the citect.ini file
that is stored locally. Therefore, any Modbus configuration settings must be included in the
citect.ini file located on the computer acting as the I/O server to the Modbus system.
By default, CitectSCADA looks for the citect.ini file in the CitectSCADA project \bin
directory. If it can't find the file there, it searches the default Windows directory.
See Also
Warning! Citect has determined the default values for these parameters to be the optimal value
for the CitectSCADA Modbus driver. All these parameters default to a value tested to work in
most cases. We do not recommend adjusting these default values except on the direct advice of
Citect Customer Support.
With certain parameters, the Modbus driver can apply different initialization parameter values to
specific I/O devices or groups of I/O devices. For details see Modbus device/group-specific
parameters.
[MODBUS]Block
A value (bytes) used by the I/O server to determine if two or more packets can be blocked into
one data request before being sent to the I/O device. For example, if you set the value to 10 and
the I/O server receives two simultaneous data requests (one for byte 3 and another for byte 8)
the two requests are blocked into a single physical data request packet. This single request
packet is then sent to the I/O device, saving on bandwidth and processing.
[MODBUS]Broadcast
Issues a write request to all controllers on a Modbus network. To use this feature, you must:
1. Define a Modbus or Modbusa I/O device with Address 0 (zero) for the Channel of
interest.
2. Define the value for the BroadcastDelay parameter in the citect.ini file (default is
50ms). This parameter defines the amount of time the driver will delay after submitting a
Broadcast request before it will send another request to the PLCs.
3. Define tags (Coils and Registers) associated with this I/ O device.
4. Implement a CitectSCADA Application that requests writes to the tags (via Cicode,
application display, and so on).
Allowable Values:
0 = Broadcast disabled
1 = write request will be issued
Default Value: 0
Notes
z Requests for Variable Tag READs to the I/O device with the address zero (0) will return a
Driver Error of Unknown Command (driver error 15 decimal).
z Requests for Variable Tag WRITEs to the I/O device with the address zero (0) will be
issued to ALL controllers on the SAME Channel (port) as the I/O device with the assigned
address of zero. The Modbus protocol does not provide a response to broadcast requests
so you should inspect the appropriate coils or registers in each controller to observe
completion of the request.
[MODBUS]BroadcastDelay
Defines the amount of time the driver will delay after submitting a broadcast request before
sending another request to the PLCs.
Default Value: 50
[MODBUS]Delay
The period (in milliseconds) to wait between receiving a response and sending the next
command.
[MODBUS]DoCRC
Enables or disables the Modbus Cyclic Redundancy Check (CRC), a communications error
check. The Modbus driver does a CRC on incoming data and provides a CRC remainder in
outgoing data blocks. In some limited cases, such as the testing of "slave" drivers, it may be
necessary to disable the CRC.
Default Value: 1
The CRC should remain "enabled" under normal circumstances. If the CRC is disabled, no
checks are performed on incoming data and the CRC field in the data transmitted by the driver
remains 0. This will mean the driver cannot detect communication errors between itself and the
I/O device.
[MODBUS]FloatMode
Control byte order for floating point values (the Modbus driver supports floating point values).
Some systems expect to use a different byte order for their floating point data.
Default Value: 0
With this parameter, you can set different values for specific I/O devices or groups of I/O
devices. See Modbus device/group-specific parameters.
[MODBUS]ForceMultiCoilsOnly
Forces the use of only function code 15 (multiple coils) for coil writes.
Allowable Values: 0 or 1:
0 - (function code 5 and 15)
1 - (function code 15 only)
Default Value: 0
[MODBUS]InitType
The type of variable the Modbus protocol tries to read on startup, to allow communication to
start.
Default Value: 2
With this parameter, you can set different values for specific I/O devices or groups of I/O
devices. See Modbus device/group-specific parameters.
[MODBUS]InitUnitAddress
The Modbus driver reads the citect.ini file to determine the correct unit address for
initialization of a PLC. InitUnitAddress is the parameter used to set the unit address.
With this parameter, you can set different values for specific I/O devices or groups of I/O
devices. See Modbus device/group-specific parameters.
[MODBUS]LongDataType
In the Modbus protocol, LONG data types default to a simplified implementation, with a
shortened range of 0 to 655,359,999 - mode 0. Mode 2 has the same range as mode 0, but with
the register order swapped. Mode 1 supports the full LONG range of -2,147,483,648 to
+2,147,483,647. Mode 3 has the same range as mode 1, but with the register order swapped.
Default Value: 0
With this parameter, you can set different values for specific I/O devices or groups of I/O
devices. See Modbus device/group-specific parameters.
[MODBUS]MaxBits
The maximum read size in one request. Decrease the value for non-standard I/O devices that
do not support large reads.
[MODBUS]MaxPending
The maximum number of pending commands that the driver holds ready for immediate
execution.
Allowable Values: 1 to 32
Default Value: 2
[MODBUS]Pad
The number of characters with which to pad protocol messages. The padding characters wake
the radio modem to allow the rest of the message to be transmitted. A value of 20 is
recommended for non-standard I/O devices that operate over radio modems.
Default Value: 0
[MODBUS]PadChar
The ASCII code of the padding character with which to pad protocol messages. The padding
characters wake the radio modem to allow the rest of the message to be transmitted.
[MODBUS]PollTime
The interrupt or polling service time (in milliseconds). Setting the polling time to 0 puts the driver
in interrupt mode.
[MODBUS]PresetMultiRegisterOnly
Forces the use of only function code 16 (multiple registers) for register writes.
Allowable Values: 0 or 1:
0 - (function code 6 and 16)
1 - (function code 16 only)
Default Value: 0
[MODBUS]RegisterBitReverse
Allows reverse interpretation of MSB and LSB in words. The Modbus specification defines bit 1
of a word as the MSB, and bit16 of the word as the LSB. Some devices use a different order,
causing bit 1 of a word to be the LSB and bit 16 to be the MSB.
Default Value: 0
With this parameter, you can set different values for specific I/O devices or groups of I/O
devices. See Modbus device/group-specific parameters.
[MODBUS]Retry
Allowable Values: 0 to 8
Default Value: 0
[MODBUS]SendBCDSwap
Reverses the byte order for BCDs on writes (the Modbus driver supports BCDs). Some systems
expect to use a different byte order for their data; in the case of BCDs, this causes "1234" to be
written to the device as "3412".
Default Value: 1
With this parameter, you can set different values for specific I/O devices or groups of I/O
devices. See Modbus device/group-specific parameters.
[MODBUS]Status
Sometimes you can read data from a device even though the processor module is not running.
In view of this, it can be useful to detect this situation by monitoring a continuously changing
register or a digital. If the register fails to change in a given period or the digital becomes zero,
the processor can be assumed to have stopped running.
If enabled, the Modbus driver will check on startup and approximately every watchtime the
status of a user specified variable in the PLC is changing. If a digital is specified, the value must
always be on otherwise the unit is put offline. If an analog is specified, on startup two
consecutive reads with an interval of 1000ms (specified by [MODBUS]Timeout) must return
different values before the unit can be put online. At every watchtime, if the digital is off or the
analog data does not change from the last value read, the driver returns an error and the unit is
put offline.
status = RawType,BitWidth,UnitType,UnitAddress,UnitAddress
where:
4 = Long 32 = Long
8 = Byte 8 = Byte
Examples
To specify Modbus address 40001 as the analog tag variable which must change to indicate the
device is online, use:
[MODBUS]
status=1,16,3,0,1
To use Modbus address 00001 as the digital tag variable which must remain set to 1 to indicate
the device is online, then use:
[MODBUS]
status=0,1,1,0,16
[MODBUS]StringReverse
Reverse byte order for strings. The Modbus protocol driver supports strings. Some systems
expect to use a different byte order for their data, which in the case of string variables, causes
"ABCD" to appear as "BADC".
Allowable Values: 0 or 1
Default Value: 0 (do not reverse byte order)
With this parameter, you can set different values for specific I/O devices or groups of I/O
devices. See Modbus device/group-specific parameters.
[MODBUS]Timeout
Specifies how many milliseconds to wait for a response before displaying an error message.
[MODBUS]WatchTime
The frequency (in seconds) that the driver uses to check the communications link to the I/O
device.
Allowable Values: 0 to 128 (seconds)
Default Value: 30
The Modbus driver can apply different initialization parameter values to specific I/O devices or
groups of I/O devices. This means the user can specify:
This feature can be implemented in the citect.ini file for the following Modbus parameters:
z [MODBUS]InitType
z [MODBUS]LongDataType
z [MODBUS]StringReverse
z [MODBUS]InitUnitAddress
z [MODBUS]FloatMode
z [MODBUS]SendBCDSwap
z [MODBUS]RegisterBitReverse
To set parameters for a particular port, group, or device, you must create a new section in the
citect.ini file. Label it with the driver name followed by a period (.) character and the name
of the particular port, group, or device you want to specify the parameter setting for.
For example:
Any parameters you then define in the following section of the citect.ini file relate only to
the specified device or device group.
Example
The following Citect INI file format is an example of how the InitType parameter could be
specified differently for different I/O devices communicating using the Modbus protocol.
Assume that two ports are used: PORT1 and PORT2. PORT1 has three I/O devices attached:
Assume that the user has specified that DEV1C and DEV2C belong to GROUPZ. The
citect.ini file contains the following entries:
[MODBUS]
InitType=1
[MODBUS.PORT1]
InitType=2
[MODBUS.PORT2]
InitType=2
[MODBUS.GROUPZ]
InitType=3
[MODBUS.PORT1.DEV1A]
InitType=1
[MODBUS.PORT2.DEV2B]
InitType=4
As the above example shows, there is a hierarchy that determines the outcome of such settings.
In simple terms, specific parameter settings overwrite general level settings. Therefore,
parameters written in the scope of I/O devices will overwrite those set for groups; parameters
set for groups will overwrite global settings, and so on.
See Also
Troubleshooting
Most large projects will suffer bugs in the runtime system. These problems usually have simple
solutions and require only perseverance to solve them.
The following topics describe the CitectSCADA tools provided to help resolve problems with
communication and configuration.
z Hardware alarms
z syslog.dat file
z Driver errors
z Citect Kernel diagnostics
z Maintaining the project database
Hardware alarms
The hardware alarm page is your primary indicator of what is happening in your CitectSCADA
system. If a communication fault occurs, if Cicode can't execute, if a graphics page is not
updating correctly, or if a server fails, this page will alert you to it. Hardware alarms consist of a
unique description and error code.
The hardware alarms do not have detailed information, but point you in the direction of a
problem. For example, if you have a Conflicting Animation alarm, CitectSCADA will not tell you
the cause. You must observe which page causes the hardware alarm, and locate the animations
yourself.
Your system should have no recurring hardware alarms. If, after reviewing all documentation,
you cannot rectify an alarm, contact Citect Technical Support.
syslog.dat file
The syslog.dat file is maintained by runtime CitectSCADA and contains a log of CitectSCADA
system information. The types of information that can be logged to the syslog.dat is extensive:
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 box control whether
logs are made for each I/O device.
CitectSCADA locks the syslog.dat file while running. However, you can still view it by using
the SysLog command in the Kernel. See Citect Kernel diagnostics, and the CitectSCADA User
Guide for details.
Driver errors
CitectSCADA Modbus driver errors can occur when a device using Modbus fails to respond, or
is disconnected or offline, or returns an error itself. Error codes are listed below.
The Modbus driver can log combinations of trace levels across different categories. For more
information, see Citect Kernel diagnostics.
z Generic errors, which are hardware errors 0-31 and common to all protocols. Some
generic errors are common to all protocols. Sometimes only the generic error is available,
though often both the generic error and a specific error are given.
z Specific errors, which can be unique and therefore cannot be recognized by the
hardware alarm system. The drivers convert their specific errors into generic errors that
can be identified by the I/O server. For example, when a driver has a fault, there is often
both a protocol-specific error and a corresponding generic error.
When a hardware error occurs, CitectSCADA generates an alarm and displays the alarm on the
Hardware Alarm page (in the alarm description of the hardware alarm). To see the error number,
make sure you have Alarm Category 255 defined with a display format that includes
{ErrDesc,15} {ErrPage,10}.
The following errors, listed in (hexadecimal) sequence, are specific to this protocol.
CitectSCADA displays the error number and description for common protocol-specific errors.
Uncommon errors are not contained in the CitectSCADA error database, in which case
CitectSCADA only displays the error number.
You might need additional information to rectify an error. This information should be detailed in
the documentation that accompanied the I/O device (or network). If, after reviewing all
documentation, you cannot rectify an error, contact Citect Technical Support.
The Citect Kernel window diagnostics framework (commonly referred to as the Kernel), is the
primary gateway into the internal workings of CitectSCADA at runtime, and is provided for
diagnostics and debugging purposes only.
The Kernel can display several different diagnostic windows each displaying an active view into
the workings of the CitectSCADA runtime system. Each window is displayed when selected from
the Citect Kernel View menu.
For details about the Citect Kernel, refer to the CitectSCADA User Guide.
Warning! Use the Kernel window with care: once in the Kernel, you can execute any Cicode
function with no privilege restrictions. A person using the Kernel has total control of
CitectSCADA (and subsequently your plant and equipment).
You need to configure your CitectSCADA project to provide run-time access to the Kernel
diagnostics window. You can do one or both of the following:
1. In the Citect Explorer menu, select View | Configuration File. This launches Windows
Notepad and loads and displays the citect.ini file for manual editing. (The
citect.ini file is located in the Windows folder, typically in C:\WINDOWS or
C:\WINNT.)
2. Scroll down to the [Debug] category, and edit the section to include the following
parameter:
[DEBUG]
Kernel=1
3. Save and Close Notepad.
This parameter causes the automatic display of the Citect Kernel window diagnostics framework
upon startup of CitectSCADA. Swap to it to view what's happening inside CitectSCADA at
runtime.
To add the Kernel menu item to the CitectSCADA runtime Control menu:
1. In Citect Explorer or Project Editor, launch the Computer Setup Wizard and select
Custom mode:
2. Click Next until you reach the Security Setup - Control Menu page:
3. Check the Kernel on menu option and click Next until finished.
At runtime, you can display the Kernel window by selecting Kernel from the Control menu (top-
left corner) of CitectSCADA. If you do not have a Title Bar displayed in your runtime project, you
can access the Control menu by pressing Alt + Spacebar (if the Alt-Space enabled option is
selected on the Security Setup - Keyboard page).
Warning! You should clear these options before handover to prevent accidental or unauthorized
use of the Kernel in the delivered system.
The key diagnostic windows included with the Kernel for testing I/O device communications are
the Main window, the I/O Devices window, and the Driver Statistics window:
z The Citect Kernel Main window displays the diagnostic messages a line at a time
indicating the current CitectSCADA startup operation and status. When running, the Main
diagnostics window continues to report changes in the status of the I/O devices.
z The Citect Kernel Unit window displays the current status of all devices defined in the I/O
device database.
z The Citect Kernel driver window displays information about each driver in the
CitectSCADA system. This window is only displayed if the computer is configured as an
I/O server with physical I/O devices attached.
After your I/O devices are properly configured, the Main window is particularly useful to check
that all of your I/O devices come online correctly when CitectSCADA is started.
First the ports are initialized, then the I/O device is brought online. If there is a problem,
CitectSCADA display the message "PLC not responding", "I/O Device Offline" or similar.
Some I/O devices might take two attempts to come online. If so, CitectSCADA waits (usually 30
seconds) and tries again. If your I/O device does not come online after the second attempt,
check your configuration (at both ends) and the network in between.
The Kernel Main diagnostic window contains legacy behavior from early versions of Microsoft
Windows. It has no scroll bar, so as new messages are added a line at a time to the end of the
displayed list of messages, and the window is filled, the oldest message (at the top of the
window list) scrolls out of view and is lost. However, you can view this information using the
syslog.dat file.
The Unit diagnostics window, launched via the Page Unit Kernel command, displays the current
status of all devices defined in the I/O device database. In this window, use the Page Up or
Page Down keys to browse available devices.
The important values to check to confirm that communications with the I/O device are enabled
and running are the Server Status and Client Status fields. When the I/O device is online,
these both display "RUNNING".
For details about the fields displayed for each I/O device in the Unit diagnostics window, refer to
the Citect SCADA User Guide.
The Citect Kernel Driver window, launched via the Page Driver Kernel command, displays
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. Refer to the CitectSCADA User Guide for details.
Over time with editing, the project database underlying a project can become fragmented and
problematic. During project development you should periodically clear out all duplicated records
and any orphaned ones.
Sometimes orphaned records from a previous I/O server are left behind in the database files. As
all the forms are indexed on the I/O server name, you can use the scroll bar to quickly navigate
to the end of the current range of records for a particular I/O server and examine the last few
and next few records to validate that they should be there. If you find extra (unwanted) records,
delete them.
You should also make sure that there are no duplicated records. Use the record search facility
to search for duplicate entries of devices that are causing unexplained communication errors. If
you find extra (unwanted) records, delete them.
Once you have deleted orphaned and duplicated records, pack the project. Packing the
database removes deleted records, and re-indexes the database. To pack the project
databases, from the File menu in Citect Project Editor, choose Pack.