SYS600 - System Objects
SYS600 - System Objects
5
System Objects
Document ID: 1MRK 511 667-UEN
Issued: February 2023
Revision: A
Product version: 10.5
Table of contents
Section 1 Copyrights....................................................................................................21
Section 3 Introduction..................................................................................................25
3.1 About this section................................................................................................................ 25
3.2 System objects.................................................................................................................... 25
3.3 Base system objects........................................................................................................... 25
3.4 Communication system objects...........................................................................................25
3.5 Attributes............................................................................................................................. 25
3.6 Using system objects in SCIL..............................................................................................26
7.7.5.3 FILE_FUNCTIONS_CREATE_DIRECTORIES............................................................89
7.7.5.4 SETTING_LA_AND_AG_DOES_NOT_ALARM.......................................................... 89
7.7.5.5 NO_QUALITY_ATTRIBUTE_SEMANTICS..................................................................90
7.7.5.6 NO_ALIAS_CHECKING...............................................................................................90
7.7.5.7 NO_ALARM_BY_OR_AND_OF...................................................................................90
7.7.5.8 DONT_RECALCULATE_AL_AFTER_ALARM_BLOCKING........................................ 91
7.7.5.9 CREATE_VERSION_1_FILES.....................................................................................91
7.7.5.10 KEEP_FILE_VERSION_1_DATABASE_FILES........................................................... 91
7.7.5.11 DEFAULT_DAYLIGHT_POLICY_IS_CALENDAR....................................................... 91
7.7.5.12 844_COMPATIBLE_MIRRORING................................................................................92
7.7.5.13 CREATE_VERSION_2_SCIL_DATABASES................................................................92
7.7.5.14 DO_NOT_SYNCHRONIZE_PICTURE_UPDATE........................................................ 92
7.7.5.15 COUPLE_AUDIO_ALARMS_AND_PRINTOUTS........................................................93
7.7.5.16 ALLOW_CONFLICTING_F_ATTRIBUTE_NAMES......................................................93
7.7.5.17 DONT_CAUSE_TAKEOVER_ON_FATAL_ERRORS.................................................. 93
7.8 Application diagnostic attributes..........................................................................................93
7.8.1 DI Application Diagnostic Interval.............................................................................94
7.8.2 DS Application Diagnostic Status.............................................................................94
7.8.3 DT Application Diagnostic Timeout.......................................................................... 94
7.9 Mirroring attributes.............................................................................................................. 95
7.9.1 Mirroring configuration.......................................................................................................95
7.9.1.1 EP Event Queue Overflow Policy........................................................................95
7.9.1.2 HE Host Enabled.................................................................................................95
7.9.1.3 IE Image Enabled................................................................................................96
7.9.1.4 IS Image Stations for System Messages............................................................ 96
7.9.2 Mirroring diagnostics......................................................................................................... 96
7.9.2.1 HD Host Diagnostics........................................................................................... 96
7.9.2.2 ID Image Diagnostics.......................................................................................... 97
7.10 Miscellaneous APL attributes.............................................................................................. 97
7.10.1 AD Application Self-Diagnostics...............................................................................97
7.10.2 CX Comment Text.................................................................................................... 98
7.10.3 EY Emergency Password.........................................................................................98
7.10.4 SV System Variables................................................................................................98
7.10.5 UV User Variables.................................................................................................... 99
14.2.2 Function...........................................................................................................................155
14.3 Communication system object types.................................................................................156
14.3.1 Communication system object names.............................................................................156
14.3.2 NOD (NET) objects......................................................................................................... 157
14.3.3 APL objects..................................................................................................................... 158
14.3.4 STA objects..................................................................................................................... 158
14.3.5 PRI objects......................................................................................................................158
14.4 Defining communication system objects........................................................................... 158
14.4.1 Principles.........................................................................................................................158
14.4.2 Initialization file of PC-NET units..................................................................................... 159
14.4.3 On-line configuration....................................................................................................... 159
14.4.4 Required Object Definitions.............................................................................................159
14.5 Attributes........................................................................................................................... 160
14.5.1 General............................................................................................................................160
14.5.2 Attribute access...............................................................................................................160
16.6.1 AC ACE..................................................................................................................215
16.6.2 AS ACE State.........................................................................................................215
16.6.3 CL Connection Time Limited.................................................................................. 215
16.6.4 CN Connection.......................................................................................................216
16.6.5 CS Connected Station............................................................................................216
16.6.6 CT Connection Time.............................................................................................. 216
16.6.7 DD Radio Disconnection Delay.............................................................................. 217
16.6.8 MC Modem Command........................................................................................... 217
16.6.9 PU Pulse Dialing.................................................................................................... 217
16.6.10 RC Remote Calls Enabled..................................................................................... 218
16.6.11 RW Radio Connection Wait Time...........................................................................218
16.6.12 SR ACE AT S Register...........................................................................................218
16.7 LON configuration attributes..............................................................................................219
16.7.1 NC Network Variable Configuration........................................................................219
16.7.2 XA Extended Address Table...................................................................................220
16.8 Miscellaneous NET line attributes..................................................................................... 221
16.8.1 Diagnostic counter...........................................................................................................221
16.8.1.1 DC Diagnostic Counters....................................................................................221
16.8.2 Clock synchronization attributes......................................................................................223
16.8.2.1 LK Link Type..................................................................................................... 223
16.8.2.2 SF Sync Format................................................................................................ 224
16.8.2.3 SS Sync Status................................................................................................. 224
Index.....................................................................................................................................309
The information in this document is subject to change without notice and should not be construed as
a commitment by Hitachi Energy. Hitachi Energy assumes no responsibility for any errors that may
appear in this document.
In no event shall Hitachi Energy be liable for direct, indirect, special, incidental or consequential
damages of any nature or kind arising from the use of this document, nor shall Hitachi Energy be
liable for incidental or consequential damages arising from the use of any software or hardware
described in this document.
This document and parts thereof must not be reproduced or copied without written permission from
Hitachi Energy, and the contents thereof must not be imparted to a third party nor used for any
unauthorized purpose.
The software or hardware described in this document is furnished under a license and may be used,
copied, or disclosed only in accordance with the terms of such license.
Trademarks
ABB is a registered trademark of ABB Asea Brown Boveri Ltd. Manufactured by/for a Hitachi Energy
company. All other brand or product names mentioned in this document may be trademarks or
registered trademarks of their respective holders.
Guarantee
Please inquire about the terms of guarantee from your nearest Hitachi Energy representative.
List of Third Party Copyright notices are documented in "3rd party licenses.txt" and other locations
mentioned in the file in SYS600 and DMS600 installation packages.
This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit.
(https://www.openssl.org/). This product includes cryptographic software written by Eric Young
([email protected]). This product includes software written by Tim Hudson ([email protected]).
This product includes software developed by Computing Services at Carnegie Mellon University
(http://www.cmu.edu/computing/).
This publication includes warning, caution and information symbols where appropriate to point out
safety-related or other important information. It also includes tips to point out useful hints to the
reader. The corresponding symbols should be interpreted as follows:
Warning icon indicates the presence of a hazard which could result in personal injury.
Tip icon indicates advice on, for example, how to design a project or how to use a certain
function.
Although warning hazards are related to personal injury, and caution hazards are associated with
equipment or property damage, it should be understood that operation of damaged equipment could,
under certain operational conditions, result in degraded process performance leading to personal
injury or death. Therefore, comply fully with all warnings and caution notices.
This manual is intended for installation personnel, administrators and skilled operators to support
installation of the software.
• The words in names of screen elements (for example, the title in the title bar of a dialog, the
label for a field of a dialog box) are initially capitalized.
• Capital letters are used for file names.
• Capital letters are used for the name of a keyboard key if it is labeled on the keyboard. For
example, press the CTRL key. Although the Enter and Shift keys are not labeled they are written
in capital letters, for example, press ENTER.
• Lowercase letters are used for the name of a keyboard key that is not labeled on the keyboard.
For example, the space bar, comma key and so on.
• Press CTRL+C indicates that the user must hold down the CTRL key while pressing the C key
(in this case, to copy a selected object).
• Press ALT E C indicates that the user presses and releases each key in sequence (in this case,
to copy a selected object).
• The names of push and toggle buttons are boldfaced. For example, click OK.
• The names of menus and menu items are boldfaced. For example, the File menu.
• The following convention is used for menu operations: Menu Name/Menu Item/
Cascaded Menu Item. For example: select File/Open/New Project.
• The Start menu name always refers to the Start menu on the Windows Task Bar.
• System prompts/messages and user responses/input are shown in the Courier font. For
example, if the user enters a value that is out of range, the following message is displayed:
Entered value is not valid.
The user may be told to enter the string MIF349 in a field. The string is shown as follows in the
procedure: MIF349
• Variables are shown using lowercase letters: sequence name
The purpose of this section is to introduce the role the system objects have in the system. It
introduces the system objects and their attributes.
System objects are programmable units that specify the system configuration and communication of
the SYS600 distributed system.
• Base system objects (B), which define the configuration for the base system.
• Communication system objects (S), which define the configuration and communication
properties for the process communication system.
The base system objects and the communication system objects, along with the configuration data of
the communication modules determine the SYS600 configuration. The communication system
objects give the communication units an image of the devices connected to them. The base system
objects give the SYS600 main program an image of the devices and the software used by the base
system.
When connecting a device to the SYS600 system, some configuration is required either in base
system configuration file or in one or more of the NET configuration files or in both places.
Connecting a station, for example, requires both a base system and a communication object
definition.
Base system objects define the physical and logical connections and the software and hardware
parameters of the base system and its applications. They also define the logical connections to NETs
and other base systems and their applications. Base system objects are also used for modification of
the base system configuration. For instance, they are used for modification of logical connections to
printers, NET communication units and other base systems, momentary connections between
different applications and so on.
Communication system objects and their attributes specify NET configurations and handle process
communication. They give the NET unit an image of the communication lines. For instance, they
have the information on which protocol is used on the line, baud rates, way of communication, where
to forward information coming from the line and so on. They also give an image of connected
devices, such as other communication units, base systems, stations and printers. Each process NET
unit has its own configuration file containing a SCIL program.
The properties of a part of a system are described by system object attributes. For instance, the baud
rate of a communication line, the station address of a process station and memory allocations in the
base system are stored in a corresponding system object attribute. Normally, a system object has
several attributes and, thus, contains several types of data. The attributes are identified by two letter
names, combined of letters A ... Z.
System object attributes, which specify the properties of a part of the system and affect the system
configuration, are called configurable attributes. Other attributes, called dynamic attributes, provide
information related to a part of the system or may cause an immediate action in its operation. A
communication system object of type SPA (a process station), for instance, has the following
configurable attributes:
The same SPA object can be accessed by the following dynamic attributes:
State, ST = 1
Update points, UP = 1
Send Message, SM = "message"
In SCIL, the system objects are accessed through their attributes. Using the object notations, which
refer to attributes, the system objects can be supervised and controlled with SCIL programs.
Changing the value of an attribute may cause an immediate reconfiguration.
In the object notation the attribute is specified with the object name, the object type and the attribute
name. For example, the station address of a SPA object defined as SPA3 is accessed by the
notation:
SPA3:SSA
where
'SA' Is the attribute name. The S after the colon indicates that the object is a communication system
object.
name:{application}type{attribute}{index}
where
The parameters within curly brackets may be omitted. No space is allowed between the parameters
in the object notation. The parameters are detailed below.
System objects have predefined names. The name of a system object is composed of three
predefined letters, A - Z, and an ordinal number, which is freely chosen. The three letters in the name
specify which type the object represents, the number separates the object from others representing
the same type. For example, SYS denotes base systems, APL applications, NOD nodes, PRI
printers, and STA stations. APL3 denotes application 3, NOD4 node 4, STA5 station 5, etc.
The object number identifies the object within one application where the notation is used. The same
physical object can be known under different object numbers within different applications. However,
the object numbers of NOD objects must be unique within the entire SYS600 distributed system.
Alternatively, a freely chosen alias name may be given for a system object by specifying its BN
attribute, see Section 5.
The predefined base system object names are listed and described in Section 5 and the
communication system objects in Section 14.
Application stands for a logical application number. The logical application number is the application
number as known to the present application (according to the application mapping, the AP attribute,
see Section 7). A prerequisite for using application number is that the applications recognize each
others through the application mapping.
Generally, there is no need to include application number in the system object notation. Mostly, an
application number is included when access to base system objects defined in another base system
is desired. Application number is also needed when accessing communication system objects from
an application, unknown (not defined) to the NET from which the objects are accessed.
The attribute represents the value or feature to be read or written with the object notation. It is named
by an attribute name, which is a combination of two letters, A ... Z. The attribute determines the data
type (see the Programming Language SCIL manual) and the value of the entire object notation.
A communication system object notation must always contain an attribute. The base system object
notation can be used without an attribute only when creating a new object.
Indices are integer numbers, which are used together with some attributes. As a rule, the indices
refer to the elements of an attribute of vector type. The actual attribute determines the data type of
the elements.
In one case (the STAn:SME attribute), the index refers to an address. In this case the index cannot
be given by an expression, it must be given as an octal number.
The indexing of the system object attributes is detailed in the attribute descriptions.
System object notations can be used in SCIL statements and expressions. When used in
expressions, the value of the attribute in the notation replaces the entire object notation. It can, for
example, be part of a window definition expression, entailing that object data is shown in the window.
It can be included in data object definitions or in conditional expressions, etc. See the Programming
Language SCIL manual.
Section 5.2 Base system object types: An overview of the base system object types.
Section 5.3 Common naming attributes: Attributes common to all base system object types.
Section 5.4 Defining base system objects: The principles for defining base system objects, the start-up
configuration, on-line configuration, attribute access, etc.
The base system object names consist of a predefined three-letter descriptive name and a number
(n), which distinguishes units of the same type:
SYS The base system itself. This object has no number, as there can be only one: the current base
system.
APLn Applications. 'n' = 1 ... 250
MONn Monitors. 'n' = 1 ...100
PRIn Printers. 'n' = 1 ... 20
LINn Links: connections to adjacent nodes. 'n' = 1 ... 20
NODn Nodes: base systems and communication modules. 'n' = 1 ... 250
STAn Stations: Remote Terminal Units, PLCs, Protective Equipment, etc. 'n' = 0 ... 50000
STYn Station type defining objects, 'n' = 1 ... 33
The base system recognizes the individual objects using the number 'n'. Henceforth, the number is
referred to as object number. The base system objects and their interconnections are illustrated in
Figure 1.
In addition to the naming convention above, a user-defined name may be given to any base system
object by specifying its name attribute BN. See Section 5.3.
The SYS object corresponds to the actual base system. The SYS object attributes specify the base
system properties, such as:
PCs running
Semi-graphic workstations
X software
Local workstations
MON MON
MON MON
LIN
LIN
Common RAM
PRI or Integrated link
Standalone frontend
NOD
Process NOD NOD
communication DCP-NET DCP-NET
Internal
systems DCP-NET NOD
or PC-NET
Printer
PRI
MON
Remote workstations
MON
Base_system_objects.CNV
GUID-ADC75407-CAE4-4D51-AE1D-FF9203D26F74 V1 EN-US
Figure 1: The base system objects defined in the shaded SYS600 base system
Each application known to base system must be defined as an APL object. This comprises not only
all applications situated within the base system in question, but also all those applications in other
base systems that will communicate with the applications in the base system.
The APL object attributes specify the properties of the applications, such as:
• Application type: Local or external (in the same or in another base system)
• Application state: HOT, WARM or COLD
• Logical connections to peripherals and stations (device mapping)
• Logical connections with other applications within the same base system and in other base
systems (application mapping)
The MON objects correspond to the SYS600 monitors that the operator opens to view an application
on a physical monitor screen. When an operator opens a SYS600 monitor, he reserves a MON
object as a logical monitor.
Each printer used by the base system must be defined as a PRI object, including printers that are
connected to NET units, LAN or other base systems. The PRI attributes specify the properties of the
printers, such as:
The LIN objects define the links between the base system and adjacent nodes (base systems and
communication units). The link object attributes specify the link properties, such as:
Each base system and NET unit known to the base system must be defined as a NOD object,
including those which are not directly connected to the base system. The NOD attributes specify the
addresses and properties of the nodes. The NOD object numbers are global and must be unique
within the entire SYS600 network.
The STA objects correspond to the stations known to the base system, when the term 'station'
denotes process control units such as Remote Terminal Units (RTUs), Protective Equipment, Central
Stations and protocol converters. The STA attributes specify the station properties that are relevant
to the base system, for example:
• Type of station: S.P.I.D.E.R. RTUs, stations on ANSI lines, SPA units, P214, etc.
• Node number of the NET unit to which the station is connected and the device number of the
station as known by that NET unit (system object number).
Each station that will be known to the base system must be defined as a STA object in the base
system, unless it is of the STA default type connected to the default NET unit.
By using the STY objects, the system engineer can define station types that are not predefined. A
requirement is that the new station type can use an existing station interface and that the protocol
has been implemented in NET unit.
The following three attributes are used to name a base system object and query the object type and
number of a named base system object. Each base system object, regardless of its type, has these
attributes. Consequently, they are described only once here.
The value of this attribute can be used in SCIL programs as an alias name for the object. The names
must be unique, there cannot, for instance, be a STA and a NOD object by the same name. For STA,
NOD and PRI objects, this name can also be used as an alias name of the corresponding
communication system object.
Example:
The user wants to create a STA object by number 5 and name "PICCADILLY_STATION". The object
can be created in either of the following ways:
Now the object may be addressed by either STA5:B or PICCADILLY_STATION:B. Also, the
corresponding communication system object STA5:S may be addressed by
PICCADILLY_STATION:S.
The base system objects are defined with SCIL using the SCIL command #CREATE (see the
Programming Language SCIL manual).
The base system objects cannot be modified with #MODIFY nor deleted with #DELETE.
During start-up, the base system objects are created and their attributes are given values with the
configuration file SYS_BASCON.COM. The main program at each base system start-up
automatically executes this text file containing SCIL commands. If the file is missing or erroneous,
the system cannot be started.
The base system configuration file SYS_BASCON.COM can be edited with a text editor both off-line
and on-line. The modifications in SYS_BASCON.COM are taken into use when the system is started
next time.
With some restrictions, the base system configuration can be modified and extended during
operation directly with SCIL. For example, it can be modified with command procedures started by
the initial event channels APL_INIT_1 or APL_INIT_2 (see the Application Objects manual), or with
the Base System Configuration tool. These online changes are not stored unless they are included in
the base system configuration file SYS_BASCON.COM.
The base system object definitions required for various types of system set-ups are detailed in the
System Configuration manual.
All attributes can be read with SCIL (the object notation), but all attributes cannot be written. The
main access levels are:
• Read-only: The attributes that cannot be written in any circumstances or given values when the
object is created with #CREATE.
• Read-only, configurable: The attributes that can be given values with the #CREATE command,
but the value cannot be changed later with #SET.
• Not configurable, otherwise no restrictions: The attributes cannot be given values with
#CREATE command, otherwise the attribute can be read and written without restrictions.
• Read, conditional write: Attributes that can be given values with #CREATE and which can be
changed with #SET provided that the object is in off state (TT = "NONE").
• Write-only: The attribute cannot be read, only written.
• No restrictions: Attributes that can be both read and written without restrictions.
Section 6.2 General: the definition of SYS objects and the SYS object notation.
Section 6.3 Basic SYS attributes:
• Common naming attributes (BN, BT, BM)
• Basic Configuration Attributes (ND, NN, SA, WA)
• Hardware and Software Information (HW, OM, ON, OS, OV, PR, RD, RE, RP, RS)
• Communication Attributes (DN, DS, ER, TI)
• Time Handling Attributes (CT, TF, TM, TR, TS, TZ)
• Memory Handling Attributes (FS, ME, MF, MP, MS, MU, RC, RU)
• Global Paths and Representation Libraries (PH, RL)
• Security Attributes (HD, ID)
• Application Information (AL, PA)
Each base system requires a corresponding SYS object definition. The SYS object must be defined
as the first base system object in the SYS_BASCON.COM file. Otherwise, the base system cannot
be started.
The SYS object attributes are accessed from SCIL with the notation:
GUID-70977DBA-E571-4498-84B5-C808759546CA v1
SYS:Bat
where
The SYS object attributes of another base system can be accessed with the notation:
GUID-57A47C1C-D0B3-4FB1-91A9-6439FB36310C v1
SYS:mBat
where
'm' Is the number of an application in the other base system as known to the present application
(according to the application mapping, see Section 7).
These attributes define the node number and address of the base system. ND, NN and SA are
obligatory for all base systems.
The node number of the base system computer. The number must be unique among all the base
system computers and communication units connected to the network.
The LAN node name of the computer (host name). NN attribute may, for example, be used to identify
the computers in a hot stand-by system.
The station address of the base system. The station address is used by the SYS600 internal protocol
ACP. It is a number, which must be unique among all nodes, for example base systems, and
communication units throughout the entire SYS600 network.
Visual SCIL Integration is enabled or disabled. The value can be changed in the SYS_CONFIG.PAR.
For more information, see the Installation and Administration Manual.
The web address of the base system. The web address is used by web user interfaces connecting to
the SYS600 base system.
The base system computer hardware, the operating system or the SYS600 kernel settles these
attributes. They are set automatically and cannot be configured or changed.
The minor version number of the operating system running in the base system computer.
See the OV attribute (Operating System Version) for more details of the version numbering.
The name of the operating system running in the base system computer.
The version number of the operating system running in the base system computer.
The following table summarizes the OV and OM values for current Windows versions that are
running SYS600:
Version OV OM
NT 4.0 4 0
2000 5 0
XP 5 1
Server 2003 5 2
Vista, Server 2008 6 0
Windows 7, Server 2008 R2 6 1
Windows 8, Server 2012 6 2
Windows 8.1, Server 2012 R2 6 3
Windows 10, Server 2016, Server 2019, Windows 11, Server 2022 10 0
To find the combined value of OV and OM as a text string, see the SCIL function OPS_NAME in the
Programming Language SCIL manual.
The name of the running operating system is given by attribute ON, see above.
The licensed revision of the product can be read from this attribute.
Date of the running SYS600 kernel software build (hours, minutes and seconds are all zeroes).
The revision number of the running SYS600 kernel software, for example 9.2.
The following attributes specify the communication properties of the base system.
The node number of the NET unit that will be regarded as default NET unit. The default NET unit
must be directly connected to the base system or connected through LAN. A system object notation
where the NET number is not explicitly mentioned, and which has no corresponding base system
object, is sent to the default NET unit.
Recommendation: Set the DN attribute to the NET number to which most of the stations will be
connected.
Example:
The system object notation STA2:SIU is routed to the default NET unit, unless the base system
contains a STAn:B object referring to the same station according to the device mapping. See the APL
attributes in Section 7.
The default value for the station type, the attribute STAn:BST, if not explicitly defined (see the STA
attributes in Section 11 ).
Enabling and disabling message routing. The base system has the capability to route messages to
other nodes, see the example in Figure 2.
If routing is enabled (ER = 1) and the base system receives a message with another destination
address than the own station address, the message is routed to the destination node. If the
destination address is unknown to the base system, the message is destroyed.
GUID-3E8AFBF4-4579-4AA1-A7B3-9604CED06644 V1 EN-US
Figure 2: If routing is enabled in base system 1 it can route messages addressed to base
system 2
The maximum time the base system is waiting for a response after it has sent a message to a
connected node. When this time has expired, an error status is produced. This timeout can be
temporarily and locally changed by the SCIL function TIMEOUT (see the Programming Language
SCIL manual).
OPC clients can use this attribute as a heartbeat signal of the base system. It may be subscribed to
using update rate 0.
The TF attribute affects several time functions (such as TIME, TIMES, DATE and TIME_SCAN) and
the #SET_TIME command, the Programming Language SCIL manual.
The time master of synchronization of the base system time. The attribute specifies who is
responsible for maintaining time zone information required to convert time values read from an
external time source to the time reference of the base system.
If TM is set to "APL", the application must set SYS:BTZ (Time Zone) to match the current bias
between the time reference of the base system and the time source (PC32 or PC-NET). SYS:BTZ is
added to the time received from the external time source to calculate the system time. SYS:BTS
(Time Season) is set according to PC31/PC32 clock, if present, otherwise it must be set by the
application if used by the application.
If TM is set to "SYS", SYS:BTZ and SYS:BTS are not set nor used by the base system. SCIL
function LOCAL_TIME_INFORMATION may be used to obtain time zone related information from the
system. The time received from the external time source (if any) is used to set the fraction of semi-
hour (minutes 0 ... 29, seconds and milliseconds) of the system clock only.
When the base system runs in local time, all the time attributes of objects and time arguments and
return values of functions operate in local time. When it runs in UTC time, they operate in UTC time.
The time reference of the system may be changed (SYS600 must be restarted, however). After the
change, all the attributes in the databases are shown in the new time reference.
If TR is set to "UTC" and the base system is synchronized by PC-NET, the TM (Time Master)
attribute should be set to "SYS" to enable different time references of the programs.
Before starting to run SYS600 in UTC time, the used application software, including COM
500 and LIBxx applications, must be checked for the support of this feature. Also, if the
base system is connected to another SYS600 base system, they should both run in UTC
time or the application software used to do APL-APL communication must be checked for
the support of different time references of the base systems.
The time season (summer time/winter time) of the PC31/32 clock, if such is used for synchronizing
the base system time. The TS attribute is updated from the PC31/PC32 clock each time a valid time
(valid according to the status register of the clock board) is read from the clock. The attribute can be
set by SCIL if there is no external clock.
Hours to add to the time given by an external time source to get the system time. See attribute TM
for details.
These attributes allow the programmer to check the free and used memory space, to specify memory
flush, and to change the memory space reserved for application pictures and report objects in the
main memory.
Specifies in which situations the base system will force the operating system to flush (write) buffered
file modifications out to disk. The purpose of the forced flushing is to guarantee file system integrity in
case of a hardware or operating system software failure.
This attribute is obsolete and likely to be removed in some future release. When a
modern operating system and modern computer hardware is used, the value "NEVER"
should always be used. The other values do not significantly improve fault tolerance, they
just degrade the performance.
Supervision of the global memory pool may be enabled/disabled by SCIL. This attribute is
implemented to control the supervision.
Setting ME to 1 always re-enables global memory pool events (even if the old value was also 1).
The number of free global memory blocks in each size class. The size of the blocks in each class is
defined by the MS attribute, see below.
Example:
The sizes of memory pools. The sizes can be changed in the SYS_CONFIG.PAR. For more
information, see the System Configuration manual.
The attributes PICO, REPR and PRIN are reported for compatibility. Their value always equal to
attribute PRIVATE.
The size of the memory blocks in bytes. The memory blocks are grouped into 26 size classes. This
attribute contains the size of the memory blocks in each class.
MS is a vector of 26 elements, where each element represents a certain block size. MF (see above)
tells how many blocks of each class are free. MU (see below) tells how many blocks of each class
are used.
The number of global memory blocks used in each size class, see MS above.
Example:
The maximum memory space allowed for the report cache, that is, the report database stored in
RAM. When the occupied space in the report cache memory (the RU attribute) rises to this value, the
oldest report objects are dropped out. Only report objects that are not running are kept in the report
cache.
The cache memory space used by report objects in the primary memory. When the RU attribute rises
over the RC attribute, the oldest report objects are dropped out from the report cache.
Base system object attributes PH and RL support system wide and application specific paths and
representation libraries.
Defines the global paths of the system (paths common to all the applications).
The attribute names of the value define the path names and attribute values define the directories
included in the path. The attribute value may either be a text value defining one directory or a text
vector defining one or more directories.
Defines the global representation libraries of the system (libraries that are common to all the
applications).
The attribute names of the value define the logical representation library names and attribute values
define the library files included in the logical library. The attribute value may be either text value
defining one file or a text vector defining one or more files.
The security attributes are used to configure and display the security settings of the base system.
Attribute REQUIRE_ENCRYPTED_ACP takes one of three keyword values. Value "NONE" accepts
all unsecure connections, value "NETWORK" (default value) allows unsecure connections from the
local host and value "ALL" requires encryption from all connections. Note that even if the value is
"NONE", unsecure connection is rejected from the node that has earlier used encrypted
communication. When this attribute is set to "NETWORK" or "ALL", neither APL-APL communication
(including mirroring) with a pre-9.4 SYS600 installation nor communication with an External Data
Access Server running in another computer works. When the attribute is set to "ALL", communication
with an External Data Access Client does not work at all. Regardless of the attribute value a secure
communication is established between the nodes, if both nodes are capable to do so.
attribute is FALSE, ACP communication is allowed from and to any IP address. Whitelisting is node-
specific and defined by the WL attribute of node objects (NODn:BWL).
In SYS_BASCON.COM, it is enough to specify only the exceptions to the default values, for example
HD = LIST(REQUIRE_KNOWN_ACP_CERTIFICATE = TRUE)
The following attributes contain information about the configured applications in the system.
Data type: Vector of list type elements, one for each local application.
Value: Attributes of each element:
AN Application number, 0 ... 250
NA Name of the application
SA Web address of the shadowing partner computer
AS Application state ("COLD", "WARM" or "HOT")
SS Shadowing state ("NONE", "RECEIVE",
"WARM_SEND" or "HOT_SEND")
SP Shadowing phase ("NONE", "TO_WARM_SD",
"WARM_SD", "TO_HOT_SD", "HOT_SD",
"TO_WARM_RC", "WARM_RC", "TO_HOT_RC" or
"HOT_RC")
IS_NEW Value is TRUE, if the application is brand new, i.e.
not yet logged-in by a user. If the application is not
new, this attribute is totally omitted from the list.
ANONYMOUS_LOGIN Value is TRUE, if anonymous logins are enabled,
otherwise FALSE
Access: Read-only
Defines the primary application of the system. The primary application works as the default
application of the SCIL API interface and as the default application of the OPC Server name space.
This attribute is useful especially in Hot Stand-by systems, where the main application is typically not
started by SYS_BASCON.COM.
Shadowing is used in Hot Stand-by base system configurations. It means that all disk and real time
database updates of the sending (hot) application are automatically copied to an identical receiving
(cold) application. As a rule, the sending and receiving applications are in different base systems
(base system computers). Shadowing is possible only between base systems connected via the
same LAN. Mainly, shadowing is controlled by the APL base system objects, see the Shadowing
attributes in Section 7.
The DDE server functionality, if used, enables external software applications (other than SYS600) to
access the SYS600 applications within the base systems. The following attributes specify the DDE
server functionality of the base system.
In operating systems before Windows Vista, there is one global DDE server in the base system. In
Windows Vista, Windows Server 2008 and later, a DDE server serves one desktop (Windows
session) only.
In pre-Vista operating systems, the DDE server attributes are truly global and the server may be
started in SYS_BASCON.COM.
In Windows Vista and later, only the DDE server attributes of the own session are seen. The server
must be started by executing a SET command within the session (#SET SYS:BDE = 1).
Enabling and disabling the DDE Server capability in SYS600. If disabled, applications within the base
system cannot be accessed by DDE.
The values of the five diagnostic counters, that count certain events in the DDE server
communication.
In Windows Vista and later, the value is 1 if the DDE server is started in the session.
In earlier operating systems, the value is 1 only if the server is started and there is a logged-in user in
the base system computer.
The OPC Server attributes are used to start, diagnose and stop the SYS600 OPC Data Access
Server.
Setting this attribute to 1 starts the SYS600 OPC Data Access Server. If set in SYS_BASCON.COM,
the OPC Server is started immediately after the applications have been started.
OPCS_SERVER_ALREADY_RUNNING (5510): Only one OPC Server is allowed. If this error occurs
when opcs.exe is not running, the server has terminated abnormally. The attribute should be set to 0
first and then to 1 again.
OPCS_SERVER_START_TIMEOUT (5509): For an unknown reason, the server did not initialize in a
reasonable amount of time.
These attributes describe the hardware of special equipment within or connected to the base system
computer:
The attributes need not be defined in cases where the equipment is not in use or the default values
are OK.
The cycle of the keep-alive output signal to the audio alarm card.
The output is usually connected to a watchdog unit. Setting the value to 0 disables the signal and
hence the watchdog functionality.
Reading and writing of external clock data. This attribute may be read even if the clock type
(SYS:BCL) is "PC31", and set only when the clock type is "PC32" or "PCI510".
When setting the clock, attributes missing in the list are left untouched (the clock is first read to
preserve them).
This attribute is not returned by FETCH function nor can be set by #CREATE command.
When cyclically reading the clock, the data is considered valid if any of the statements listed apply:
FREE = 0
SYNC_AFTER_RESET = 1
SOURCE = 1
The time period in seconds for periodically recurrent time synchronization of the operating system
clock and the physical computer clock against the external clock (see the CL attribute). The attribute
determines the time period between automatic clock synchronization. It also works as a momentary
synchronization command when the attribute is set to 1.
The type of the external clock, if any. The external clock synchronizes the SYS600 time. See also
attributes TM, TZ and TS.
The status register of an external clock. that provides additional clock information when a radio or
satellite clock (for example PC31/PC32) is used for synchronizing the base system. Each time the
status register of the clock is read by the base system, the value in the register (byte or word) is
copied as such to the CS attribute. The meaning of the value is clock type specific.
'1' '0'
D0 Clock state Free running DCF77 controlled
D1 Daylight saving Enabled Disabled
D2 Sync'ed since reset Yes No
D3 Dayl.sav. is going to change Yes No
D4 UTC time Yes No
D5 Leap second announced Yes No
D6 Board time from Serial iface DCF77
D7 On-board time invalid Yes No
The following attributes specify the connection of a SPACOM device directly to the base system
computer through a COM port.
The operating system device name of the SPACOM communication port when connected directly to
the base system computer (not via NET unit). The attribute applies only to base systems with SP = 1,
see below.
If COM port 10 or higher is used for SPACOM communication, the name must be given in
the format "\\.\COM10". For lower port numbers, simple name will do (e.g. "COM5").
Operating System Event Handler is a Windows-based program, which passes Windows™ system
events to SYS600.
The program is started when SYS600 service is started and it is stopped when SYS600 is stopped
(shutdown).
Information about which event types are passed to SYS600. Before an application can receive
events, attribute EE of the base system application object must be set to 1.
Example:
#SET SYS:BOT=(1, 3, 7)
;Errors are reported from the application log
;Errors and warnings are reported from the system log
;Errors, warnings and information are reported from
;the security log
The attribute can be used as global variable. It is reserved for Hitachi Energy and should not be used
in application programs.
Example:
This section describes the base system APL objects and their attributes:
Each application known to the base system must be defined as an APL object. This concerns not
only all applications situated in the current base system (local applications), but also applications in
other base systems (external applications) which are communicating with the local applications. An
external application is defined with a reference to the application in the other base system.
At least one local application must be created with an application name (see the NA attribute) and set
to "HOT" (see the AS attribute) in the SYS_BASCON.COM file.
The APL attributes are accessed from SCIL with the object notation:
GUID-02AD6A69-9005-4C2A-B4F9-3B2107DFA088 v1
APLn:Bat
where
'n' The application number, 1 ... 250. If 'n' is omitted or n = 0, the object notation refers to the
application where the notation is used.
'at' Attribute name
The APL attributes of applications in another base system are accessed with the following object
notation:
GUID-CE5A899E-7232-4420-817E-468B4786004A v1
APLn:mBat
where
'm' The logical application number (according to the application mapping, the AP attribute) of an
external application (see the TT attribute).
'n' The number of the application object in the other base system
The following attributes are set when defining the APL objects. When defining APL objects
corresponding to local applications, all attributes are relevant. When defining APL objects
corresponding to external applications, the AN and TT attributes are relevant.
The base system object number (the 'n' in the object notation above) of the application. The number
is defined when the APL object is created. This attribute is not included in FETCH (see the
Programming Language SCIL manual).
Example:
!SHOW AN APL:BAN
The state of a local application (an application within the same base system). The attribute
determines whether the application is running (HOT), passive but available (WARM) or passive, not
available (COLD). Setting an application to COLD performs a clean shutdown of the application.
Example:
When an application is set to "HOT", the event channels APL_INIT_1 and APL_INIT_2
are activated. When it is set to "COLD", the event channel APL_CLOSE is executed
before the shutdown (see Application Objects manual).
The name of the local application. The application name is the same as the name of the application
directory branch used in the directory tree in the APL directory. The directory tree must exist when
the application is created. The name is obligatory for all local applications.
Determines how the base system regards the application and where the application is found, see
example in Figure 3.
Changing TT from normal operating state LOCAL to any other state will cause the application state to
be set COLD.
The following attributes must be defined for external applications, that is, applications located in
another base system (TT = "EXTERNAL"). The attribute TN must be defined for alias applications
(TT = "ALIAS").
Data_communication.eps
GUID-60C857A4-17E6-4690-BDFD-0F16AD7EA290 V1 EN-US
When the application is located in another base system (TT = "EXTERNAL"), this attribute is the
node number (the NOD object number) of the base system where it is found. The attribute is not
applied for local applications (applications located in the same base system).
Example:
The application that APL2 refers to is located in the base system whose node number is 10. See also
Figure 3 and the TN attribute below.
Concerns external applications (TT = "EXTERNAL") and applications defined as an alias (TT =
"ALIAS"). If the application is external, the attribute is the object number of the corresponding
application in the other base system (defined by the ND attribute). If the application is an alias, the
attribute is the translated object number.
Examples:
APL2 in the current base system refers to APL1 in the base system with node number 10. By using
APL2 in application mapping (Section 7.4), communication is obtained with application 1 in the other
base system.
A proxy application is an application that represents an HSB application pair for other applications.
An APL-APL communication request to a proxy application is routed to the hot application of the HSB
pair.
When a request fails because of lost communication or non-hot application state, the base system
starts polling the two applications. If a newly hot application is found within the communication
timeout of the request, the currently hot application (attribute HA) is updated and the switch-over (or
a short communication break) goes unnoticed by the issuer of the request. Otherwise, a
SCIL_APL_APL_COMMUNICATION_TIMEOUT error is returned.
A proxy application is created by an application object of translation type "PROXY" (attribute TT) and
defining the HSB application pair (attribute HS).
If the second application number is 0, the proxy represents only one application. This kind of
configuration may be used when HSB is temporarily out of use or, in a non-redundant system, to take
advantage of the recovery from short communication breaks.
Examples:
HOT_NODE_NAME = SYS:10BNN
SHADOWING_PHASE = APL:10BSP POSITION = BREAKERNAME:10POV10
Supervision of the local pools may be enabled/disabled by SCIL. This attribute is implemented to
control the supervision.
Setting ME to 1 always re-enables local memory pool events (even if the old value was also 1).
An application may disable the queue supervision temporarily when it causes an event burst by itself,
for example at application start-up. Setting QE to 1 always re-enables queue overflow events (even if
the old value was also 1).
Application object attributes PH, RL and TD define the application specific paths, representation
libraries and text databases.
The attribute names of the value define the path names and attribute values define the directories
included in the path. The attribute value may be either text value defining one directory or a text
vector defining one or more directories.
The attribute can be set by the "#CREATE APLn:B" command (typically in SYS_BASCON.COM) or
the "#SET APLn:BPH" command. However, the #SET command is not allowed after the initialization
of the application has completed. It is allowed in command procedures executed by the event
channels APL_INIT_1 and APL_INIT_H.
Example:
;The following line of code may be used in APL_INIT_1 to add path "XXXX"
to the APL:BPH #SET APL:BPH = MERGE_ATTRIBUTES(APL:BPH, LIST(XXXX = "/APL/
APLNAME/XXXX"))
The attribute names of the value define the logical representation library names and attribute values
define the library files included in the logical library. The attribute value may be either text value
defining one file or a text vector defining one or more files.
The attribute can be set by the "#CREATE APLn:B" command (typically in SYS_BASCON.COM) or
the "#SET APLn:BRL" command. However, the #SET command is not allowed after the initialization
of the application has completed. It is allowed in command procedures executed by the event
channels APL_INIT_1 and APL_INIT_H.
Example:
#CREATE APL2:B=LIST(-
RL = LIST(DEFAULT = "c:\own_pirs\my_pir",-
"APL_/APL_STAND",-
"LAN_/LAN_STAND")),-
... )
The database file names are listed in their logical search order, site specific files first and product
specific files last.
The attribute can be set by the "#CREATE APL:B" command or the "#SET APLn:BTD" command
regardless of the application state.
Example:
#CREATE APL2:B=LIST(-
TD = VECTOR("APL_/SPECIAL_TEXTS.SDB",-
"/LIB6/TEXTS/LIB666_TEXTS.SDB"),-
... )
Application mapping is required if the application communicates with other SYS600 applications, in
the same or other base systems.
Enabling communication between different applications in the same or in the different base systems.
An application recognizes other applications by their logical application numbers. The AP attribute is
a translation table between the logical application numbers and the corresponding physical
application numbers (base system object numbers). The logical numbers are used as indices and the
physical numbers are the value of the attribute.
The application gets access to the data bases of all applications that are known to it by a logical
application number. The logical application numbers are used in the object notations after the colon
when referring to an object in another application, see Figure 4.
If no intercommunication between different applications is needed, the attribute need not be set. The
attribute is not needed for file shadowing.
Example:
The application knows application 2 (APL2) as application 5 (logical number). For example, the
notation BREAKER:5POV refers to the process object BREAKER in application 2. See the Figure 4.
APL:BAP5 = = 2
Base system
APL1 APL2
AP1 = 1
.
.
AP5 = 2
The device mapping attributes define the mapping between the logical and physical device numbers
for the MON, PRI and STA objects.
Logical device numbers are numbers used within an application in various tools and in SCIL object
notation. For instance, the unit number given in the process object definition is a logical station
number. Likewise, when accessing STA communication system objects (STA:S objects), the 'n' in the
object notation is the logical number of the station.
The physical device number is the number of the corresponding base system object.
Using device (and application) mapping, complete standard applications may be designed for re-use
in different base systems. The application may use fixed logical device numbers that are later
mapped to the physical reality of the hosting base system.
The device mapping attributes are translation tables between logical and physical device numbers.
See the example in Figure 5. The attributes are vectors where the logical device numbers work as
indices and the element values give the corresponding physical device numbers.
For PRI and STA objects, it is recommended to use one to one device number mapping for simplicity,
if there is no good reason to do otherwise. This is also the default for the ST and PR attributes.
For MON objects, value -1 is used instead of the physical device number, indicating that any physical
monitor number will do.
APL1 APL2
Station_mapping_attribute.eps
GUID-08C859FD-9C97-4CFD-9DAD-F009BBB56ECA V1 EN-US
Figure 5: An illustration of the station mapping attribute (ST). The PR attribute works in a
similar way.
The attribute defines how many SYS600 monitors will be available for the application, and which are
the logical numbers of monitors that the application may use. For each currently open monitor, it tells
the mapped physical monitor number.
When a monitor is opened, any free physical monitor number is allocated for it. Physical monitor
number -1 is configured in MO. During an open monitor session, the actual physical monitor number
is shown in MO.
An open monitor may be unmapped by setting its MO index value to -1. This may be used (with care,
of course) to close a monitor from another monitor.
Example:
Because one-to-one mapping is the default, PR attribute does not always have to be specified.
Because one-to-one mapping is the default, ST attribute does not always have to be specified.
Base System
Application Software Base System Objects
APL1 APL1 Station Mapping:
ST1 =
Application program: ST2 =
#SET BREAKER:POV1 .
.
ST5 = 10
Process Database:
BREAKER:PUN 1 == 5 STA10:B ND = 3
TN = 20
ST = RTU
Communication Unit
NET3
STA20
Type: RTU
Station_number_transaltion.eps
GUID-E63F7223-3725-41BA-B7B3-FBC0BB70CFDA V1 EN-US
Shadowing means that data from the hot application is copied to the stand-by application. Data is
shadowed on event basis, which means that during run-time, only changed data items are
shadowed.
The maximum waiting time that the primary application tries to get connection with the stand-by
application after shadowing has been activated.
The connection for shadowing is established either by setting the APLn:BSS attribute to
"HOT_SEND" state (provided that shadowing has been enabled using the SYS:BSH attribute), or by
enabling shadowing with the SYS:BSH attribute (when APLn:BSS already is "HOT_SEND"). If no
response is received within the time specified by the SC attribute, an error code is generated and no
more trials are done.
The value of the diagnostic counters on the connection between the hot and the stand-by base
systems.
1. TRANSMITTED MESSAGES
2. TRANSMITTED COMMANDS
3. TRANSMITTED TRANSACTIONS
4. TRANSMITTED KILOBYTES
5. RECEIVED MESSAGES
6. RECEIVED COMMANDS
7. RECEIVED TRANSACTIONS
8. RECEIVED KILOBYTES
9. RAM DUMP TIME
10. FILE DUMP TIME
The maximum time a message is buffered before it is flushed to the stand-by application.
The shadowing handling process copies all updates in files stored on disk under the application
directory and all updates on RAM to the stand-by application. It tries to pack as much as possible in
one copy transaction and meanwhile keeps the messages to be transferred in a buffer. A flush is
performed when the message length arises over 60 kb or when the oldest message in the buffer is
as old as specified by the SF attribute.
The time between the diagnostic commands which the running (HOT and SEND) application sends
to the stand-by application (if no transaction messages are sent).
Shadowing dump phase control. In some applications, the file dump phase of shadowing start-up
might degrade the system disk I/O performance unacceptably. Particularly, this might happen if
shadowing was used within one system to build a file database copy for backup purposes. Using the
SL attribute the file dump data transfer can be slowed down. SL specifies the slow down time in
milliseconds per kilobytes of transferred data.
Setting this attribute to a non-zero value slows down the dump phase drastically. The
attribute is more or less obsolete with today's operating systems and hardware.
The logical application number of the shadowing partner application (usually an external application).
When the application is the sending part in a shadowing relation (see the SS attribute below), the SN
attribute is the number of the receiving application. When the application is the receiving part, the SN
attribute is the number of the sending application.
If a host application is an HSB application, both partners are defined as external applications in the
image system and their SN attributes are set to point to each other. This enables the mirroring
software to automatically switch communication to the host that becomes hot.
If an image application is an HSB application, both partners are defined as external applications in
the host system and their SN attributes are set to point to each other. This enables the mirroring
software to listen to the two image applications and communicate with the one that is currently hot.
Enabling and disabling the shadowing of the event channel queue in hot stand-by applications.
When a process object is updated, it may activate an event channel for post-processing the event by
command procedures and data objects. The event channel activation requests are queued and
executed in turn. In a hot stand-by environment, it is possible that a take-over occurs after a process
object has been updated but before the activated event channel has been executed. If the event
channel queue has not been shadowed, the post-processing of the event is lost.
During shadowing, the event channel activation requests caused by process object updates are
transferred to the receiving application. Likewise are indications of completed event channels
transferred. (An event channel is completed when the connected data object, command procedure or
time channel has been executed). After a take-over, the event channel queue is reconstructed in the
running application and the event channels are executed after APL_INIT_H. The events are queued
in the original order. If there were several pending activations for the same object, only the last one is
re-queued. The snapshot variables of the process object are not shadowed but reconstructed from
the current values in the running application. Event channel activations generated by SCIL are not
shadowed.
The event channel shadowing guarantees that each event channel activation is executed in at least
one of the HSB application pairs. However, there is a slight risk that an event channel is executed
twice (in both applications).
The hot stand-by connection is considered broken if no response is received when this time has
elapsed since a message (or a diagnostic command) has been sent from the primary system to the
stand-by system. Likewise, the connection is considered broken if the stand-by application does not
receive any diagnostic command when the diagnostic interval (the SI attribute) in addition the time
specified by the SR attribute has elapsed.
This attribute determines whether the application acts as the sending or receiving application in a
shadowing relation. The shadowing pair is defined with the APLn:BSN attribute. During operation the
sending application should be in "HOT" state and the receiving one in "COLD" state.
Example:
The current application APL1 sends file and RAM shadowing to application defined by the APL:BSN
attribute:
APL:BSS == "HOT_SEND"
APL:BSN == 10
The time between time synchronization signals sent from the primary application to the stand-by
application.
The number of APL-APL communication servers that handles the APL-APL communication.
If there is only one process per application to serve incoming APL-APL communication requests and
if a request takes a long time to satisfy, other requests will have to wait. A request can take a long
time to satisfy if it contains process communication, which might time out. The situation might lead to
timeouts and/or slow communication. Hence, in applications that receive APL-APL communication
requests from more than one base system, the APL:BAA attribute should be given a larger value for
better throughput.
Attribute AU below may be used to analyse the communication and help finding an adequate value
for AA attribute.
Setting APL:BAA to 0 disables APL-APL communication with the application. This may be
used for security reasons.
This attribute may be used to supervise the APL-APL communication and analyse its problems. In a
normal situation, this value should be zero indicating that all the incoming requests are served
immediately. If it shows positive values, the value of AA attribute (see above) may be too small. If it
shows growing values or stays positive for a long time, the external SCIL application(s) sending the
requests should be checked.
The maximum number of process events that will be queued for event channel activation or for
mirroring communication.
If the application is local, the attribute specifies the maximum length of the event channel input
queue. While the queue is full, the base system does not accept process messages from the process
communication units (for example PC-NET's, mirroring clients and External OPC Clients). The
behavior is specified for not losing events in any circumstances (However, if the event buffers in
those units or process stations behind them do overflow, events will be eventually lost).
If the application is external, the attribute specifies the maximum length of the mirroring event queue.
The behavior in an overflow situation is specified by attribute EP, see Section 7.9.
The current used length of the event channel input queue (if a local application) or the mirroring
event queue (if an external application). See the EM attribute.
The size of the history buffer, that is maximum number of process object history registrations.
When this number is full, no new print-out commands are handled. The function of the system is
delayed. The limit protects the system from being overloaded. SYS600 printer despooler (PRNC)
also supervises the length of the print queue of the connected printer and waits while the length is
more than 100 jobs.
The maximal number of parallel report queues that the application can use.
The present number of printout commands waiting for execution, see the PM attribute.
Default: 0
Access: Read-only, configurable
Example: See QP
A dedicated parallel queue is a queue that does not execute report objects whose PQ attribute is 0.
If all parallel queues are dedicated, a report object with PQ=0 (and PE=1) is run in event channel
queue.
Maximum length of process database query performed with the function PROD_QUERY, see the
Programming Language SCIL manual.
This attribute is designed to protect the SYS600 system against erroneous SCIL applications. For
example, a command procedure MYSELF that only requeues itself twice (two #EXEC MYSELF:C
commands) would very quickly eat all the system resources and freeze or crash the whole program.
When the limit specified by the attribute is reached, #EXEC commands will fail by error code
REPF_EXECUTION_QUEUE_FULL (1118).
However, the length of the queues 2 and 3 may exceed the limit specified by the attribute because of
process events. The reasoning behind this is as follows:
The rate of incoming process events is supervised by the EU and EM attributes (as well as PU and
PM) attributes of the application.
When a process event is accepted into the process database (i.e. EU < EM and PU < PM), the
attribute EU is incremented, the value from the process is stored in the database and, among other
things, its event channel is activated. The event channel may contain one or more command
procedure and data object activations. These objects are queued for execution in the event channel
queue (queue 2), or in one of the parallel queues. In this situation, the queue length maximums
QM(2) and QM(3) are not honoured, because otherwise events would be lost. When all the objects of
the event channel have been executed, the EU attribute is decremented to make the process
database accept a new process event.
So, as an example, if each process message activates 5 parallel command procedures (the primary
object of the event channel plus 4 secondaries) and the value of the EM attribute is 500, the length of
parallel queues (QU(3) is likely to be about 2500 in a rush situation, regardless of the value of QM(3).
The names of objects in various system queues queued for execution, but not yet started (c.f.
attribute RO).
If a queue is empty, the corresponding element of the attribute is an empty vector, otherwise it is a
text vector listing the queued objects. An object is identified by a text string starting with character 'D'
(for data object), 'C' (for command procedure), 'T' (for time channel object), 'A' (for event channel
object) or 'E' (for event object) followed by the name of object. In case of an event object, the index of
the object enclosed in parentheses follows.
The priority of the queue defines how the operating system is to allocate processor time for the
queue compared to the time channel queue, event channel queue and other parallel queues. There
are three priority classes: low, normal and high.
The priority of time channel and event channel queue is fixed (always 'normal').
Example:
An application is created with 3 parallel queues. The queues 1 and 2 run with normal priority and
serve report objects with PQ = 0. The queue 3 runs with a higher priority and only accepts report
objects, whose PQ attribute is 3.
The names of the data objects or command procedures currently under execution in REPR queues.
If a queue is empty, the corresponding element of the attribute is an empty text string, otherwise it is
a text string starting with character 'D' (for data object) or 'C' (for command procedure) followed by
the name of object.
Specifies the alarm picture queue handling, and how pictures are removed from the monitor alarm
picture queues.
Tells whether CAM (Centralized Account Management) is used for user authentication or not.
Area of Responsibility (AoR) cannot be used when CAM is in use. SYS600 Base System
automatically disables AoR if also CAM is enabled. Warning message about such
configuration is logged to SYS600 Notify.
When SYS600 application attribute CE is set to value 2, custom roles defined in SDM600 can be
used in SYS600. Each custom role definition has a unique integer identifier in both systems.
Typically, these identifiers are negative integer values. To match custom role defined in SDM600 and
SYS600 role, these identifiers must be identical in both systems.
Specifies whether system events (event channel SYS_EVENT) are received by this application or
not.
There may be several applications in the system with EE = 1. When a system event
occurs, the event channel is activated in all these applications. The applications should
be programmed to co-ordinate the actions taken as a consequence of the event.
Determines storing the history of events. The alternatives are history database, event logging and
history buffer, or neither of them. For more information on how to configure storing the event history,
see the System Configuration manual.
HP may be set by "#CREATE APLn:B" command and by #SET command when the
application is cold and its shadowing state (APL:BSS) is "NONE".
If HP = "DATABASE", attribute HB (History Buffer length) does not have any meaning.
When HP = "DATABASE", the application attribute HT is incremented every time an event is written
into the history database.
Informs whether the application has an OPC Alarms and Events Server.
Defines the Object Identifier (OI) structure used by the process objects of the application.
If the attribute is not defined in SYS_BASCON.COM, it is, for compatibility reasons, automatically
constructed from APL:BSV(15) when the application is started. If APL:BSV(15) is not defined, the
default value is used.
Example:
LIST(DEPTH = 3,-
LEVELS = VECTOR(LIST(WIDTH = 10, NAME = "STA", TITLE = "Substation"),-
LIST(WIDTH = 15, NAME = "BAY", TITLE = "Bay"),-
LIST(WIDTH = 5, NAME = "DEV", TITLE = "Device"))
Configuration data for the OPC Alarms and Events Server of the application.
Setting this attribute has no immediate effect on the running OPC A&E Server. To apply
the changes, restart the server (by setting the OE attribute to 0 and back to 1).
This attribute specifies how the incoming status 1 from stations is treated in the process database.
The status may be stored in the database as a FAULTY status 1, or it may be changed to 2
(OBSOLETE_STATUS, or INVALID).
This attribute has been implemented to prevent excessive events and alarms from gateway
applications that report some communication problems by status 1.
When an incoming status 1 is received from a station, the policy of the corresponding station object
(attribute STA:BPF, see Section 11) is first applied. Only if STA:BPF = "DEFAULT", or the unit number
(UN) of the object is 0, the policy defined by this APL:BPF attribute is applied.
Defines the port numbers used by external sql databases. These values are not used by SYS600
base system.
This attribute is useful if the default port (5432) is already reserved in the local machine or in the Hot
Stand-by shadowing partner machine.
If the attribute is not defined in SYS_BASCON.COM, both list attributes default to value 5432.
Attribute LOCAL defines the port number on the local computer. Attribute REMOTE defines the port
number on the shadowing partner computer.
The post-processing policy applied when the status of a process object of the application changes
from 0 (OK) to 2 (OBSOLETE) or vice versa.
This attribute specifies how the activation criteria (attributes PA, AA and HA) are interpreted in case
the status of the process object changes from 0 to 2 or vice versa while the object value (OV)
remains unchanged. The keyword informs when the status change is considered to fulfill the criterion
NEW VALUE.
The phrase "when OS is set" here means that the status is explicitly set by SCIL, an OPC client or a
process (ACP) message, as opposed to the implicit status change to 2 caused by lost connection to
the station.
When the status of a process changes from 0 to 2 or vice versa, the policy of the corresponding
station object (attribute STA:BPP, see Section 11) is first applied. Only if STA:BPP = "DEFAULT", or
the unit number (UN) of the object is 0, the policy defined by this APL:BPP attribute is applied.
Defines the default encoding of topological states in the process database of the application. The
encoding is applied to determine the TS (Topological State) attribute value of DB (Double Binary)
process objects as well as to determine the return value of the SCIL API function
SCIL_Get_Switch_State.
If the value of the attribute is an empty list (the default value), the system-wide default, which
corresponds to the SM value LIST(OPEN = 2, CLOSED = 1, MIDDLE = 0, FAULTY = 3), is applied.
This attribute may be overridden station-wise by the similar SM attribute of the station object, see
Section 11.2.2.
Windows Single Sign-on and its requirement are described in the Application Design manual.
The input timeout affects the semi-graphic input commands !INPUT_VAR, !INPUT_KEY and !
INPUT_POS. The execution of the SCIL program containing the input command is interrupted by
error PICO_INPUT_TIMEOUT (961), if the operator does not respond in the specified time. The timer
is reset by each character typed.
The timeout is applied in all semi-graphic pictures shown by the monitors of the application.
The chosen language can be overridden by the MONn:BLA attribute and by the SCIL function
SET_LANGUAGE.
The size of the monitor alarm signal in the upper right corner of the screen.
The alarm signal is always square formed and this attribute specifies the number of semi-graphic
character positions on one side of the square.
A tag number that is updated each time the alarm queue is updated (a new alarm occurs, an alarm is
acknowledged, or an alarm is cleared).
The attribute can be used, for example, in the alarm list so that a change of the attribute causes an
updating of the display.
A tag number that is updated each time the history buffer is updated.
The attribute can be used, for example, in the event list so that a change of the attribute causes an
updating of the display.
A tag number that is updated each time a blocking attribute (AB, HB, PB, UB or XB) of a process
object is set or cleared.
The attribute can be used, for example, in the blocking list so that a change of the attribute causes an
updating of the display.
Setting one of the following attributes externally terminates the execution of the SCIL program in the
specified SYS600 process. For example, this can be used as an emergency stop of an erroneous
SCIL program that has entered an eternal loop.
Terminates the SCIL program currently run by a printer spooler process (PRIN)..
Allowing the application engineer to choose the behavior of SCIL language elements when upgrading
to a new SYS600 version that works differently from the version used during the application
engineering. The mechanism may be useful, for example, in the following cases:
• A bug has been corrected in the new revision, but an application has taken advantage of the old
bug and relies on it.
• Some limit or restriction of the program has been removed, but an application may be coded to
rely on the restriction.
The compatibility with the old revision is defined by compatibility issues. The mechanism is handled
by the RC attribute and a SCIL function. With the RC attribute, all the SCIL programs executed within
the application may be forced to behave in the old way regarding one or more compatibility issues.
The SCIL function REVISION_COMPATIBILITY enables the programmer to temporarily (in a picture,
dialog system or command procedure) override the revision compatibility defined by the RC attribute.
"DEFAULT_DAYLIGHT_POLICY_IS_CALENDAR"
"844_COMPATIBLE_MIRRORING"
"CREATE_VERSION_2_SCIL_DATABASES"
"DO_NOT_SYNCHRONIZE_PICTURE_UPDATE"
"COUPLE_AUDIO_ALARMS_AND_PRINTOUTS"
"ALLOW_CONFLICTING_F_ATTRIBUTE_NAMES"
"DONT_CAUSE_TAKEOVER_ON_FATAL_ERRORS"
Access: Read-only, configurable
Example:
Compatibility issues:
In MicroSCADA revision 8.1 and older, the macros of each SCIL command line were expanded
before the line was interpreted. This lead to an incorrect behavior in case of a single line #ON
command, for example:
@A = "XYZ"
#ON EVENT:E1 #EXEC 'A':E2
When event EVENT:E1 occurred, command "#EXEC XYZ:E2" was executed regardless of the
current value of A. Variable expansion is a run-time operation, which should use the current values of
variables. The following worked correctly:
If the file name argument of READ_TEXT or other file handling functions was given in operating
system dependent format, such as \DIR\FILE.TXT, the directory was created if it did not exist. This
bug has been fixed. FILE_DIRECTORY_DOES_NOT_EXIST status is now returned.
WRITE_TEXT
WRITE_BYTES
WRITE_COLUMNS
#CREATE_FILE
Other file handling functions (e.g. READ_TEXT) never create the directory.
In rev. 8.4.0 and earlier, setting AG or LA attribute of a process object did not affect the alarm state of
the object and no post-processing was done. In 8.4.1, the alarm state is updated according to the
new value and normal post-processing is done. Due to the change, some old applications generate
unwanted alarms and printouts when run under 8.4.1. To prevent this, this revision compatibility value
was implemented.
The value can be used only as the value of the application attribute RC. It cannot be used as an
argument of SCIL function REVISION_COMPATIBILITY, because event handling is done by the
process database.
In MicroSCADA revision 8.4.2 and earlier, the quality attributes SB (Substituted), BL (Blocked), OR
(Out of Range) and OF (Overflow) have been information-only attributes, i.e. they have been stored
in the process object to be available for SCIL but their values have not affected the behavior of the
process object in any way.
Since revision 8.4.2 of MicroSCADA global variables are guarded against alias references. The
revision compatibility switch NO_ALIAS_CHECKING is implemented for compatibility. Status
SCIL_VARIABLE_ALIASING_ERROR is generated when aliasing rules are violated.
The arguments of method calls, as well as all the arguments of SCIL functions except for the last
one, are passed by copy instead of reference. This degrades performance, when text, bit string, byte
string, vector and list arguments are used. See the Installation manual.
If the MicroSCADA base system revision 8.4.2 will be used together with applications created with
earlier revisions of the base system, e.g. using LIB 4.0.1, the revision compatibility switch
NO_ALIAS_CHECKING should be turned on.
Since revision 8.4.4 of MicroSCADA, the protocol specific attribute OR (Out of Range) and OF
(Overflow) value 1 generate an alarm (c.f OS value 1 or FAULTY).
"NO_ALARM_BY_OR_AND_OF" may be set if the application, for a reason or another, does not like
this new behavior.
Since revision 8.4.4 of MicroSCADA, the alarm state is recalculated when AB is set back to 0.
However, no alarm printouts nor event channels are activated (they are not activated when AB is set
to 1, neither).
In revision 8.4.4 of MicroSCADA, the implementation of keyed files was enhanced to give better
performance and to support files of any size (earlier implementation had the size limit of 32 MB).
Process and report database files, pictures, representation libraries and files created by SCIL using
#CREATE_FILE command are implemented as keyed files.
The files created by the new version 2 implementation cannot be read by earlier MicroSCADA
revisions. However, they can be converted to version 1 format by SCIL function
KEYED_FILE_MANAGER, see the Programming Language SCIL manual.
When "CREATE_VERSION_1_FILES" is set, all the files are created in the old version 1 format. The
use of this value is not recommended, but it may be useful in cases where pictures are engineered in
8.4.4 environment but used in 8.4.3 or earlier.
In revision 8.4.4 of MicroSCADA, the implementation of keyed files was enhanced to give better
performance and to support files of any size (earlier implementation had the size limit of 32 MB).
When an application is started up the first time using MicroSCADA revision 8.4.4, the process
database file APL_PROCES.PRD and the report database files APL_REPORT.nnn are automatically
converted to the new version 2 format. The old files are renamed by appending a postfix "_V1" to the
name. If the conversion fails, for example because of disk space shortage, the old file is used and the
conversion is tried again during the next start-up.
If, for some reason, the conversion is not wanted, compatibility issue
"KEEP_FILE_VERSION_1_DATABASE_FILES" may be set before starting up the application. If it is
later removed, the conversion takes place during the next start-up.
Prior to revision 8.4.4, the scheduling of time channels was synchronized to the local time of the
system. When the local time was moved backwards at daylight saving to standard time switch, the
time channels stopped for an hour. Correspondingly, at standard to daylight saving time switch, the
time channels were excessively scheduled.
In revision 8.4.4, the default behavior is that the time channels are scheduled evenly (synchronized
to UTC time) when the local time changes due to daylight saving and there is a new attribute DP
(Daylight Switch Policy) to specify the behavior, see the Application Objects manual.
Mirroring between MicroSCADA 8.4.4 and MicroSCADA 8.4.5 does not work when default settings
are used. When upgrading from 8.4.4 to 8.4.5, both systems have to be upgraded to make mirroring
work again.
If the SYS600 mirroring network is large, upgrading may cause unacceptably long breaks in the
operation of the network. The compatibility issue, "844_COMPATIBLE_MIRRORING", has been
implemented to ease upgrading.
When "844_COMPATIBLE_MIRRORING" is set (in MicroSCADA 8.4.5, or later), the mirroring works
with an 8.4.4 application, and also with another 8.4.5 application with
"844_COMPATIBLE_MIRRORING". However, it does not work with an 8.4.5 application without
"844_COMPATIBLE_MIRRORING".
The setting of "844_COMPATIBLE_MIRRORING" does not affect the functionality of the program or
cause any decrease in performance. All the new features introduced in MicroSCADA 8.4.5 (such as
hierarchical mirroring) work as specified.
The internal implementation of SCIL databases (SDB) has been optimised for faster access in
SYS600 9.0. An SDB created in the new (version 3) format cannot be read by MicroSCADA 8.4.5,
which uses version 2 format.
The timing of update programs of pictures is synchronized to the system clock (See the
Programming Language SCIL manual, command !UPDATE). In the revision 8.2 (or older), such a
synchronization was not done. When an old application that relies on the old behavior is upgraded,
this setting may be used to avoid recoding of the pictures.
This setting does not affect the cyclic methods of Visual SCIL objects.
Generation of audio alarms has been changed in SYS600 9.1 and in MicroSCADA 8.4.5 SP2. Audio
alarms and alarm printouts are now generated independently of each other. In earlier revisions, an
audio alarm was generated only when an alarm row was printed on the event printer.
When an old (Rev. 8.4.3 or older) application was upgraded to 8.4.5 or later, the creation of F (Free
Type) objects fails by PROF_FREE_ATTRIBUTE_NAME_ALREADY_EXISTS (2212), if the F object
defines attribute names implemented as common process attributes in the base system in
MicroSCADA revisions up to 8.4.4.
Examples of such conflicting attributes are RB, TI, TY, OI, BL, RB, OR and CT.
This switch should be used only when an old application is upgraded, because the new base system
functionality implemented by conflicting attributes will be lost when the name is overloaded. In
addition, some common SCIL tools (such as the Object Navigator) and other SCIL software may be
confused when the data type and meaning of some common attributes are not that expected.
Since Rev. 9.3, a deliberate HSB takeover is initiated in case of an occurrence of a fatal error (such
as global memory pool overflow or lack of operating system resources), if the primary application of
the system is ready for a takeover (its shadowing phase is HOT_SD).
For a hot application, application diagnostics provide an automated means of monitoring the state of
other applications. The diagnostics is based on the APL-APL communication, that is why it is also
called APL-APL diagnostics. Both external and local applications may be monitored.
The attributes DI (Application Diagnostic Interval) and DT (Application Diagnostic Timeout) of the
monitoring application define the applications to be monitored. The status of the APL-APL connection
and the state of the external application may be read from the DS (Application Diagnostic Status)
attribute.
When the status of the APL-APL connection changes from bad to good or vice versa, or the state of
the supervised application changes, the predefined event channel APL_EVENT is activated to allow
application specific actions. For details about the event channel, see the Application Objects manual.
The diagnostics of application 'n' is started, when both DI(n) and DT(n) are set to a non-zero value. If
they are non-zero at the application start-up, the diagnostics is started after the event channel
APL_INIT_1 (or APL_INIT_H) has been executed.
Correspondingly, the diagnostics of application 'n' is stopped, when either DI(n) or DT(n) is set to
zero.
The status of the APL-APL connection and the state of the supervised application.
Example:
The attributes relevant only to mirroring systems are described below. For further information about
the mirroring concept, see the System Configuration manual.
The policy to be obeyed in the host system when the mirroring event queue is about to overflow (EU
>= EM).
When the policy is "DISCARD", the host will dispose of all the events in the queue and send an
overflow message to the image application. The image will then re-establish the connection and do a
new subscription.
When the policy is "KEEP", the host application will do what it can to avoid losing events. Specifically,
the host application works exactly in the same way as when its own event channel queue is about to
overflow: it does not accept process messages from the NET unit while the queue is full. The "KEEP"
policy is obeyed only while the connection to the image application is established. During a
connection break, "DISCARD" policy is applied to prevent shortage of system resources.
Enables and disables mirroring communication with this (external) host application.
The attribute is used in the image system to temporarily block the incoming events from a host
application. During the blocking, the host buffers the events and sends them when the
communication is re-enabled.
Enables and disables mirroring communication with this (external) image application.
The attribute is used in the host system to temporarily block sending events to an image application.
During the blocking, the host buffers the events and sends them when the communication is enabled
again.
The locations of the image stations that are to receive system messages from this host application.
The system messages are recognized by their object address, the unit number (attribute UN) of the
process object is 0.
Note: The attribute is read by the application only at application start-up. Consequently, setting the
attribute while the application is running has no immediate effect.
In future, additional categories, areas, object types and sources may be implemented.
Emergency password can be used only once. When consequent emergency login has to be done, an
integer larger than the previously used has to be assigned to the EY attribute.
Instructions:
1. Stop MicroSCADA
2. Open sys_bascon.com file and insert EY attribute, see listing below. Note to use correct
application.
3. Start MicroSCADA
4. Use user name EMERGENCY when logging in to the application
5. Password is same as the value of EY attribute
6. Change administrator password from the user management
7. You can leave or comment EY attribute definition in sys_bascon.com file so it is easier to
remember what integer value was used last time.
The attribute can be used as global application related variables. It is reserved for Hitachi Energy and
should not be used in application programs.
The attribute can be used as global application related variables in application programs.
Section 8.2 General: The link types and the MON object notation.
Section 8.3 MON attributes:
• Basic monitor definition attributes (BN, BT, BM, DT, TT)
• Informative monitor attributes (AN, AP, LI, SD, SG, SZ)
• Monitor control attributes (BP, ED, IL, LA, MS, PC, WC)
• Miscellaneous monitor attributes (CX, SV, UV)
The MON objects correspond to the SYS600 monitors opened on screens either by the operator or
automatically. A screen, the base system screen or a workstation, can contain one or more SYS600
monitors connected to the same or different applications in the same or in different base systems.
Each SYS600 monitor that will be used by the base system and its applications must be defined as a
MON object. The monitors are reserved by an application with the monitor mapping attribute
(APLn:BMO, Section 8.).
The MON object attributes are accessed from SCIL with the following object notation:
GUID-EDCB4712-1773-49C7-A45E-36DE186E8C8B v1
MONn:Bat
where
'n' The object number for the SYS600 monitor. The 'n' may be omitted from the object notation,
whereby the notation refers to the monitor where the notation is used.
'at' The attribute name
The MON attributes of monitors defined in another base system are accessed with the following
object notation:
GUID-8132B518-BD5B-4EBF-AE7B-5387D8467CF3 v1
MONn:mBat
where
'm' The logical application number of an external application (see the TT attribute, Section 7)
'n' The object number of the SYS600 monitor in the other base system
The MON specific attributes are described in this and next sections.
The type of the SYS600 monitor given as a text. The type of monitor affects the user interface.
Determines the operating state of the monitor. If TT = "LOCAL", it must not be set to "NONE".
The logical number of the monitor as seen from the controlling application.
The number of the application that controls the monitor according to the monitor mapping (the
attribute APLn:BMO, Section 7).
Informs whether a user has logged in on the monitor. When a user logs in or out, an event channel
named MON_EVENT (if it exists) is started in the application. See the Application Objects manual.
The identifier of the system device. This attribute is set automatically when the operator opens a
monitor.
The value is always an empty string. This attribute is preserved for compatibility reasons.
The graphic mode identifier of the monitor. This attribute is automatically set to 1 by the base system
software if the monitor is not capable of displaying primitive graphics.
Specifies how to handle the blink behavior in situations when the picture handler is busy, for example
with a demanding SCIL command. Blinking in pictures is realized as a shift between background and
foreground display.
In SYS600 pictures that are not in an input state, the enter key has the same function as the mouse
click. This functionality may be disabled by this attribute.
When a monitor session is closed, the value of this attribute is restored to the value it had
at the beginning of the session.
Prevents the input to a SYS600 monitor from keyboard or mouse. This attribute affects semigraphic
monitors only, not Visual SCIL dialogs.
It is not recommended to have more than 1 picture container in a dialog, because the SCIL programs
of all the pictures within a dialog are executed sequentially. Therefore, a picture doing a lengthy
operation (such as !INPUT_VAR, #PAUSE etc.) blocks all the other pictures in the dialog.
The color of the background behind a window in a picture and behind the blinking alarm signal.
When a window is shown on a graphics screen, this color will be shown in the window locations for a
moment until the window is drawn. Likewise, when a window is erased from screen, this color is
shown until the background is redrawn.
Example:
The attribute can be used as global monitor related variables. The system variables are reserved for
Hitachi Energy and should not be used in application programs.
Section 9.2 General: The link types and the LIN object notation.
Section 9.3 LIN attributes:
• Common naming attributes (BN, BT, BM)
• Basic LIN Definition Attributes (LT, TR, SC)
• Integrated Link Attributes (NA, TI)
• Diagnostic Counters (DC)
• Miscellaneous LIN attributes (CX)
The LIN objects describe the links and connections to adjacent nodes - base systems and
communication units. All node connections must be defined as LIN objects, but several nodes can be
connected to the same link and use the same LIN object definition. The object number 'n' of the LIN
objects can be freely chosen in the range 1 ... 20.
From SCIL the LIN object attributes are accessed with the following object notation:
GUID-974B04C4-2F5A-4DAB-81B5-301FBD85DB8E v1
LINn:Bat
where
'n' The object number and 'at' the attribute name. The 'n' must not be omitted from the object
notation.
The LIN attributes of links defined in another base system are accessed with the following object
notation:
GUID-AF7B9FC4-DFB8-42B0-A0CF-E0886069A5C9 v1
LINn:mBat
where
'm' The logical application number of an external application (see the TT attribute, Section 15)
'n' The object number of the link in the other base system
The type of the link. This attribute must be given for all types of links.
When an INTEGRATED link is created, the integrated PC-NET program is started, provided that the
SC attribute has been given correctly, see below.
When an INTEGRATED link is deleted (by setting the LT attribute to "NONE"), the PC-NET program
is stopped and all the process objects located in the PC-NET are marked old, i.e. their status is set to
2 (OBSOLETE_STATUS).
The type of LAN protocol. This attribute is defined only for LAN links (LT = "LAN"). The only
possibility is TCP/IP, which is also the default value.
The location and name of the executable program of the PC-NET unit and the location and name of
the configuration file.
The configuration file for the PC-NET unit must be ANSI encoded.
Loading of UTF-8 coded file will fail.
Default: Empty
Access: Read, conditional write
Examples:
The maximum number of NAKs (negative acknowledgements) accepted by the base system. When
this number is reached, the base system regards the message transmission as failed and an error
status is produced (16105).
The time limit applied when the nodes are waiting for response to a message or polling packet.
A counter of all major events and error situations of the communication link.
Each line has 16 diagnostic counters numbered 1 ... 16 and with the following meanings:
1. TRANSMITTED MESSAGES
A counter that is incremented whenever a message is transmitted successfully. A successful
transmission includes the reception of a positive acknowledgment (ACK).
2. FAILED TRANSMISSIONS
A counter that is incremented when a message transmission fails. The transmission has failed if
no positive acknowledgment (ACK) is received in spite of retrials. The counter is also incremented
if the states of the modem signals CTS and DCD prevent transmission.
3. TRANSMIT TIMEOUTS
A counter that is incremented each time a time-out occurs during response waiting. If, for
example, 3 timeouts occur at the transmission of a message (with retrials), the counter is
incremented 3 times. When the retry limit is reached, the counter 2 is also incremented once.
4. TRANSMITTED ACKS
A counter that is incremented each time when a positive acknowledgment (ACK) is transmitted.
5. TRANSMITTED NAKS
A counter that is incremented each time when a negative acknowledgment (NAK) is transmitted.
6. TRANSMITTED ENQS
A counter that is incremented each time an enquiry (ENQ) is transmitted.
7. RECEIVED ACKS
A counter that is incremented each time a positive acknowledgment is received from the line.
8. RECEIVED NAKS
A counter that is incremented each time a negative acknowledgment (NAK) is received from the
line.
9. RECEIVED ENQS
A counter that is incremented each time an enquiry (ENQ) is transmitted.
10. Not in use.
11. RECEIVED MESSAGES
A counter that is incremented each time a message has been received from the line without
errors.
12. Not in use.
13. Not in use.
14. Not in use.
15. Not in use.
16. Not in use.
This section details the NOD objects and their attributes. It contains two sections:
Section 10.2 General: The meaning of the NOD objects and the NOD object notation.
Section 10.3 NOD attributes: Common naming attributes (BN, BT, BM), Basic node definition attributes (LI, NN,
NT, RN, SA), Node diagnostic attributes (DF, DI, DT), Node communication attributes (LT, RT),
Security attributes (ID, PI, AI, SC, WL) and Miscellaneous NOD attributes (CX, OP).
The NOD objects represent nodes in the SYS600 system. The following devices and communication
programs must be defined as NOD objects in a base system:
• Other base systems, which will communicate with the base system in question.
• NET units (PC-NET) which will communicate with the base system in question, directly or
indirectly.
• Gateways (protocol converters using CPI-library) of various types.
• OPC Data Access Servers that are used as a data source for the process database.
• OPC Alarm and Event Servers that are used as a data source for the process database.
The NOD object numbers are global and must coincide throughout the entire network. They must
also coincide with the system object node numbers (NET object numbers) defined in the
communication units (see Section 15).
From SCIL the NOD object attributes are accessed with the following object notation:
GUID-C4B0C5FD-9306-4B52-8F72-4251593C08B7 v1
NODn:Bat
where
'n' NOD object number 'n' can be 1 ... 250. 'n' may not be omitted from the object notation.
'at' Attribute name
The NOD attributes of nodes defined in another base system are accessed with the following object
notation:
GUID-FD377DEC-8B2D-40EB-9DC7-DDA381BEF5C9 v1
NODn:mBat
where
The number of the LIN object that defines the link along which the node is reached. See Section 9.
This attribute is irrelevant for OPC nodes. The OPC servers are addressed by OP and RN attributes.
The LAN node name of the node (host name) or the TCP/IP internet address of the node.
The attribute applies to nodes connected to LAN. For other nodes, such as OPC nodes, this attribute
may be used as a comment like description.
For other than OPC server nodes, this attribute does not have to be set. If node diagnostics is
enabled, it will set the attribute according to the reply from the remote node. The value of the attribute
is purely informative.
For OPC server nodes, the attribute must be set to "OPC_DA" or "OPC_AE" to start the
communication with the server. The computer where the server is running is specified by the RN
attribute, see below. The communication may be stopped by setting NT to "UNKNOWN", and
restarted by setting it back to "OPC_DA" or "OPC_AE".
The type of the communication engine behind the node. This attribute is used by the System
Configuration Tool in its internal processing.
Attribute is purely informative, and it must be set when the node is created. Reading is allowed.
All the messages sent to this node are re-routed to the node specified by the RN attribute. A routing
node is useful when the node defined by the NOD object is not directly connected to the base
system.
When the node type is "OPC_DA" or "OPC_AE", the RN attribute specifies the physical node where
the OPC server is running (0 = the current SYS node).
For nodes of other types, the current SYS node cannot be specified as the routing node.
Only one-step routing is allowed, the node specified by the RN attribute of another node may not be
re-routed. For example, if the RN attribute of node 1 is 2, the RN attribute of node 2 must be 0.
Example:
Base system A is connected via LAN to another base system B (with nd = 1), which contains an
internal NET unit (with nd = 10). Use the following definition in the base system A:
#SET NOD10:BRN = 1
The station address of the node used by the SYS600 internal protocol ACP.
The station address is a number, which must be unique among all nodes (base systems and
communication units) in the entire SYS600 system. When assigning station addresses, also the
station addresses of the stations using the ANSI protocol must be regarded as these use the same
numbering. For base systems, the station address is the value of the SYS:BSA attribute. For
communication units it is NETn:SSA.
Nodes that do not communicate with the ACP protocol, such as OPC server nodes, need no station
address.
This attribute specifies whether a system event (a "FOUND" type SYS_EVENT) is generated when
the connection to the node has been established for the first time after the system start-up.
The time in seconds between diagnostic messages from the base system to the node.
The timeout of diagnostic messages, that is, the time the base system waits for a reply to a
diagnostic message sent to the node.
When the node type is "OPC_DA" or "OPC_AE", this attribute has no meaning. The diagnostics is
enabled by the DI attribute alone.
The transaction number of the last transaction (RP570 or SPA protocol) that the NET unit has sent to
the base system. The attribute is updated only in the stand-by base system and applies to the NET
nodes. See the LT attribute in Section 15.
Example:
The moment of time when the node last sent a message to the base system.
The attribute can be used for supervising NET units. Note that the time is not updated with messages
that are replies, for example to diagnostic messages.
Setting AI to 1 accepts the pending identity of the node, copies the PI attribute to ID and clears the
PI. AI can be set using the Security tab of the node in the Base System Object Navigator tool.
When the base system receives from a node a certificate that differs from the known certificate
(attribute ID, see above), it stores the new certificate in this attribute to be accepted by the user. A
warning message like "OSSL_CERTIFICATE_MISMATCH. SA: 110 Address: 172.31.2.153" is written
into the system log. The pending certificate is accepted by setting attribute AI, see above.
Tells whether the connection between the base system and the node is secure (encrypted) or not.
The IP addresses that are allowed to communicate with the base system via this node.
If an external node (typically another SYS600 or a node running External Data Access Client)
attempts to connect to SYS and its IP address is not in the IP Whitelist, the connection request is
rejected and a warning message is written into the system log. Outgoing connection requests to a
non-whitelisted IP addresses are blocked as well.
When an IP address is dropped out of the whitelist, the active TCP/IP connection(s) to that IP
address are aborted, if any.
This attribute is meaningful only for nodes connected to the LAN link using ACP protocol. For
example, it has no effect on OPC_DA and OPC_AE type nodes.
This attribute has no effect when the system hardening (SYS:BHD) attribute
REQUIRE_ACP_IP_WHITELISTING is FALSE.
The OPC server is located by the RN attribute, which identifies the network node where the server is
running, and the CI field of the OP attribute, which identifies the server within the node.
The user account for launching an OPC server is defined by the US and PW attributes of the node
describing the server. If not given, the user account is defined by the referenced network node object
(RN). If not defined there either, the MicroSCADA user account is applied.
Every OPC_DA node (OPC Data Access Server) has two predefined item groups, which are used
when the IG attribute of a process object has been left undefined (IG = ""):
• DefaultGroupIn is the default group for input objects. Its UR and PD are both zeroes.
• DefaultGroupOut is the default group for output objects (process object types BO, DO and AO).
This group is not subscribed to.
The "DefaultGroupIn" may be overridden by the OP attribute, for example to specify a non-zero
update rate.
Setting this attribute does not affect an existing connection to the OPC server. To apply
the changes, restart the communication (by setting the NT attribute to "UNKNOWN" and
back to "OPC_DA" or "OPC_AE").
This section describes the base system objects related to stations (process units):
Each station, that is communicating with the base system and is not of the default STA type (the
attribute SYS:BDS) or connected to a communication unit other than the default NET unit (the
attribute SYS:BDN), must be defined as a STA object. Stations of the default STA type connected to
the default NET unit need not be individually defined. Devices that are not communicating with base
system, such as star couplers in LONWORKS® [1] networks need not be defined as STA objects in
the base systems.
From SCIL the STA object attributes are accessed with the following object notation:
GUID-B6A47D9D-62D3-41A6-920D-5B019249028A v1
STAn:Bat
where
'n' 0 ... 50 000. 'n' must not be omitted from the object notation
The STA attributes of stations defined in another base system are accessed with the following object
notation:
STAn:mBat
where
'm' The logical application number of an external application (see the TT attribute in Section 7.
'n' The object number of the station in the other base system
[1] LONWORKS is a trademark of Echelon Corporation registered in the United States and other countries.
The attribute is set when the first AUTO state process object connects to the station.
The attribute is set when the communication between a process database unit and the station is
established. This happens when the first process object of the unit is created.
The node number of the NET unit is the same as the NET system object number.
If the station type of the station is "OPC" or "OAE", the ND attribute is the node number of the node
object that specifies the OPC server of the station (see Section 10).
For proxy stations (see Section 11.2.2.3), this is a read-only attribute that reflects the ND attribute of
the active station. When no connection to the process has been established, its value is 0.
This attribute has no functional purpose for the base system if the station is an image station (MR =
"IMAGE"). However, it may be set for documentation or application purposes.
The status may be stored in the database as a FAULTY status 1 (default behavior), or it may be
changed to 2 (OBSOLETE_STATUS, or INVALID).
This attribute has been implemented to prevent excessive events and alarms from gateway
applications that report some communication problems by status 1.
This attribute specifies how the activation criteria (attributes PA, AA and HA) are interpreted in case
the status of the process object changes from 0 to 2 or vice versa while the object value (OV)
remains unchanged. The keyword specifies when the status change is considered to fulfill the
criterion NEW VALUE.
The phrase "when OS is set" means here that the status is explicitly set by SCIL, an OPC client or a
process (ACP) message, as opposed to the implicit status change to 2 caused by lost connection to
the station.
If the policy is "DEFAULT" and the policy of the application (APL:BPP, see Section 7) is "DEFAULT"
as well, the "WHEN_SET_TO_2" policy is applied for compatibility.
If the value of the attribute is an empty list (the default value), the application default specified by the
similar SM attribute of the application object is applied, see Section 7.7.1.
"DNP" Distributed Network Protocol for upper level and process level
communication
"OPC" Any field device exposing its data via an OPC Data Access Server
"OAE" Any field device exposing its data via an OPC Alarm and Event Server
Additional station type names defined by STY objects, see Section 11.3.
Default value: SYS:BDS
Access: No restrictions
For stations connected to a NET unit, TN is the STA system object number in the NET. The
communication unit may have own limitations for the value range of the attribute TN and the amount
of STA objects created to the instance of the unit. These limitations may depend on the used
protocol. For the PC-NET communication unit, see description of the NET Node attribute DV in
Section 15.4.4. For other communication units, see corresponding manual. If TN is modified on-line,
the application logic must ensure that a valid basesystem STA object is configured for each STA
object configured to the NET unit all the time. The swapping of the TN values between two STA
objects is usually used in project specific solutions of back-up connections.
For "OPC" type stations, TN is the device number within the OPC server, or 0, if the OPC server
does not support numbered devices.
For proxy stations (see Section 11.2.2.3), this is a read-only attribute that reflects the TN attribute of
the active station. When no connection to the process has been established, its value is 0.
This attribute has no functional purpose for the base system if the station is an image station (MR =
"IMAGE"). However, It may be set for documentation or application purposes.
If value "STA", i.e. local time different from the base system’s local time, is specified, attribute TB
must be set to tell the bias.
The attribute is set when the first AUTO state process object connects to the station.
For further information about the mirroring concept, see the System Configuration manual.
An 'event object' here means that every update of the object value is significant and may not be
sacrificed for communication throughput.
Notes:
1. The value may be set only as a whole. Single vector elements may not be set.
2. In mirroring, the value of this attribute is in use only when the mirroring role (MR) of the station is
"HOST" or "BOTH".
3. In mirroring, the value of this attribute is checked only when a subscription of process events is
received from an image application. If, during the mirroring communication, an immediate effect
after a change is required, the mirroring of the station must be stopped and then restarted (for
example by setting MR to "NONE" and then back to "HOST").
This attribute is cleared (APL and UN set to 0) when attribute MR is set to "NONE" or "HOST".
This attribute is cleared (APL and UN of each vector element set to 0) when attribute MR is set to
"NONE" or "IMAGE".
The "DEFAULT" behavior depends on the station type. The policy is defined by the LP attribute of the
corresponding STY object.
In mirroring, the value of this attribute has a meaning only when the mirroring role (MR) of the station
is "HOST" or "BOTH".
For proxy stations (see Section 11.2.2.3), this attribute defines the buffering scheme of analog
process events.
The value of this attribute is checked only when the process database is set up. If an
immediate effect after a change is required, the mirroring of the station must be stopped
and then restarted (for example by setting MR to "NONE" and then back to "HOST").
Notes:
Overview GUID-D221EA8F-B524-4DCD-8204-AC0618505A51 v1
A redundant station configuration consists of
In the first case, the events received by the base system via the two communication links are
identical. In the second case, time stamps of the events may differ slightly and polled values
(typically analog values) are received at mutually independent intervals.
The implementation of station redundancy at the base system level is described below. It guarantees
that no events are lost nor duplicated when one of the two communication links between the IED and
the base system fails.
1. The proxy STA object represents the redundant station for the application. It is not directly
connected to the IED.
2. The primary STA object represents the primary communication route between the base system
and the IED.
3. The secondary STA object represents the secondary communication route between the base
system and the IED.
The role of each STA object in the redundancy is defined by their RR (Redundancy Role) attribute.
Each proxy STA object contains references to its primary and secondary STA object (attributes PS
and SS), and each primary and secondary STA object contains a reference to its proxy STA object
(attribute RS).
Commands (process object SET’s) and requests (access to STA:S attributes) for the proxy STA
object are sent via its active STA object. Primary and secondary STA objects may not be explicitly
accessed by the process database, no unit (UN) in the database can refer to a primary or a
secondary STA. On the other hand, the primary and the secondary STA may be explicitly accessed
via STA:S attributes.
The currently active station may be read from the AS (Active Station) attribute of the proxy STA
object. By setting the same attribute, the active station is forced and automatic routing by the base
system is disabled.
Switch-over GUID-0F800211-82C4-4556-A45A-A6D334B8B425 v1
When the connection to the IED via the currently active STA object has been lost, the base system
automatically switches to use the stand-by STA object, if it is in RUNNING state. The buffered events
of the stand-by STA are browsed and new events (the events not received via the lost connection)
are fed into the process database. Communication between SYS600 and the IED then continues
normally via the new route. No events are lost nor duplicated.
When both connections to the IED have been established (or re-established after a connection
break), the PR (Prefer Primary) attribute of the proxy STA object is examined by the base system. If it
is set to 1 and the secondary STA is currently active, a switch-over to the primary takes place.
An application event (APL_EVENT) is generated for each change of active station, see the
Application Objects manual.
Here, the event time stamps are considered equal if they differ less than 10 milliseconds. This allows
for a small synchronization bias between redundant IED’s.
Not all analog values are kept, they are buffered according to the scheme used in mirroring. The
policy is configured by the LP (Load Control Policy) and the AE (Analog Events) attribute of the proxy
STA object, see Section 11.2.2.2.
The events sent to the cold application that is in HOT_RC shadowing phase are buffered by the base
system exactly like the events received via the stand-by route in the redundant station scheme
described above. The situation may be seen as an analog of a redundant station, where the events
received by shadowing come from the ’active station’ and the events from the communication unit
come from the 'stand-by station'.
When the receiving application becomes hot at HSB switch-over, the buffered new events that have
not been received via shadowing are fed into the process database. Again, no events are lost nor
duplicated.
Note that the behavior at HSB switch-over is independent of station redundancy. It works in the same
way for redundant and non-redundant stations and is based on RUNNING/SUSPENDED reporting
from communication modules. With External OPC DA Clients, it is thus recommended to use the
SE=4 configuration if connected to an IEC 61850 OPC Server or SNMP OPC Server. See also
SYS600 External OPC Data Access Client, circular buffering. Buffering in the cold application is not
available with PC-NET communication units. This means that the communication lines of the PC-
NET unit should be kept out of use when the main application is cold. For more information, see the
SYS600 System Configuration manual. For IEC 60870-6 (ICCP) and IEC 61850 Client, see protocol-
specific manuals, section 'Starting and Stopping communication'. Buffering in a cold system requires
that communication is enabled in the WD application.
Attributes GUID-6074B32C-C7A6-453C-BA73-C93C1CF99638 v1
The attributes related to redundant stations are described below. In addition, attributes AE (Analog
Events) and LP (Load Control Policy) are applied to redundant stations, see Section 11.2.2.2.
This attribute is relevant to PROXY objects only. In other STA objects, its value must be 0.
When read, the attribute tells which one of the two routings currently feeds the process database. By
default, the routing is automatically selected by the base system.
When set to 1 or 2 (or the STA object is created with AS value 1 or 2), the routing is forced to the
given value. Automatic routing is disabled.
This attribute is effective only when the secondary station is the active station and the primary station
becomes RUNNING. If PR is set to 1, the base system in this situation switches to use the primary
routing.
This attribute is relevant to PROXY objects only. In other STA objects, its value must be 0.
This attribute is relevant to PRIMARY and SECONDARY objects only. In other STA objects, its value
must be 0.
This attribute is relevant to PROXY objects only. In other STA objects, its value must be 0.
The primary and secondary STA object are first created but not started, because the proxy STA does
not yet exist. After the proxy has been created, the primary and the secondary are ready to start. The
first example below shows the configuration when the primary and secondary stations are in different
nodes. The value of TN defines the used object number in the communication module and same TN
value cannot appear twice within the same node. This example is applicable to especially to External
OPC DA client nodes where the same configuration file is used as a template for both primary and
secondary nodes.
The second example below shows the configuration when the primary and secondary stations are in
the same node. The value of TN defines the used object number in the communication module and it
must be different within the same node. The value of the TN is freely selectable but the most
common practise is to use the same value as in the station number. This example is applicable
especially to PC-NET nodes. It is worth to note the if the primary and secondary nodes are
configured to the same node, the decreases the level of the redundancy.
The operation is fully functional not until at least one process object to the destination application has
been created for the proxy station and it is in automatic state (SS=2).
In case the primary and secondary STA objects are connected to different IEDs, it is possible that
some data items from the process have different values depending on the IED which is transmitting
the data. Even if the IEDs are controlling the same part of the process.
Because of this, it is recommended to update the process database whenever the active station
changes. In practise, this can be implemented by attaching a piece of code to the command
procedure which is activated by pre-defined event channel APL_EVENT. Snapshot variables
%SOURCE_NR defines the STA number and the required action is dependent on used protocol. See
protocol specific manuals for details.
#block_end
For IEC61850 devices the forced update is needed because the events from the IED which becomes
active can be considered as buffered and will be discarded from the External OPC DA Client. The
time delay is needed to handle the situation when the system starts, the communication ok event is
received before the buffered reports has been enabled and without the delay invalid data would be
transmitted creating unnecessary burst to event list and possible NCC connections.
The predefined station types listed in the ST attribute description in Section 11.2.2 are not enough for
all possible station types. Using the STY object, additional station types can be defined provided that
they can use an existing database interface (the database interface of a predefined station type).
Using the STY object also enables that some properties of the predefined station types can be
accessed.
The station types are internally recognized by an integer 0 ... 33. The station types with numbers 0 ...
21, 29 … 30 and 32 ... 33 are reserved for predefined types. Other station types are reserved as
follows:
• Type number 22 for the "SPI" type (stations connected via RP570 slave protocol).
• Type number 23 for "LMK" stations (stations on LONWORKS lines, other than REx and SPA).
The station types can be given freely chosen names. However, it is recommended that the names
given in Table 1 are used because these are the names used on NET unit. The table lists some
station types and the corresponding database interfaces.
The STY objects and their attributes are accessed with the following object notation:
GUID-42EA21AA-634D-4C32-A551-4D57E73018C9 v1
STYn:Bat
where
'n' the internal station type number, 1 ... 33. The following station type numbers are preset:
3 STA
4 RTU
5 SIN
6 PCL
7 SID
8 PAC
9 SAT
17 REX
20 LCU
21 SPA
22* SPI
23* LMK
24* ADE
25* PCO
26* WES
27* ATR
28* PLC
29 IEC
30 DNP
32 OPC
33 OAE
* These station type numbers have to be created separately.
The logical meaning of the CT attribute of the process objects updated from stations of the station
type in question.
STY17:BCT2 "INTERROGATED"
STY17:BCT3 "HISTORY"
Access: No restrictions
Example:
If a device of type 17 (REX_DEVICE) updates a process object's CT attribute to value 2, the attribute
STY17:BCT2 defines the reason of that transmission ("INTERROGATED" by default).
Specifies the predefined station type whose data interface will be used. When a new station type is
defined, it must use the same data interface as a predefined station type, see Table 1. The
predefined interface is used when NET unit issues commands to the stations of the new type.
Example:
Load control policy applied to the analog input objects of the stations of the type.
For those STY objects that have the DB attribute value "STA", the "DEFAULT" policy is equivalent to
"KEEP_TIME_STAMPED_ANALOGS". In all other cases, the "DEFAULT" policy is equivalent to
"KEEP_NO_ANALOGS".
This attribute is overridden on a station basis by the LP attribute of the station object.
The value of this attribute is checked only when the process database is set up for
mirroring. If an immediate effect after a change is required, the mirroring of the stations of
the type must be stopped and then restarted (for example by setting MR to "NONE" and
then back to "HOST").
This section describes the PRI base system objects and their attributes. It contains two sections:
Section 12.2 General: the definition of PRI objects and the PRI object notation.
Section 12.3 PRI attributes:
All printers used by the SYS600 base system (and its applications) must be defined as PRI objects,
whether they are connected directly to the base system computer, to a LAN or to a NET unit. A base
system can use up to 20 printers. The printers are connected to an application using the printer
mapping attribute (APLn:BPR, see Section 7). A certain printer can be used by several applications
in different base systems.
It is possible to define printers that have no real physical correspondence (virtual printers). These are
used for obtaining printout on disk only (see Printer Log, Section 12.3.5). It is also possible to define
more than one PRI object for one physical printer. This may be useful if several types of printouts, for
example semi-graphic and full graphic, are printed to the same printer.
From SCIL the PRI object attributes are accessed with the object notation:
GUID-9834E9B2-84A2-44CD-BE4E-7A85A31BB379 v1
PRIn:Bat
where
'n' Indicates printer number, which can be 1 ... 20. The 'n' may not be omitted from the object
notation.
'at' Attribute name
The PRI attributes of printers defined in another base system are accessed with the following object
notation:
GUID-F8C926E3-8DB8-4CA1-ACAB-67364362A5AD v1
PRIn:mBat
where
'm' The logical application number of an external application (see the TT attribute in Section 7
'n' The object number of the printer in the other base system
The type of the printer connection. See examples considering DT attribute below to see how to use
the attribute for different connection and printer types.
Printers connected directly to the base system computer or to a LAN always produce black and white
printout, unless the printers are defined as 'transparent'. Concerning printers connected to NET units,
the value of this attribute must coincide with the communication system attribute PRIn:SPT (see
Section 18). Some examples of PRI object definitions for different printer types and connections are
presented later in this section.
Black and white ASCII Interface with character translation according to the PRIn:SCT attribute,
or pixel based, black and white or color printer that uses the EPSON FX-80 or EPSON JX-80
interface (PRIn:SPT = 5, 3 or 7 respectively):
PRIn:BTT = "LOCAL"
PRIn:BND = NET node number
PRIn:BTN = PRI system object number in NET unit
PRIn:BDT = "NORMAL"
PRIn:BDC = "NET"
The operating state of the printer. See examples considering DT attribute above.
The node number (NOD object number) of the NET unit to which the printer is connected, if the
printer is connected to a NET unit. See examples considering DT attribute above.
The name of the printer or UNC path. The attribute applies to printers that are connected directly to a
base system computer or to a LAN via a printer server (DC = "LINE"). See examples considering DT
attribute above.
Printers connected to NET units and printers defined as "alias". For a printer connected to a
communication unit, the attribute is the system object number of the printer as known to the actual
communication unit, see examples considering DT attribute above. For "alias" printers, it is the
PRIn:B object number of the printer to which the printout is redirected (see the TT attribute).
To redirect printout, use the CL attribute that sets the TN and TT attributes automatically.
Access: No restrictions
This attribute is a vector of printer control sequences (printer commands and control codes)
specifying the printer control commands used by the PRINT_TRANSPARENT function, see the
Programming Language SCIL manual.
Each element of the vector specifies a control sequence that can be defined as a text value
containing the bytes to be sent to the printer. It can also be a vector of text values, printer control
commands and print processing commands. A control sequence is referred to by the index of the
element. The control sequences are printer interface dependent. However, by using the same
conventions for all printers, the PRINT_TRANSPARENT function can be used equally independent of
printer type.
If track-keeping of page numbers and line numbers is in use (the LP attribute is set), the print
processor (PRNC) tries to count the lines of the through-passing output flow. The New Line as well
as New Page commands are accounted for. However, there is no possibility for the print processor to
know which control sequences move the paper vertically. Therefore, use the print processor
commands Increment LN and Increment PN to notify about such moves (in the CS vector element or
in the print vector defined by the PRINT_TRANSPARENT function)
Example:
For example, if the printer is a simple ASCII printer, CS(1) (the control sequence for New Line)
should contain the two-byte text calculated as ASCII(13) + ASCII(10) (CR / LF).
The header text produced on each printed page when page numbering is in use (PN > = 0). The text
can contain constant as well as variable text.
Example:
The line count of the printed text, starting from 1. Possible header lines are included in the count.
The page numbering and the generation of headers for printouts. The feature applies to the
automatic process printout (event and alarm printout) and printout started by the #LIST command
and #PRINT commands if the FORM_FEED variable is = 0. It does not apply to pages printed with !
SEND_PIC or #PRINT with FORM_FEED <> 0, nor to pages produced by documentation tools. Such
pages do not get any header and are not included in the printout numbering.
If page numbering is in use, a variable %PN that contains the page number is automatically
generated and can be used in the header text, the HF attribute, see above.
Maximum number of printout requests in the printer queue. When this length is exceeded, an error
message is displayed in the Notification Window and some of the oldest requests are lost. Event
channel SYS_EVENT (see the Application Objects manual) is activated to notify the application(s)
about the event.
A printer log is a copy stored on disk of all printouts sent to the printer. Each printer can have its own
printer log. The printer log directory is defined by the LD attribute. The name of a printer log file
depends on the printer number and the logging period. See the LL attribute below. The name
contains the following information ('nn' = PRI object number, 'yy' = year, 'ww' = week number, 'mm' =
month, 'dd' = day):
Storing printout in a printer log is possible even if the printer does not exist physically. Hence, virtual
printers, that is, PRI objects without corresponding physical printers, can be defined to get the
printout exclusively to printer log files. The maximum size of the files is determined by the computer
resources and the operating system.
If a printer has a printer log, everything sent to the printer is copied to the printer log, independent of
how the printout is activated (with #PRINT, #LIST or !SEND_PIC, or automatically from the process
database) or from which application the printout is activated (several applications can use the same
printer). As the printout can contain picture elements, the printer log files contain the same characters
as the printout to a black and white ASCII printer.
The attribute has no meaning if OD = "PRINTER". The PRI object attribute OD defines the output
destination of the log.
Unit: Milliseconds
Default value: 1000 milliseconds
Access: No restrictions
Defines how often the operating system buffer is written to the log file on disk. The operating system
keeps a RAM buffer of the output to the printout log on disk. There are the following three
alternatives:
• The operating system transfers the contents to disk when the buffer is full. In the case of
hardware failure (for example a power break), the content of the buffer is lost.
• The buffering handled by the operating system is bypassed, so that each new log entry is
immediately stored on disk. This procedure loads the system.
• The buffer is emptied regularly with a selected time interval
The period (day, week, month or year) during which the printer log is written to one file. When a new
period begins (always at midnight, 00:00:00), the log switches to a new file.
The attribute has no meaning if OD = "PRINTER". The PRI object attribute OD defines the output
destination of the log. See below.
Defines if the printout to the printer will be copied to a printer log on disk or not.
Enabling control of the printer and facilitating a redirection of the printout to another printer, for
example in error situations.
When redirecting the printout from one printer to another using this attribute, the jobs in the input
queue of the printer are moved to the input queue of the new printer.
Setting the attribute is meaningful only if the printer is in normal operating state (TT = "LOCAL").
Example:
States whether the printer will be opened (reserved) once and kept open continuously, or opened
and closed on job basis.
Global variables used in tools, etc. The attribute should not be used in application programs.
This section describes the Base System Object Navigator tool located in the SYS600 Tool
Manager System Configuration page.
The Base System Object Navigator tool is an on-line tool that provides the following common
functionality:
Because the tool is an on-line tool, the modified attribute values or added base system objects affect
only the running system. If there is need to configure the system permanently, the changes should be
made to base system configuration files (e.g. SYS_BASCON.COM).
During start-up, the tool reads all the found base system objects regarding to the system
configuration. For each found base system object, the object related set of base system attributes is
read.
In the main view of this tool, all of the above mentioned base system objects are presented in
hierarchical way in an object tree. Navigation in the object tree, e.g. expanding the Applications
category, shows a set of leaves, each of which represent one application that was located from the
SYS600 system. The shown leaves in the tree are identified by additional information to provide
easier location of base system object under user's interest. Depending of the base system objects,
the following identification is provided in the tree:
• Application number, name, operating and application states. In applications of operation state
PROXY application numbers constituting a HSB pair are shown instead of application state
• Monitor number, monitor type and application number into which the monitor is connected
• Node number, station address of the node and LAN node name (if any)
• Station number and station type
• Number of station type, name of the type, database interface and comment text (if any)
• Printer number, printer type and operating state
The number, name, type and states are displayed either by using textual information or using
different type and/or color in icon representation. The current application and monitor are marked by
asterisk. Asterisk stays after the application and monitor number.
In the main view of this tool, all the base system object related attributes and their values are also
presented in hierarchical way in attribute tree. For example, selecting of one leaf under certain
category lists all the base system attributes and values regarding the selection. The amount of shown
attributes depends on the base system object type. Each unique attribute belongs to a group of
attributes. The used group names are identical to those used in the documentation of SYS600
system (System Objects manual), e.g. for Application base system object:
Attributes may also be shown in alphabetical order by selecting All Attributes in Alphabetical
Order from the View drop-down list. Each unique attribute is displayed with its two-char identification
name (e.g. AN, AS or HP), together with its attribute description (e.g. Application Name, Application
State or History Logging Policy) and data type identification (in the form the different type in icon
representation). The attribute values are presented with or without attribute value descriptions
(e.g. 10, or 1 - Enabled). If an attribute value has a certain unit for the values, the unit information is
also included in the end of attribute description inside the brackets (e.g. Shadowing Flush Time [ms].
When an attribute is selected in the tool, a help text of the selected attribute is displayed in the
information bar of the tool.
In the main view of this tool, the base system attribute values are also presented, and they may be
modified in the Edit Attribute area. When a base system attribute is selected under a certain group
name, its current value is presented. The user can then use the appropriate dialog items to modify
them. For example, when an attribute value contains certain keywords, the possible keywords are
presented in a drop-down list from which the user may select an item. The role of the Edit Attribute
area is to contain verification of the attribute value. If the user enters a non-valid value, the previous
valid value is silently returned. If the attribute value is formally right, but it conflicts somehow with the
system, the appropriate message box is displayed to the user as a result of non-valid data entry.
Limitations: In the edit attribute area, it is not possible to insert new elements into
complex data types (vectors and lists, e.g. Global Paths, Representation Library and Text
Database attributes of APL). Also, the existing element cannot be removed. The
capabilities of the edit area are to display the data structures as static and edit values of
existing elements. However, it is possible to modify complex data types in the edit area
for structured attributes. In that area, data is presented as a SCIL expression. The edit
area for structured attributes is shown when a node of a complex attribute is selected in
the attribute tree Figure 10. Note that the simple data type BYTE_STRING can only be
modified in the edit area of structured attributes.
When adding a new base system object, first select the category of the base system object in the
object tree of the tool. E.g. when there is need to add a new application, the Applications category is
selected first. Then, select Object ->New from the menu, enter keystroke CTRL+N or click the New
Object toolbar button.
GUID-1A46FCDF-B0A4-4A6C-ACC5-EB334DBD6F3F V1 EN-US
New Object dialog is displayed and an object number is requested from the user. When adding a
monitor object, a monitor type is required. Depending on the base system object type to be added,
different set of attributes need to be specified by the user before the base system object adding may
proceed. For example, at least the following information needs to be specified for a new application
object:
• Application name or
• Operating state (Translation Type, TT) attribute.
If an error occurs during the creation of base system object, an appropriate message box is shown to
the user with additional status information.
To start the Base System Object Navigator tool, click the Base System tool icon in the SYS600 Tool
Manager System Configuration page and select Open from File menu or double-click the tool icon
Figure 7.
GUID-79CD3335-0400-41E6-B998-5AB1F900F747 V1 EN-US
Figure 7: Base System Object Navigator tool on the System Configuration page of Tool
Manager.
The Base System Object Navigator tool page includes a menu bar and a toolbar, which can be
selected from the Options /Toolbar . Below the toolbar, there is an object tree on the left, an
attribute tree in the middle and an attribute editing area on the right hand side. In addition, there is an
information text bar at the bottom of the page.
GUID-276F2187-C312-4865-BE50-5092A927C24D V1 EN-US
Figure 8: The menu bar, tool bar, object tree and attribute tree in the Base System Object
Navigator tool.
GUID-3A9E3ADB-A8C4-408E-8B4B-1436781E1CA9 V1 EN-US
Figure 9: The attribute area and attribute edit area in the attribute tree of the Base System
Object Navigator tool.
GUID-94FAAE02-5AB9-4D81-A86B-30E5954FC2AD V1 EN-US
Figure 10: The attribute area and edit area for structured attributes in the attribute tree of the
Base System Object Navigator tool. By clicking Notify button after editing saves
the given value.
When an object is selected from the object tree, all the attributes linked to it are shown in the attribute
tree (see Figure 8). The working order is from left to right: after selecting an object in the object tree,
an attribute can be selected in the attribute tree and the selected attribute can be edited in the
attribute editing area.
A tree can be expanded by clicking the + sign on the left or by double-clicking the text area on the
right. Likewise, the tree can be collapsed by clicking the - sign or double-clicking the text area. The -
sign means that the branch of the tree cannot be expanded any further.
The whole attribute tree can be expanded and collapsed using the + and - buttons that are situated
below the tree or by right-clicking the tree and selecting Expand All or Collapse All from the pop-up
menu (see Figure 14).
GUID-055092AC-DDD4-4147-9190-FD92024A30E8 V1 EN-US
Figure 11: The Expand and collapse buttons and pop-up menu for the attribute tree.
Start the management tool either by selecting Base Object from the object attribute tree or by
selecting Tools/HSB Management . The menu is enabled if the shadowing attribute SH of Base
Object is on.
• Packages
• Shadowing Applications.
The Packages page indicated the versions and statuses of the installed package and disk package.
Install the disk package by clicking the Install button (see Figure 12).
GUID-1C415AFA-69D8-443C-882D-86BAC0FDF307 V1 EN-US
GUID-50E15696-2423-49FD-BCE3-8827D437287A V1 EN-US
Figure 13: The Shadowing Applications page of the HSB Management tool.
Selecting a shadowing application and clicking the Edit button starts the edit dialog of the application
(see Figure 14).
GUID-9BE2D03E-6139-480F-BCE3-B7837DFB2F97 V1 EN-US
Section 14.2 General: This section gives a general description of communication system objects, their features
and functions.
Section 14.3 Communication system object types: The types of the communication system objects. The types
are illustrated by a picture and each type is described briefly.
Section 14.4 Defining communication system objects: The principles for defining communication system
objects, the configuration software and the required definitions.
Section 14.5 Attributes: The function of the communication system attributes and the attribute access levels.
The communication system objects and their attributes specify the NET unit configurations and
handle the process communication. Each NET unit (NET) has its own set-up of system objects. The
communication system objects give the NET unit an image of the communication lines and the
connected devices. The connected devices may be:
During operation, the communication system objects are included in the communication program
running in the host PC.
Each device connected to the process communication system (base system, application,
communication unit, printer and station) has a device image. The device image is in form of a
communication system object in the NET unit to which it is directly connected. The communication
system object attributes of the unit describe the data communication with the devices.
The base systems and communication units are regarded as nodes. These devices are defined by
NET or NOD objects in each NET unit where they are to be recognized, even if they are not directly
connected to it (see Figure 15). As the node numbers are recognized by each communication unit, a
message can be routed to a device connected to another node.
The application engineer can configure the communication network, define routes, control I/O
devices and RTUs, read diagnostic counters, handle system messages, etc. using the
communication system objects and their attributes.
The system object names consist of a predefined three-letter descriptive name, and an object
number that distinguishes units of the same type from each other:
NODn or NETn Node objects: communication units and base systems, 'n' = 1 ... 250
APLn Application objects, 'n' = 1 ... 250
STAn Station objects, 'n' = 1 (0) ... 255 (each station type has its own number series)
PRIn Printer objects, 'n' = 1 ... 8
The 'n' here is the device number as known to the NET unit (integer). In this manual, the number is
called a communication system object number or, where no misunderstanding can occur, simply
object number. The object number must be unique for a specific object type within a certain
communication unit, except that STA objects of different station types can have the same numbers.
The NOD (NET) object numbers are global node numbers and must be unique within the entire
SYS600 network.
When accessing the STA and PRI communication system objects from SCIL, the object number in
the object notation is the number under which the device is known to the application. The APL
objects are accessed from SCIL through the NOD (NET) objects.
Alternatively, communication system objects of type NOD, STA and PRI may be accessed by their
user-defined name, i.e. the name of the corresponding base system object. For example, if the name
of base system object STA5 is PICCADILLY_STATION (STA5:BBN == "PICCADILLY_STATION"),
then notations STA5:S and PICCADILLY_STATION:S are equivalent. See Section 5 for naming base
system objects.
Figure 15 illustrates the system object types and their roles in the system. After that follows a brief
presentation of each system object type.
Workstations
Operator
Console
Figure 15: The communication system objects defined in the shaded NET unit that is a
PCNET running in the base system. The unbolded and unmarked devices require
no object definitions in the NET.
The NOD or NET objects (the names are equivalent) represent the NET unit itself as well as every
other known node (communication units, base systems) in the SYS600 system. The object numbers
of the NET objects are global and may be 1 ... 250.
The SYS600 system engineer uses the NET objects and their attributes for example for the following
purposes:
• Defining the NET itself, e.g. its station address and the system message handling.
• Adding, modifying and removing communication system objects definitions for connected
devices.
• Accessing application object attributes.
By using indices in the NET object notation, the NET line attributes are accessed. The index refers
then to the line in question. The system engineer uses the NET line attributes, for example, for the
following purposes:
• Defining the NET lines by choosing protocols for the communication lines.
• Defining communication line features (baud rate, number of stop bits, etc.).
In this manual, the NET device attributes and the NET line attributes are described in different
sections.
The APL communication system objects refer to applications in the connected base systems. Each
application known to the NET unit must be defined as an APL object. A NET unit can recognize up to
250 APL objects (applications).
The attributes of the application objects are accessed using the NOD (NET) object notation and
giving the APL object number as the index.
This system object type is used to supervise and control properties of connected stations: RTUs,
protective equipment, central stations, etc. Each station (logical or physical) connected to the NET
unit is usually defined as a STA object. The STA objects specify and handle, e.g.:
The STA objects are defined in different ways and have different attributes depending on the station
type they represent. See protocol specific sections and manuals for more information.
One NET unit can be connected to up to 2047 stations and the configuration is made using System
Configuration Tool or SCIL scripts. See SYS600 System Configuration for more information.
Each printer connected to the NET unit must be defined as a PRI object. The PRI objects describe
printer features, such as:
Connecting a new device to a NET unit requires that the corresponding system object is defined in
that unit. This is a condition for the physical connection to work. Defining a new communication
system object means that it is assigned a type specific object number and a line number. The
procedure is:
• Defining the line to be used by assigning it the desired protocol (the PO attribute, see Section
16).
• Giving the line its communication properties using the line attributes (Section 16).
• Creating the object by giving it an object number and assigning it the line number.
• Setting the attributes of the created object.
• Taking the line and the device into use.
The configuration of the NETs can be extended and modified online using SCIL or tools.
In SCIL, the objects are defined using the #SET command. New communication system objects are
created with the device specific NETn:S attributes NE, SY, DV, ST, RT, etc. which are described in
Section 15. The communication system objects cannot be created, deleted or modified with the SCIL
commands #CREATE, #DELETE and #MODIFY.
If a PC-NET unit is stopped and restarted, System Configuration Tool loads the saved configuration
automatically for the unit.
Each PC-NET unit has an initialization file (PC_NET.CF1) which defines the NET unit itself, the host
base system and an application in the host base system. The initialization file is a text file that is read
each time the PC-NET unit is started. This file is used by the System Configuration Tool and should
not be edited by the user.
In addition, the communication system objects can be written online with application dependent
command procedures and pictures, with SCIL or with tools. For example, they can be written with
command procedures started by the event channels APL_INIT_1, APL_INIT_2, and APL_INIT_H,
see the Application Objects manual. It is also possible to build command procedures that are started
at each start-up of a NET unit.
Table 2 provides an overview of the communication system object definitions required by various
configuration projects. It also refers to the sections and sections where the attributes are detailed.
The communication system objects required for various system set-ups are detailed in the System
Configuration manual.
Table 2: An overview of the communication system object definitions required for various configuration projects
• Configuration attributes, which affect the system configuration of the NET unit but do not cause
any immediate data exchange with connected devices.
• Communication attributes, which cause data communication between different devices but do
not affect the system configuration.
The communication system object attributes are of the following main access levels:
• Read-only: The attribute cannot be written. There are still a few exceptions in which the values
can be reset.
• Read, conditional write: The attribute can be given values with #SET provided that the object
first is taken out of use (IU = 0).
• Write-only: The attribute cannot be read, only written with the #SET command. It is not stored in
NET unit, but transmitted directly to a station.
• No restrictions: The attribute can be read and written without restrictions.
This section describes the NOD (NET) objects and their attributes.
Section 15.2 General: The definition of NOD (NET) objects and the object notation.
Section 15.3 Basic NET attributes: Basic Definitions (NN, SA, SX), Functional Specifications (TL), NET
Information (KP, NT, VE), System Message Attributes (MI, MS, SE, UI, UA), Connected Nodes
(AD, LI).
Section 15.4 Object definition attributes: External Nodes (NE), Applications (SY), Station Definition Attributes
(LC, LM, PC, RT, RX, SM, SP, ST), Adding Devices of Exchangeable Device Types (DV), Printer
Definition Attributes (PR).
Section 15.5 Application attributes: DS, SU, SW.
Section 15.6 Authentication attributes: KS.
Section 15.7 Miscellaneous NET device attributes: FM, LT, MA, MU, TM.
The NET attributes related to the communication lines are described in the next section.
The following devices must be defined as NOD (NET) objects in a NET unit (NET):
• The NET unit itself. This is done by the System Configuration Tool for each created NET unit.
• All other communication units which will be recognized by the unit.
• All base systems, which will communicate with the unit.
The NET unit itself must is defined in the initialization file if of the PC-NET. The other nodes (external
nodes) are defined by setting the NE attribute (see Section 15.4) of the NET node.
The system object numbers of the nodes (node numbers), 1 ... 250, must be unique within the entire
SYS600 network. For communication units and base systems, they must be the same as the node
numbers defined with the NOD base system objects (NODn:B) (see Section 10). The node numbers
can be taken into use in any order.
In case the node number given to PC-NET node is bigger than 50, the default addresses of the
general NET Messages and application diagnostic messages defined with NET node attribute MI
may overlap with some other NET node having a number = node number - 50. If this happens, a
new, not overlapping value must be given to attribute MI. The object addresses of the SYS_NETD:Px
created by the System Self Supervision must be re-entered manually.
From SCIL, the NET attributes of the NET unit or a CPI-based communication module is accessed
with the notation (the NOD and NET names are equivalent):
GUID-B206E5C8-6B39-44D8-98F2-F4546BD76937 v1
NODn:Sat (or NETn:Sat)
where
'n' The object number (= node number) of the unit, 1 ... 250
'at' An attribute name
The NET attributes of other nodes (external nodes) defined in the communication unit, that is, other
communication units and base systems are accessed with the notation:
GUID-0288C90D-4CB1-4A72-8EB4-0BA3E0B1C5F5 v1
NODn:Satm (or NETn:Satm)
where
'n' The node number of the NET unit where the object is defined.
'm' The node number of the base system or communication unit. The application attributes are
accessed in an analogue manner.
The NET object number. The number is defined when the PC-NET unit reads its configuration from
the PC_NET.CF1 file. An external NET object is created with the NET attribute NE (Section 15.4). As
a rule, the attribute should be regarded as read-only.
Example:
The NET number of an external NET (base system or communication unit) is changed (not
recommended):
#SET NET1:SNN2 = 3
The ACP station address of the NET object (communication unit or base system). The station
address is used in all communication between nodes. The address must be unique among all NETs
and base systems in the entire network. At online station address configuration the communication
program checks that this uniqueness is maintained.
Example:
Defines that the NET2 connection in NET1 will have the station address 27:
#SET NET1:SSA2 = 27
The station address of the NET used in the communication with ANSI stations. The address is used
as the source address in messages to the stations and should be given as destination address in the
stations. It must not be the same as a station address used by any connected ANSI station.
However, it may be the same as the ANSI address of stations connected to other NETs. The attribute
has no meaning if no ANSI station is connected to the communication unit.
The maximum number of logical destination translations accomplished on the same message. The
attribute concerns node data communication (NET-NET communication), that is communication with
other communication units and base systems.
This attribute prevents messages from circulating eternally in a network composed of several nodes
(for example because of some configuration error).
Example:
When NET node attribute KP is read, vector with the following elements is returned
(1,2,3,4,7,9,12,13,14,15,16,17,18,23,25,26,27,28,30,31,32,33,35,41,43,44,45)
The type of the node: NET, base system, workstation or gateway. Attribute is not supported by the
communication modules using CPI-library.
The attributes of this section affect the transmission of system messages from the NET unit to one or
more applications in one or more base systems.
The system messages are integer values, which inform an application about changes in the device
communication. System messages are generated by STA, PRI and NET objects at the appearance
and disappearance of abnormal situations. A system message contains a status code, which
describes the state of the device (see the manual Status Codes). As a rule, the status code in a
system message is zero, if the message indicates recovery from an error situation, otherwise non
zero (an exception is the application messages, see below).
Communication units generate system messages, for example, in the following situations:
In the process database of an application the attributes MS and MT direct the communication system
messages from NET unit to a fictitious process object. The transmission of system messages from
NET unit can be enabled or disabled using the SE attribute. The status codes of the system
messages can be used in the application (specified by the MS attribute) as follows:
1. Create a fictitious analog process object (AI) with the object address OA = the MI attribute
below. The system message codes of the device will be registered as the object value of this
process object.
2. Define the consequential operations by means of event, alarm and printout attributes, see
Figure 16. For more information, see the System Configuration manual.
System Messages
APL
History Buffer
Process
Database
.
OS = 2 Alarm Handling
.
.
.
.
Object
Event Command
. Channel Procedures
.
. MI
Data Invalidation
MS
Configuration Control
PRINTER
RTU
Process Control Operator Messages
System_message_handling.eps
GUID-7E92D055-6A15-474E-A3B0-318863CCCEB8 V1 EN-US
The object addresses (the OA process object attribute) of the process objects, which will receive the
system messages generated by the device. At the generation of a system message, the status code
of the message is updated in the OV attribute of the process objects. The process objects are
specified by the MI attribute in the application specified by the MS attribute. The status code is not
registered if there are no fictitious process objects with the specified address. NET unit generates
two types of system messages, which are directed to process objects as follows:
If the NET node attribute SE (System messages enabled) has a value 4, a binary process object is
updated at the same time as the analog process object mentioned above. The binary process object
must be of type ANSI Binary Input and its unit number UN must also be 0. The address of this
process object is MI+16777216 (MI+1000000hex) and its OV attribute has values 1 (station is OK) or
0 (station is not OK). See the example at the end of this description.
In case the node number given to PC-NET node is bigger than 50, the default addresses of the
general NET Messages and application diagnostic messages defined with NET attribute MI may
overlap with some other NET node having a number = node number - 50. In case the node number
given to PC-NET node is bigger than 100, the overlapping may occur with the NET line supervision
objects, too (see formula below). If either of these happens, a new, not overlapping value must be
given to attribute MI. The object addresses of the supervision process objects created by the System
Self Supervision (SYS_NETD:Px) must be re-entered to match with the given MI value.
Example:
The system message receiving process object in application 3 should have the following attribute
features:
#SET STA2:SMS = 3
If the NET node attribute SE (System messages enabled) has a value 4, following process object is
also updated:
The communication system object number of the application, which receives the system messages
from the device. If the application is suspended, the message is sent to the first application that is not
suspended in number order.
The NET start-up system message code (10001) is sent to all known applications, independently of
the MS attribute.
Example:
If MS == 3, the system messages related to the NET unit are sent to the application defined as
number 3 in the NET unit
Makes it possible to disable the system messages of a NET unit, state whether system messages
related to a NET unit are to be sent to the base system or not. When the sending of system
messages is disabled, the messages (up to 20 per object) are queued in the communication unit.
The queued messages are sent all at a time when the transmission of system messages are
enabled.
The address of the analog status process object is defined by the MI attribute. The corresponding
binary status object has an object address OA = MI+16777216 (MI+1000000hex), OB = 0. The
meaning of the binary status object is to indicate whether the line or the application is OK or not
(1=OK, 0=not OK).
The UI attribute is used to define the name for the node for the UAL (User activity logging) events. It
is used to identify the source of the UAL events. Since this string is added to the identification
information of all user UAL events from this node, a unique value within the system is preferred. In
case the source of the event is a STA object or a line object within the node, identification information
will also contain the contents of the station or line level attribute UI. In case the event is generated
from the node level, the identification information is formed based only on the contents of the node
level attribute UI. If node identifier is not needed, empty string should be assigned to this attribute.
Attribute UA defines whether the user activity events from this node are generated or not. If the UAL
event generation is enabled for the node, it may still be disabled by the STA object.
Indicates whether a station address is reserved by a node or not. This attribute gives access to the
ACP (application communication protocol) station address table of the communication unit. The table
contains the NET object numbers and the corresponding station addresses.
Example:
The expression NET1:SAD10 could for example yield the value 4106, which is 4096 + 10. The ACP
station address 10 is reserved by NET10.
The number of the communication line, to which a node (another communication unit or a base
system) is connected. If the node is indirectly connected to the communication unit, the attribute is
the number of the line to the nearest node. The line number is selected when the connected NET
object is created.
Example:
Each communication unit and base system that will be recognized by a communication unit, must be
defined as a node, a NOD (NET) communication system object, in the unit. Also all communication
units connected in a series and all base systems connected to any of them must be defined as a
node. The external nodes are defined by giving them a device number (= object number, node
number) and assigning them a line number of an ACP or Integrated Link line.
With SCIL or in the system configuration, the nodes are added by means of the NE attribute
described below. After a NOD (NET) object has been defined, it must be given a station address with
the SA and SX attributes described in Section 15.3.
Adding and removing the NET objects of connected nodes in communication units and base
systems.
When adding a node, the NE attribute is assigned the value of the connection line, which must have
been defined as an ACP or Integrated Link line (see Section 16). The line number for a node that is
connected indirectly via other communication units is the line number of the nearest communication
unit. PC-NET communication units are connected to the base system on line number 13. When
adding a node (that is a new NET object), an error code is produced if the object already exists.
When removing a NET unit, the attribute is assigned a "D". Removing a node means that the NET
object, including all its attributes, is deleted.
Example:
#SET NET2:SNE3 = 4
All applications that will communicate with a NET unit, i.e. all applications that will receive any type of
messages from NET unit (spontaneous messages, data, system messages, etc.), and all application
that will write system configuration data in NET unit must be defined as APL objects in the unit. An
application is defined by the node number of the base system, the APLn:B object number in the base
system in question and by an APLn:S system object number (device number). Applications are
defined by means of the SY attribute described below.
Adding, removing and redefining an APL object, that is an application, with SCIL. Adding an
application means that an APL object is created. Removing an application means that the APL
object, including all its attributes, is deleted. A previously created APL can be redefined, for example,
so that it refers to an application in another base system.
Example:
The application 5 (APL5:B) in the base system with node number 9 is defined to the NET unit NET1
as APL5:S:
Each IED or station directly connected to the NET unit must have a corresponding STA object. A STA
object is defined by a station type, a system object number (device number) and the NET connection
line. Before a STA object can be created, a NET line with the correct protocol must be defined. Most
station types allow the connection of several stations to one line. Stations using the ANSI full duplex
and the RP570 slave protocols require one NET line per station.
REX REx relays - REF, REL, REC, RED, etc. - connected via LON
LCU Load Control Unit, LCU500
SPA SPA modules connected directly to a NET unit or to a LONWORKS line via an LSG device (a
LON/SPA gateway)
SPI Stations connected via the RP570 slave protocol
LMK LSG devices connected to LONWORKS lines and other LONWORKS devices (for example a
Weidmüller node), but not REX type stations.
Some other station types can be defined as exchangeable device types, see Section 15.4.4.
The STA object numbers must be unique for a certain station type, but STA objects of different types
can use the same object number. Stations of the types SPA, RTU, PCL and LCU use station number
0 for broadcast station. This station is automatically created by the communication unit.
Instead of a complete device image, the STA (ANSI stations) and PRI type system objects can
contain a reference to another system object. The system object has to be of the same type in the
same or in another communication unit. See Figure 17. These system objects have no attributes.
Each time the NET unit reads the name of a system object, the object number is interpreted
according to a translation table. The translation of an object name gives a device image in the same
communication unit, or a reference to another system object name of the same type defined in the
same or in another unit. A NET unit can know one device image and one reference under the same
name (the same object number). If a system object has both a device image and a reference to
another object, the reference precedes the device image, and the device image is searched
according to the reference. Hence, a switch between the devices is obtained by adding or deleting a
reference object.
A new STA object (if it is a real device image) is assigned certain default values, which are given in
the STA object descriptions in Section 17.
Basesystem
Application Software:
STA1:S..
Translation according to the
basesystem configuration
STA:S in node no 1.
Communication Communication
Unit, NET 1 Unit, NET 1
STA1:S STA2:S
Translation
Translation
ANSI_stations.eps
GUID-17D76064-6555-44B7-B593-976D650C3A1A V1 EN-US
Figure 17: Provided that the stations are of type ANSI, the notation STA1:S in an application
program can refer to either station 1 or station 2. A switch from station 1 to station
2 is obtained for example with the statement: #SET NET1:SST1 = (2,2). PRI
objects can be used in a corresponding way.
Creating STA objects corresponding to stations on LON: LSG devices and other process devices
connected to LON. However REF, RED and REC protective relays are created with the RX attribute
instead of LM attribute (see below).
The NET line number to which LMK is connected must be defined as a LONWORKS line.
Example:
Creating a LMK station (the STA attributes are described in Section 17.):
Defining and removing STA objects corresponding to S.P.I.D.E.R. RTUs or Collector 100 and 300.
Creating STA objects of station type REX (REC, RED, REF, etc.)
Creating STA objects corresponding to SPA units (SPACOM modules or other stations) using the
SPA or LonTalk protocol.
It is possible to configure 2047 SPA devices to one PC-NET. In one PC-NET, a maximum of 12 SPA
lines can be created. The amount of SPA devices in one SPA line is limited only by the SPA device
addressing but the recommended value 30 or less. Because SPA is a master/slave polled protocol,
the number of devices per lines affects directly the performance and response times of the systems.
Especially the analog value update times are sensitive to the system configuration, because usually
they have to be polled one by one. Therefore, the more devices there are per line, and the more
there are configured analog measurements, the slower the response time in the system. In other
words, to keep the response times fast, spread the SPA devices to as many lines as possible.
Connecting SPA units to a LONWORKS line requires LSG device, which must be defined as an LMK
type station with the LM attribute in the NET unit.
Defining and removing STA objects corresponding to stations using the ANSI X3.28 protocol. If ANSI
half duplex is used, several stations can be situated on the same line.
Example:
#SET NET1:SST5 = 4
Addition of the system object STA20 in NET1. STA20 refers to STA3 in NET1:
Addition of the system object STA4 in NET1. STA4 refers to STA2 in NET2:
#SET NET1:SST20 = 0
Internally in a NET unit, each object type is represented by an integer code, 1 ... 31. The code
numbers 1 ... 30 are predefined, including all the station types enumerated in Section 15.4.3. The
codes 24 ... 30 are predefined to following station types and the creation of these STA objects must
be done using the attribute DV.
25 = PCO (Procontic/RCOM)
28 = PLC (Modbus)
30 = DNP (DNP3)
Adding and removing devices of exchangeable device types. In PC-NET, this attribute can also be
used to create stations of fixed type numbers if the protocol is supported. The maximum value of the
object number is also the maximum amount of STA objects of that type in one PC-NET instance. The
given object number and value of the TN (Translated Object Number) attribute of the base system
object number binds the basesystem STA object and STA object of the NET unit to each other.
Example:
The variable A will get the value 0 if no such object is defined, otherwise the value 5:
@A = NET1:SDV29005
Printers are defined to the NET unit by a PRI object with an object number (device number) and a
connection line number. Printers can be defined with SCIL or with tools. With SCIL, printers are
defined when new PRI objects are created using the PR attribute described in this section.
Like the STA objects of type ANSI stations, a PRI object can be either a real device image or a
reference to another printer connected to the same or another communication unit, see Figure 17.
One device image and one reference can be defined with the same object number.
When a new PRI object is created (which is a device image), it gets certain default values. The
default values are listed in appendix A.
This attribute is needed only when the printer is connected to the serial line of a NET unit.
Adding and removing a printer with SCIL, that is a PRI object, or a reference to another PRI object.
Example:
The attributes in this sub-section apply to the application objects defined in NET unit. The SU and
SW attributes specify the communication between the application and the communication unit. The
DA and DS attributes provide means for monitoring the communication between NET unit and the
application.
where
‘n’ Is the node number of the NET unit where the application is defined. The ‘at’ is the attribute
name, and ‘m’ is the object number of the application.
Each application defined in NET unit has 4 diagnostic counters accessed with the notation:
NETx:SDAs
where
‘s’ Is the APL number in NETx. The counters are:
1. PL_SUSPENSIONS
2. APL_QUERIES
3. APL_TIMEOUTS
4. APL_ERROR_REPLIES
Example:
@A = NET1:SDA2
The current status of the connection between the applications and the NET unit.
Example:
@A = NET1:SDS(1 .. 250)
The communication sends cyclically diagnostic status requests to all known applications. As long as
the APL connection is OK, NET unit sends diagnostic commands with an interval of double the SU
attribute (2*SU) if there is no other communication with the application during this time.
NET unit suspends an APL connection when it receives no reply or a reply with a non-zero status
code to a diagnostic command, a split message or a message from an RTU. While an application is
suspended, diagnostic commands, and exclusively diagnostic commands, are sent to it until it
replies. When the application replies to a diagnostic command, the suspension is cancelled and the
APL will again receive spontaneous messages from the stations.
Some types of stations cause an application to be suspended if there is no base system STA object
mapped for a station that sends a message to the application. Also, if the station type in question is
not the default station type, the application can be suspended.
When an application is suspended, NET unit sends a system message (see Section 15.3.4) primarily
to the message application (the MS attribute). If this application is suspended, NET unit sends the
message to the first connection in number order that has an OK connection. When the application
recovers, NET unit sends one system message to the application itself and one the application that
received the suspension message. The system messages are addresses to MI(2), see the MI
attribute in Section 15.3.4.
Example:
#SET NET1:SSU5 = 2
The reply wait time in seconds for diagnostic commands and split substation messages (see Section
17) transmitted to an application. If no reply is received until this time has run out, the application
connection will become/remain suspended. The RTUs with a suspended application as the Allocating
Application (see the STA attribute AS) are not polled.
The KS attribute is used to define the key storage file which contains the user information and
authentication keys needed by the station objects created to this NET node. If none of the station
objects uses authentication, the definition of KS is not needed and the value may be an empty string.
All station objects configured to same NET node use the same key storage file. The creation of the
key storage file is done using the Authority Tool. If an empty string is written to the KS attribute, the
node is detached from the key storage file. This is needed is HSB configuration. For more
information, see the System Configuration manual.
Example:
Files "SS_HillSt_NCC.dat" and "SS_HillSt_IEDs.dat" have been created for the COM500i computer.
Example 1
#SET NET1:SKS="C:\sc\sys\active\sys_\SS_HillSt_NCC.dat" ; database for
NCC lines
#SET NET2:SKS="C:\sc\sys\active\sys_\SS_HillSt_IEDs.dat" ; database for
process devices
The LAN protocols created to NET nodes will reserve IP port numbers for their interprocess
communication. In case there are multiple NET nodes using the same local IP address and same line
numbers, there is a limitation of creating these lines. This limitation is described in the protocol
specific manuals in the description of the line attribute LD. In large systems, where it necessary to
create multiple NET nodes and tens of LAN protocol lines using the same local IP address, it may
necessary to override this limitation by setting a new base value for the reserved port number range
using the NET node attribute LP, local port. In practice, this means that a unique value of LP for each
NET node instance should be given.
basevalue: This could be the default 2502 or an unassigned value from the TCP/UDP port number list
maintained by IANA (Internet Assigned Numbers Authority).
offset: This should be 12 or more (256 or more if IEC60870-5-104 redundancy is used).
NET'a':SLP = basevalue
The value of LP should be set before creating the NET lines using LAN protocols.
If the maximum amount of the communication lines (12) is created to the NET node, the reserved
port numbers are LP ... LP + 11 (or LP ... LP + 255 if IEC60870-5-104 redundancy is used). Each
created line reserves one port from the mentioned range (16 if IEC60870-5-104 redundancy is used).
The port numbers are reserved from the IP addresses defined by the line attribute LD.
Example:
SYS600 versions 9.2 and older have used a fixed basevalue of 2502 in each NET node. The default
value of LP will provide the same characteristics as the previous versions.
The following port numbers are reserved by the listed protocols for external
communication. The port number range defined by LP should not overlap these values:
2404 IEC60870-5-104 slave, 20000 DNP3.0 LAN/WAN slave, 20000 DNP3.0 LAN/WAN
master (in UDP mode only), 21845 and 21846 SYS600 LAN Link
All master protocols using TCP/IP (IEC60870-5-104 master, DNP3.0 TCP master,
Modbus TCP, SPA-TCP) are operating as TCP clients. Consequently, no protocol specific
port numbers are reserved.
NET unit has a buffer for storing the last data messages received from S.P.I.D.E.R. RTUs and
SPACOM units. Using the LT attribute, the last transmitted transaction number can be read, and a
forced re-transmission to the application of the latest transactions can be started.
Example:
The transactions occurred after the last received transaction is transmitted to the application that
issues the command:
The content of a buffer, which can be freely used for transferring messages between NET unit and
the base system. When NET unit is started, all elements in the MA attribute are set to zero. After
that, the attribute can only be changed with SCIL. The attribute can, for example, be used for
checking that NET unit has started (provided that the attribute has been previously set to another
value than 0).
When this attribute is written, a system message (16633) is sent to the application specified by the
MS attribute.
The time of the NET unit in SYS600 time format (32 bits integer). Using this attribute, the computer
clock can be set manually. The attribute is supported because of the backward compatibility.
Example:
@A = HR_CLOCK
#SET NET1:STM(1..2) = (A:VCL,(A:VUS DIV 1000))
#SET NET1:STM3 = 50
The value of the TZ attribute is added to the synchronization time read from an external clock or set
from a central station connected to a RP570 slave, IEC 101 or DNP 3.0 slave line. The time zone can
be changed on-line from the base system with this attribute.
Example:
#SET NET20:STZ=60
This section describes the configuration of NET lines and the NET line attributes. The section is
divided in the following sections:
Section 16.1 General: The numbering and use of NET lines, the definition of NET lines and the object
notation for accessing NET lines. An overview of the NET line attributes applicable for
different protocols.
Section 16.2 Basic line attributes: PO, SD, LD, IU, LK, PM, PS, NB, PB, MI, MS, AO, AU.
Section 16.3 Data transmission attributes: BR, ER, PY, RD, RE, SB, TD.
Section 16.4 Communication control attributes: DE, EN, HT, NA, OS, PD, RI, RK, RL, SG, TI, TD, OM.
Section 16.5 Polling attributes: AW, CP, PD, PL, PP, PT, RP.
Section 16.6 Autodialing attributes: AC, AS, CL, CN, CS, CT, DD, MC, PU, RC, RW, SR.
Section 16.7 LON configuration attributes: NC, XA.
Section 16.8 Miscellaneous NET line attributes: Diagnostic counter (DC) and clock synchronization
attributes (LK, SF, SS).
The attributes in this description cover mainly the protocols listed in Table 3. The attributes of other
protocols are described in separate documents, which are available on request.
The PC-NETs communicate through the serial ports (COM ports) of the host computer, possible
PCLTA cards (one or two) or through the network interfaces. The COM ports can physically be in the
mainboard of the computer or in the extension card. It is also possible to use virtual serial ports by
using simulated states of the CTS and DCD signals, see description of the line attribute CM (COM
Port Mode).
In case the protocol of the NET line uses COM port, the port name is assigned using the line attribute
SD (System Device Name).
The protocols using TCP/IP or UDP/IP are configured to use some of the network interfaces present
in the system. The IP address which is used in the communication is defined with the line attribute
LD (Local Address). The used port number is selected by the operating system (Protocol operates as
a TCP client) or is fixed for the protocol (Protocol operates as a TCP server).
The NET line numbers of the LONWORKS channels (up to two per card) can be freely chosen
among the free NET line numbers 1 .. 12. On the LONWORKS lines, only the LonTalk protocol is
supported. The connection between the NET line numbers and the LONWORKS channels are also
defined by a NET line attribute SD.
PC-NET communicates with the base system (kernel) through line number 13, which is a fast internal
communication link used only for the basesystem communication.
Autodialing can be used on all NET serial lines defined for the following protocols:
Protocols which use the LAN connection are IEC60870-5-104 master and slave, DNP V3.00/LAN
master and slave, Modbus TCP and SPA-TCP. Protocols other than SPA-TCP are also described in
the protocol specific manuals.
For protocols DNP V3.00/LAN master and slave, Modbus TCP and SPA-TCP, the operation mode
which uses network is defined using the line attribute SD. In general, the IP address of the remote
end is defined with the IA station attribute and the IP address which locally used by the line is defined
with the line attribute LD.
Using a NET line requires that it is defined in the NET in question. A NET unit line is basically defined
by assigning it a protocol. It is recommeded to use System Configuration Tool for line creation, but if
configuration is created using SCIL scripts, the line creation is done setting the attribute PO as
described in Section 16.2. See SYS600 System Configuration for more information.
The line is further specified by a number of line attributes. Depending on the protocol used on a line,
some of the line attributes are applicable some are not. Table 3 lists the line protocols and the
applicable line attributes.
When a line is defined online, separate attribute writes is needed to complete the configuration of the
created line. In most cases, the line attributes can be changed only while the line is out of use (the In
Use attribute, IU, is 0).
The NET line attributes are accessed from SCIL with the notation:
GUID-10343DE4-A896-42BA-9C6A-EEFFA590CB04 v1
NETn:Sati (or NODn:Sati)
where
If not otherwise mentioned in the attribute descriptions, all line attributes are indexed with the NET
line number (1...12 and 13).
Protocol Attributes ACP and Integrated SPA LONWORKS RP570/571 RP570 Slave
ANSI full link Master
duplex
Basic attributes - - - - - -
-Basic definition PO PO PO PO PO PO
-In Use IU IU IU IU IU
-System Message MS, MI - IU MS, MI MS, MI MS, MI
-Other LK, PS PS MS, MI PS, SD PM, PS PS
LK, PS
Data transmission BR, ER, RD BR, PY, RD BR, PY, RD BR, PY
RE, SB, TD SB, TD RE, SB, TD SB, TD
Communication CM, EN, EN, NA, TI CM, DE, HT, HT, PD, TI CM, DE, CM, DE
Control NA, SG, TI RL EN, HT
RI, RK, SG
TI, TW
Polling PD, PP, PR AW, CP, PD
PT PP, RP
Autodialing AC, AS, CL AC, AS, CL AC, AS, CL
CN, CS, CT CN, CS, CT CN, CS, CT
DD, MC, PU DD, MC, PU DD, MC, PU
RC, RW, SR RC, RW, SR RC, RW, SR
Communication Loops BO, BU, CF
DR, LU, LS
MD, MT
LONWORKS Conf. NC, XA
Miscellaneous - - - - - -
-Diagnostics DC DC DC DC DC DC
-Clock Synchr. LK
The PO attribute creates and removes NET line definitions. A line that has not been defined in NET
cannot be used.
Using the SD attribute, the connection between the NET line number and the physical line can be
changed on LONWORKS lines.
The data transfer protocol used on the line. The line is defined to the NET by setting this attribute. By
setting the attribute to 0 the line definition, including all line attributes, are deleted.
When the line is defined, its line attributes get the protocol dependent default values given in the
attribute descriptions.
The PC-NET communication units support the following protocols (as well as some other protocols):
• ACP, Application Communication Protocol. This protocol is used for the communication between
SYS600 nodes (base systems and communication units). It is a protocol for point-to-point lines,
where both ends transmit spontaneously. The ACP protocol is based on ANSI X3.28 Full Duplex
but additional features have been added to the upper protocol layers.
• ANSI X3.28 Full Duplex. This protocol is used for the communication with stations of type Allen-
Bradley, SPACOM via SRIO, Westronic D20 and M4000, DTU1 and 2, SELMA II and SCP-
micro. It is a protocol for point-to-point lines, where both ends transmit spontaneously.
• ANSI X3.28 Half Duplex. This protocol is used for RTU communication on multidrop lines. The
stations are usually polled cyclically. The protocol is used by the same stations as for ANSI
X3.28 full duplex.
• ASCII printer protocol. This protocol is used for printer communication.
• RP570/571 master protocol. The protocol is used for communication with S.P.I.D.E.R. RTUs.
NET is the master and the connected RTUs are slaves.
• RP570 slave protocol. When using this protocol on a NET line, NET is regarded as the slave
and the communicating device as the master. The master sees NET as a S.P.I.D.E.R. RTU200.
• SPA protocol for direct communication with SPACOM modules. The protocol is allowed on max.
four lines per NET.
• The P214 protocol (Indactic 35). The protocol is used for communication with P214 RTUs
(Indactic 35).
• ADLP180 Master for communication with Collector 100 and 200.
• LCU500 for communication with LCU500 stations.
• General ASCII for communication with clock synchronization receivers, or ADEMCO alarm
receiver.
• RCOM (Procontic) for communication with Procontic PLCs.
• MODBUS RTU mode master for communication with PLCs, process automation systems, etc.
Writing something else than 0 to the attribute is possible only if the line is undefined. Changing
protocol on a line requires that the line definition first is deleted (PO = 0). Reading the PO attribute
for undefined lines returns the value 0.
Example:
#SET NET3:SPO1 = 14
Defining line 1 of NET number 3 for the SPA protocol and taking the line into use:
#SET NET3:SIU1 = 1
#SET NET3:IU1 = 0
#SET NET3:PO1 = 0
Deleting a line definition is possible only if there are no devices connected to the line.
Associates the NET line numbers of the PC-NET with the device names of the physical
communication interfaces.
On LONWORKS lines:
Each physical connection from PCLTA card or from network connected Loytec device (a
LONWORKS channel) is associated with a specific device name (see the Installation Manual,
Section 7).
If network connected Loytec device is used, see a separate Application Note for the definition of the
SD value.
If the LONWORKS device driver MiSCLONP is installed and configured according to the
recommendations in the Installation manual, "LONP0" is the device name of channel A on the "first"
PCLTA card, "LONP1" is the device name of channel B, and so on.
When a NET line is defined and assigned the LonTalk protocol (PO = 27), it is related to a device
name with "LONP" as the first four letters and a number calculated as the NET line number minus 1
as the last digit. For example, if NET line 2 is defined as a LonTalk protocol line (PO = 27), it is by
default assigned the device name "LONP1". The name corresponds to channel B of PCLTA card 1 (if
the LONWORKS device driver is installed as recommended in the Installation manual).
If the Echelon device driver is used, the device name for channel A is "LON1" and for channel B
"LON2". The channels of the second PCLTA card are named "LON3" and "LON4".
SD attribute gives the possibility to associate the NET line number to any COM port number.
The SD attribute is used to define the mode of the operation. When a value "TCP" or "UDP" is given,
the line uses LAN instead of serial port.
Example:
#SET NET3:SSD1="COM9"
The SCIL statement connects NET line number 2 of NET1 with the LONWORKS device name
LONP0 (channel A of PCLTA card 1 if installed according to the advises in the Installation manual):
The IP address which is locally used. The setting of this attribute is necessary when the computer
has multiple IP addresses and it is defined which address the line must use. The setting of this
attribute must be done before the line is taken into use for the first time. This attribute is supported in
the IEC60870-5-104 protocols, DNP-LAN protocols, Modbus TCP protocol and SPA protocol in TCP.
For more information on protocols other than SPA-TCP, read also the protocol specific manual. This
attribute is not available with serial protocols and the LonTalk protocol.
The state of the line, whether it is in use or not. When a line is not in use, no data can be transmitted
on it, and no data is received from it. The line attributes can be read as usual. Generally, a line must
be taken out of use by setting this attribute to 0 before the line attributes can be written.
When a line is stopped by setting the IU attribute = 0, all data transmission on the line ceases.
However, before that, NET executes to the end all on-going data transactions. E.g., the polling of the
station in turn is completed.
If the line is a LonTalk protocol line, the station objects should be taken into use after the line object
of the stations is set to IU=1. Correspondingly, all station objects connected to a LonTalk protocol line
should be taken out of use before the line object is set to IU=0.
The type of data link connection used on the line. The attribute has no meaning for the printer lines,
nor for LONWORKS lines. (LonTalk protocol lines do have a LK attribute but this has another
meaning.)
In protocols using serial ports, the states of the CTS and DCD signals may have simulated values
and the usage of the special serial cables are not needed. See line attribute CM for more information.
The mode of the protocol. The attribute applies to the general ASCII protocol (PO = 15), RP570/571
master protocol (PO = 7), the RCOM protocol (PO = 17), SPA protocol (PO = 14), LCO500 protocol
(PO = 12) and the Modbus master protocol (PO = 25).
The number of message buffers reserved for the line. Each buffer can contain one message. The
maximum data content length of a message depends on used protocol. In general, the temporary
buffer consumption is higher with master protocols than with slave protocols. The allocated buffers
are divided into two pools and the current state of these pools can be checked using line attributes
NB (Normal Buffer Pool) and PB (Priority Buffer Pool).
In SYS600 version 9.3 FP1 and newer, fixed buffer pool size values are used. This attribute is
supported for backward compatibility, but if written, the written value is ignored.
The usage of the normal buffer pool can be checked using the line attribute NB. This attribute is
available with all protocols. The size of the normal buffer pool is half of the size defined by line
attribute PS.
The number of available buffers in the pool is read using the following description. This is the
recommended method to monitor the pool usage e.g. in the test dialog.
If the value of the attribute is 0, the communication line has most probably entered an abnormal
state.
For more detailed information, the availability of individual buffers can be checked using the following
description. This method is used by various tools.
Example 1:
Example 2:
The usage of the priority buffer pool can be checked using the line attribute PB. This attribute is
available with all protocols. The size of the priority buffer pool is half of the size defined by line
attribute PS.
The number of available buffers in the pool is read using the following description. This is the
recommended method to monitor the pool usage e.g. in the test dialog.
If the value of the attribute is 0, the communication line has most probably entered an abnormal
state.
For more detailed information, the availability of individual buffers can be checked using the following
description. This method is used by various tools.
Example 1:
Example 2:
The attributes in this subsection apply to all lines and all protocols, except printer lines. The NET
lines generate system messages, for example, in the following situations:
• When the line is taken into use (IU = 1) (does not concern all protocols).
• At dial-up (concerns autodialing lines).
• When no time synchronization message is received from a General ASCII line.
Refer to Section 15 and the System Configuration manual to learn how to handle generated system
messages.
Object address of system messages. If the NET node attribute SE (System messages enabled) has
a value 4, a binary process object is updated at the same time as the analog process object defined
with MI.
Default value: When a line is defined on-line, the MI gets a default value obtained from the expression:
6000 + (100 * NET number) + line number
This default value can be used as such (copied to the process object address), or it can be
changed.
Access: Read, conditional write
The number of the application that is the receiver of the system messages generated by the line.
The UI attribute is used to define the name for the line object and it is used to identify the source of
the UAL (user activity logging) events. This string is added to the identification information of all user
activity events from this line object. A unique value within the node is preferred. The node level
module name (also in attribute UI) is added to form the full identification information for the user
activity event. If a line identifier is not needed, an empty string should be assigned to this attribute.
The AO attribute is used to define and enable/disable the interface for the analyzer. When an
analyzer is enabled, it can be used to view the transmitted and received messages. The analyzer
module prints out the bytes as they are passed to or returned from the operating system calls which
control the communication hardware. The timestamp in the output is taken from the local clock of the
computer. It defines the time point of the Read/Write system call made.
The setting of this attribute is necessary when there is a need to analyze the incoming and outgoing
messages of a communication line. This attribute is supported with all protocols. The port number is
optional and if used, it must be separated with a colon.
When an empty string is written to the attribute, the analyzer interface is removed from the system.
When the attribute is read and an empty string is returned, no interface for this line exists. The
analyzer interface operates as a TCP server and any TELNET program can be used as a user
interface. For problem solving it is necessary to have a possibility to record the analyzer output to a
file.
If the port number is not specified, port number 50 000 + line number is used. Only the local IP
address 127.0.0.1 is supported at the moment.
The analyzer interface reads the bytes sent by the client program, but does not use them. In case the
total amount of the received bytes is bigger than 1024, the TCP session is closed by the analyzer
interface.
Examples:
#SET NET1:SAO1="127.0.0.1:10001"
#SET NET1:SAO10="127.0.0.1"
#SET NET1:SAO1=""
Note: The given address and port number should not overlap with other TCP servers. If this situation
occurs and the creation of the server fails, no error code is returned, but the AO attribute will return
an empty string if read. Assigning a different port number is needed in this situation. It is
recommended to keep analyzer interface disabled when not used.
This attribute is a bit pattern, which defines the type of the output.
Bit 0: If this bit is 1, the contents of the data messages are printed out. This is the default operation. If
this bit is 0, the contents of the data messages are not printed out.
Bit 1: If this bit is 1, the changes in the control signals (RTS, CTS, DCD, DTR) of the RS232 lines and
the changes in the TCP connection states with TCP protocols are printed out. This is the default
operation. If this bit is 0, the changes in control signals are not printed out.
Bit 2: If this bit is 1, the internal printouts are enabled. This option can be used to detect the
completion timepoint of the of the write operation with the serial hardware. The completion timepoint
defines the behavior of the RTS signal of the line.
Bit 3: If this bit is 1, the contents of the data messages are printed out in ASCII format. This applies to
decimal numbers 32 – 126, which contain the ASCII printable characters. All other decimal numbers
are printed in hexadecimal format. If this bit is 0, the contents of the data messages are printed out in
hexadecimal format. This is the default operation. The ASCII printout format can be useful when
using SPA, LON or Modbus ASCII protocols.
Examples:
Transmission rate used on the line. The attribute is valid for all serial lines and all types of protocols
using serial lines.
Example:
Example:
¦ PO Protocol 00025 ¦
¦ IU In Use 00000 ¦
¦ MS Message Application 00001 ¦
¦ MI Message Ident. 00000 ¦
¦ LT Link Type 00000 ¦
¦ BR Baud Rate 09600 ¦
¦ SB Stop Bits 00001 ¦
¦ PY Parity 00002 ¦
¦ RD Receiver Data Bits 00008 ¦
¦ TD Transm. Data Bits 00008 ¦
¦ OS Output Synchroniz. 00001 ¦
¦ RE Redundancy 00000 ¦
¦ TI Timeout Length 02000 ¦
¦ NA NAK Limit 00000 ¦
¦ EN ENQ Limit 00003 ¦
¦ DE CTS Delay Length 00050 ¦
¦ ER Embedded Response 00000 ¦
¦ RP Reply Poll Count 00000 ¦
¦ PD Poll Delay 00300 ¦
¦ PS Buffer Pool Size 00016 ¦
¦ PP Polling Period 00001 ¦
¦ CN Connection [Ign] ¦
Indicates if NET transmits embedded responses (ACK, NAK) and ENQ:s within the messages, see
the illustration in Figure 18. The attribute applies to ANSI X3.28 Full Duplex and ACP lines (PO = 1).
The use of embedded responses increases the performance of a line especially when there is heavy
simultaneous communication in both directions. The ER attribute affects only the transmitter of the
communication unit. The NET unit is always able to pick embedded responses and ENQs from
received messages, independent of the ER value. Some ANSI X3.28 station types may lack support
for Embedded Response.
The parity check (if any) used for the characters transferred on the line. The attribute is essential for
all types of protocols using serial hardware.
The number of data bits in each received character. The attribute is valid for all protocols using serial
hardware.
The type of checksum added to each message. NET knows two types of checksums: CRC-16 and
BCC.
The attribute applies to the ANSI X3.28 full and half duplex. On P214 and RP570 lines, the
checksum is always BCC.
The number of stop bits attached to each transmitted byte. The attribute applies to all protocols using
serial hardware.
The number of data bits in each transmitted character. The attribute is essential for all protocols
using serial hardware.
Time delay between the activation of the RTS signal (Request to Send) and the start of a new
transmission, see Figure 19. The attribute has somewhat different functions depending on the
protocol used on the line. For other protocols but ANSI X3.28 and RP570/RP571 master, see
protocol specific manual for details.
On ANSI lines:
The half duplex communication is controlled by the RTS and CTS (Clear to Send) signals of the V.24
interface. When the NET unit has something to transmit (ACK, NAK, a polling packet or a message),
it activates the RTS (Request to Send) signal. The NET unit also waits for the CTS (Clear to Send)
signal to become active. In some cases, e.g. on some radio lines, the activation of CTS does not
guarantee that transmitted data will go through to the receiver. For example, switching on the carrier
may need extra time.
The DE attribute defines the delay (in milliseconds) from the activation of RTS until the transmission
is started. If DE = 0, the transmission starts immediately when CTS is activated. If DE is larger than
0, the time indicated by DE is waited. When this time has run out, the transmission starts if CTS is
active. If CM bit 1 (Simulated 'high' of CTS signal) is set, there is no raising edge of CTS and
transmission wait time is DE msecs.
On RP570 lines:
If the TW attribute (see below) is 0, the DE attribute controls both the CTS wait time and the
transmission delay. If the line does not get CTS (Clear To Send) after DE milliseconds have elapsed,
it will return the message including an error code to the sender. The line will start transmitting
immediately after it has got the raising edge of CTS, or if the TW attribute has a value greater than 0,
transmission will still be delayed by TW milliseconds. If DE=0, maximum CTS waiting time is 500
msecs. If CM bit 1 (Simulated 'high' of CTS signal) is set, there is no raising edge of CTS and the
transmission wait time is DE+TW, or if DE is 0, 500+TW msecs.
On P214 lines: Delay after receiving CTS before starting the telegram transmission.
DE - CTS Delay
RTS
CTS
DE = 0: Data
DE > 0: DE
Data
Illustration_DE_attribute.eps
GUID-FAFA95C8-CA69-4B7D-825B-D8691F785716 V1 EN-US
Figure 19: An illustration of the DE attribute on ANSI Half Duplex and RP570 lines
This attribute defines how long time the RTS-pin of the RS232-port is kept in the signal state after the
serial driver completes the write operation. The write operation here means a transmission of any
message with any protocol. See also line attribute CM (Com Port Mode), bit 3.
Value: 0 ... 20
Unit: Bytes (absolute time depends on baudrate)
Access: Read/Conditional Write
Default: 1
For the standard serial port of a PC the value must be 1 or more. With a standard serial driver, the
functionality of the write operation may be dependent on multiple factors such as transmit FIFO
buffer setting. Testing of different settings may be necessary. The setting of the bit 3 of the line
attribute CM (Com Port Mode) should be considered.
For the Rocket port serial card the value can also be 0 because the write operation is seen as
complete not until all bytes are actually sent. This applies only if the 'Wait on physical transmission
before completing write' flag is set in the driver configuration.
For the Digi Neo serial port card the value can also be 2 or more. With the serial driver the write
operation is seen as complete when there is still two bytes to be sent. Thus, value 0 will cause the
RTS to be in nonsignaled state before the message is completely sent.
The maximum number of times that a telegram is retransmitted after a timeout. The attribute applies
to the ANSI X3.28 full and half duplex and the RP570 protocols.
On RP570 lines a timeout occurs when an RTU fails to respond with a correct response telegram
within the time specified by the HT attribute. When the message has been sent the number of times
specified by the EN attribute, the transmission is considered as failed and the RTU is suspended.
The line returns a command including an error code to its sender and the telegram transmission is no
more repeated. On RP570 lines NET starts to send SCIs (Status Check Instructions) to the
suspended RTU.
On ANSI full duplex lines time-out occurs when no ACK or NAK is received to a transmitted message
within the time defined by the TI attribute. The NET unit transmits an enquiry (ENQ) at most the
number of times stated by the EN value. If no response is received, the NET unit refrains from further
retries.
On ANSI half duplex lines time-out occurs when no ACK is received to a transmitted message, or no
response is received (EOT or message) to a polling packet within the time defined by TI. If no ACK is
received, the NET unit retransmits the message until the EN limit is reached. If a station connected to
a half duplex line does not respond to a polling packet, it is polled at most the number of times stated
by the EN value. After that, the next station will be polled.
With protocols other than ANSI Half duplex, HT is the maximum waiting time in milliseconds within
which the first byte of a response from the RTU should have been received after the transmission of
a message. If no response has been received within this time, new attempts are performed the
number of times specified by the Enquiry limit. If still no response is obtained, the station is
suspended. Figure 20 illustrates the HT and the TI attributes.
On SPA lines: Max. transmission time of the complete message is calculated automatically based on
the message length and baud rate.
On RP570 lines: If TI = 0, the reception time is calculated automatically. If both HT and TI are = 0, the
program sets HT to 700 ms. If HT == 0 and TI > 0, there is no separate header timeout supervision,
but the entire message must be received within TI seconds from the end of NET's transmission.
On ANSI Half Duplex lines: The HT (if >0) or TI attribute value is always used as a timeout for the
complete message, since the length of the received message cannot be calculated.
TI
HT
In to NET Response
HT_and_TI_attributes.eps
GUID-F36AA47F-1EFF-4A8F-93F4-346B624E06CA V1 EN-US
The number of NAK responses that the line accepts at the transmission of a message, without
considering the transmission failed. The attribute is essential only for ANSI X3.28 Full Duplex (ACP).
States the flow control principle used by the printer. Hence it states how the printer informs NET that
the reception buffer is full and the character transfer should temporarily cease. It also states that
there is enough free space in the buffer for the data transfer to be restarted. The OS attribute applies
to printer lines only.
The cable wiring of the printer connection differs depending on the OS attribute, see the Installation
Manual.
LonTalk protocol bus repeat timer. This is given as a code in the range 0...15 as defined in NEURON
Chip Distributed Communication and Control Processors. The repeat timer is not used with
transparent SPA messages in LonTalk protocol.
Defines when the receiver of a NET line should be enabled after a message has been issued. The
attribute applies to P214 and RP570/571 lines.
The number of padding characters (null characters) inserted after the message to the end of
telegram to delay the passivation of the RTS signal (Request To Send). See Figure 21.
With some modem circuit types, the data bytes are delayed much more than the handshaking signal
state changes. This means that if RTS is passivated immediately when the last byte is transmitted to
the modem, the carrier will be broken before the last byte is transmitted by the modem. By inserting
padding characters after the message, the passivation of RTS can be delayed to give the modem
enough time to transmit all characters belonging to the message. The number of padding characters
is given by the RK attribute. The extra delay needed by the modem is about two bytes.
The attribute is valid for all ANSI Half Duplex, IEC 60870-5 and RP570 modem lines.
On P214 lines: Defines how many times in a sequence a telegram may be transmitted to a station before
giving up
On SPA lines: Number of telegram repetitions before moving the station into the sub cycle (suspended).
Telegrams to stations in the sub cycle will not be repeated.
Data type: Integer
Value: 1 ... 255
Default value: 2 (SPA)
Indexing: Line number
Access: No restrictions
This attribute determines whether the incoming Carrier Detect (DCD) signal of the serial port must be
set in order for the line to receive messages. This attribute is available only with IEC60870-5-101 and
IEC60870-5-103 protocols. See protocol specific manual for details. The same functionality can be
configured using line attribute CM, bit 2, which is supported with all serial protocols.
This attribute consists of a set of flags which control the behaviour and functionality of the serial port
of the line. This attribute is available on all protocols using the serial line. Each flag is one bit of this
attribute.
When this bit is 0, the UART errors are read before the bytes are read from the serial port. This is the
default mode.
When the bit is 1, the UART errors are read as a separate operation after the bytes are read from the
serial port. This mode is similar to PC-NETs older than 9.2SP2 and it does not detect all errors
detected by the serial port hardware. If the line has a lot of disturbances, this mode may result better
performance than the default mode.
When this bit is 0, the actual state of the CTS signal is used in the protocol. This is the default mode.
When this bit is 1, the CTS signal is simulated to be in 'high' state all the time and the protocol
configured for the line behaves according to that. This setting may be necessary with the virtual serial
port or for easier cabling. Bit 1 can also be controlled using line attribute SG. See line attribute DE
how transmission starts when CTS is constantly 'high'.
When this bit is 0, the actual state of the DCD signal is used in the protocol. This is the default mode.
When this bit is 1, the DCD signal is simulated to be in 'high' state all the time and the protocol
configured for the line behaves according to that. This setting may be necessary with the virtual serial
port or for easier cabling. Bit 2 can also be controlled using line attribute SG.
When this bit is 0, the keep up time of the RTS signal is not calculated using the length of the
message but it is assumed that the driver of the serial port blocks the execution of the sending
process until the message is actually sent. This setting should be used if the setting 'Wait on physical
transmission before completing write' or similar is selected in the driver for the port in question. The
tuning of the RTS keep up time should be done with line attribute RY. This is the default setting.
When this bit is 1, the keep up time of the RTS signal is calculated using the length of the sent
message and the baudrate of the port. The RTS keep up time defined with the line attribute RY is
added to the calculated time. This setting is not needed if the setting 'Wait on physical transmission
before completing write' or similar is selected in the driver for the port in question. This setting is the
most common with the virtual serial ports, too.
Protocol implementations mark the message as transmitted, not until the RTS keep up
time is completed. If the real transmission speed is different from the value defined with
line attribute BR (baudrate), unexpected errors may occur since a response may, for
example, be received before transmission is completed. In these cases, usage of CM bit
3 is not recommended.
If the serial driver does not provide setting 'Wait on physical transmission before completing write' or
similar and RTS signal is actively used by the modem hardware, it is worth to test both alternatives.
For accurate analysis using protocol analyzer function, see also the description of the bit 2 of the line
attribute AU Analyzer Usage.
When this bit is 0, RTS pin is controlled as configured for the protocol. Usually the RTS pin is set to
'high' before message is transmitted.
When this bit is 1, RTS pin is not controlled. This setup may be useful with virtual serial ports,
especially if the RTS signaling is not required by the modem devices connected to virtual serial port
server device. Network delays and/or a malfunction in virtual serial port server or driver may cause
delays also for the RTS pin controlling. These delays may be seen as a disconnection between PC-
NET node and base system. If bit 4 is set in one line, it is strongly recommended to use it for all lines
using the same virtual serial device. Bit 4 can be set for the non-virtual serial devices, too, but
depending on the characteristics of the serial device and connected modem devices, the
communication does not necessarily work at all. Thus, the setting of bit 4 with non-virtual devices is
useful in very rare cases.
The direct supervision and control of the state of the modem signal. The attribute applies to all
protocols. It is used for diagnostics and testing.
If the incoming signal DCD or CTS is wanted have a simulated 'high' value all the time, value 1 can
be written to these signals. This feature may be necessary for easier cabling or with the virtual serial
ports. If value 0 is written to these signals, the actual state of signal will be used. The default mode of
operation is the actual state.
Examples:
The different protocols are handling the DCD and CTS differently. See also line attribute
descriptions LK, DE and CB for the protocol in question. Having a simulated value in CTS
or DCD may have an effect how RS-232 line disconnection is detected and reported to
the MicroSCADA application.
The time limit applied when the NET unit is waiting for response to a message or polling packet. The
attribute applies to the ACP, ANSI and P214 protocols and to General ASCII when TAIP sync format
is used (PM = 6 and SF = 6).
The value of TI is the time in seconds, that NET waits for acknowledgements (ACK or NAK on full
duplex lines, ACK on half duplex lines). TI also states the maximum time NET waits for response to a
polling packet on half duplex lines (EOT or message). The NET unit starts the response wait timer
when the last byte of a message or polling packet has been transmitted to the receiving station.
TI is used to specify maximum reception time, while the HT attribute should be used to check
whether a station is responding or not. The timeout on SPA and RP570 lines are specified
exclusively by the HT attribute (see above). See the illustration of the HT and TI attributes in Figure
20.
On General ASCII lines with PM = 6, the TI attribute is the time NET waits for clock synchronization
messages. If NET receives no synchronization message within this time, it starts to reconfigure the
clock device with the time interval given with the PD attribute above and sets the SS attribute to Time
invalid.
LonTalk protocol lines have a TI attribute with another meaning, see below.
Time between retries when acknowledged or request/response service is used. This is given as a
code in the range [0..15] as defined in NEURON Chip Distributed Communication and Control
Processors. Applies to LonTalk protocol lines only. The timeout of transparent SPA messages in
LonTalk protocol is defined with line attribute TW, see corresponding description for more
information.
The transmission delay in milliseconds, i.e., the time that the NET must wait after receiving a CTS
signal until starting the transmission of a message.
If TW = 0, the DE attribute controls both the CTS wait time and the transmissions delay as before. If
the TW attribute is greater than 0, it specifies the transmission delay while the DE attribute specifies
the maximum waiting time for the CTS signal.
• RP570/RP571 master
• ANSI
• IEC60870-5-101/103 master and slave
• DNP 3.0 master and slave
• RCOM master
With LON line the TW attribute has a different meaning, see below.
LON acknowledgement timeout given as a code in the range [0..15] used with transparent SPA
messages.
This attribute consists of a set of flags which control the behaviour and functionality of the line. From
the protocols which are described in this manual, OM attribute is available only in ANSI X3.28 half
duplex protocol. Each flag is one bit of this attribute, see detailed descriptions below.
When this bit is 1, the STA object is not set to a SUSPENDED state when a request goes to timeout
defined with station attribute RT or if the IED does not acknowledge the request. The process data
from the station also remains as valid. The setting of this bit recommended if there is a separate IED
connected to each STA object. When this bit is 0 and a request goes to timeout i.e. statuses 12337 =
STAP_REPLY_TIMEOUT or 16205 = XHCP_TIMEOUT_WHILE_WAITING_ACK is returned to SCIL,
the station object is also set to SUSPENDED state and the process objects are set to invalid state.
This is the default mode of operation and should be used with the gateway devices.
When this bit is 1, no link layer retries are made for all messages of type 'Write' from the application
layer. The setting of this bit is recommended e.g. if the message contains time synchronization
information or if the retransmission of the message is implemented to the SCIL application. When
this bit is 0 and a no ACK message is received from the remote device to a the request, the link layer
retries are sent according to the line attribute EN. This is the default mode of operation.
When this bit is 1, no link layer retries are made for all messages of type 'Read' from the application
layer. The setting of this bit is recommended e.g. if the retransmission of the message is
implemented to the SCIL application or if the retransmissions cause problems in the IED or in the
transmission media. When this bit is 0 and a no ACK message is received from the remote device to
the request, the link layer retries are sent according to the line attribute EN. This is the default mode
of operation.
When this bit is 1, no link layer retries are made for all messages of type 'Reply' from the application
layer. The setting of this bit is recommended e.g. if the retransmission of the message is
implemented to the SCIL application or if the retransmissions cause problems in the IED or in the
transmission media. When this bit is 0 and a no ACK message is received from the remote device to
the request, the link layer retries are sent according to the line attribute EN. This is the default mode
of operation.
IEDs are time synchronized from SCIL application and data is also requested cyclically from SCIL by
using #GET or by reading the ME-attribute. The recommended value for OM is
It is possible to send control characters to serial communication line. The functional purpose of these
characters is to control the switches located in the line. The functionality is common for all the
communication protocols. When this attribute is written, the given bytes are sent to the serial line.
At the beginning of the vector, bytes 0 (NULL character) and 32 (Space character) have a special
meaning:
• each NULL character at the beginning of the message results in a 10-byte preceeding delay in
the transmission.
• each SPACE character at the beginning of the message results in a 1-byte preceeding delay in
the transmission.
The NULL character cannot be entered as string. See the examples below.
The length of the vector is limited by the length of the SCIL statement i.e. 255 bytes.
After the dial-up connection is established, the SCIL sequence could be the following:
#PAUSE 1
#SET NETx:STB'line'=(64,49) ; send "@1" to switch to select COM1
#PAUSE 1
#SET STA'sta':siu=1 ; polling starts
Polling is performed on ANSI X3.28 Half Duplex, SPA, RP570, IEC 60870-5 and P214 lines (PO = 2,
14, 7 or 9). If nothing else is mentioned, the attributes described in this section are essential for these
protocols. The PD attribute applies also to General ASCII with PM = 6. The polling attributes have no
meaning for lines using other protocols.
The example below illustrates the polling of an ANSI station. It is supposed that STA4 replies to the
second reply poll. Suppose that the base system issues a reply message for STA4, when the NET is
polling STA2. The polling will continue as follows:
If the message from the base system to STA4 is a command, the polling continues as follows:
Table 6: Polling of an ANSI station after a command to STA4 from the base system:
The time that the line waits for an acknowledgement or response from an application to a data
telegram or message sent from an RTU. The attribute applies to RP570 and P214 lines.
If no acknowledgement is received within this time, due to a loss of connection with the base system,
the application is suspended. The polling of all stations allocated by the application is stopped. The
NET unit starts to send diagnostic commands to the base system and when it has recovered, the
polling of the stations continues.
Defines how many times in a sequence a station will be polled when receiving an event from it. The
attribute applies to P214 lines only.
When the NET unit is polling stations, it inserts a delay between the response to a poll and the
transmission of the next polling packet. The length of this delay (in milliseconds) is given by the PD
attribute. The purpose of the poll delay is to prevent the polling from overloading the communication
unit.
A message sent from NET to a station during the poll delay time is serviced immediately.
On general ASCII lines using TAIP clock sync format (PM = 6 and SF = 6), the PD attribute
determines the time between configuration messages to the clock. The time is determined in
situations when NET has not received clock synchronization messages within the time specified by
the TI attribute.
IEC 60870-5: The delay between polling messages. The purpose of this attribute depends on the IEC
protocol mode. The unbalanced slave uses this attribute only to detect if the master is polling it. The
unbalanced master sends the polling messages (for class 1 or class 2) with interval of PD attribute.
With balanced mode, the link checks that communication is alive if the time between messages is
more than PD time.
Controlling the polling sequence of unbalanced master protocol. The purpose of PL attribute is to
limit the number of successive polls of same link address. Normally the MicroNET polls the same link
address until the all data from the same link address is read. This attribute is used only for
unbalanced IEC 60870-5-101 master mode.
The polling frequency of suspended stations. The attribute specifies how often suspended stations
on the line are polled. Normally, the NET unit is continuously polling the stations. Each station gets
the permission to transmit, when its turn comes. The polling of a station stops completely when it is
taken out of use (the IU attribute is set to 0).
On RP570 and P214 lines: A polling cycle is completed, when all stations have been polled at least
once (RTUs responding with priority 1 information are polled several times in a row). When a polling
cycle is completed, another one starts. A suspended station is polled every PP:th beginning of a
polling cycle.
On SPA lines: A polling cycle is completed, when the stations have been polled as defined with
attribute PT Polling Ratio. One suspended SPA station is polled at the end of every PP:th polling
cycle.
On ANSI Half Duplex lines: The station can respond to a polling packet with a message, or if it has
nothing to transmit, with an EOT. If the number of polls specified by the EN attribute (see above) are
transmitted to the station and no response is received, the station is suspended (is classified as
faulty). The suspended stations are polled less often than other stations. The PP attribute specifies
the number of poll cycles completed between each poll to a suspended station. Only one suspended
station per PP number of poll cycles is polled. See also the PC attribute above.
When a suspended station responds to a poll, the suspension is cancelled if the suspension reason
was that the station did not respond to polls (suspensions due to other reasons are not affected).
From that moment it will be polled in every polling cycle.
The PP attribute is supported also by protocols IEC 60870-5-101 master (unbalanced mode), IEC
60870-5-103 master, DNP3.0 Master and Modbus Master. See protocol specific manuals for more
information.
A poll ratio concept is used by NET when requesting data and events from SPACOM units. This
means that a certain pattern of poll messages is sent cyclically. During one poll cycle NET polls a
certain number of SPA units for data and events. Each slave (station) has a certain event poll priority
class, 1 or 2, which is defined by the STAn:SEP attribute, see Section 17.
The PT attribute specifies how many stations of each event poll class NET polls during a poll cycle
and how many data polls NET performs during a poll cycle.
If suspended SPACOM units exist, such a unit may be interrogated when a certain number of poll
cycles have been completed. The PP attribute, see above, defines how often this is done.
Example:
#SET NET1:SPT303 = 2
On RP570 lines: Specifies the maximum number of consecutive polls sent to a station while waiting for
the process response to an object command or an analog setpoint
On ANSI lines: Maximum number of consecutive polls sent to a station while the NET unit is waiting for
a reply
The value of the RP attribute sets a limit to the number of reply polls transmitted to a station after a
command has been transmitted to it. If e.g. RP = 3, the receiver station will be polled 3 times for a
reply, after a command message has been transmitted to it. If no reply is received, the station is
classified as faulty and the next station will be polled.
Messages from the base systems and stations will always override the polling. Therefore, if a
message from the base system is to be transmitted to a station on a half duplex link, NET transmits
this message when the current polling packet gets a response or a time-out occurs. After the
message transmission, NET continues to poll the station in turn. However, if the message from the
base system (or a station) was a command message, the receiving station will first be polled for a
reply to the command transmitted.
IEC 60870-5: This attribute is used only with unbalanced master protocol mode IEC 60870-5-101
Data type: Integer
Value: 0 ... 255
Table continues on next page
The following attributes are significant only when an autocaller (a modem with functions for automatic
dial-up) is connected to the line. The availability of these attributes are controlled by the AC attribute
of the line.
Autodialing is possible only on ACP, ANSI X3.28, RP570 master, SPA, Modbus, IEC 61107, Alpha,
IEC 60870-5-101 master and slave, IEC 60870-5-103 master, DNP 3.0 master and slave protocols.
The link type (the LK attribute) must be 1 or 2.
The dial-up connection may be initiated by the PC-NET or by the remote IED or system.
States whether an autocaller is connected to the line or not. The autocaller must use the AT (Hayes)
command set.
Makes it possible to put a time limit for the duration of the connection. The value of this limit is given
by the attribute CT.
Default value: 1
Suggested value: A time limit is necessary on certain radio telephone lines. Limiting the connection time may
be good practice also in other cases, if there is a risk that the connection is not broken
otherwise.
Access: No restrictions
Dialling devices from NET and for breaking telephone connections. Using CN presupposes that there
is an autocaller connected to the line (AC = 1).
A call to a station or workstation is initiated by writing the phone number to the CN attribute. NET
then commands the autodialing modem to dial the number. The success of the dialling is reported as
a system message. The connection is broken by writing an empty string to CN.
When dialling a station, the station number should be given at the end of the phone number string,
preceded by the letter "S". This option is normally used to increase the communication performance
on multidrop lines.
Example:
Indicates which station NET is communicating with. The attribute is used on incoming calls on ANSI
X3.28 half duplex and RP570 lines. With IEC 60870 master protocols, if the station is explicitly
defined in writing to the CN attribute, the returned value is the link address of the polled station.
The maximum time that a connection is allowed to last (in seconds). The attribute is significant only if
time limiting is activated (CL = 1).
Using this attribute, a modem can be controlled directly from SCIL with AT/Hayes commands. When
an AT command is written to the MC attribute it is transmitted to the modem on the line. Modem
commands can only be sent when the line is not in use.
Example:
With AT/Hayes command ATS0=3 you can set the register S0 value in the modem to value 3, this is
the amount of ringsignals before the modem accepts the call. See the Modem Manual for more
information.
#SET NET3:SIU1=0
#SET NET3:SMC1="ATS0=3"
#SET NET3:SIU1=1
States whether remote calls are enabled on a line, i.e., if NET can be called from the stations
connected to the line in question. The attribute applies to lines with autocaller (AC = 1).
When a station using RP570 protocol has called NET, it informs NET which station to poll by sending
a PRI (Poll Request Instruction). After that, the line works as an ordinary modem line.
Normally the DCD (Data Carrier Detect) signal is used to indicate an active connection. There are
cases, however, e.g. on radio telephone lines using half duplex links, where this is not possible. The
RW attribute gives the amount of seconds to wait in such a situation, from the finishing of the dialling
until the transmission is started.
All autocallers using the AT command set have a number of S registers. The number of registers
used and the meaning of the individual registers slightly varies from one autocaller model to another.
The contents of the S registers are therefore not described in this document, refer to the modem
manuals.
Using the SR attribute, the S registers number 2, 6, 7, 8, 9, 10, 11 and 12 are accessed. By using the
MC attribute (see above) also other S registers can be accessed.
Example:
#SET NET1:SSR206 = 4
Reading and writing of the network variable indices. Each LonTalk protocol line acts as an interface
to the LONWORKS device bus. It is possible to read the Network Variable (NV) indices 0 ... 4095 to
other entities on the LONWORKS network. External tools can configure each of these indices in the
same way as for other LONMARK™ [1] devices. Using the NC attribute, it is possible to read and
write the network variable indices 0 ... 4095. Writing to the NC attribute is equivalent to issuing
corresponding network management command directly from a LONWORKS network configuration
tool.
The attribute is used indexed with a code calculated from line number and network variable index.
The corresponding SPA point or LMK point (see Section 17) must exist before a network variable
index can be configured.
where
‘p’ Network variable priority, 1 bit
‘d’ Direction, 1 bit value 0 for IN and 1 for OUT
‘nv_selector_high’ Nv selector, 6 msb bits
‘nv_selector_low’ Nv selector, 8 lsb bits
‘t’ Turnaround, 1 bi
‘st’ Service type, 2 bits
0 = Ackd, acknowledged
1 = Unackd_repeated, Unacknowledged/repeated
2 = Unackd, unacknowledged
‘a’ Authentication, 1 bit
‘addr_index’ Index to address table, 4 bits.
The value should be 0x0F
‘ext_addr_index’ Index to address table, 4 bits.
The value should be 0x0F
Indexing: (4096 * NET line number) + network variable index
Access: No restrictions
More information can be found in the manual Connecting LONWORKS Devices to SYS600.
Example:
Reading the network variable configuration for NV-index 1 on line 1 (more information is found in the
Neuronchip Data Book):
@NV_IX_CFG = NET1:SNC4097
Reading and writing of the LONWORKS device address table configuration. The attribute is indexed
with a code calculated from NET line number and address index. Using the XA attribute, it is possible
to read and write the extended address table indices 0 ... 255 (0 ... 14 might be reserved by the
processor and therefore not recommended to be used).
where
‘type’ Type of address entry or 80H + group size
Type of address:
0 = Unbound address table entry (if element 2 = 0)
0 = Turnaround address (if element 2 = 1)
1 = Subnet or node address
3 = Broadcast address
80H...8FH = group address. The bits 0...6 specify the
size of the group.
‘d’ Domain index, 1 bit
‘node_or_member’ Node number or member of a group, 7 bits
‘rpt_timer’ Time between repetitions in unack_repeated service, 4
bits. The values of timers are coded, see the reference
table in the Neuronchip Data Book.
‘retry’ Retry count, 4 bits
‘rcv_timer’ Receive timer for multicast (group) messages, 4 bits. The
values of timers are coded, see the reference table in the
Neuronchip Data Book.
‘tx_timer’ Transmit timeout for acked or request /response service,
4 bits. The values of timers are coded, see the reference
table in the Neuronchip Data Book.
‘subnet_or_group’ Subnet number or group number
Indexing: (4096 * NET line number) + address index
Access: No restrictions
Example:
Reading the address table entry information from address table index 2 of NET line 1 (more
information is found in the Neuronchip Data Book):
@ADDR_TBL_ENTRY = NET1:SXA4098
This attribute applies to all protocols. For other protocols but ANSI X3.28 Half duplex / Full duplex,
SPA and RP570/RP571, see protocol specific manual for information.
The line protocols gather statistical information about the events on the lines by incrementing a
number of diagnostic counters. All major events and error situations of the communication have their
own counters.
Each line has a number of diagnostic counters numbered 1 ... 16 (or 32 if the line contains
autodialing). The meaning of the individual counters in number order is:
1 TRANSMITTED MESSAGES/TELEGRAMS
This counter is incremented whenever a message is transmitted successfully. On ANSI X3.28 lines, a
successful transmission includes the reception of a positive acknowledgement (ACK). On Half Duplex
lines, the counter is not incremented by polling packets, only by messages (commands or replies).
2 FAILED TRANSMISSIONS
The counter is incremented when a message transmission fails. On an ANSI line, the transmission has
failed if no positive acknowledgement (ACK) is received in spite of retrials. The counter is also
incremented if the states of the modem signals CTS and DCD prevent transmission. For the special
DCD link type LK = 8, the counter is updated after each retry while waiting for passive DCD.
3 TRANSMITTED TIMEOUTS
The counter is incremented each time a timeout occurs during the waiting for a response. If for example
3 time-outs occur at the transmission of a message (with retrials), the counter is incremented 3 times.
When the retry limit is reached, finally also the counter 2 is incremented once.
4 TRANSMITTED ACKS/FETCH
Is incremented on ANSI X3.28 lines each time a positive acknowledgement (ACK) is transmitted. Not
used on RP570 lines.
5 TRANSMITTED NAKS/POLLS
Is incremented on ANSI X3.28 lines each time when a negative acknowledgement (NAK) is transmitted.
Not used on RP570 lines.
UNPROCESSED LON MESSAGES
The amount of messages read from the driver but not yet processed. Used in LON line only.
6 TRANSMITTED ENQS/BROADCAST
Is incremented on ANSI X3.28 lines each time when an enquiry (ENQ) is transmitted. Not used on
RP570 lines.
7 RECEIVED ACKS
RECEIVED EVENT TELEGRAMS (SPA lines)
RECEIVED XONS (printer lines)
Is incremented on ANSI X3.28 lines each time a positive acknowledgement is received from the line.
Not used on RP570 and P214 lines.
8 RECEIVED NAKS
RECEIVED DATA TELEGRAMS (SPA lines)
RECEIVED XOFFS (printer lines)
Table continues on next page
Is incremented on ANSI X3.28 lines each time when a negative acknowledgement (NAK) is received
from the line. Not used on RP570 and P214 lines.
9 RECEIVED ENQS/TIMEOUTS (P214)
Is incremented on ANSI X3.28 lines each time when an enquiry (ENQ) is received from the line. Not
used on RP570 lines.
10 RECEIVED EOTS (ANSI X3.28 lines)
APPLICATION FAILURE (RP570 lines)
APPLICATION CONNECTION TIMEOUTS (P214 lines)
Is incremented on ANSI X3.28 lines each time when an end-of-transmission (EOT) is received from the
line.
11 RECEIVED MESSAGES/TELEGRAMS
Is incremented each time a message has been received from the line without errors.
12 PARITY ERRORS
Is incremented when a received message is rejected because of a parity error.
TCP CONNECT COUNT (IEC60870-5-104 master)
13 OVERRUN ERRORS
Is incremented when a received message is rejected because of an overrun error.
TCP ACCEPT COUNT (IEC60870-5-104 slave)
14 CHECK SUM ERRORS (ANSI lines)
REDUNDANCY ERRORS (P214, SPA and RP570 lines, LON)
Is incremented when a received message is rejected because of a discrepancy in the checksum (BCC
or CRC).
TCP CLOSE COUNT (IEC60870-5-104 master and slave)
15 FRAMING ERRORS (ANSI, P214, SPA, RP570, LON)
Is incremented when a received message is rejected because of a framing error.
16 BUFFER OVERFLOW ERRORS
Is incremented when a received message is longer than 259 bytes and therefore does not fit into the
message buffer.
17 ACE_CONNECTIONS_ LOCAL_ORIGIN
Calls initiated locally.
18 ACE_CONNECTIONS_REMOTE_ORIGIN
Calls initiated remotely.
19 ACE_RECEIVED_ERROR_RESPONSES
20 ACE_RECEIVED_NO_CARRIER_RESPONSES
TCP CONNECT COUNT (SPA-TCP, DNP V3.00/LAN master, Modbus TCP)
21 ACE_TIMEOUTS
TCP ACCEPT COUNT (DNP V3.00/LAN slave)
22 ACE_FAILED_DIALINGS
TCP CLOSE COUNT (SPA-TCP, DNP V3.00/LAN master and slave, Modbus TCP)
23 ACE_FAILED_CONNECTINGS_OF_REMOTE_CALLS
24 ACE_FAILED_DISCONNECTIONS
25 ACE_IGNORED_RINGS
26 ACE_RECEIVED_RINGS
None of the line protocols updates all of the counters. See protocol specific manuals for details. The
following counters are updated for the ANSI, SPA, LON and printer lines:
GUID-4D3BA055-4116-4D3A-8BE0-B81E5F629C60 v1
ANSI X3.28 Full Duplex: nr 1 - 9 and 11 -16
Example:
The diagnostic counters 1 ... 16 of line 3 in NET1 are displayed in the window COUNTER:
#SET NET1:SDC(101..132) = 0
The clock synchronization of LONWORKS lines. The lowest 3 bits in the attribute specifies clock
synchronization functionality as follows. Note that time synchronization cannot be used for several
base systems, which are connected to the same device. This creates erroneous time stamps.
0 No clock sync
1 Send LSG clock sync (for the relays that utilise nv warning and nv clock telegrams)
2 Send minute pulse (for the relays that utilise nv time telegram)
3 Send LSG and minute pulse
4 Receive LSG clock sync
5 Receive the minute pulse. It is recommended to use minute only when the other synchronization
methods do not work, or when the exact time is not needed because of the inaccuracy on high channel
load on LON line with minute pulse.
6 Send SLCM Reference Time
On an IEC 60870 line this attribute controls the behavior of RTS-control line:
12 RTS always on, full duplex (balanced slave default)
13 RTS / CTS controlling also with balanced mode
On DNP V3.00 protocol:
14 Collision detection in use, transmission when the Data Carrier, Detect signal of the line is not set
15 No collision detection, Data Carrier Detect signal is handled as in other protocols
Time sync message format for the clock synchronization reception. This attribute has a meaning only
on General ASCII lines with PM = 5 or 6.
The status of the clock synchronization on the line. This attribute has a meaning only for General
ASCII lines with PM = 5 or 6.
Example:
This section describes the STA objects and their attributes. The section is divided into nine sections
as follows:
Section 17.2 General: The station types, the definition of STA objects, the object notation.
Section 17.3 Common STA attributes: This section describes in details the attributes that are common to all
station types: Basic Attributes (IU, LI), Device Reservation Attributes (AL, AS), System Message
Handling Attributes (MI, MS, OS, SE).
Section 17.4 STA attributes, ANSI stations: Basic Attributes (PH, SA, ST), Polling Attributes (CP, PA),
Suspension Attributes (FS, RT, SU), Diagnostic and Counter Attributes (CT, DC, DE, DI, DS, LS),
Station Communication Parameters (EN, NA, TI), Memory Area Definitions (AD, AT, BF, CO, DT,
LE, MC, MR, TS), Message SPLIT (SL, SP), Memory Access (ME), Time Synchronization (SY).
Section 17.5 STA attributes, S.P.I.D.E.R. and collector RTUs: Basic Attributes (HR, SA), Diagnostic Counters
(DC), RTU Configuration Attribute (FC, FT, SY), Process Communication (DA, RD, RT, SC, SM,
TA, TD), Terminal Reports (TE, TM, TS), Communication Loop Attributes (DR, LS, LU, LW).
Section 17.6 STA attributes, SPACOM: Basic Attributes (BL, SA, UN, UT, RL, EC, EL, EP), Diagnostic Counters
(DC), Station Suspension Attribute (RT), SPA Point Definitions (ED, SP), Miscellaneous SPACOM
STA Attributes (DA, PR, SM, ST, UP), SPACOM attributes for TCP interface (CT, ET, IA).
Section 17.7 STA Objects, P214 RTUs: Basic Attributes (IU, LI, SA), Device Reservation (AL, AS), Suspension
and Diagnostics (DC, RT), System Message Handling (MI, MS, OS), Data Communication (DA,
EC, FC, FE, GP, NR, TV), Priority Control (PC, PM)
Section 17.8 STA attributes, REX stations: Basic Attributes (NN, SN, UN, UT), Session Handling (SC, SH, SI,
SK, SR, SS), Process Communication (DA, RQ, SM, TC, TQ, GI, GO, IL), Event Handling (EF, HI,
HS, RM), Suspension Attributes (RT), SPA Point Definition (SP), File Transfer Handling (FO, FP).
Section 17.9 STA attributes, LMK stations: Basic Definition Attributes (NN, SN, UT), Polling Attribute (CT),
Process Communication (DA, GI, LM, RT), Diagnostic Attributes (DC, DI), LON Point Definition
(LP).
Section 17.10 STA attributes, SPI stations: Basic Attributes (SA), Configuration Attributes (FT, FV, OL, RM),
Process Data Communication Attributes (AV, DD, EI, EX, ID, PC, TA, TR). Process Data
Communication attributes apply also to Modbus Slave station, Function Control Attributes (CB, CT,
DC, DI, EC, MM, RT, TI), Terminal Messages (ST, TV), Loop Control Attributes (LC, LT),
Redundant Line Attributes for RP-570 Slave Protocols (LI, RU), Application Based Command
Controlling Attributes (AT, CS).
All the station types that can be connected to NET unit were listed in Section 15. If not otherwise
mentioned, the station type can be connected only to PC-NET unit. This section describes the
attributes of the following station types:
• STA stations: the process units that communicate with NET unit using the ANSI X3.28 protocols,
for example, Allen-Bradley PLCs and SRIO.
• RTU stations: Relays and control devices and NCC connections, which communicate by using
the RP 570 master protocol. S.P.I.D.E.R. RTUs and Collector 100 and 300.
• SPA stations: bay control units, mainly SPACOM relay units, connected via the SPA protocol or
via the LonTalk protocol and LSG devices. The SPA stations connected via a LSG device are
configured as SPA units connected via the SPA protocol, except for two attributes. These
attributes are UT attribute and the RL attribute. There are also some differences in the SPA point
definition attributes.
• REX stations: REx type relays (REF, REC, RED, REL, etc.) communicating with the base
system through a LONWORKS line and the PC-NET unit.
• LMK stations: LSG devices and other devices connected to the LONWORKS network through a
standard LONWORKS interface (for example Weidmüller).
• SPI type stations: SCADA systems and other control systems, which communicate with NET
unit through the RP570 slave protocol in a master-slave relation where NET unit is the slave.
• Modbus Slave station: SCADA systems and other control systems, which communicate with
CPI-NET unit through the Modbus Slave protocol in a master-slave relation where the CPI-NET
unit is the slave. Modbus Slave station can only be connected to CPI-NET unit.
• IEC type stations: Relays and control devices and NCC connections, which communicate by
using the IEC 60870-5-101, -103 and -104 Protocols.
• DNP type stations: Relays and control devices and NCC connections, which communicate by
using DNP 3.0 protocols.
• PLC stations: Relays and control devices, which communicate by using Modbus Master
protocols, Modbus RTU, Modbus ASCII and Modbus TCP.
Each station must be defined as a STA object in the NET unit to which it is directly connected. The
STA object can be defined with System Configuration Tool or on-line with the NET station definition
attributes described in Section 15. ANSI stations are defined with the ST attribute, RTUs with the RT
attribute, SPA stations with the SP attribute, REX stations with the RX attribute, and LMK stations
with the LM attribute. Station type PLC, IEC and DNP are created using line attribute DV.
When the STA objects are defined on-line, the STA attributes get the default values given in the
attribute descriptions. Separate attribute writes is needed to complete the configuration.
Each time a NET unit is started, it creates automatically four STA objects with system object number
0. One STA object is of type RTU (S.P.I.D.E.R. RTUs and Collector), one is of type SPA (SPACOM),
one is of type LCU and one is of type PLC. These STA objects are broadcast objects. For stations of
type RTU, the broadcast object means all stations of this type connected to the same NET unit. For
stations of type SPA, the broadcast object means all stations connected to chosen NET lines (see
the BL attribute in Section 17.6). Provided that the broadcast stations have been mapped for the
application, they can be accessed from SCIL.
The STA attributes are accessed from SCIL with the object notation:
GUID-8B915A52-13A6-4ED2-9092-1C8798B06DEF v1
STAn:Sat
where
'n' The logical station number, 0 ... 5000, as known to the application where the object notation
is used. 'n' is translated to the communication system object number (0 or 1 ... 255) as
described in Section 7
'at' The attribute name
The attributes that are described in this section apply to all station types.
The operational status of the station, whether it is in use or out of use. Taking the station out of use
with this attribute stops all data communication with the station. All operations that would result in a
data exchange are disabled. The station itself is not affected by the attribute, only NET unit’s image
of the station.
The station causes no system messages as long as it is out of use, only at the moment when it is
taken out of use. Likewise, taking a station into use causes NET unit to send a system message (see
the SE attribute).
Setting IU to 1 is allowed only if the station address is legal (the SA attribute) and the device is
allocated by some application (the AL and AS attributes).
Regarding S.P.I.D.E.R. and Collector RTUs, NET unit sends an SCI (Status Check Instruction) to the
station when it is taken into use by setting the IU attribute to 1. This is done unless the SC attribute
has been set to 0 manually while the station was not in use. In this case, the polling will proceed from
the state where the station was left when taken out of use.
Regarding REX and LMK type stations, the station objects should be taken into use not until the line
object of the stations has been set to IU=1. Correspondingly, all station objects connected to a
LonTalk protocol line should be taken out of use before the line object is taken out of use.
By writing a new value to the LI attribute, the station can be switched from one line to another. Both
lines need to be defined with the same protocol and their original and destination lines have to be
taken out of use. Changing the LI attribute, that is moving a station from one line to another,
demands that the station as well as the old and new lines have been taken out of use (IU = 0).
This attribute is also used for setting the number of the back-up line if redundant lines are used. The
indexes are used only when the redundant lines are used. Note that the indexes 1 and 2, i.e. main
and back-up line numbers, are switched when a line switch operation is executed. The number of the
back-up line is set to index 2 of the LI attribute.
Allocates the station to an application. When the AL attribute has the value 1, the station is reserved
by the application specified by the AS attribute. All spontaneous messages from the station will be
sent to this application.
The stations address all their messages to one single station address, which is the address of the
communication unit. The NET unit forwards the received messages to the application, which has
reserved the station (the AS attribute).
Although one application has reserved a station, other applications can send read commands to the
station. The station will not transmit spontaneous messages to these other applications, unless the
message split feature of NET unit is used. See the SP attribute in Section 17.4.
Example:
#SET STA1:SAL=1
The allocating application of the station (see AL attribute). The allocating application will get all the
spontaneous process data from the station. This application is also the only one that is allowed to set
the device communication attributes.
When AL is set to 1 on line, AS is automatically set to the number of the application from which AL is
set. When AL is set to 0, AS also is automatically assigned the value 0.
The allocating application will receive all the spontaneous process data from the station (if message
split, Section 17.4, is used, also other applications will receive the messages).
The attributes of this section affect the transmission of system messages that NET unit sends on
various events related to the STA objects. The system messages are sent to the applications defined
by the MS attribute and updated in the process objects defined by the MI attribute. Via the process
objects event channels, loggings, alarms, etc. may be activated automatically.
Based on system messages from STA devices, the SYS600 base system automatically updates the
validity stamp of the object values in the process database (the OS attribute). See the System
Message Attributes in Section 15. When a system message of type "not valid" is received from a STA
object, the main program automatically marks all process objects related to that station as not valid.
The marking is done by setting the OS attribute (Object Status) to 2 (OBSOLETE_STATUS). The
process objects, whose UN attribute (Unit Number) corresponds to the station in question, are to be
marked. A system message from the same station, which tells that the connection is OK again, does
not lead to any process object marking. The updated object values are subsequently marked valid
(OS = 0).
Refer to Section 15 and the System Configuration manual to learn more about the system message
handling.
The system message generation of the RTU type stations (S.P.I.D.E.R. RTU and Collector) differs
from the system message handling of other stations.
Stations of other types than RTU cause the generation of system messages on the following events:
• The station is put into suspended state because it does not respond to poll packets or
messages, or because IU has been set to 0.
• The connection to a station has been lost or re-established.
• The station connection recovers after a disturbance.
Due to the differences in the generation of system messages, the MI attribute of the RTU type
stations differs from the MI attribute of other stations. It is therefore described separately below.
The message address used in system messages. The MI attribute is the address of the process
objects (the OA attribute) where the system messages from the device are updated. At the
generation of a system message the status code of the message is updated in the OV attribute of the
process object with this object address.
The system message status code is stored in the process database of the receiving application or
applications (defined by the MS attribute). If the NET node attribute SE (System messages enabled)
has a value 4, a binary process object is updated at the same time as the analog process object
defined with MI. See the MI attribute in Section 15 for more information.
The attribute has the same meaning as described above for other station types, but there may be
several receiving process objects, one per message type.
The S.P.I.D.E.R. RTUs may cause four different types of system messages with different origins. The
message types are numbered 1 ... 4 as follows:
Specification of the application or applications that will receive the system messages caused by the
station. Each station may have up to six applications that receive system messages. The APL
system object numbers as defined in NET unit specifies the application.
It is possible to send system messages to more than one application with a STA object. The System
Configuration Tool does not support this, instead you have to create a user defined program if you
need to do it.
Indicates the state of the station. Writing to the OS attribute (OS = 1) of a station makes NET unit re-
transmit the last system message caused by the station. Possible "Stopped" and "Suspended"
messages cause old marking of process objects. By reading the OS attribute, the status code of the
system message can be read. The attribute is available for Master and Slave for IEC stations.
Specifies whether system messages generated by NET unit and related to the station are sent to
applications or not. Using this attribute, it is possible to disable the system messages related to the
station. The attribute does not affect messages generated in the stations (terminal messages in
S.P.I.D.E.R. RTUs).
The value SE = 0 should be used only in special cases, for example if the base system
application program often executes commands, which cause undesirable system
messages. Undesirable system messages can be regular stopping and starting of a
station.
Besides the common attributes described in Section 17.3, the STA objects of type ANSI stations
(STA) have the attributes described in this section.
The PH attribute is not directly used for dialling, but it can function as a memory for the phone
number to be used when calling a station.
Example:
The station address of the ANSI station. The value of this attribute must be the same as the
corresponding station address value defined in the station.
Each station connected to a NET unit through the ANSI X3.28 protocol must have a unique station
address. This demand for uniqueness also comprises the NET unit itself, see the SX attribute in
Section 15. However, stations connected to separate NET units may have the same station
addresses. When the station address is written on-line with SCIL, the communication program
checks that the uniqueness is maintained.
Example:
#SET STA1:SSA = 20
The type of the ANSI station: SLC-500 or other types. The type specification is needed because the
interpretation of object addresses in messages from SCL-500 differs from the other ANSI station
types.
The attributes in this section apply exclusively to stations on ANSI half-duplex lines.
The number of commands polled from one station until the next station is polled. The attribute is
significant only to stations, which are connected to multidrop lines and which transmit command
messages spontaneously.
The CP attribute states how many commands the station is allowed to transmit in succession, before
the next station is polled for commands. The commands from applications have higher priority than
the polling of stations.
CP gives a possibility to optimise the multidrop line. It is also a way to assign different priority levels
to the stations for heavy-load situations.
A high value may slow down the communication to other stations, for example in
hardware fault situations.
Using this attribute, a station can be polled by using another address than its own station address
(the SA attribute). The PA attribute makes it possible to connect PLC-5 and stations using Data
Highway to a multidrop line of NET unit. In all other cases, the PA attribute should be equal with the
SA attribute.
Suspension of a station means that the NET unit notices that the communication to the station does
not work, and gives this information to an application as a system message. All process object values
related to that station are marked as outdated, as they apparently are not properly updated. The
reasons for a suspension may be:
• A reply message from a station does not arrive in time (REPLY TIMEOUT), see the RT attribute.
• A station on a multidrop line does not respond to polling packets (DEV STATUS IN signal
generated in NET unit).
• A reply message from a station contains a severe error code.
• No acknowledgement (ACK) to a reply message.
Table 7 shows an overview of the reasons for suspension and the states that cause recovery from
the suspension.
Determining which kind of commands from the application will be forwarded to a suspended station.
The maximum time the NET unit will wait for a reply from the station.
Unlike the DI attribute (see Section 14), this attribute is used when the station is in a suspended
state. If DE = 0, SU has no meaning. If an acceptable reply is received to the diagnostic command,
the station returns to the normal state, otherwise it stays in the suspended state for another SU
period. If any other message is received from the station without errors during the period, the station
enters the normal state.
The values of the counters and timers situated in the station. Most station types have a number of
diagnostic counters and timers. The CT attribute is used to read and reset these counters and timers.
The exact number and format of diagnostic counters and timers may vary depending on the station
type.
When reading the CT attribute, the word addresses of the counters are given as indices. The first
counter address is obtained from the station by reading the DS attribute (see below).
The counters and timers are reset by a #SET command, by which the value 0 is assigned to the CT
attribute. In the reset command the indices have no meaning. The reset command always concerns
all the counters and timers.
The values of the diagnostic counters which NET unit keeps for the station.
To make the supervision and testing of the station communication easier, NET unit holds five
diagnostic counters (numbered 1 ... 5) for each station. Each counter monitors a certain kind of
events, according to the following list:
1. STATION SUSPENSION
The counter is incremented each time the station is suspended. Depending on the reason for
the suspension, one of the other counters is also incremented at the same time.
2. DEV STATUS RECEIVED
The counter is incremented when a DEV STATUS IN signal is received from the ANSI X3.28
Half Duplex protocol data link layer. This signal indicates either that a station has ceased to
respond to polling packets, or that it has started to respond again after a disturbance. The first
situation will lead to a suspension of the station and increment counter 1 as well. From the
function of this counter follows that generally an odd value indicates that the station does not
respond to polling packets at present.
3. REPLY TIMEOUTS
This counter is incremented when a command has been transmitted to a station and no reply
arrives from the station within the time limit specified by the value of the RT attribute. The station
is suspended.
4. STS NOT OK FROM RTU
This counter is incremented each time a reply message from the station contains a non-zero
value in the status code byte (STS). This does not necessarily lead to a suspension of the
station. Suspension may occur depending on the severity of the status transmission responses
are transmitted.
5. STS NOT OK FROM NET
This counter is incremented when the NET unit transmits a reply message with a non-zero
status code value (STS). Usually, the error code is caused by missing definitions in the NET unit
or by the contents of the command message from the station, e.g. an unknown destination
device, an undefined memory address or a memory area defined with a wrong data type or
coding.
Indicates whether the NET unit will transmit diagnostic commands to the station cyclically, and what
type of diagnostic commands that will be used.
The time cycle always starts from zero when a message (command or reply) is received from the
station. The length of the time cycle (in seconds) is normally the value of the DI attribute. When the
station is suspended, the cycle length is obtained from the SU attribute.
The diagnostic commands used are Diagnostic Status and Diagnostic Loop. The Diagnostic Status
command reads status information (see the DS attribute below) from the NET unit of the station. The
status information received tells among others the type and operating mode of the station, and also
gives an indication of possible errors. Diagnostic Loop transmits a byte sequence to the station, and
only checks that the same byte sequence is received in the reply message.
If both commands are implemented into the station, Diagnostic Status is normally the command to
use, but some station types have only the Diagnostic Loop.
If an RTU does not transmit messages spontaneously, it might stay in the suspended state although
it answers to the polling packets. This situation can occur if the polling packets and their end-of-
transmission responses are transmitted correctly, but line disturbances prevent the correct
transmission of a whole message. After such a disturbance the station can return to the normal state
if:
c) The value of the FS attribute is non zero, so that the commands from the application system are
forwarded to the suspended station.
The time between diagnostic commands to a station, which is not in suspended state (cp. the SU
attribute, Section 14).
The DI attribute is meaningful only if DE has a non-zero value. Then DI gives the time in seconds
from the last message (command or reply) reception from the station until the next diagnostic
command will be sent. If some other message is received from the station during that time, the timer
restarts from zero.
The status code of 10 bytes. A read command using the DS attribute returns 10 bytes of status
information from the station or its communication unit. The format and exactitude of the status
information depend on the station type. Usually information about station type, NET unit type,
operating mode, error bits, counter and timer start address and station program version is included.
The SYS600 error code for the last error that NET unit has discovered in a spontaneous message
from a station.
In the reply message to the station, NET unit sends the corresponding ANSI error code.
This can be read in the station. The SYS600 error codes are translated to ANSI codes.
See the Status Codes manual.
These attributes can be used only in connection with some station types (for example SPSC500M
and Allen-Bradley PLC-2). The attributes are write-only, and their values are not stored in the
communication unit, but directly transmitted to the station. Normally, the parameters are set in the
process units.
Maximum number of ENQs (response requests) per message from the station communication unit.
The station will send ENQs in full duplex communication if it does not receive a response (ACK /
NAK) to a command within its time limit (see the TI attribute below).
Maximum number of NAKs (negative acknowledgement) the NET unit of the station accepts at the
transmission of a message in full duplex communication. When this limit is reached, the message
transmission has failed.
Time limit used by the station when it is waiting for a response to a message transmitted.
The part of the station memory visible to other devices is divided into a number of memory areas
(max. 30) for different types of data: binary input (BI), binary output (BO), and analog input (AI), and
analog output (AO) and transparent data (TD). In addition, data may be transmitted with or without
time stamps. Analog values may be coded as BCD numbers, floating-point numbers or binary
numbers, etc.
The communication program needs definitions for each memory area of a station to know how each
memory area is to be used, that is, to enable correct data interpretation and access checking. The
memory area definitions specify the location of the data types in the data tables of the stations, the
data coding, time stamping, message split (see Section 17.4.7), address format, and protected or
unprotected write.
A memory area definition in the NET unit consists of a collection of eight attributes, namely DT, CO,
AD, LE, AT, BF, TS and SL. The SL attribute is described in Section 14.
A memory area definition is added and removed using the MR attribute. When a new memory area is
added, a memory area number that is used as identifier when referring to the area is defined. The
entire memory area configuration for one STA can be copied from another STA with the MC attribute.
The memory area defining attributes contain no process data. Usually, several memory areas are
defined for a station. For this reason, the number of a memory area is given as indices to the
attributes. Only one index is allowed. On-line changes in the memory area definitions are possible
only if the IU attribute of the station has first been set to 0.
When a new STA object using the ANSI X3.28 protocol is created the following memory areas are
automatically created:
Defines if write commands directed to this memory area are protected or unprotected. The attribute is
relevant only to Allen-Bradley stations.
With unprotected commands, any station can write anywhere in the data table of a PLC, if the
unprotected commands are not disabled with a dipswitch. Concerning protected commands, the PLC
program contains definitions stating which station is allowed to write in the memory locations. Write
commands from undefined stations or to undefined areas not accepted.
States if the spontaneous command messages from the station use the basic format of the protocol
or if an additional address field is utilized.
The need for special formats is due to the implementation of spontaneous transmission into Allen-
Bradley PLC-2 programs. In this programmable logic, a sent command includes a command line that
contains a constant memory address. At transmission, the PLC adds this constant address to the
word address field. However, sending data from several memory addresses may lead to a great
number of command lines, which consume a lot of memory and programmer time. By adding an
additional address into the data part of each message, the sending of commands requires only one
or a few command lines. The additional address identifies the data elements the values of which are
transmitted.
The constant address of the command line is chosen as the start address of a memory area with the
BF value 2 or 3, depending on the coding of the second address. The additional address is defined in
a memory area with BF = 1.
Coding of the data elements in the address interval defined by the memory area. The value of CO
tells the communication program how to interpret the data of the memory area.
The data type of the memory area. There are five types of memory areas BI, BO, AI, AO and TD.
Memory areas of the types BO and AO can be used for both reading and writing data. There is also a
certain memory area for the time synchronization area.
Example:
The type of the memory area number 1 of station 2 is set to binary input:
#SET STA2:SDT1=1
States the number of the station from which the configuration is copied. Using this attribute the whole
memory area configuration of a station can be copied from another station.
When the configuration of station A is copied from station B, any old memory area definitions of
station A will be overwritten. If an area nr x is defined for station A but not for station B, it will be
removed.
Example:
All memory area definitions of STA5 are copied (using the same memory area numbers) to STA1:
#SET STA1:SMC = 5
Addition and removal of memory area definitions in a station data structure. Giving the MR attribute a
string value with "C" as the first character creates a memory area. The NET unit then assigns default
values to the memory area attributes. After the "C" may follow the two-character abbreviation of the
data type wanted (AI, BI, AO, BO, and TD). By specifying the data type in the creation command, the
application programmer can help the communication program to choose appropriate default values.
Fewer SCIL commands are needed for completing the definition of the memory area. For example
"CBI" means that a binary input memory area is created. If no other characters follow the "C" in the
creation command, the NET unit will create a memory area of the type TD (Transparent Data). A
memory area definition is removed by giving the value "D" to the MR attribute.
When a new memory area is added, the communication unit uses the following default values:
TS 0 No time stamp
SL 0 All five elements
DT TD (Transparent Description
Data) or undefined
DT 5 Transparent Data
CO 3 16 bit binary number
AD 0
LE 2
AT 0 Unprotected
BF 1 Basic Allen-Bradley format
TS 0 No time stamp
SL 0 All five elements
In any case, appropriate values must be assigned separately to the attributes AD and LE, before the
new memory area is ready to be used.
At the creation of a new memory area, the attribute values can be copied from another memory area,
within the same station or in another one. In this case, the attribute is assigned a coded integer
value.
Example:
States whether time tagged information is included in spontaneous commands from the station.
For the registration of signal sequences it is often desirable to "stamp" some data with the actual time
already in the station. The time stamp is made by copying the minute, second and millisecond values
from the station clock. If present in a message, a time stamp occupies 4 bytes, one for minute, one
for second and two for milliseconds.
Suggested value: Most commonly, time tagging is used for binary input data and two bits ("double") indications
(defined as AI areas in the communication unit).
If the station sends time tagged messages, the TS attribute must be 1, else TS = 0.
Indexing: Memory area number, only one index is allowed.
Access: Read, conditional write
If time stamp is used, the station clock should be synchronized to the base system real
time clock. This is accomplished with SCIL using station attribute SY Clock
Synchronization.
Spontaneous messages from the station are sent to the application specified by the AS attribute (see
Section 17.3). The split feature means that the NET unit copies the spontaneous messages from the
station to other applications. The messages are also copied to the destination application defined by
AS, see Figure 22. The feature must be activated for each STA individually. The receiving
applications are memory area specific.
Message Split
APL1 APL2 APL3
NET1
STA1:S AS = 1
SP = 1 NET2
SL = (2050, 2051)
STA1 Message_spit.eps
GUID-C3018575-9FAB-4910-80A7-27EC4482FD10 V1 EN-US
A list of the applications, that will receive a copy of spontaneous messages with an address in a
certain memory area. If the SP attribute of the station is <> 0, the NET unit copies an arrived
message to all applications in the list. The maximum number of copy destinations is five.
Example:
Spontaneous messages from the 3rd memory area of station 1 will be copied to APL3:
#SET STA1:SSL304=2051
Specifies if message split is used or not. It also specifies the error handling in those cases where one
or several receiving applications do not reply.
The copy destination applications for different memory areas are the ones defined by the SL
attribute.
The data element(s) in the memory area(s). This attribute is used for reading from and writing data to
the memory area of a station. The attribute is indexed with the station memory addresses (word
addresses). For access to binary inputs or binary outputs, bit numbers may also be used.
Example:
STA1:SME1003
STA3:SME(3121..3127)
STA5:SME1234^5
Synchronizing the station time with the NET time. The time in the message is the NET time at
transmission of the last bit of the first byte (DLE) in the message. Each station must be synchronized
separately, broadcast is not supported. For stations that do not compensate for transmission time,
the accuracy is not better than 50 ... 300 ms.
Using the SY attribute for synchronizing a station requires that a memory area with DT = 6 and LE =
9 has been defined, see Section 17.4.6. The address of the memory area is not significant to NET
unit, but the station may require a specific address.
Besides the common attributes described in Section 17.3, stations of type RTU (S.P.I.D.E.R. RTUs
and Collector RTUs) have the attributes described in this section.
If the station is a sub-RTU, the HR attribute tells the station address of the host RTU one level up in
the RTU hierarchy. For the uppermost RTU level, the HR attribute value is the same as the station
address (the SA attribute). See Figure 23.
GUID-1CEFF538-A6AA-4C43-94B1-D6FE66F9F3B2 V1 EN-US
The station address of the RTU. The address must be unique among all S.P.I.D.E.R. RTUs, Collector
and P214 RTUs connected to the same NET unit. The address must coincide with the corresponding
address in the RTU itself.
For S.P.I.D.E.R. RTUs legal addresses are 1 ... 255, except for the broadcast STA object, which has
the address 0. The RTU can not be taken in use (see the IU attribute) unless it has a legal address.
This attribute is used to define a station specific time compensation to the synchronization message
initiated with SY attribute. If the used hardware delays the transmission of the message to the RTUs,
a value close to this delay should be assigned to this attribute. Some tuning work or a good
knowledge of the used hardware is needed when this attribute is used.
Example:
If the average transmission delay to the station STA1 is known to be 60 milliseconds, the station
object should be configured with the following SCIL command:
#SET STA1:SSO=600
The attribute can be modified while the system is running. It is possible for the SCIL application to
retune, if the feedback of the synchronization accuracy is available.
Negative values will cause the RTU time to be behind the actual time. Also, too big a value,
compared to the actual transmission delay, will cause the RTU time to be ahead of the actual time.
The diagnostic counters for an RTU device monitors the telegram exchange to the specific RTU. The
counters are:
1. SUSPENSIONS
A S.P.I.D.E.R. RTU is suspended when the RTU line has got erroneous replies or no reply after
the number of trials determined by the EN attribute of the line
2. TERMINAL STATUS RECEIVED
3. TERMINAL EVENTS RECEIVED
4. TERMINAL MESSAGES RECEIVED
System messages from the RTU
5. PROCESS MESSAGES RECEIVED
Indications, measurands and pulse counters
6. REPLY TIMEOUTS
When these attributes are set, the NET unit sends an RP570 telegram to the RTU and, unless the
telegram is in monologue mode (no response expected), wait for the response from the RTU. If the
response is not a positive acknowledgement, an error code is returned.
Enabling transmittance of function commands to the RTU. The number of the function command is
given as index and additional information is given as the value of the attribute.
All function commands listed in the S.P.I.D.E.R. RTU manuals and in the RP570 protocol
descriptions can be used, except the commands number 14, 15 and 16.
Example:
Example:
#SET STA1:SFC1
To tag the database version with the current time, give the command:
#SET STA1:SFC19=RTU_ATIME
Sending of a single function table to the RTU. The value written to the FT attribute should be the
context of the function table that is stated in a text string. Note that sending function tables also
demands sending the corresponding function commands depending on whether you are sending the
complete set of function tables or just some alternating function table. The FT attribute is always set
from a tool.
Makes an accurate time synchronization of the RTU(s). No value is necessary for this attribute
because the time sent to the RTU(s) is taken from the internal clock of the computer. See also
attribute SO Synchronization Offset.
When writing to the SY attribute of the broadcast object, all RTUs connected to the same NET unit
are synchronized, one line at a time. The synchronization telegram is sent out as a broadcast
telegram on each line with the RP570 protocol. Note! RTU200 and RTU210 substations do not
support broadcast time synchronization commands, therefore each RTU200/210 station must be
synchronized separately. The internal clock of the computer should be synchronized before
synchronizing the RTUs.
Example:
STA2 is synchronized:
#SET STA2:SSY
Determines the maximal time that the NET unit will wait for a telegram response from the RTU.
The SC attribute is used when the application desires to "force out" a status check instruction (SCI).
By this command it is possible to update the process database completely from one RTU (for
example at application start-up if the NET unit is not started at the same time). The SC attribute is
automatically set to 1 when the station is taken out of use (IU=0). An SCI is sent when the station is
taken into use again, unless the SC attribute has been set to 1 manually. The SC attribute is
automatically set to 0 after an SCI.
The status check is sent automatically to all connected S.P.I.D.E.R. RTUs when NET unit is started.
It is also sent automatically to suspended RTUs.
Example:
#SET STA2:SSC = 1
Enables the registration of RP570 telegrams (transparent data telegrams (TDR), SYSM (terminal
messages), terminal status (TSTA), ERMFD messages and ERMIR messages) in bit stream process
objects. The TA attribute specifies the addresses of the receiving process objects when the telegram
type is given as the index. Transfer address 0 for an index means that the telegram type is not
updated as a bit stream.
Giving an address to transparent data (index 1) means that the whole transparent data telegram is
updated in the bit stream object with the given transfer address, and no system message is
generated. TA(1) = 0 means that a system message is generated but the telegram is not updated in a
process object.
Giving an address to terminal messages (index 2) means that the whole terminal message content is
sent into a bit stream object with the given transfer address, and additionally a system message is
generated. TA(2) = 0 means that a system message is generated, but the message is not updated in
a process object.
Giving an address to the terminal status messages (index 3), the messages are updated as a bit
stream message in the process object with the given address. The messages are updated each time
NET unit receives a TSTA message, which indicates the change of RTU terminal status. If TA(3) == 0
(default), NET unit uses the old transfer method, which means that NET unit sends a system
message when a terminal status change has occurred. In that case, each bit change in the terminal
status causes a system message, that is, one TSTA message may cause 16 system messages.
To make the bit stream messages readable, the SYS600 application must contain a command
procedure that translates the messages to terminal status information. The TSTA bit stream contains
40 bits as follows:
Giving an address to the ERMFD messages (index 4) means that the messages are updated as bit
streams in process objects. If TA(4) = 0, the ERMFD messages are updated in analog process
objects (RTU object type 11, RTU analog event recording object).
Giving an address to the ERMIR messages (index 4) means that the messages are updated as bit
streams in process objects. If TA(4) = 0, the ERMIR messages are updated in analog process
objects (RTU object type 10, RTU indication event recording).
Writing transparent data (TDC) to the RTU. The RP570 protocol conveys the data directly. The
interpretation and handling of transparent data are defined in the RTU. The response (TDR) can be
read with the RD attribute a few seconds after the transparent data has been sent, or it can be
updated in a process object specified by the TA attribute. When an answer arrives, the system
message 12683 RTU_TRANSPARENT_DATA_PENDING) is generated.
Example:
Reading of the terminal events stored in NET unit. There is a ring buffer storage of 10 events for
each RTU in the NET unit. Each time NET unit receives a terminal event it will send a tag number
(1...999) as a system message (see the MI attribute). The corresponding event can be fetched from
NET unit by reading the TE attribute indexed with the tag number.
If the event with the desired tag number is no longer found (due to buffer overflow), NET unit
responds with the error code 12655 RTUC_TAGGED_EVENT_NOT_FOUND.
Reading of the terminal message (system message in the RTU) stored in the NET unit. There is a
ring buffer storage of 3 messages for each RTU in the NET unit. Each time a terminal message from
RTU, NET unit will send a tag number (1 ... 999) as a system message (see the MI attribute) to the
base system. The corresponding terminal message can be fetched from the NET unit by reading the
TM attribute indexed with the tag number.
If the event with the desired tag number is no longer found (due to buffer overflow), error code 12656
RTUC_TAGGED_MESSAGE_NOT_FOUND is returned.
Reading the TM attribute results in a 30 byte long text string. The text is used for system analysis of
the RTU. Note that terminal messages are sent only by a function command request.
Reading the current (= last reported) terminal status stored in the NET unit as two 16 bit words. The
terminal status is sent by the RTU after a status check (start-up) (see SC attribute) or at changes in
the status during operation.
Besides the common attributes described in Section 17.3, the STA object of type SPA (SPACOM),
have the attributes described in this section.
Choosing to which NET lines the broadcast messages, that is messages to station STA0, will be
transmitted. SPA stations on LonTalk protocol lines (communicating via LSG device) must not be
included in a broadcast. The attribute can only be used with STA0W
Example:
#set STA0:SBL=(0,0,0,0,1,0,0,1,0)
#set STA0:SBL=(0,0,0,0,0,0,0,0,1)
Now it should be possible to read the message with STA0:SBL. The answer should be the line
number if only one line is specified. Otherwise it should be a vector containing the line numbers.
The station address of the SPACOM unit used in the communication with NET unit. The station
address must be unique among all SPA modules connected to the same NET line. Modules
connected to different lines may be given the same station address. The station address of a STA
object must coincide with the station address (slave number) defined in the corresponding SPACOM
unit.
The broadcast telegrams always use the address 900 and need not be specified by this attribute.
Unit number of the SPA. Corresponds to the SPA station address (slave number).
The type of the relay module: relay unit, alarm unit or SPA unit connected to LSG device.
The RL attribute defines the object number (STA object number) of the LSG device to which the SPA
station is physically connected and which acts as a router for the SPA station.
The attribute applies only for SPA units that are connected to the LONWORKS network via LSG
devices (UT = 3). It has no meaning for the SPA units connected directly to the NET unit.
Event updated points are polled periodically with this interval to ensure that the value in the database
is OK.
The number of events stored in the station specific event buffer in NET unit. The suitable size is
limited by the available free memory in NET unit.
The event poll priority class of the station. Using the SPA line attribute PT (see Section 14), it is
possible to define a ratio between event polls to stations of different priority classes.
Diagnostic counters keep count of various situations that can occur in the STA device. Each counter
is associated with a descriptive name, but when it is accessed from SCIL the corresponding counter
number (integer constant) must be used.
Maximum time in seconds to wait for reply from a SPACOM unit. If the station does not answer within
RT seconds, it will be suspended.
These attributes specify the handling of individual SPA points in NET unit. Station specific sequence
numbers identifies the SPA points.
Defines SPA points that are updated by events. The attribute specifies which events that may update
each SPA point, and how the event codes shall be interpreted.
Example:
In a SPOC 110C unit, channels 1 ... 8 are defined as double indications, channels 9 ... 16 as single
indications. Both are event updated. The double indications use the following event codes:
GUID-1F1F15E7-2EAB-432F-9A04-92042F17DD9E v1
E1 = 01 (closed)
E2 = 10 (opened)
E3 = 11 (error)
E4 = 00 (error)
Table 8: Explanations of the SPA point and event updating definition parameters (the SP and ED attributes)
Parameter Explanation
bit transpose mask Integer, 0 ... 65535. The bits in the bit mask of the integer specify in pairs a possible
change of bit order in double indications. ''00" = no change of order. "11" = change of
order. In SYS600 the first bit in a double indication is supposed to be "closed" and the
second bit "open". If the SPACOM unit uses another order, the bits must change order.
bit type mask Integer, 0 ... 65535. The bits in the bit mask of the integer specify in pairs the type of
indication: "11" = double indication, "0" = single indication.
channel 1 Integer, 0 ... 999. The lowest channel which updates the point.
channel 2 Integer, 0 ... 999. The highest channel which updates the point.
data format 1 = bits
2 = hexadecimal
3 = real
4 = long integer
data category The data category as defined in the SPA protocol (v.2.4) given as a text: "I", "O", "S",
"V", "M", "C", "F', "T", "D", "L", "B".
data nr 1 Integer, 0 ... 65535
data nr 2 Integer, 0 ... 65535
event number An event number that updates the point.
event value The value that the point is updated to when the event specified by ‘event number’
occurs.
filter (deadband) Real positive decimal value 0 ... 0.999 (less than 1). The smallest change in input value
that is reported to the process database.
object type Integer 0 ... 7. 0 = indication, 1 = digital input, 2 = analog input, 3 = digital setpoint, 4 =
analog setpoint, 5 = object command, 6 = pulse counter, 7 = event code parsing (for
internal use only)
process object address Integer, 1 ... 255. The block address of the process object corresponding to the SPA
point (as defined in the process object definition.
bits per channel Integer, 0 ... 15. The number of bits per channel.
significant bits Integer, defines the count of the bits that are affected by the event to data conversion.
1 - single indication, 2 = double indication.
updating method 1 = cyclical polling
2 = event update
3 = event consume. Events are used for the updating of the corresponding process
object, but not for updating of the event handling object.
Defines the SPA points to NET unit. It ties together the SPA identifications and the corresponding
process objects. Each SPA point, independent of updating method, must be defined by this attribute.
A SPA point number identifies each SPA point, which must be unique among all SPA points within
the SPA module.
If the object type is analog input or pulse counter and the amount of the configured data points is
greater than 1 (data2 - data1 > 1), the entered SYS600 process object address is understood as a
starting address and is updated with value 'data 1'. The deadband value given as element 9 is
meaningless in this configuration. The maximum amount of values in one definition is 15. See the
example at the end of this description for more information.
When writing to this attribute, all parameters must be present. See the parameter explanations in
Table 8. The SPA points in SPA units connected via LSG device are defined mainly in the same way
as SPA points connected via the SPA protocol. However, there are some differences in the analog
point definition.
2: Channel 1
3: Channel 2
4: Data category
5: Data 1
6: Data 2
7: SPA data format
8: Process object address
9: Updating method
Indexing: SPA point number, 1 ... 4095
Access: No restrictions
Example:
Defining an analog point that contains the measured current on phase 3 (SPA item: channel 0, "I",
data 3), in a SPAC 310 C/SPTO 1D unit. Filtering is set to 0.1*In. The SYS600 process object
address is 200:
Defining three pulse counter points of active energy in the SPAC 330C unit (SPA item: channel 0,
"V", data 8 ... 10). The delta value 0 is meaningless in this situation. The updated SYS600 process
objects are 100 .. 102:
This attribute is used for process database communication. It may not be used in SCIL programs.
By writing to this attribute (value 1), the writing application reserves the right to read and write the
SPA parameters using the STAn:SSM attribute of the station. By writing a zero (0) to the PR attribute,
the reservation is released. Only the reserving application, or the AS application can release the
reservation. By reading the attribute you get information of the reserving application.
When no reservation is active, only the AS application is allowed to access the SM attribute.
Spontaneous data (events etc.) is always sent to the application defined by the AS attribute.
Makes it possible to communicate with a SPACOM unit by sending any SPA message and reading
the reply as a text. No check of the message is performed in SCIL, or in NET unit, that is, even faulty
messages are sent to the SPACOM unit.
When a SPA message has been sent from an application, the reply to the message can only be read
once from the same application.
Unless a reservation has been made with the PR attribute, only the application specified by the AS
attribute has access to the SM attribute.
Example:
Requesting SPACOM unit identification using data category "F", from a 16D alarm unit:
@R = STA1:SSM
Starts an updating of all SPA points. When the attribute is set to 1, NET unit starts to poll all defined
SPA points once (including event updated points) and sends the data to the application, whether the
data had changed or not. Filter values for analog points are ignored. When all points have been
polled once, NET unit resets the UP attribute to 0 and sends a system message
(SPAP_DATABASE_UPDATE_COMPLETE).
These attributes are used only with the TCP/IP communication mode of the SPA protocol. The SPA
protocol is configured to the TCP mode by giving the SD attribute of the line object the value "TCP".
See also the LD line attribute.
The other parts of the SPACOM attribute interface are the same for serial and TCP modes of the
SPA protocol.
The maximum time of the TCP connect operation. The value of this attribute depends on the speed
of LAN, remote station and the possible routers between SYS600 and the substation. It should be
smaller than the HT attribute of the line but it should be big enough to enable reliable reconnecting of
the substation. In a multidrop configuration, too big a value may cause communication disturbances if
some of the stations is not available.
The IP address or the host name of the remote host. The connection is established with a device in
this address using port number 7001 (defined in [2]). The line must be taken into use at least once
before the writing to this attribute.
or as an alias name
When an alias name is used, it must be defined in the TCP host file %windir\system32\drivers\etc
\hosts
If the remote slave device uses a non-standard port for the communication, it can be specified
followingly:
No space characters are allowed between the address and the port number. The port number must
be in range 1 ... 65535.
Each station of type Procontrol P214 (Indactic) must be defined as a STA object (of type "PCL") in
the NET to which it is directly connected. The STA object can be defined with the PC attribute, see
Section 15.4.3 .
When the P214 STA objects are defined on-line (with the PC attribute), the STA attributes get the
default values listed in appendix A and mentioned in the attribute descriptions.
A broadcast STA object with system object number 0 is automatically created each time the
communication unit starts up. The broadcast object notates all P214 RTUs connected to the same
NET.
The attributes in this section are valid only for stations of type P214. The attributes are accessed
from SCIL with the object notation:
GUID-56F11076-A9B8-43A2-A250-0D1D6C1ABCAB v1
STAn:Sat
where
'n' is the station number, 0 ... 1000, as known to the application by the station mapping, see
section 12.3.4. The number is translated to system object number, 0 ... 100, as illustrated in
figure 12-5.
'at' is attribute name.
The STA attributes in this section are valid only for stations of type P214. The attributes are
described in the following subsections:
This attribute states whether the station connection is in use or not. The attribute tells the state of use
as known to the communication unit. It does not affect the station itself, only its image in the
communication unit.
The station sends no system messages as long as it is out of use. At the moment when the station is
taken out of use a system message is sent.
The number of the NET line, to which the RTU is connected. The station is switched from one line to
another by writing a new value to the LI attribute. Change of line in this way is possible only if both
the previous and the new lines are defined with the same protocol and have been taken out of use.
The station address of the RTU. The address must be unique among all S.P.I.D.E.R. RTUs and P214
RTUs connected to the same NET. The attribute must have the same value as the station address in
the corresponding RTU.
The attribute tells whether or not the RTU is reserved by a certain application (see the AS attribute).
Rec. value: For P214 connections AL should always be 1, i.e. the allocation is always active (AL = 1).
The number of the application which has reserved the RTU. The spontaneous messages from the
station are sent to this application. Other applications can send read commands to the station but do
not get any spontaneous messages.
Value: Integer, 0 ... 250. The application number as known to the communication unit. 0 = no
application.
Access: No restrictions
• When the RTU line has got erroneous replies or no reply after the number of trials determined
by the EN attribute of the line (Section 16.4).
• When a reply message from a station does not arrive in time (REPLY TIMEOUT), see the RT
attribute.
1. STATION_SUSPENSIONS COUNTER
2. DEV_STATUS_RECEIVED COUNTER
3. REPLY_STATUS COUNTER
4. STS_NOT_OK_FROM_PCL COUNTER
Value: Vector of four integers in the range 0 ... 30000. Each element is a counter value.
Indexing: Counter number.
Access: No restrictions.
The maximum time (number of seconds) that the communication unit will wait for a reply from the
station.
Based on the system messages from STA devices, the SYS600 base system automatically updates
the validity stamp of the object values in the process database (the OS attribute), see Figure 16 and
Section 15.3.4.
Refer to Section 15.3.4 to learn more about the system message handling.
The object address (the POA attribute) to which the system messages from the device are sent. See
the MI attribute in Section 15.3.4.
The MS attribute is the system object number of the application which will receive the system
messages from the station.
Value: Integer, 1 ... 250. The APL object number as known to the communication unit.
Default value: 1
Access: No restrictions
Writing to the OS attribute (OS = 1) of a station makes NET retransmit the last system message
caused by the station. Possible Stopped and Suspended messages cause old-marking of process
objects. By reading the OS attribute, the status code of the system message can be read.
Value: Integer
When written: 1 = retransmit system message
When read: a status code:
0 OK
12803 Station not in use
12801 Station suspended
Examples:
#SET STA2:SDA500^1 = 1
@V = STA4:SDA300
The event generation in the RTU can be enabled or disabled for one class at a time using the EC
attribute. When the EC attribute is read, NET returns a 16 bit mask, but the attribute is written one bit
at a time by indexing the attribute.
Example:
Freezes the counters of all P214 RTUs connected to NET. NET will send one freeze counter
command per P214 line.
Value: 1
Access: Write-only, only for broadcast station
Example:
#SET STA0:SFC = 1
Setting this attributes clears all the event buffers of the station.
Value: 1
Access: Write-only
Example:
#SET STA1:SFE = 1
Group parameters (at present, only deadband) can be read and written with this attribute. Because
the number of parameters varies from group to group, the parameters should always be read first,
then edited and written. When reading the GP attribute, NET returns a vector. When writing, a string
variable should be used.
Example:
@V = STA2:SGP200
Value: 1
Access: Write-only
Example:
#SET STAn:SNR = 1
Synchronizes the clocks of all P214 RTUs to the NET clock using one broadcast command to each
P214 line. The internal clock of the computer should be synchronized before synchronizing the
RTUs.
Value: 1
Access: Write-only, only for broadcast station
Example:
#SET STAn:SST = 1
Writing of group type code to the attribute TV means a request for updating objects of that type in the
process database.
Example:
#SET STAn:STV=5
This attribute controls the polling relation between the priority levels. The value of the PC attribute
tells how many times in a sequence the events of the high priority level can be read, before the data
of the low priority level will be read once. The attribute value is significant only if there are events on
both levels in every polling cycle.
With this mask the event classes of the RTU can be grouped into two priority levels. The mask is a
16 bit word. Each bit in the mask controls the corresponding event class. The ones in the mask tell
which classes will be polled with a higher priority. The internal event classes (13, 14 and 15) are,
however, always polled with high priority, and will always be returned as ones from NET when PM is
read. When writing the PM attribute, NET ignores the contents of bits 13 ... 15.
Besides the common attributes described in Section 17.3, the STA object of type REX (REF, RED,
REC, etc. relays) have the attributes described in this section.
Unit number used in transparent SPA messages (both messages resulting from commands and
messages generated with the SM attribute.
This attribute is obsolete, it has no functional meaning. For compatibility reasons, it has not been
removed.
The timer (Terr) for controlling the cyclic sending of NACK after a message sequence error. This
timer is active only when the network congestion occur, and should be a bit less than the retransmit
timer (Retr).
Controlling and monitoring of REX device Session Setup. The session Setup mode must be
configured with SH attribute before the device is taken in use.
Example:
The idle ACK message interval timer (Tidle) is used to keep channel alive. It also retransmits ACK
messages in case of ACK loss. In that situation the flow will be driven by the retransmission timer.
The Session Idle Timeout needs to be smaller than the Session Keepalive Timeout (SK).
The connection timer (Tconn) that supervises the operation of the remote node. On the idle channel
both of the transmission partners send frequently so called keepalive messages. This transmission
should happen in the range of 1 minute. Otherwise the connection timeouts.
The retransmit timer (Tretr) is used to trigger a retransmission of the unacknowledged message if the
message or ACK / NACK was lost. The Session Retransmit Timeout should be greater than the time
to send a full window (max Credit).
The time that the receiver of the message waits before responding. The timer is activated after every
received message. If the channel is idle the timer will timeout. During obstruct of traffic the sender will
lose the Credit and flag the message for immediate ACK (TranAck flag). In such circumstances, the
Tseq timer will not expire.
This attribute is used for process database communication. It is not used from SCIL programs.
Receive quota for the station. This attribute defines the maximum amount of incoming data
messages received from the device but not yet acknowledged and transmitted to the SYS600
process database. This value is not used in the transparent SPA communication. Generally, the
default value is suitable. A bigger value increases the buffer consumption from the pool defined with
the line attribute PS.
Sending of any SPA message to the REX station. The reply that is received can be read as a
character string using the SM attribute and processed in SCIL. When sending a SPA message,
SYS600 does not check the correctness of the message syntax.
Example:
Requesting SPAOM unit identification using data category "F", from a 16D alarm unit:
#SET STA1:SSM = ("RF::") ;This result "<1RF::XXcr" (XX=CHECKSUM) on the SPA BUS, read the result
@R = STA1:SSM ;%R could now be "<1D:SACO 16D1:cr"
This attribute can be used to report for too high speed of issuing the SPA messages using attribute
SM. If the value of TC is 1, STA object may return an error code 13356 REXC_SM_WRITE_BUSY
indicating that the amount SPA messages is too big for the device. With most devices, this
transaction check is not needed.
Transmit quota for this device. This attribute defines the maximum amount of outgoing data
messages transmitted to the device but not yet acknowledged by the device. This value is not used
in the transparent SPA communication. Generally, the default value is suitable.
An application may at any time force a complete update of point data by mean of this attribute.
Setting this attribute to 1 makes the NET unit send a general interrogation command to the REX unit
that then reads its process connections and sends the data to NET unit. NET unit resets the GI
attribute to 0 when the general interrogation termination message is received from the unit.
Example:
#SET STA4:SGI = 1
Example:
Substitute & block double point information 1 to unit number 7, object address 1342 in REX device 4,
length 1 byte, originator address 3:
UN Unit Address of the handled object. This is an end of commands flag, session start-up
sequence can continue, rest of the elements are ignored. Value: 1 ... 65535
OA Object Address of the handled object
OG Originator Address
TOH
Value: Description:
0 Substitute
1 Desubstitute
2 Block
3 Deblock
4 Substitute & block
5 Desubstitute & deblock
6 Set (parameter)
7 ... 255 Reserved for future use
TOV
Value: Description:
0 Value not present
1 SPI Single Point Information
2 DPI Double Point Information
3 SVAF Short Floating Point Number
4 BSI Binary State Information
5 BCR Binary Counter Reading
6 VAI Signed Integer Information (16 bit)
7 VAI32 Signed Integer Information (32 bit)
8 VTI Value with Transient State Indication
9 CP16 Two Octet Binary Time
10 Time Tag Information
LOV Length of attribute value (AVA) in bytes
AVA Array of bytes according to TOV as defined in LAG
Downloading the interlocking data to a bay unit when substitution concept is used.
Example:
Filter number for event sessions. This attribute value specifies, which filter is going to be used. It is
specified when the PC-NET is configured when opening a session between the relay and the PC-
NET. The lower the filter value is, the more signals are sent by the relay.
At the moment the default value for PC-NET is 0, which means that the REF relay sends all signals
without filtering them. In this case, it would mean having a great amount of events. Therefore, it is
recommended to use event filter number 2 with SYS600.
Specifies whether history events are requested at event session start-up or not. History events are
events collected before event session start-up time.
If this attribute is set to 1, all history events registered in the station since the time specified by the
HS attribute (see below) are reported at the beginning of an event session.
The start time of the history events, which will be reported at the beginning of an event session when
HI = 1 (see the HI attribute above).
Example:
Assuming NEWEST_EV is a process object whose time is used to specify the start time of history
events:
The maximum time in seconds that NET unit waits for reply from the REX unit when sending
commands and transparent SPA messages.
The binary output objects of the REX stations must be defined in NET unit as SPA points using the
SP attribute.
The binary output objects (SPA commands) as SPA points to NET unit. It ties together the SPA
command identifications and the corresponding process objects. A SPA point number identifies each
SPA point, which must be unique among all SPA points within the same REX module.
Example:
Defining a binary output at channel 1 in a SACO16D unit (SPA items: 1O1) at OA 666:
With REX device File Transfer Timeout handling attribute timeout value can be changed if necessary.
Example:
#SET STA1:SFO = 10
With REX device File Transfer Progress handling attribute user can follow the processing of file
transfer. Value is the amount of transferred bytes. This attribute cannot be read by SCIL because the
data transfer is not known by SCIL. User gets the value of progressed file transfer from FP process
object attribute.
Besides the common attributes described in Section 17.3, the STA object of type LMK (LSG devices
and other LONWORKS devices, but not REX relays) has the attributes described in this section.
• LSG device
• Multiple LONMARK devices (devices which take input from many physical devices)
• Other devices using the standard LONWORKS interface (for example Weidmüller)
Defines the period of time that the LMK device polls network variables (each CT minutes). This
ensures that the data in the local LMK database is consistent with the data in the physical device.
(The LMK needs a local database to be able to handle deadband supervision). The consistency
polling is initiated from PC-NET for configured LON Points of types analog input and digital input.
The attribute for process communication database. It is not used from SCIL programs.
An application may at any time force a complete update of point data by mean of this attribute.
Setting this attribute to 1 makes the NET unit send a general interrogation command to the LMK unit,
which then reads its process connections and sends the data to NET unit. NET unit resets the GI
attribute to 0 when the general interrogation termination message is received from the unit.
Example:
#SET STA4:SGI = 1
Sending any LonTalk message to the LMK station. The reply that is received can be read back from
the LM attribute (as a character string) and processed in SCIL.
Maximum time in milliseconds to wait for reply from a LONWORKS node when sending commands
and transparent SPA messages.
Keeping count of various situations that can occur in the STA device. Each counter is associated with
a descriptive name, but when it is accessed from SCIL the corresponding counter number (integer
constant) must be used. LMK stations have 8 diagnostic counters.
1. LKM_PROCESS_DATA_TLG_RECEIVED
2. LMK_SENT_SPA_MESSAGES
3. LMK_SUSPENSIONS
4. LMK_REPLY_TIMEOUTS
5. LMK_BUFFER_ALLOC_FAILURES
6. LMK_TRANSPARENT_SPA_TIMEOUTS
7. LMK_UNEXPECTED_REPLY_RECEIVED
8. LMK_REPLIES_RECEIVED
Defines the period of time that the LMK device polls node status from the physical device (each DI
seconds) to make sure that the connection is alive. A failed status poll suspends the device. The
diagnostic message is initiated from PC-NET to the LSG device and it uses REQUEST/RESPONSE
service provided by LON.
Ties together the LONWORKS Network Variable indices with process objects in the process
database. A LON point number identifies each LONWORKS point in NET unit, which must be unique
among all LON points referring to the same LONWORKS module.
Example:
Defining an analog input with process database address OA= 6666, LON NV index = 234 and
deadband 1.123:
#SET STA1:SLP1 = (2, 234, 2, "Phase 1current on bay 3",1, 6666, 1.123)
SPI type stations correspond to SCADA systems and other control systems, which communicate with
NET unit through the RP570 slave protocol in a master-slave relation where NET unit is the slave.
NET unit sees the control system as a station (a STA object), and the control system (from now on
referred to as 'master station') sees NET unit as a S.P.I.D.E.R. RTU200.
The RP570 slave interface in NET unit emulates a RTU200. It is parameterized like RTU200 with
FTABs, which must be loaded at each NET unit start-up. FTABs can be loaded either from the
master station or from the SYS600 base system.
The attribute interface of Modbus Slave station resembles the process communication attributes of
SPI stations.
Besides the common attributes described in Section 17.3, the STA object of type SPI has the
attributes described in this section.
The station address of the master station. The address must be unique among all SPI type stations
connected to the same NET unit. The address must coincide with the corresponding address in the
master station.
Loading FTABs to NET unit. By using this attribute, NET unit can be parameterized with FTABs
loaded from the SYS600 base system, and FTABs need not be downloaded from the master station.
The FT attribute accepts FTABs in the same format as the RTU 200 devices (RTU type STA objects)
in NET unit. This format is a character string whose ASCII value represents the corresponding FTAB
byte in a certain FTAB. Use the SCIL function RTU_BIN to convert hex values to ASCII. Refer to the
RP-570 protocol manual to find details about the FTAB contents. The supported FTAB fields are
listed in the document Functional specification for RP-570 Slave protocol in NET. Unsupported fields
are ignored.
When all FTABs have been loaded, bit 8 (RTU active) in the ST1 attribute must be set to 1. This has
the same effect as "FCOM ACTIVATE" from the master.
Example:
Writing a simple AMV FTAB for block number 100 with priority 1 and deadband 10:
This attribute is used to define and store the version of the RP570 database in the SPI station object.
The version string consists of six info bytes with the following meaning:
RP570 master may define this string using the function command 19 = Database version or it can be
defined from SCIL using this FV attribute. The SPI station object uses terminal event 23 to report the
version string which is currently active e.g. after a cold start.
Example:
#SET STA1:SFV="000000"
This attribute defines the low and high limits for valid analog input values. If the value is outside the
range defined by this attribute, the data is sent with faulty status.
Default: 1 -2000
2 2000
Access: Read/write
Consists of a set of flags that control the behavior and functionality of the SPI station. Each flag is
represented by one bit of this attribute.
The following attributes are used for sending data from SYS600 base system to the master station
via the NET databases. Each SPI type station defined in NET unit has its own database for data
transfer to the master station. The data transmission and the activation of the data transmission must
be handled on application level using cross references in the process database (the FX and FI
process object attributes), event channels and command procedures. For this purpose, there are
ready-made tools and procedures, which can be used as such or modified.
The data sent from the master station to SYS600 are updated in the SYS600 process database as
input data.
The attributes described in this section apply also to Modbus Slave station. For more information on
Modbus Slave stations, see the Configuring SYS600 for Modbus Slave Manual.
Update of changes in analog measured values in the master station. The values assigned to this
attribute are transferred to the master station as AVM/AVS telegrams. The AV attribute is assigned a
vector consisting of a time stamp, the analog value and a status indicator. The current value of the
AV attribute can be read back, but a read operation only returns the analog value (not a vector).
The attribute is indexed by the block address of the value as defined in the master station and in NET
unit.
Example:
Setting the analog value with block address 100 to an object value with status = OK (= 0):
Send of changes in double indications to the master station. The values assigned to this attribute are
transferred to the master station as IDS/IDM telegrams. The attribute is assigned a vector containing
a time stamp, bit number, double indication value, and status indicator.
The contents of the attribute can be read back to a SCIL variable, but the result of a read operation is
a single integer rather than a vector. The integer variable is a 16-bit bitmask that represents the state
of all bits in this block.
Example:
Single indication handling. Assume that we have a single indication at block 55 bit 8, a time stamp in
the variable %TIME, and time_quality = 5. To send an ERMI message to the master station when bit
8 changes state to 0, execute the following SCIL statement:
To send an ERMI message when bit 8 changes state to 1, execute the following SCIL statement:
Example:
Double indication handling. Assume that we have a double indication at block 55, bits 2 and 3, a time
stamp stored in the TIME variable, time_quality = 5, bit 2 = 1 and bit 3 = 0 (the double indication bits
are thus 01).
To send an ERMI message when bit 2 changes state to 0 (switch opens, but has not reached end
position yet), that is, the double indication bits are 00, execute the following SCIL statement:
To send an ERMI message when bit 3 changes state to 1 (switch is open and has reached end
position), i.e., the double indication bits are 10, execute the following SCIL statement:
To send an ERMI message when the switch is closed again but a fault keeps bit 3 activated, while bit
2 changes state to 1, i.e. the double indication bits are 11, execute the following SCIL statement:
Generating ERMx messages. By writing a vector of bytes to the EX attribute, NET unit generates
ERMx message according to the data of the vector. The first element in the vector determines the
type of the ERMx message.
The ERMx messages are stored in a queue in NET unit that can contain max. 100 ERMx messages.
This queue is common for all ERMx messages, also the ERMI messages generated using the EI and
ID attributes. If the ERMx queue overflows, the EX attribute returns en error value and NET unit
sends the systems status message to the SYS600 base system and a TEV (2) message to the
master station.
Updating changes in indications (binary input data) in the master station. The values assigned to this
attribute are transferred to the master station as IDS/IDM telegrams. The attribute is assigned a
vector containing a time stamp, bit number, bit value, and status indicator.
The contents of the attribute can be read back to a SCIL variable, but the result of a read operation is
a single integer rather than a vector. The integer variable is a 16-bit bitmask that represents the state
of all bits in this block.
Example:
#SET STA99:SID(25)=(RTU_ATIME(%RT,%RM),0,1,0)
Setting double indication bits 2 and 3 at block 5 to 10 (= OFF), assuming that status is OK:
#SET STA99:SID(25)=(RTU_ATIME(%RT,%RM),2,0,0)
#SET STA99:SID(25)=(RTU_ATIME(%RT,%RM),3,1,0)
Setting bit 8 in block 55 to 1 and generating ermi, status set to 1, time quality = 5:
Updating changes in pulse counters in the master station. The values assigned to this attribute are
transferred to the master station as PCM telegrams. The PC attribute is assigned a vector consisting
of time stamp, end of period flag and pulse counter value.
The content of the attribute can be read back to a SCIL variable, but the result of a read operation is
a single integer rather than a vector. The integer variable contains the last PC-value that was written
to this block.
A previous value that has not yet been sent to the master station cannot be overwritten by a new
value. If an attempt is made to write such a value, the SCIL STATUS
SPIC_PREV_PC_VALUE_NOT_YET_REPORTED is generated. The pulse counter value may be
saved and sent later.
Example:
The TA attribute used with index 1 specifies the address of the bit stream type process object where
the data part of incoming TDC messages from the master station will be sent. Address 0 disables
transparent data handling and the NET unit responses with NXR to TDC messages.
NET unit sends some incoming FCOM messages directly to a bit stream type process objects in the
base system. The TA attribute used with index 2 specifies the address of this process object. The
following FCOM numbers are handled this way:
FCOM20
FCOM21
FCOM22
FCOM24
Data type: Integer
Value: Each index of the attribute is a process object address given as an integer
Indexing: 1 or 2. TA(1) = TDC address. TA(2) = FCOM address.
Default: Both indices = 0
Access: No restrictions
The base system is responsible to reply to a received TDC message with a TDR message. A TDR
message is created by writing a byte string to the TR attribute. The NET unit adds the necessary
frames to the message and sends it with priority 3 to the master station.
NET unit has a queue for 5 TDR messages, that is, NET unit can store up to 5 unsent TDR
messages.
The command blocking in NET unit. When NET unit detects an exclusive command (IXC, CBXC,
EXC, IHC or SPM message when EC >0) from the master station, NET unit sets the command
blocked flag to 1. The commands can also be blocked by setting the CB attribute = 1 in a SCIL
program. The blocking is automatically released when the time defined by the EC attribute (see
below) has elapsed. The blocking can also be released by setting CB = 0.
If the base system replies with an error reply to a command, which would have caused a command
blocking in NET unit, no command blocking takes place.
Time limit in minutes between CBXC and EXC telegrams. If this time limit is exceeded, the command
selection is aborted.
Keeping count of various situations that can occur in the STA device. Each counter is associated with
a descriptive name, but when it is accessed from SCIL the corresponding counter number (integer
constant) must be used. The following counters are updated:
1. ERMI_BUFFER_OVERFLOW
2. SCI_RECEIVED
3. CBXC_TIMEOUT
4. EXC_FAILED
5. IHC_FAILED
6. IHC_RECEIVED
7. SCS_REPLY_TIMEOUT
8. STATUS_NOT_OK_FROM_NET
9. TEV_BUFFER_OVERFLOW
10. TR_BUFFER_OVERFLOW
11. BLOCKED_COMMANDS
12. EXCLUSIVE_COMMAND_TIMEOUT
Indicating whether or not the database in NET unit has been initialized and can be polled from the
master station. At NET unit start-up, the DI attribute has the value 0. When all values in the NET
database have been initialized (either given a value or a faulty status), this attribute must be set to 1.
NET unit does not answer to polls from the master station until DI = 1.
Specifies the command blocking time in seconds. Command blocking means that after a command
from the master station, no new command is allowed until the blocking is released. The command
blocking is automatically released when the time defined by the EC attribute has elapsed. It can also
be released by writing a 0 to the CB attribute (see above). During command blocking the NET unit
replies to incoming commands with NXR.
When the data communication attributes AV, ID, EI, EX and TV are updated, NET unit updates the
data in the databases of all SPI type stations, which have MM = 1. This means that the same data is
sent to all these master stations. The MM attribute does not affect the transmission of transparent
data.
The maximum time in seconds for waiting for a reply from the base system before regarding it as
communication timeout. When NET unit receives an EXC, IXC or TXI telegram from the master
station, it sends it to the receiving SYS600 application. If NET unit does not receive an
acknowledgement from the base system within RT seconds, it is regarded as a communication
timeout and an NXR message is sent to the master station.
When all relevant parts of the SYS600 system have received time synchronization as a result of a
TSI telegram (Time Sync Instruction) from the master station, NET unit should be notified by setting
this attribute to 1. As long as TI is 0 (default), the bit with the information "RTU is synchronized" is 0
in all applicable RP-570 messages.
Corresponds to terminal status messages (TSTA) generated by the RP-570 interface. Each time the
ST attribute is set, a new terminal status message is sent to the master station (if new status <> old
status).
The attribute is used indexed. Index 1 of the ST attribute corresponds to TSTA, ID=1 messages, and
index 2 to TSTA ID=2. Each index is assigned a vector value where the first element indicates the
number of the bit to be operated (set or cleared). The second element determines the operation (set
or clear) to be performed on the bit.
The lists below shows the status information that the master station associates with the different bits.
Example:
Setting the TI attribute (see Section 17.10.4) is equivalent to setting ST(1) bit 9.
Activating and de-activating the loop control. Set the IU attribute of both the line and the STA object
to 0 before changing this attribute.
The maximum time for NET unit to wait for reply from the master station before sending the system
message to the base system. Loop switching is done if no RA or RB polls are received within LT
number of seconds.
When the DI attribute is set to 1, that is, NET unit starts to wait for messages from the master station,
it waits LT number of seconds. If no valid RP-570 message is received within this period, the system
message SPIP_COMMUNICATION_WITH_CS_LOST is sent to the SYS600 base system. If loop
control is used, the loop direction is toggled.
After each valid RP-570 message, NET unit waits LT + 30 second before
SPIP_COMMUNICATION_WITH_CS_LOST is sent.
When communication has been down, and a valid RP-570 message is received, the system
message SPIP_COMMUNICATION_WITH_CS_ESTABLISHED is sent to the SYS600 base system.
The following attributes can be used for defining redundant lines for RP-570 Slave and IEC
60870-5-101 Slave protocols.
The number of the back-up line is set to index 2 of the LI attribute. More about LI attribute can be
found in Section 17.3.2.
Example:
#SET STA1:SLI(2) = 5
This attribute defines the number of the STA object connected to redundant RP-570 lines. This
attribute should be set both for the main and back-up lines. The information provided by this attribute
is needed when a line switch operation is executed. Value 0 indicates that redundant lines are not
used.
The attributes RM (bit 0), AT and CS can be used to form a negative or a positive response to an
incoming control command from the SCIL application.
With setting RM bit 0 = 0, all command messages (CBXC, EXC, IXC and IHC) are always responded
by PC-NET with CBR/EXR, meaning OK. This is the default behavior and if it is used the information
of this section is not needed.
With setting RM bit 0 = 1, PC-NET is configured to use the enhanced mode and it waits until the
SCIL application has written to the CS attribute. No automatic responses are sent in this mode.
When a control command is received by the SPI station object, it updates a process object with the
same address as the object number in the incoming command message. The updated process
object is of type ANSI/Digital Input.
With setting RM bit 0 = 1, the incoming command updates the attribute RA of the mentioned process
object as follows:
With setting RM bit 0 = 0, RA is updated with value 0 and the application need not write to the CS
attribute. When a control command is received, the operation of the COM500i signal routing
procedure COM_DSBO is based on the value of the RA attribute of the updated process object.
The application should write to the CS attribute within the time specified by the SPI station attribute
AT.
Timeout value for the command confirmation from application. The value specifies how long the
application is waited for to write to the CS attribute. This timeout should be longer than the response
header timeout multiplied by the retry count in the master end. In normal situation, this attribute has
no effect.
Manual confirmation of the received messages. In RP570, the commands received by the slave
station are confirmed by using specific response messages and the response message is selected
using the status value given as the first parameter.
This section describes the communication system PRI objects and their attributes:
Each printer connected to the process communication system must be defined as a PRI object in the
NET unit to which it is directly connected. PRI objects are defined with the NET object attribute PR
(Section 15). Defining a PRI object requires that the line has been defined as a printer line (Section
16). The printers must also be defined as PRI base system objects in the base systems that will use
the printers.
When the PRI objects are defined with SCIL (with the PR attribute), the PRI attributes get the default
values given in the attribute descriptions.
From SCIL, the PRI attributes are accessed with the notation:
GUID-FF4B14F6-9124-4B99-8433-8A0E21287597 v1
PRIn:Sat
where
'n' The logical printer number, 0 ... 20, as known to the application according to the printer
mapping (see the mapping attributes in Section 7). The number is translated in the base
system (through the application mapping and the corresponding PRIn:B object) to system
object number, 1 ... 8.
'at' An attribute name
Specifies whether the printer connection is in use or not. The attribute determines the state of use as
known to the communication unit. It does not affect the printer itself, only its image in the
communication unit.
If the printer is off-line or its IU = 0 when a printout message is sent to the printer, the message is
saved in the spool queue of the base system. The message is stored until IU is set to 1.
The printer sends no system messages as long as it is out of use, only at the moment when it is
taken out of use.
The number of the NET line to which the printer is connected. The line is determined when the printer
is created with the NETn:SPR attribute.
The type of the printer as defined to NET unit. There are six types of printers which product different
type or printout:
• Character based black and white printout (ASCII). The base system sends CR and LF
characters within the print messages.
• Transparent printout. Printers defined as transparent can print the printout commanded by the
SCIL function PRINT_TRANSPARENT.
• Pixel based, black and white printout. All EPSON FX compatible printers can be used for this
type of printout.
• Character based black and white printout (ASCII). The base system does not send CR and LF
characters, but it sends color information, which is not printed. Graphical characters can be
replaced by printer characters using the CT attribute (Section 18.3.6).
• Character based color printout. This type is used on FACIT 4544 printers. The characters CR
and LF are generated by the communication unit.
• Pixel based color printout. All EPSON JX compatible printers can be used for this type of
printout.
The CR character causes a carriage return and the LF character a line feed.
The corresponding PRI base system objects must be defined as the same printer type in the base
systems.
NET uses the control sequence ESC ? K for setting printers of type 3 and 7 in graphical
mode. This sequence is not supported by all EPSON FX-80 and EPSON JX-80 printers.
Reservation of a printer is needed to prevent mixing of printer outputs from different program
processes (in the same or in separate base systems). Therefore, the main program always reserves
a printer before sending print messages (if all the data to be printed does not fit into one message).
After sending the print messages, the main program releases the printer (AL = 0) automatically.
Normally, there is no need to write the AL attribute from application programs. Manual printer
reservation with SCIL is needed only when using DA and CD attributes (see Section 18.3.5).
If the printer has been reserved by setting the AL attribute or it is reserved for some other reason, it
must be released by a program in the same application as reserved the printer. When releasing a
printer, the printer must first be taken out of use with the IU attribute (see below) before the AL
attribute can be reset.
The number of the application that reserved the printer. NET unit automatically updates the AS
attribute by the number of the writing application when the AL attribute is set to 1 on-line. When the
AL attribute is set to 0 on-line, the AS attribute is set to 0 as well.
A PRI object generates system messages, for example in the following situations:
• The printer has been offline or busy for more than 10 seconds.
• The printer connection (DCD) has been lost.
• The printer accepts data again after any of the above situations.
Concerning the system message handling, see System Message Attributes in Section 15 and the
System Configuration manual.
The process object address (the OA attribute of the process object) to which the system messages
from the device are sent.
Specifies the application that will receive the system messages caused by the PRI object. Its value is
the system object number of the application as known to NET unit.
When written the attribute causes a re-transmission of the latest system message (write value 1), or
cancels a possible OFF_LINE state (write value 0). When read, the attribute returns the current
printer status.
If the printer does not send XON after it has been turned on, NET unit will regard it as offline. Writing
to the OS attribute cancels the off state, provided that the printer is on.
After an application has been started, the process object that receives the system messages caused
by the printer (the MI attribute) has no value (OS = 10, not sampled). An updating of the process
object is achieved by writing to this attribute, for example in the command procedure started by
APL_INIT_1.
Write:
1 Re-transmission of latest system message
0 If printer is off, writing value 0 does nothing. If printer is on, writing value 0
cancels the OFF_LINE (XOFF) state. This causes a system message with the
status code 13126 PRIC_PRINTER_OFF_LINE_STATE_CANCELLED.
Example:
The latest system message is retranslated and updated in the process object defined by the MI
attribute of the PRI object:
#SET PRI3:SOS = 1
Contains a diagnostic counter value that counts the occurrences of certain events related to the PRI
objects. The counter is updated by the NET unit.
• Each time a flow stop request (XOFF) character has been received from the printer, and no flow
start request (XON) character has followed within 10 seconds. As an example this situation
occurs when the printer runs out of paper or when a user has left the printer in off-line mode.
• When DCD(Data Carrier Detect) has been low for more than 10 seconds and the OS attribute of
the printer line is 2 or 3.
An application program transmitting control sequences to the printer as character strings. Any 8-bit
character value can be used. For example, CD can be used to choose a new font, initiate form feeds,
choose a national character set or change horizontal or vertical spacing. Unlike the DA attribute
(described later), CD makes it possible to send non-printable characters to the printer. Control
sequences may be sent to the printer, for example when the base system is started up, or from the
start programs of format pictures.
Storing control sequences in the printer data structure and sending them automatically to the printer.
The information is sent when a new printer is added or the IU attribute of a printer is changed from 0
to 1. The CS attribute can be used for printing control sequences at the initialization of printers, which
is sometimes necessary.
Transmitting data to the printer without using a format picture (for example for test purposes). (NET
unit uses the DA attribute also for other purposes). By writing a character string to the DA attribute,
the application program can transmit the string to the printer. In more extensive use of the DA
attribute, the application programmer must provide for the printer allocation using the AL attribute
described earlier. To type short printouts that go into one message, the AL attribute need not be set.
Example:
In some special application cases there is need to stop a printer temporarily. The stopping is done so
that the messages meant for the printer are not stored in the spool queue of the base system (what is
the case if IU is set to 0). This is possible by setting the PE attribute to 0.
Enables an automatic color conversion for color pixel based printers (PT = 7). The attribute contains
a programmable color transformation table that translates the video monitor colors to printer colors.
An array of 256 elements that translates the SYS600 specific character codes to corresponding
printer codes. By using this attribute it is possible to utilise graphic characters from the character set
of the printer.
Example:
#SET PRI1:SCT(1..20) = 65
The printed bit pattern for each character code can be decided by the application. There is only one
pixel printer character set in each communication unit. Therefore, all printers connected to the same
NET unit use the same character set and a change in the set will appear in all printers.
Example:
Index
LCU500......................................................... 186 M
LD :Local Address (NET line)........................ 189 Mailbox (NET)................................................180
LD :Log Directory (PRI(B))............................ 143 Mail Update Identification (NET)....................181
LE Length (ANSI).......................................... 241 MAINT (File Sync Criterion).............................44
Length (ANSI)................................................241 MA Mailbox (NET)......................................... 180
Length of Time-out (ANSI).............................238 MC :Memory Configuration (ANSI)................241
LF Log Flush Timeout (PRI(B))..................... 143 MC :Modem Command (NET line)................ 217
LI :Line Number (NET).................................. 169 ME :Memory (ANSI )..................................... 245
LI :Line Number (P214)................................. 264 ME :Memory Pool Supervision Enabled (APL)64
LI :Line Number (PRI(S))...............................302 Memory (ANSI)..............................................245
LI :Line Number (SPI)....................................297 Memory area................................. 238, 239, 244
LI :Line Number (STA(S)).............................. 227 Memory Area Definitions............................... 238
LI :Link Number (NOD).................................. 114 Memory Blocks Free (SYS)............................. 44
LI :Logged In (MON)......................................103 Memory Block Size (SYS)............................... 45
LIN..................................... 29, 31, 107, 110, 114 Memory Blocks Used (SYS)............................ 45
Line........................................................158, 187 Memory Configuration (ANSI)....................... 241
Line Number :NET.........................................169 Memory Pool Sizes (SYS)............................... 45
Line Number :P214........................................264 Memory Pool Supervision Enabled (APL)....... 64
Line Number :PRI(B)..................................... 141 Memory Rung (ANSI).................................... 241
Line Number :PRI(S)..................................... 302 Message Application :NET............................ 167
Line Number :SPI.......................................... 297 Message Application :NET line......................194
Line Number :STA(S).................................... 227 Message Application :P214........................... 266
Lines per Page (PRI(B))................................ 142 Message Application :PRI(S).........................304
Link................................................................ 107 Message Application :STA(S)........................230
Link Number (NOD)....................................... 114 Message Identification :NET..........................165
Link Type :LIN................................................108 Message Identification :NET line................... 193
Link Type :NET line............................... 190, 223 Message Identification :P214........................ 266
LK :Link Type (NET line)................................190 Message Identification :PRI(S)...................... 304
LK Link Type (NET line).................................223 Message Identification :RTU......................... 229
LL Log Length (PRI(B))................................. 144 Message Identification :STA(S)..................... 229
LM :LMK Stations (NET)................................172 Message split.................................................228
LM :LON Message (LMK)..............................280 Message Split (ANSI).................................... 245
LMK....................................................... 171, 278 MF Memory Blocks Free (SYS).......................44
LMK Stations (NET).......................................172 MI :Message Identification (NET).................. 165
LN Line Number (PRI(B)).............................. 141 MI :Message Identification (NET line)............193
Load Control Policy :STA(B)..........................127 MI :Message Identification (P214)................. 266
Load Control Policy :STY.............................. 135 MI :Message Identification (PRI(S))...............304
Load Control Unit (NET)................................ 172 MI :Message Identification (RTU).................. 229
LOCAL (APL Translation Type)....................... 61 MI :Message Identification (STA(S))..............229
LOCAL (Time Reference)..............................126 MIDDLE (Topological State Mapping)..... 84, 124
LOCAL (Translation Type).............................102 Mirroring...................................... 72, 75, 95, 126
Local Address (NET line)...............................189 Mirroring Role (STA(B))................................. 128
Local application..............................................60 MM SYS Command Multiplier (SPI).............. 294
Local Port (NET)............................................179 MO :Monitor Mapping (APL)............................67
LOG (Output Destination)..............................144 MODBUS.......................................................186
Log Directory (PRI(B))................................... 143 Modem Command (NET line)........................217
Log Flush Timeout (PRI(B))...........................143 Modem Signal (NET line).............................. 206
Logged In (MON)...........................................103 MON.................................................. 29, 30, 101
Logical application number..............................66 MON_EVENT................................................ 103
Logical device number.....................................67 Monitor Alarm Signal Size (APL)..................... 86
Log Length (PRI(B))...................................... 144 Monitor Mapping (APL)....................................67
LON Message (LMK).....................................280 Monitors.........................................................101
LON Point (LMK)........................................... 281 Monitor Stop (MON)...................................... 105
LonTalk protocol............................................ 187 MONTH (Log Length).................................... 144
LonTalk protocol line......................................219 MP Memory Pool Sizes (SYS).........................45
Loop Control (SPI).........................................296 MR :Memory Rung (ANSI )............................241
LOW (Queue Priority)...................................... 78 MR :Mirroring Role (STA(B))......................... 128
Loytec............................................................ 188 MS :Memory Block Size (SYS)........................45
LP :Lines per Page (PRI(B))..........................142 MS :Message Application (NET)................... 167
LP :Load Control Policy (STA(B)).................. 127 MS :Message Application (NET line).............194
LP :Load Control Policy (STY).......................135 MS :Message Application (P214).................. 266
LP :Local Port (NET)..................................... 179 MS :Message Application (PRI(S))................304
LP :LON Point (LMK).....................................281 MS :Message Application (STA(S))............... 230
LS :Languages Supported (APL).....................81 MS :Monitor Alarm Signal Size (APL)..............86
LS :Last Error Status (ANSI)......................... 237 MS :Monitor Stop (MON)............................... 105
LT :Blocking Tag (APL).................................... 87 MU :Mail Update Identification (NET)............ 181
LT :Last Transaction (NOD)........................... 117 MU :Memory Blocks Used (SYS).................... 45
LT :Last Transaction Number (NET)..............180
LT :Link Type (LIN)........................................ 108
Receiver Data Bit Count (NET line)...............198 RTS Keepup Delay (NET line).......................200
Reconnecting Timeout (SPA)........................ 262 RTS Keep Up Padding Characters (NET line)....
Recovery....................................................... 233 203
Redundancy :NET line...................................198 RTU....................................................... 170, 246
Redundancy Role (STA(B))........................... 131 RTU (Station Type)........................................124
Redundant Line Station (SPI)........................297 RTU Configuration Attributes.........................248
REGARD_AS_2 (Post-processing Policy for Obj RU :Redundant Line Station (SPI).................297
ect Status 1)....83 RU :Report Cache Used (SYS)....................... 46
Registration Time (NOD)............................... 117 RUNNING (Communication State)................ 122
Remote Calls Enabled (NET line)..................218 Running Mode :REX......................................277
Repeat Time Delay (NET line).......................203 Running Mode :SPI....................................... 285
Reply Polling (NET line)................................ 214 Running Objects (APL)....................................79
Reply Time-out :ANSI....................................234 RW Radio Connection Wait Time (NET line).218
Reply Timeout :LMK...................................... 280 RX REX Stations (NET).................................173
Reply Time-out :P214....................................265 RY RTS Keepup Delay (NET line).................200
Reply Timeout :RTU...................................... 250 S
Reply Time-out :SPA..................................... 256
Report Cache Size (SYS)................................46 S.P.I.D.E.R. RTU (NET).................................173
Report Cache Used (SYS).............................. 46 S.P.I.D.E.R. RTUs......................................... 246
Report Task Stop (APL)...................................88 S.P.I.D.E.R. SCADA Master Stations (NET)..173
Representation Libraries :APL.........................65 SA :Shadowing Partner Web Address (APL).. 69
Representation Libraries :SYS........................ 47 SA :Station Address (ANSI)...........................232
REPRINT (Printer Control)............................ 145 SA :Station Address (NET)............................162
Request to Send............................................199 SA :Station Address (NOD)........................... 116
RESET (Printer Control)................................ 145 SA :Station Address (RTU)............................247
Retry Limit (NET line).................................... 204 SA :Station Address (SPA)............................ 254
REVISION_COMPATIBILITY.......................... 88 SA :Station Address (SPI)............................. 283
Revision Compatibility (APL)........................... 88 SA :Station Address (SYS)..............................36
Revision Date (SYS)........................................39 SA :Station Adrress (P214)........................... 264
Revision of the Product (SYS).........................39 SB Stop Bits (NET line)................................. 198
Revision State (SYS).......................................40 SC: Session Nack Timeout (REX).................271
REX............................................................... 171 SC :Shadowing Connection Time (APL)......... 70
REX (Station Type)........................................124 SC :Start Command (LIN)............................. 108
REX Stations................................................. 270 SC :Status Check Request (RTU)................. 250
REX Stations (NET).......................................173 SCIL...........................................................26, 28
RI Receive Interrupt Enable Delay (NET line)..... Screen Size (MON)....................................... 103
203 SC Secure Communication (NOD)................ 118
RK RTS Keep Up Padding Characters (NET line SD :Diagnostic Counters (APL)....................... 70
)....203 SD :SPACOM Driver Name (SYS).................. 55
RL :Representation Libraries (APL).................65 SD :System Device Name (MON)................. 103
RL :Representation Libraries (SYS)................ 47 SD :System Device Name (NET line)............188
RL :Retry Limit (NET line)..............................204 SD :System Device Name (PRI(B))...............139
RL :Router LMK (SPA).................................. 255 SE :System Messages Enabled (NET)..........167
RM :Running Mode (REX).............................277 SE: System Messages Enabled (STA(S))..... 231
RM :Running Mode (SPI).............................. 285 SECONDARY (Redundancy Role)................131
RN Routing Node (NOD)............................... 115 Secondary station..........................................129
RO Running Objects (APL)............................. 79 Secondary Station (STA(B)).......................... 131
Router LMK (SPA)......................................... 255 Secure Communication (NOD)...................... 118
Routing............................................................ 41 Semigraphic (MON).......................................103
Routing Node (NOD)..................................... 115 Session Idle Timeout (REX).......................... 271
RP :Reply Polling (NET line)......................... 214 Session in Sequence Response Delay (REX).....
RP: Revision of the Product (SYS)..................39 272
RP570/571 master protocol...........................186 Session Keepalive Timeout (REX)................ 272
RP570 slave protocol.................................... 186 Session Nack Timeout (REX)........................271
RQ Receive Quota (REX)..............................273 Session Retransmit Timeout (REX)...............272
RR Redundancy Role (STA(B)).....................131 Session Setup Handling (REX)..................... 271
RS :Proxy Station (STA(B))........................... 131 SET (File Sync Criterion).................................44
RS :Report Task Stop (APL)............................88 Set Time (P214)............................................ 269
RS :Revision State (SYS)................................40 SETTING_LA_AND_AG_DOES_NOT_ALARM
RT :Registration Time (NOD).........................117 ....89
RT :Reply Time-out (ANSI)............................234 SF :Shadowing Flush Time (APL)................... 70
RT :Reply Timeout (LMK).............................. 280 SF :Sync Format (NET line).......................... 224
RT :Reply Time-out (P214)............................265 SG :Modem Signal (NET line)....................... 206
RT :Reply Timeout (REX).............................. 277 SG Semigraphic (MON).................................103
RT :Reply Timeout (RTU).............................. 250 SH :Session Setup Handling (REX).............. 271
RT :Reply Time-out (SPA)............................. 256 SH :Shadowing (SYS)..................................... 49
RT :S.P.I.D.E.R. RTU (NET).......................... 173 Shadow Dump Slowdown (APL)..................... 71
RT :SYS Reply Timeout (SPI)....................... 294 Shadowing (SYS)............................................ 49
RTS............................................................... 199 Shadowing Connection Time (APL)................ 70
Shadowing Diagnostic Interval (APL).............. 71
W
WA :Web Address (SYS).................................37
WAITING (Printer State)................................145
WARM_RC (Shadowing Phase)......................72
WARM_SD (Shadowing Phase)......................72
WARM_SEND (Shadowing State)...................73
WARM (Application State)...............................60
Watchdog........................................................ 52
Watchdog application...................................... 74
WC Window Color (MON)............................. 105
Web Address :SYS..........................................37
WEEK DAY (Log Length).............................. 144
WHEN_SET_TO_2 (Post-processing Policy for
Object Status 2)....84
WHEN_SET (Post-processing Policy for Object
Status 2)....84
Window Color (MON).................................... 105
Windows Single Sign-on enabled (APL)..........85
WINTER (Time Season)..................................43
Write-only................................................ 33, 160
WS :Windows Single Sign-on enabled (APL)..85
X
X3.28 Station address (NET).........................163
XA Extended Address Table (NET line).........220
Y
YEAR (Log Length)....................................... 144