Microscada System Configuration: 1Mrs751248-Men

1MRS751248-MEN MicroSCADA
Issue date: 29.02.00 System Configuration

Program revision: 8.4.3
Documentation version: A
Copyright © 2000 ABB Substation Automation Oy.

All rights reserved.
Notice 1
The information in this document is subject to change without notice and should not
be construed as a commitment by ABB. ABB assumes no responsibility for any error
that may occur in this document.
Notice 2
This document version complies with the program revision 8.4.3.
Notice 3
Additional information such as Release Notes and Last Minute Remarks can be found
on the program distribution media.
Trademarks
Microsoft is a trademark of Microsoft Corporation.
Windows NT is a trademark of Microsoft Corporation.
LONWORKS is a registered trademark of Echelon Corporation.
Other brand or product names are trademarks or registered trademarks of their respective holders.
All Microsoft products referenced in this document are either trademarks or registered trademarks of Microsoft Corpo-
ration.
MicroSCADA System Configuration 1MRS751248-MEN
Configuration Manual
Related MicroSCADA Technology Manuals

The following SYS 500 manuals are published with this software release:
Installation 1MRS751254-MEN
Picture Editing 1MRS751255-MEN
Visual SCIL User Interface Design 1MRS751256-MEN
Visual SCIL Objects 1MRS751257-MEN
System Management 1MRS751258-MUM
The following MicroSCADA technology manuals are published with this software
release:
Connecting LONWORKS Devices to MicroSCADA 1MRS751249-MEN
System Configuration 1MRS751248-MEN
System Objects 1MRS751252-MEN
Application Objects 1MRS751253-MEN
Programming Language SCIL 1MRS751250-MEN
Status Codes 1MRS751251-MEN
ABB Automation
1MRS751248-MEN System Configuration MicroSCADA
Contents
Page
1 Introduction .................................................................................... 1
1.1 System Description..............................................................................1
1.2 Configuration Principles .......................................................................6
2 Base System Object Definitions ................................................... 9
3 Communication System Object Definitions .............................. 13

3.1 Overview............................................................................................13
3.2 Defining Communication System Objects Off-line..............................14
3.3 Defining Communication System Objects On-line..............................15
4 Configuration Data Files.............................................................. 21

4.1 General Rules....................................................................................21
4.2 Frontend Configuration Parameters...................................................22
5 Base Systems............................................................................... 29
5.1 Configuring a Base System ...............................................................29
5.2 Communicating Applications..............................................................33
6 MicroSCADA Networks................................................................ 39
6.1 Global Definitions...............................................................................39
6.2 Object Numbering..............................................................................41
7 Local Area Networks (LANs)....................................................... 43
8 Process Communication System ............................................... 45

8.1 Configuring a Communication Unit (NET) ..........................................45
8.2 Internal NETs (DCP-NETs) ................................................................49
8.3 Configuring Base Systems with PC-NET ...........................................51
8.4 Communication Frontends.................................................................53
8.5 Networks of Interconnected NETs .....................................................58
ABB Automation
9 Operator Workstations ................................................................ 65
10 Peripherals.................................................................................... 67
10.1 Printers.............................................................................................. 67
10.2 Other Peripherals .............................................................................. 73
11 Configuring Stations.................................................................... 77
11.1 General Principles ............................................................................. 77
11.2 Stations Using ANSI X3.28 Protocol.................................................. 79
11.2.1 MicroSCADA Configuration......................................................... 79
11.2.2 SRIO Configuration..................................................................... 86
11.3 S.P.I.D.E.R. and Collector RTUs ....................................................... 89
11.3.1 MicroSCADA Configuration......................................................... 89
11.3.2 RTU Configuration ...................................................................... 93
11.4 Stations in the LONWORKS Network................................................ 93
12 Redundancy Configurations ....................................................... 95

12.1 Hot Stand-by Base Systems.............................................................. 95
12.1.1 Base System Configuration Procedure ....................................... 97
12.1.2 Editing SYS_BASCON.HSB........................................................ 98
12.1.3 NET Configuration .................................................................... 101
12.1.4 Installing Watchdog Application ................................................ 101
12.1.5 Starting the Shadowing ............................................................. 102
12.1.6 Editing the Command Procedures ............................................ 103
12.1.7 An Example Hot Stand-By Configuration .................................. 105
12.2 Redundant Frontends...................................................................... 109
12.3 Communication Loops..................................................................... 116
13 Miscellaneous............................................................................. 121
13.1 System Message Handling.............................................................. 121
13.2 Auto-dialing ..................................................................................... 124
13.3 Time Synchronisation ...................................................................... 126
13.4 Storing the Event History................................................................. 128
13.4.1 History Database ...................................................................... 128
13.4.2 Event Log.................................................................................. 129
14 System Configuration Tool ....................................................... 131

ABB Automation
14.1 Main Functions ................................................................................131

14.2 Starting the Tool ..............................................................................132
14.3 How to Handle the Object and Attribute Trees .................................133
14.4 How to Save a Configuration from a Former Release ......................133
14.5 How to Create a New Configuration.................................................133
14.5.1 Methods for Adding New Objects ..............................................133
14.6 Default Configuration .......................................................................135
14.7 Online Configuration ........................................................................136
14.8 How to Change the Attribute Values ................................................138
14.8.1 Station Address .........................................................................139
14.9 How to Take Configuration in Use or Out of Use .............................139
14.10 How to Delete an Object ................................................................140
14.11 Cut, Copy and Paste Functions; Reallocating Stations ..................141
14.12 Preview Function ...........................................................................142
14.13 User-Defined Programs .................................................................143
14.14 General Object Handling Command ..............................................144
14.15 System Self Supervision ................................................................145
14.16 Signal Engineering .........................................................................148
14.16.1 Signal Engineering on Station Level .......................................149
15 NETCONF Tool ........................................................................... 153

15.1 Requirements ..................................................................................153
15.2 Installation .......................................................................................153
15.3 NETCONF Tool Basics ....................................................................154
15.4 Using NETCONF Tool .....................................................................156
16 NET Tool ..................................................................................... 163

16.1 NET Tool Basics ..............................................................................163
16.2 Using the NET PRECONFIGURATION Tool....................................165
17 REx Configuration Tool ............................................................. 171

17.1 Using REx Configuration Tool..........................................................171
17.2 Defining the Device..........................................................................173
18 LMK Configuration Tool ............................................................ 177

18.1 Using LMK Configuration Tool .........................................................177
ABB Automation
18.1.1 Defining the Device................................................................... 180
Index
Customer Feedback
ABB Automation
Configuration Manual 1 Introduction
1 Introduction
This manual gives you information on the various configuration settings that you have
to make in order to take your MicroSCADA system in use. It also describes how to
use the configuration tools, which are available in current release.
About this Chapter
This chapter introduces the MicroSCADA system concepts and the system configura-
tion principles:
1.1 The first section provides a summary of the MicroSCADA system with empha-
sise on the concepts which are essential when configuring MicroSCADA: the
base systems, the process data communication system, the connection of de-
vices to a distributed network, etc.
1.2 The MicroSCADA configuration principles: the MicroSCADA configuration

software modules and the configuration software management.
1.1 System Description
A MicroSCADA system is composed of one or more base systems, a process commu-

nication system, workstations and peripherals. In addition, it may utilise local area
networks (LANs). See Figure 1.
Base Systems
The MicroSCADA base systems are control centres that contain the supervisory con-
trol and monitoring functions of MicroSCADA. The tasks of a base system are to
collect all process-related data from the stations into the process database, distribute
the information and to send control commands via the NET communication units.
Each base system is composed of a base system computer including base system soft-
ware. The base system computer is a standard PC running the Windows NT™i oper-
ating system. The MicroSCADA base system software comprises the MicroSCADA
kernel, a number of facility programs, engineering and system handling tools, con-
figuration software and application software.
The MicroSCADA kernel, as well as most of the engineering and system handling
tools, is the same in all base systems independently of the application area and the
extent of use.
The configuration software is specified for the base system in question and adapted to
the device configuration of the entire MicroSCADA system.
i Windows NT is a trademark of Microsoft Corporation
ABB Automation 1
1 Introduction Configuration Manual
A base system may contain one or more applications. An application includes appli-
cation software and databases. The application software specifies the functions of the
MicroSCADA base system as a supervisory control system. The application software
is adapted for a certain process and for the user’s needs regarding the level of infor-
mation, user interface, control operations, and so on. A base system can run several
applications in parallel.
Process Communication System
The process communication system connects the application software in the base
systems with the process stations, which gather the process data, and performs the
control commands. In addition, it may interconnect several base systems as well as
base systems and printers.
The process communication is handled by a number of parallel or serially intercon-

nected communication units, also called NETs. A NET is a communication program
running on a special communication board (board based NETs or DCP NETs) or di-
rectly on the CPU of a PC (PC based NETs or PC NETs). The NETs may be situated
within the base system computers and within PCs specially assigned for process
communication. Such PCs are called frontends or communication frontends.
LANs
LANs may be used for connecting base systems with other base systems, base systems
with frontends, and base systems with workstations.
2 ABB Automation
Figure 1. The main system components of MicroSCADA
Workstations
A MicroSCADA workstation is a PC that runs the MicroSCADA HMI (Human Ma-

chine Interface). To be able to run the HMI the workstation must run an X Server pro-
gram.
ABB Automation 3
The workstations are connected via LAN or via remote connections, which use the
operating system feature RAS.
Peripherals
The printers are connected to the base system computers, to a LAN via printer servers,
or to the process communication system.
External alarm units can be connected to the base systems.
Radio clocks for external clock synchronisation may be connected to the base sys-
tems, to NETs, and to the frontends.
MicroSCADA Networks
Figure 2 shows an example of a MicroSCADA system. The system can be regarded as

a network where the communication units (NETs) and the base systems function as
routing nodes, which can forward messages and data from one node or device to an-
other. All base systems connected by the same process communication system or by a
LAN belong to the same network.
There may be several communication units in a series between two communicating

devices. However, for performance reasons, it is not recommended to have more than
three communication units between communicating devices. In a large network, the
routes between nodes can be doubled to obtain redundancy.
4 ABB Automation
Figure 2. An example of a MicroSCADA network. Most configuration possibilities

are represented in this network, which will be used as an example
throughout this manual.
Interoperability
An essential feature of MicroSCADA is the interoperability between separate base

systems. The interoperability means that all connected applications can communicate,
whether they are situated in the same or in separate base systems. In Figure 2, for in-
ABB Automation 5
stance, all applications can intercommunicate. Communication between the base sys-
tems 2 and 3 requires some special arrangements in base system 1.
The connected devices - printers, workstations and process units - can be shared by
several base systems in the network. The workstations connected to a LAN, for exam-
ple, can be used by all base systems connected to the same LAN. Likewise, the sta-
tions and printers connected to NETs can be used by all base systems connected to the
same network of interconnected NETs. A frontend can recognise up to four base sys-
tems.
In the network in Figure 2, for example, all applications in base systems 1 and 3 can
utilise the workstations on the LAN. The PCs running X software can be connected to
several base systems and applications simultaneously. Application 5 can use both
printers 1 and 2. A redirection of printout can be done during operation.
1.2 Configuration Principles
For a MicroSCADA system to operate properly, it must be configured for the special
environment in which it is operating. MicroSCADA contains configuration software
in the form of objects and data files. The configuration software defines:
• Nodes.
• Applications.
• Device connections.
• Communication properties.
• Memory capacities, destination addresses, etc.
The System Configuration Tool manages the configuration of the base system and the
PC-NET. In the current version, the following base system and system objects can be
created and configured:
• Integrated link to the PC-NET.
• PC-NET.
• LonTalk (LON), IEC, RP570, RP571, LCU500, DNP 3.0, Modbus and SPA pro-
tocol Lines.
• REX, LMK, IEC, SPI, LCU500, DNP, PLC, and SPA Stations.
• LON Clock Master and LON Star Coupler.
Configuration Software
The MicroSCADA configuration software is composed of objects and data that reside
in the base systems, communication units (NETs) and communication frontends, see
Figure 3:
• Each base system contains a set of base system objects that specify the base sys-
tem itself and its environment. During operation, the base system objects reside in
the primary memory of the base system computer. The base system objects are
6 ABB Automation
created with SCIL commands when the MicroSCADA base system is started.
They can be added and modified during operation.
• Each communication unit contains a set of system objects that specify the unit it-
self and its environment. During operation, the system objects reside in the mem-
ory of the communication boards (DCP-NETs) or PC (PC-NETs). The NET pro-
grams contain a preconfiguration, which gives the system objects default values.
The system objects can be added and modified during system operation.
• The communication frontends contain data files, which specify the frontend con-
figuration and the parameters for the communication with the base system.
The process units (stations) contain their own configuration definitions that must be
regarded in the MicroSCADA configuration. For some station types, the configuration
can be built in MicroSCADA and downloaded to the stations.
The MicroSCADA configuration software handling is detailed in part II of this man-

ual.
Building System Configuration
As a rule, when a device is added to the MicroSCADA system, several configuration

modules are affected. For example, when a process unit (station) is connected to a
NET, additions and modifications are required in:
• The base system which will use it: base system objects.
• The communication unit to which it is directly connected: system objects.
Concerning PC-NET and LONWORKSii network, the configuration work is done with
the System Configuration Tool, which automatically gives default values, which can
be changed if needed.
The MicroSCADA system configuration can be changed any time, though in some
cases a shut-down and restart is required for the changes to become valid.
ii LONWORKS is a registered trademark of Echelon Corporation.
ABB Automation 7
Figure 3. The configuration software modules in MicroSCADA
The communication server COM 500 is described in the COM 500 Engineering man-
ual.
8 ABB Automation
Configuration Manual 2 Base System Object Definitions
2 Base System Object Definitions
This chapter describes:

• The base system objects in general.
• The principles for defining and modifying base system objects.
• The definition of base system objects in the SYS_BASCON.COM file.
• How to handle the base system objects on-line.
The base system objects and their attributes are detailed in the System Objects man-
ual.
Base System Objects
Each base system has a set of base system objects which specify the base system and
its environment, the hardware and software of the base system, the physical and logi-
cal connections of the base system and its applications. A base system is completely
configured by the following base system objects:
• A SYS object for the base system itself.
• An APL object for each application residing in the base system ("local applica-
tions") and an APL object for each communicating application residing in con-
nected base systems ("external applications").
• A MON object for each MicroSCADA monitor that will be opened to supervise
an application in the base system in question.
• A LIN object for each connection link. A LIN object is not needed for peripher-
als, nor for workstations.
• A NOD object for each directly or indirectly connected base system and NET unit
(optionally also for each communication frontend).
• A PRI object for each printer, including both real printers and pseudo-printers for
sending the printout to files, which will be used by the base system.
• A STA object for each connected station (connected through one or more NETs)
(recommended in all cases, though not always required).
The base system object definitions and attributes, which are required for various in-
stallations, are detailed later in this manual.
Principles for Defining Base System Objects
Generally, the base system objects are defined in the file SYS_BASCON.COM. The
file is read and the commands in it are executed each time the base system is started.
With a few limitations, the base system objects can also be created and modified dur-
ing MicroSCADA operation with SCIL and tool pictures.
ABB Automation 9
2 Base System Object Definitions Configuration Manual
Base system objects are created using the SCIL command #CREATE. The principles
for creating a base system object with SCIL is as follows:
#CREATE object = LIST(attribute = value, attribute = value,...)
‘object’ The object to be created specified using the base system object notation
without attributes and index numbers
‘attribute’ Attribute name
‘value’ The value assigned to the attribute
Example:
Creating a SYS object:

#CREATE SYS:B = LIST(-
SA = 209,- ;STATION ADDRESS OF BASE SYSTEM
ND = 9,- ;NODE NUMBER OF BASE SYSTEM
DN = 1,- ;DEFAULT NET NODE NUMBER
DS = "RTU",- ;STA TYPES: E.G. STA,RTU,SPA,REX
FS = "NEVER") ;FILE SYNCH CRITERIA
After a base system object has been created, its attributes (provided that writing is en-
abled) can be changed with the #SET command. The objects cannot be modified with
the #MODIFY command nor can they be deleted with the #DELETE command.
To learn more about the SCIL commands, refer to the Programming Language SCIL
manual, chapter 7. For more information on the base system object notation, refer to
the System Objects manual, chapter 2.
! Please, notice that SCIL programming is not needed when system objects are created
with the System Configuration tool.
SYS_BASCON.COM
The SYS_BASCON.COM file is an ASCII file that is located in the

\sc\sys\active\sys_ directory. It can be edited with an ordinary text editor, e.g., the
Notepad editor or with the MicroSCADA program editor, accessed from the Tool
Manager. The SYS_BASCON.COM file is most conveniently accessed for editing
from the MicroSCADA Administrator, which is accessed from the MicroSCADA
Control Panel.
If the MicroSCADA base system revision 8.4.2 or subsequent is used together with
applications that were 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. This is done by adding “NO_ALIAS_CHECKING” to the RC attribute of the ap-
plication in SYS_BASCON.COM.
Sys_Bascon.com:
#CREATE APL:V = LIST(-

...
10 ABB Automation
Configuration Manual 2 Base System Object Definitions
RC =
VECTOR(“FILE_FUNCTIONS_CREATE_DIRECTORIES” ,”NO_ALIAS_CHECKING”) ,-
...
The SYS_BASCON.COM file is composed of SCIL commands, which create base

system objects and assign them appropriate attributes.
Example:
A portion of the standard SYS_BASCON.COM file (version 8.4.2):
;File: Sys_bascon.com
;Desription: Standard Base system configuration file
; Version 8.4.2
;----------------------------------------------------
;Base System Object

@l_Standard_Paths = do(read_text("/STool/Def/Path_Def.txt"))
#CREATE SYS:B = List(-

SA = 209,- ;Station address of base system
ND = 9,- ;Node number of base system
DN = 1,- ;Default NET node number
DS = "STA",- ;Default STA type: E.G. STA,RTU,SPA,REX
DE = 1,- ;DDE server enabled
PC = 0,- ;Color allocation policy
-
- ;MS-STOOL Settings
PH = %l_Standard_Paths,-
SV = (0,- ;System Variables
list(t_System_Configuration_File = "sys_/SysConf.ini",- ;System Configura-
tion information
b_In_Use = TRUE,-
t_Version = "8.4.2")),-
- ;Operating System events
OE = 0,- ;1=Enabled, 0=Disabled
OT = (Bit_Mask(0,1,2,3,4),- ;Application events (Bit 0=ERROR, 1=WARNING,
2=INFORMATION, 3=AUDIT_SUCCESS, 4=AUDIT_FAILURE)
Bit_Mask(0,1,2,3,4),- ;System events (Bit 0=ERROR, 1=WARNING,
Bit_Mask(0,1,2,3,4)),- ;Security events (Bit 0=ERROR, 1=WARNING,
-
FS = "NEVER") ;File sync. criteria:
NEVER,MAINT,SET,CHECKPOINT,ALWAYS
;----------------------------------------------------
;Communication Links
;NOTE! Use the system configuration tool to create a link for the PC-NET!
#CREATE LIN:V = LIST(- ;Link to DCP-NET (requires DCP driver)

LT = "RAM",- ;Link type
SD = "RM00",- ;DCP card (first:RM00, second RM01)
RE = "BCC",- ;Redundancy
TI = 2,- ;Timeout length (s)
NA = 3,- ;NAK limit
EN = 3) ;ENQ limit
;#CREATE LIN1:B = %LIN
#CREATE LIN:V = LIST(- ;Link to other SYS or LAN frontend (re-

quires TCP/IP)
LT = "LAN") ;Link type
;#CREATE LIN2:B = %LIN
;----------------------------------------------------
;Node objects (NET's and SYS's)
;NOTE! Use the system configuration tool to create nodes for the PC-NET!
#CREATE NOD:V = LIST(- ;Node for DCP-NET
LI = 1,- ;Link number
SA = 201) ;Station address: 0..255
;#CREATE NOD1:B = %NOD
#CREATE NOD:V = LIST(- ;Node for LAN frontend or SYS
LI = 2,-
SA = 202)
;#CREATE NOD2:B = %NOD
ABB Automation 11
2 Base System Object Definitions Configuration Manual
The creation of a base system object in SYS_BASCON.COM comprises two steps;

first a temporary variable object is created and then the actual system object is cre-
ated, based on the variable object. This is not valid, when the System Configuration
tool is being used, because the SYS_BASCON.COM file is automaticallay updated by
the tool.
The SCIL language uses the semicolon character to mark the beginning of a comment.
The comment ends at the end of the commented line. If the line defining the base
system object is commented the object is not created when the system is started. By
removing the semicolon from the beginning of the line the base system object is cre-
ated. This mechanism allows the person who configures the system easily to take into
use or to prevent the creation of a system object.
On-line Modifications
Most base system object attributes can be modified on-line with the Base System tool
and with SCIL. These changes are not persistent and will be lost when the system is
shut down. If the changes are to be persistent they should be included in the
SYS_BASCON.COM file.
! The System Configuration tool writes directly to the SYS_BASCON.COM file.

Therefore the changes that are made with this tool are persistent.
12 ABB Automation
Configuration Manual 3 Communication System Object
Definitions
3 Communication System Object Definitions
This chapter describes the definition of the communication system objects. It contains
the following three sections:
3.1 An overview of the communication system objects and the alternatives for
defining communication system objects.
3.2 Configuring NETs off-line: the preconfiguration of the DCP-NETs and the
initialization file of the PC-NETs.
3.3 Configuring NETs on-line: the principles for defining and modifying
communication system objects with SCIL, defining communication system
objects in the SYS_NETCON.COM configuration file and configuring NET
start-up.
The communication system objects and their attributes are detailed in the System
Objects manual.
3.1 Overview
Communication System Objects
Each communication unit contains a set of system objects which specify the unit it-
self, the line properties and connected devices, etc. A NET unit is completely config-
ured by the following system objects:
• A NET object for the definition of the NET unit itself.
• A NET object for each directly or indirectly connected base system and NET unit.
• NET line definitions such as line protocol, data transmission rates, etc.
• An APL object for each application in the connected base systems.
• A PRI object for each directly connected printer.
• A STA object for each directly and indirectly connected station.
Defining Communication System Objects
The communication system objects can be defined both off-line (the NET is out of
operation) and on-line (NET in operation).
The off-line configuration comprises:

• The DCP-NET’s preconfiguration written off-line by a configuration tool, see
later.
• The PC-NET configuration with the System Configuration Tool and automatic
updating of the initialisation file.
• When started, the PC-NETs read an initialization file which contain the most fun-
damental definitions.
ABB Automation 13
3 Communication System Object Configuration Manual
Definitions
The on-line configuration can be done with SCIL or tool pictures as follows:
• The SYS_NETCON.COM executed at each base system start-up may contain
SCIL statements for defining communication system objects.
• The communication system objects can be changed with SCIL programs started
automatically or manually.
• The objects can also be changed with tool pictures.
The on-line configuration can be read into the System Configuration Tool by selecting
Configuration - Open On-line. Reading the on-line configuration sets the tool into On-
line mode.
3.2 Defining Communication System Objects Off-line
Preconfiguration with the System Configuration Tool
The System Configuration Tool configures the LIN and NOD base system objects
needed for the PC-NET. All configurable attributes of the LIN:B object and NOD:B
object can be changed from the tool. The initialisation file pc_net.cf1 is updated
automatically.
Preconfiguration in DCP-NETs
The DCP-NET communication program which runs in the board based communica-
tion units contains what is called a "preconfiguration". The preconfiguration is a set-
up of system objects and attributes which functions as a default configuration. Each
time the NET unit is loaded and started the preconfiguration becomes valid.
The preconfiguration can be viewed, edited and documented off-line with a program
called NETCONF which runs in the DOS environment or during operation from the
base system by means of a preconfiguration tool picture.
Changes made in the preconfiguration come into force when the communication pro-
gram is next time loaded into the communication unit.
The preconfiguration has the following limitations:

• A maximum of 20 stations per unit can be preconfigured.
• Some attributes cannot be preconfigured.
The required configuration blocks are described in detail in part III of this manual and
the attributes are found in the System Objects manual.
PC-NET Configuration with the System Configuration Tool
When a PC-NET configuration is created with the System Configuration Tool, the
tool produces two data files: sysconf.ini and signals.ini. When the system is started, it
reads the mentioned files and creates a pc_net.cf1 file automatically.
14 ABB Automation
Definitions
To create system objects the System Configuration Tool creates automatically the file
sys_base.scl, which is executed at system start-up.
After the PC-NET has started the system executes the file sys_net.scl to configure the
PC-NET. The file is automatically created by the System Configuration Tool.
Initialization File of the PC-NET
When the PC-NET program is started, it reads the initial configuration file
PC_NET.CF1, which is a text file located in the SYS_ directory. It defines the basic
communication nodes and addresses to enable the communication to an application
that will download the total configuration. The initial configuration file is composed
of a number of lines, each of which specify an attribute, see below. The attributes are
referred to with the notation:
object.attribute
The possible objects are:
local_node The PC-NET itself

ext_node An external node (the base system where the NET is situated)
ext_apl An application in the base system where the NET is situated
In case the PC_NET.CF1 file is missing when the PC-NET is started, a default con-
figuration becomes valid.
The following PC_NET.CF1 file is included in the MicroSCADA delivery:
local_node.sa=203 ; the station address of the PC NET

local_node.nn=3 ; the node number of the PC NET
ext_node(1).sa=209 ; the station address of the base system
ext_node(1).nn=9 ; the node number of the base system
ext_apl(1).nn=9 ; the node number of the base system
ext_apl(1).an=1 ; an application in the base system
All line and station configuration of the PC NET, as well as the definition of other
nodes and applications can be done with the System Configuration Tool (with User-
Defined Programs, if not supported by the tool yet). The usage of the tool is de-
scribed in the manual Connecting LONWORKS Devices to MicroSCADA.
3.3 Defining Communication System Objects On-line
The on-line changes take effect immediately. However, if the NET unit is stopped and
restarted, the on-line changes are lost and the preconfiguration is restored. On-line
changes which need to be permanent, and are not made in the preconfiguration,
should therefore be included in a command procedure which is executed each time the
NET unit has been restarted.
ABB Automation 15
Definitions
Principles
The procedure for creating communication system objects is as follows:

• Define the NET line to be used by assigning it the desired protocol (the PO attrib-
ute, see chapter 11).
• Give the line its communication properties by means of the line attributes (chapter
11).
• Create the object by giving it an object number and assigning it the line number.
• Set the attributes of the created object.
• Take the line and the device into use.
In SCIL, communication system objects are created and deleted using NET attributes,
see the System Objects manual, section 12.3.1 - 12.3.5. When adding a device, the
NET line must first be defined. NET lines are defined by the NET line attribute PO.
See examples 4 and 5 in section Modifying Communication System Objects with
SCIL.
Most attributes can be both read and written on-line with SCIL commands. The at-
tributes are accessed with the object notation according to the format:
OBJnn:Sati
’nn’ Object number (device number)
’at’ Attribute name
’i’ The possible index
The object notation is detailed in the manual System Objects.
The attributes are written with the #SET command according to the format:
#SET OBJnn:SATi = value

See Example 1 in section Modifying Communication System Objects with SCIL.
The line attributes can be changed with the SCIL command #SET:
#SET NETnn:Sati = value

’i’ Line number
When a new line or device is created on-line, its attributes get the default values given
in the System Objects manual.
Modifying Communication System Objects with SCIL
By changing attributes, it is possible to define new devices (create new system ob-
jects), switch over a device from one line to another, and even redefine a line for an-
other protocol.
16 ABB Automation
Definitions
Changing the line protocol on-line requires that the line is first removed then added
again with the new protocol. A line is removed from the configuration by setting its
PO attribute to 0. First the line must be taken out of use as described below. In addi-
tion, all devices on the concerned line must be removed by setting the attributes which
create them to "D". A line is removed from the configuration by setting its PO attrib-
ute to 0. A new line is created by setting the PO attribute of the line to the line proto-
col value (System objects, section 13.2). See examples 3 and 4 below.
Changing the line attributes on-line generally requires that the actual line is taken out
of use, i.e. setting IU = 0, while the change is performed. After the modification, the
line is restarted by setting the IU attribute to 1. See Example 2 below.
Example 1
Changing the printer type of PRI2:
#SET PRI2:SIU = 0 ;The printer is taken out of use.
#SET PRI2:SPT = 7 ;The printer is changed to a pixel-based colorprinter.
#SET PRI2:SIU = 1 ;The printer is taken into use.
Example 2
Changing the transmission rate on line 1 of NET1:
#SET NET:SIU1 = 0 ;The line is taken out of use.
#SET NET:SBR1 = 1200 ;The baud rate is changed.
#SET NET:SIU1 = 1 ;The line is taken into use.
Example 3
Removing line 2 of NET1, when two stations (STA1 and STA2) are connected to the
line:
#SET STA1:SIU = 0
#SET SAT2:SIU = 0 ;The station is taken out of use.
#SET NET1:SIU2 = 0 ;The line is taken out of use.
#SET NET1:SST1 = “D”
#SET NET1:SST2 = “D” ;The stations are deleted.
#SET NET1:SPO2 = 0 ;The lines are deleted.
Example 4
Adding a printer on line 2 of NET1:
#SET NET1:SPO2 = 4 ;Line number 2 is created as a printer line.
#SET NET1:SIU2 = 1 ;The line is taken into use.
#SET NET1:SPR4 = 2 ;Printer number 4 is connected to line 2.
Example 5
Adding three stations of type S.P.I.D.E.R. (STA1, STA2 and STA3) on line 4 of
NET1:
#LOOP WITH NR = 1 .. 3
#SET NET1:SRT’NR’ = 4 ;Station number ‘NR’ is connected to line 4.
#SET STA’NR’:SSA = %NR ;The station address of the station.
#SET STA’NR’:SAL = 1
#SET STA’NR’:SIU = 1
#LOOP_END
SYS_NETCON.COM
The base system recognizes and executes a file called SYS_NETCON.COM, which is
a text file containing SCIL commands. The file is executed each time the base system
is started. Normally, the file contains only commands for starting possible internal
frontends by means of the SCIL function LOAD_DCP (see the manual The Program-
ming Language SCIL, section 8.10). However, it can also contain statements for re-
ABB Automation 17
Definitions
configuration of NET objects provided that there is a time delay of at least 5 seconds
(achieved with the #PAUSE command) between the start-up of an internal frontend
and the subsequent configuration statements.
Only NET objects can be configured in SYS_NETCON.COM. Configuring STA and

PRI system objects is not possible (though the objects can be created).
The SYS_NETCON.COM file can be edited with a text editor in Windows NT envi-
ronment e.g., Notepad or with the MicroSCADA SCIL Program Editor (see Pro-
gramming Language SCIL, chapter 12). The SYS_NETCON.COM file must be stored
in ASCII format.
NET Start-up Configuration with SCIL
A command procedure for on-line reconfiguration of NET could be started as follows:

• When a NET unit is restarted, it sends the system message 10001 to all defined
applications (by default to process object address 6000 + NET no.). Provided that
the application is running, the system message may be used for updating a process
object which activates an event channel, which in turn starts a command proce-
dure with reconfiguration commands. See System Message Handling in section
13.1.
• When the connection between NET and an application recovers after a break,
NET sends the system message 1000 + APL no. to the application (by default to
address 6050 + NET no.). This message can be used for conditional start of re-
configuration procedures, i.e., reconfiguration takes place if NET has been re-
started, not if the application has been out of use. This can be checked, e.g., by
reading a system object attribute configured on-line. If on-line configuration
changes are valid, NET has not been out of operation.
Reconfiguration commands could also, for example, be included in the command pro-
cedures started by the event channels APL_INIT_1 and APL_INIT_2, (APL_INIT_H
in Hot Stand-by systems, see Application Objects, section 8.3.). However, a NET unit
can be restarted even though the application is not.
NET Start-up Configuration with the System Configuration Tool
The System Configuration tool creates procedures for automatic start-up and configu-
ration of the PC-NET. The automatic starting/configuration can be switched on or
off. Manual starting/stopping of the PC-NET can be done in on-line mode.
The automatic starting and configuration of the PC-NET works in the following way:
• A command procedure SYS_INIT_1:C is connected to the event channel
APL_INIT_1:A as the first secondary object. If the list of the secondary objects
is full the last one is removed and a warning is generated (notify window, log
file).
18 ABB Automation
Definitions
• The command procedure SYS_INIT_1:C calls a text file (StartPCNET.scl) which

starts the PC-NET. The program in the text file first updates the sys_/pc_net.cf1
file and then starts the PC-NET by setting the corresponding base system link
object type to "INTEGRATED". The pc_net.cf1 file is updated in the following
way:
local_node.sa Taken from the stored configuration
local_node.nn Taken from the stored configuration
ext_node(1).sa Own base system station address (SYS:BSA)
ext_node(1).nn Own base system node number (SYS:BND)
ext_apl(1).nn Own base system node number (SYS:BND)
ext_apl(1).an Own application number (APL:BAN)
• The PC-NET sends a system message to the own application when it is started.
This message is received by a process object to which an event channel,
SYS_NET’net_number’D:A, is connected. This event channel calls a command
procedure SYS_NET’net_number’D:C. If the process object exists (e.g. created
by LIB5xx) and has an event channel connected to it, all objects connected to that
event channel are moved to the SYS_NET’net_number’D:A event channel as sec-
ondary objects. In other cases, the tool automatically creates a process object
SYS_NETD:P(’net_number’), to which the event channel
SYS_NET’net_number’D:A is connected.
• The command procedure SYS_NET’net_number’D:C checks the message coming
from the PC-NET and if this is the start message (10001), the PC-NET is config-
ured according to the information entered in the tool.
All possible error messages that occur during the start-up or configuration of the PC-
NET are shown in the notify window and logged into a log file, which can be viewed
in the tool.
ABB Automation 19
Configuration Manual 4 Configuration Data Files
4 Configuration Data Files
4.1 The general rules for the configuration data files of the communication
frontends. The data files are illustrated by an example.
4.2 The configuration parameters of the communication frontend.
4.1 General Rules
Contained Parameters
As mentioned above, the configuration parameters of the workstations are listed and
described in the workstation manuals. The parameters of the communication frontend
are described in section 4.2. below. All the listed parameters need not be included in
the configuration data files. Some parameters are mandatory only for certain configu-
rations and some represent optional features. Many configuration parameters have de-
fault values (see the parameter lists) which are valid if no other values are given for
the parameters in the configuration data file. If the default values are correct, the pa-
rameters need not be included in the data files. The values given in the data files re-
place the default values.
File Format
The parameter definition lines of the data files can be arranged in any order. Each line
in the files has the following structure, see Figure 4:
• The first six character positions of a line are reserved for the parameter name.
• The seventh position contains a blank space.
• The parameter value is written starting from position 8.
• After the parameter a comment may follow, indicated with a starting semicolon
(;).
C haract
er
positi
ons:
S pace
Figure 4. The format of a line in the data files MFLCONF.DAT and

MWCONF.DAT
ABB Automation 21
4 Configuration Data Files Configuration Manual
Editing the Data Files
The data files can be changed with a text editor (DOS format). They can not be
changed while the workstation or frontend is in operation, because a modification re-
quires that the actual workstation or frontend (including the communication units) is
restarted.
4.2 Frontend Configuration Parameters
Frontend Parameters
SRC Station Address of Frontend
The station address of the communication frontend must be unique among all nodes
(base systems, communication units and ont-ends) in the entire MicroSCADA net-
work, see "Station Addresses" in section 5.1.
SRCNOD Node number of Frontend
Value: 1 ... 32
Default value: Station address - 200
Base System Parameters
The communication frontends can be connected to up to four base systems, each of

which is identified by a sequence number 1 ... 4. The sequence number is related to a
certain base system by the DST parameter, see below. The base system communica-
tion parameters must always be included in the frontend configuration data file
MFLCONF.DAT, unless the given default values are accepted.
DI Diagnostic Command Interval
MFL sends cyclically diagnostic commands to the base systems when there is no
other communication. This parameter specifies the time interval between the com-
mands.
Type: Integer
Value: 0 ... 65535

The time interval in seconds
0 = no diagnostics
Default value: 15
Indexing: Base system sequence number, 1 ... 4

If index is omitted, the value is valid for all base systems
22 ABB Automation
DST Station Addresses of Connected Base Systems
The station addresses of the base systems to which the frontend is connected. This
parameter is the value of SYS:BSA in the connected base system, see the System
Objects manual, chapter 4.

If omitted, index = 1
NOD Node number of base system
Value: 1 ... 32

PROT Protocol
The link layer protocol used in the communication with the base system.
0= ANSI X3.28 (using a COM port)

2= TCP/IP (possible if the base system computer is PC /Windows NT)
Default value: 0

NET Parameters
Each communication frontend can contain up to four communication units (NETs)

connected to the RAM interface. In the MFLCONF.DAT file the individual units are
identified by a board index (interface number), 1 ... 4. The indexes are related to the
I/O base addresses, IRQ levels and RAM window locations of the DCP/MUXi boards
as follows:
Index I/O address IRQ RAM address
1 33CH 5 D0000H ... D3FFFH
2 2BCH 12 D4000H ... D7FFFH
3 23CH 15 D8000H ... DBFFFH
4 1FCH 3 DC000H ... DFFFFH
CMOD Initial mode of NET
0= Single mode of NET

1= Redundant hot
2= Redundant stand-by
Default value: 0
ABB Automation 23
Indexing: Board index

0 = single (no redundancy) see above
If omitted, index 1
CSRC NET Station addresses
The station address, the AS attribute, of the NET (see System Objects, chapter 12).
This parameter is only needed when a NET unit or base system is connected to a se-
rial line of the NET unit in ques-tion (specified by the index). The parameter name
may occur several times in the configuration file, with different values, if several base
systems or communication units are connected to the same unit.
Indexing: Board index, see above

If omitted, index 1
CPNOD Peer node number of NET
The node number of the partner NET in a redundant relationship. The parameter has
no meaning if there is no redundancy.
Indexing: Board index, see above

If omitted, index 1
TCP/IP Interface Parameter
The following parameter is mandatory if TCP/IP communication is used:
HOST TCP/IP Host Name
The internet address or host name of the base system computer given either as host
name/alias name or with dot notations. The parameter is valid only for TCP/IP com-
munication, i.e. PROT = 2.
Indexing: Base system sequence number, 1 ... 4 (see the Base system Com-
munication Parameters above)
No index = index 1
Examples:
HOST SPIDER
HOST 130.0.9.130
Comments are not allowed on this parameter line.
24 ABB Automation
Serial Communication Parameters
The following parameters are meaningful only when the frontend is connected to a
base system through serial lines and a COM port. If a base system is connected on a
COM port, an external clock cannot be connected, see below. Likewise, if an external
clock is connected to a COM port, it is not possible to connect a base system this way.
BR Baud Rate
The transmission rate used on the line.
Recomm.: BR = 9600
COM Communication Port
The communication port used for serial communication with the base system.
Value: 1 = COM1
2 = COM2
Default value: 1
EN ENQ Limit
See the EN attribute in the System Objects manual, chapter 13.
Type: Integer
Value: 1 ... 255
ER Embedded Response
For more information, refer to the MicroSCADA System Objects manual chapter 13.
Value: 0 = No
1 = Yes
NA NAK Limit (1 ... 255)
See the NA attribute in the System Objects manual, chapter 13.
ABB Automation 25
PY Parity
See the System Objects manual, chapter 13.
Value: 0 = No parity
1 = Odd parity
2 = Even parity
Recomm.: Even parity (PY=2)
RE Redundancy
See the System Objects manual, chapter 13.
Value: 0 = No redundancy
(1 = CRC, not supported)
2 = BCC
Recomm.: RE = 2
TI Timeout Length
See the TI attribute in the System Objects manual, chapter 13.
Type: Integer
Value: 1 ... 255
External Clock Parameters
The following parameters apply when an external clock is connected to a COM port
of the PC:
COMAG COM Port for ASCII General
The number of the COM port (1 or 2) reserved for time synchronization using the
General ASCII protocol. Only one COM port at a time is available for serial commu-
nication (software limitation). Hence, if a COM port is used for time synchronization,
no base system can be connected through a serial line, or, if a base system is con-
nected via a COM port, time synchronization of the frontend is not possible.
Values: 0 = No external clock (default)

1 = COM1
2 = COM2
26 ABB Automation
CLOCK Clock Type
The type of clock used on the COM port specified by the COMAG parameter.
Values: 1 = COMPUTIME
2 = RCC8000
5 = GPS166
6 = TRIMBLE
MODE Synchronization Mode
Currently needed only if CLOCK = 6. In that case MODE should be given value 6.
Internal Clock Parameters
The following parameters are required when the Meinberg radio clock boards PC31
and PC32 are used for clock synchronization:
TZ_MIN Time zone (minutes)
Time zone dependent correction added to the time received from the radio clock.
Value: -720 … 720
CF Clock read frequency
Clock read frequency (cycle) in seconds. The parameter determines how often the
time will be read from the PC31/PC32 clock and written to the NET boards. The
value should be an adjusting between the demands for accuracy and the increased
load caused by the readings.
Default value: 0 = No reading
CA Clock address
The I/O address of the radio clock.
Default value: 768 ( = 300H)
ABB Automation 27
Configuration Manual 5 Base Systems
5 Base Systems
5.1 The fundamental configuration of a base system and its applications.
5.2 How to configure intercommunication between two applications in the same

or in separate base systems. The base system configuration additions and
modifications required by various installations are described in detail in
chapters 7 ... 14. Chapter 2 describes the structure of the SCIL program blocks
for base system object definition.
5.1 Configuring a Base System
Fundamental Definition (SYS)
Create a SYS:B object with at least the following attributes (see the example in Figure
5):
ND The node number of the base system. The node number must be
unique within the entire MicroSCADA network, see chapter 6.
SA The MicroPROTOCOL station address of the base system. Like

the node number, the station address must be unique within the
network, see chapter 6.
The following attributes are optional:
ER The use of the base system as a routing node, which means that if
routing is enabled in a specific base system it can route messages
addressed to other nodes. See section 4.2.4 in System Objects
manual.
DN, DS Default node number and default station type. These attributes
should not be used!
SH Shadowing attribute. This attribute is used for the configuration of

hot stand-by, see chapter 12.
TI Timeout length for node communication. The attribute can be lo-

cally and temporarily sidestepped by a SCIL function
(TIMEOUT).
PC, RC Memory cache space attributes, see the headline "Memory Tun-
ing" later in this section.
FS File Sync. The flushing of buffered data onto disk.
DE Allowing applications in the base system to be accessed by other

software using DDE
ABB Automation 29
5 Base Systems Configuration Manual
AA The use of standard audio-visual alarm unit
CA, CF, CL, TZ Attributes related to an external clock, see chapter 10 or 4.3.2 in
System Objects manual
SD, SP SPACOM devices connected directly to the base system
DM, TF Debug mode and time format
The following attribute is read-only and is therefore not set:
DU The attribute states whether the DDE server is usable or not. Its
value is 0 if the DDE server has not been started. If the DDE
server has been started, its value is 1 if a user has logged on to the
base system computer, otherwise 0.
The SYS:B object definition must come first in the base system configuration file
SYS_BASCON.COM, otherwise the system will not start.
Links (LIN)
A link is a data transmission line to another base system, a NET unit or a device. Each
link is defined by a LINn:B object (n = 1 ... 20). A base system can have the following
links:
• One link for the LAN. The definition of LAN links is described in chapter seven.
• Two RAM links for internal DCP NETs. The RAM links are described in section
8.2.
• One Integrated link for a PC NET. (Created by the System Configuration Tool.)
Nodes (NOD)
Nodes are the directly or indirectly connected base systems, communication units, and
communication frontends. The nodes are defined by NODn:B objects (n= 1 ... 99). A
node definition is needed for:
• Communication with another base system. This is described in section 5.2.
• Communication through the communication units. Each NET unit - DCP NETs as
well as PC-NETs - which will be recognized by the base system must be defined
as a node. These node definitions are described in chapter eight.
• Reading and writing the attributes of communication frontends. A node is pri-
marily specified by the used connection link and the station address of the node.
If a node is only indirectly connected to the base system, the link to the node is
the link to the nearest intermediate node. The link object must have been defined
before the node can be defined.
30 ABB Automation
Devices (MON, PRI, STA)
The monitors , printers and stations are defined as MONn:B (n = 1 ... 50), PRIn:B (n
= 1 ... 20) and STAn:B (n = 1 ... 999) objects respectively.
The required MON definitions are described in chapter nine, PRI objects in chapter
10 and STA objects in chapter 11.
Local Applications (APL)
A local application is situated in the base system in question, which means that all the
application software is stored in the computer as a directory branch under the appli-
cation directory apl. For example: The application software of the local application
"sample" is stored in the directory \sc\apl\sample.
The application directory branch with its subdirectories must exist before a local
application can be defined in the base system configuration (see the Installation
Manual).
Figure 5. An example of the fundamental definition of a base system and the defi-
nition of two local applications
ABB Automation 31
To configure a local application in the base system:
Create an APLn:B object (’n’ = 1 ... 10) and assign it the following attributes (see
System Objects manual, chapter 5):
NA Application Name. The application name is the name of the appli-

cation directory branch containing the application software (e.g.
"SAMPLE" according to the example above).
MO Monitor mapping, see the headline "Device Mapping" below
AS "HOT" if the application will be running
AP Application mapping if the application will communicate with

other applications within the same or in different base systems (see
section 6.2).
ST, PR Printer and station mapping. These attributes are generally not
needed, see the headline "Device Mapping" below.
TT "LOCAL"
EM, HB, PM History buffer and queue lengths, see the headline "Tuning Mem-
ory Parameters”
PQ Number of parallel queues
QL Maximum length of process queries
See the examples in Figure 5.
At least one local application must be created in SYS_BASCON.COM, given a

name (NA), set to "LOCAL" (TT) and to "HOT" (AS) and mapped for at least one
monitor (MO).
The application that is created first in SYS_BASCON.COM will be the default appli-
cation. If no application number is given when opening a MicroSCADA monitor, the
default application is chosen. Likewise, if no application number given when using
the program interface, the default application is addressed.
Device Mapping
Monitors, printers and stations can be mapped for an application, which means that
the application recognises the devices under logical numbers.
32 ABB Automation
The station mapping, for instance, specifies the station numbers under which the ap-
plication will know the stations. The station mapping has the following format:
APLn:BSTi = j
‘i’ The logical station numbers as known to the application and the values
‘j’ The STA object numbers of the stations
The printer mapping works in a similar way and also the mapping of semi-graphic
workstations. Printers and stations can be mapped for several applications simultane-
ously, while the semi-graphic workstations are reserved for the application when
mapped.
The printers and stations have a default mapping, which means that each logical ap-
plication recognises them under the real object numbers. Therefore, the printer and
station mapping is needed only if the application for some reason needs to know the
devices under logical numbers. If there are no obstacles, let the logical numbers be the
same as the object numbers (i.e. i = j), i.e. do not change the default values of printer
and station mapping.
The monitor mapping is described in chapter nine.
Tuning Memory Parameters
The allocation and use of the available RAM memory is affected by the following
base system attributes:
• The SYS:B attributes PC (= Picture Cache Size) and RC (= Report Cache Size),
see the System Objects manual, chapter four.
• The APLn:B attribute HB (= History Buffer), see the System Objects manual,
chapter five.
• The picture cache and report cache memory space is in common to all applica-
tions in the base system. The cache memories contain only objects and pictures
that have been in use, but are not currently running. The maximum cache space is
specified by the PC and RC attributes. When these limits are reached, the least
used objects are removed.
During operation, there should be at least 500 kB free memory. The MF, MS and MU
attributes can be used for reading the occupied and the free memory space, see System
Objects manual, section 4.2.5. If there is not enough free memory, memory is taken
from the picture and report caches.
5.2 Communicating Applications
Communication between applications means that the object data in one application
can be read and written from another one by means of the object notations. Communi-
cation between applications in the same base system, i.e. between two local applica-
tions, is achieved simply by application mapping (the APLn:BAP attribute).
ABB Automation 33
Communication between applications in separate base systems requires that the base
systems are physically connected to each other, either through direct serial lines,
through LAN or through frontends, see Figure 6. The configuration and communica-
tion principles are the same, independently of the route between the base systems. The
communicating base systems are identified to each other by node numbers and station
addresses and the link to the nearest node. The route through the network need not be
defined. It is not recommended that there are more than three communication units
between two communicating base systems.
Figure 6. Base system 1 can be configured to access the database of the applica-
tions in base systems 2 and 3 as described in section 5.2. A communica-
tion between base system 2 and base system 3 requires that there is an
external application in base system 1, which forwards the data between
the two base system.
Local Applications
Suppose that application ’a’ needs to read and write data in application ’b’ in the same
base system, see figure in chapter 6. Application ’b’ then must be "introduced to" ap-
plication ’a’ by means of the application mapping (see System Objects manual, section
5.3):
#SET APLa:BAPi = b
where
’i’ The logical application number under which application ’a’ recognizes
application ’b’
If there are no obstacles, let the logical number be the same as the object number of
the application, i.e., ’i’ = ’b’.
34 ABB Automation
For example, setting #SET APL1:BAP2 == 2 means that APL2 is recognized to APL1
by the logical application number 2. In application 1 it is possible to read object data
in application 2, e.g. with the notation: OBJ:2POV1.
Figure 7. An illustration of the data communication between applications in the

same base system
Base System Configuration:
(See Figure 6.)
Application 1:
...
#SET APL:VAP2=2
...
Applications in Separate Base Systems
Suppose that application ’a’ in base system 1 needs to read and write data in applica-
tion ’b’ in base system 2. Then the following configurations are required in base sys-
tem 1:
1 Create a LINn:B object for the link to the base system 2 (if not already existing,
see chapters seven and eight). If base system 2 is connected via several
communication units, the link is the link to the nearest unit.
ABB Automation 35
2 Create a NODn:B object representing base system 2, where ’n’ is the node number
of base system 2. The NODn:B object must be assigned at least the following
attributes:
LI The number of the link to base system 2 (the LINn:B object
number, see above)
SA Station address of base system 2
In addition, if LAN is used:
NN LAN node name of base system 2 (see chapter seven, "LAN
Nodes")
In some special cases, a routing node must be defined, see the RN attribute in System
Objects manual, section 8.2. This applies the communication between a base system
connected to a communication frontend via LAN or COM port and a base system
connected to a NET unit in the frontend. If no routing node is defined, the communi-
cation must be initiated from the latter base system, e.g. by means of an object nota-
tion.
3 Create an external application, an APLn:B object, referring to application ’b’ in

base system 2. For clarity, use the same object number (’n’) as the application
object number in base system 2 (though this is not a requirement), i.e. create
APLb:B. Assign the APLb:B object the following attributes:
TT "EXTERNAL"
ND Node number of base system 2
TN Application object number in base system 2 (’b’)
4 Map the external application in base system 1 to the communicating application,
application a, by setting APLa:BAPi = b, where ’i’ is the logical application
number under which application a will recognize application b. If there are no
obstacles, let the logical number be the same as the object number of the
application (i.e. ’i’ = ’b’).
36 ABB Automation
Figure 8. An illustration of the configuration and data communication between two applications situated in
separate base systems
LAN Link Configuration
(See Figure 8.)

;LAN link:
#CREATE LIN1:B=LIST(-
LT=“LAN”,-
TR=“TCP/IP”)
;Node for Basesystem 2:
#CREATE NOD10:B=LIST(-
LI=1,-
SA=210,-
NN=90.0.1.124)
;Application 1:
#CREATE APL1:B=LIST(-
AP3=3)
;Application 3:
#CREATE APL3:B=LIST(-
TT=“EXTERNAL”,-
ND=10,-
TN=3)
ABB Automation 37
Configuration Manual 6 MicroSCADA Networks
6 MicroSCADA Networks
6.1 The global definitions in a MicroSCADA network: The node numbers, and the
ACP (MicroPROTOCOL) station addresses.
6.2 The object numbering which is unique within a certain base system or commu-
nication unit.
6.1 Global Definitions
The MicroSCADA configuration software contains some global definitions which

must correspond in all configuration modules throughout the entire MicroSCADA
distributed network. These are the node numbers and the ACP station addresses, see
Figure 9. ACP is the MicroSCADA internal protocol previously called MicroPRO-
TOCOL.
The node numbers and station addresses can be changed any time. However, if the
network is extensive, a change of node number or station address may require recon-
figuration in several modules. It is therefore recommended to assign the node numbers
and the station addresses fixed and unique values which are regarded as non-editable
data.
In a Local Area Network (LAN), the connected computers - base system, worksta-
tions and frontend computers have a LAN node address which is not to be confused
with the MicroSCADA node numbers. Likewise, if LONWORKS network is used for
process communication, the LONWORKS devices are defined by node numbers. These
have nothing to do with the MicroSCADA nodes.
Nodes
In the MicroSCADA network, the base systems and communication units (NETs) are
regarded as nodes. Each of them are given a node number which must be unique
throughout the entire MicroSCADA network. Likewise, the communication frontends
are nodes with unique numbers.
The node numbers can take integer values from 1 to 32 (limited by the NET program).
However, for compatibility reasons, it is not recommended to give the NET nodes
numbers above 19. A suitable convention could be to assign the NET units sequential
node numbers from 1 and upwards, and the base systems, likewise, sequential node
numbers starting from a number which is large enough. For instance, if the NET
nodes are less than 8, the base system node numbering could start from 9.
In the base systems, the communicating nodes are defined by NODn:B objects, where
’n’ is the node number. In the communication units, the nodes are defined by NETn:S
objects, where ’n’ is node number.
ABB Automation 39
6 MicroSCADA Networks Configuration Manual
Figure 9. The global definitions and the object numbers of a typical MicroSCADA network. The figure in-
cludes also the base system specific link numbers and the NET unit line numbers.
Station Addresses
Each base system and NET unit has an ACP station address which must be unique
40 ABB Automation
Configuration Manual 6 MicroSCADA Networks
within the network of intercommunicating devices.
Devices which never communicate and which are not recognized by the same NET
unit or base system may have the same station address.
The station addresses can take integer values from 1 to 254. A widely used conven-
tion when assigning station addresses is as follows:
Base systems: 200 + node number
Communication units: 200 + node number
6.2 Object Numbering
Each MicroSCADA monitor, printer, station and application that is included in the
network has an object number. The object numbers of monitors, devices, printers,
stations and applications are unique within the base system that uses them. The print-
ers, stations and applications are also given object numbers, which are unique within
the NET unit that they are directly connected to.
Though the object numbers need not be globally unique, the configuration work is
simplified by keeping them unique as far as possible. This means that a certain device
is assigned the same object number in all base systems and communication units, see
Figure 9. In principle, the object numbers can be changed any time. However, it is
generally not recommended to change the numbers in a working system.
Each connection line has a number which is unique for the base system or NET unit in
question. The numbers of the NET unit lines are identical with the physical numbers
of the lines. In a base system, the links to other base systems, communication units
and workstations are numbered 1 ... 20. Figure 9 includes the NET unit line numbers
and the base system link numbers.
Monitors (MON)
The monitors are symbolized with the object name MON. The MON objects can take
numbers in the range 1 ... 50.
Each monitor that the operator starts to view and supervise a MicroSCADA applica-
tion is regarded as a MicroSCADA monitor. A MicroSCADA monitor can contain
several monitors for supervising one or more applications. All monitors that are avail-
able for the base system must be defined as MON objects.
Printers (PRI)
The printers are notated by PRI object names. The PRI objects can take numbers 1 ...
20 in the base systems and 1 ... 8 in NET.
ABB Automation 41
6 MicroSCADA Networks Configuration Manual
Stations (STA)
The stations are notated by the object names STA. They can take numbers 1 ... 2000
in the base systems and 1 ... 255 per station type in the communication units (limited
by the RAM size in NET).
Applications (APL)
The applications are notated by the object names APL. Each base system can contain
up to 99 applications, while each NET unit can recognise up to 32.
42 ABB Automation
Configuration Manual 7 Local Area Networks (LANs)
7 Local Area Networks (LANs)
This chapter describes how to configure MicroSCADA for LAN communication. The
chapter does not describe the LAN product specific configuration. To learn about this,
refer to the LAN product manuals.
Base System Configuration
In order to connect a base system to a LAN:
Create a LINn:B object with the following attributes (see System Objects, chapter
seven):
LT = "LAN"
TR = "TCP/IP"
All workstations, base systems and frontends can utilize the same LIN object, i.e.,
only one LIN object definition is required. No LIN object is required for the LAN if
the base system uses LAN only for communication with workstations running X soft-
ware.
Frontends
In each communication frontend the LAN communication is established with the fol-
lowing definitions in the configuration data files:
1 Set the parameter PROT = the LAN protocol used, i.e. TCP/IP.
2 Set the HOST parameter to the LAN node number of the connected base system.
The parameters can be indexed by a base system number for communication with
several base systems, see the parameter descriptions in section 4.2.
LAN Nodes
In the LAN network, each connected base system, workstation and frontend has a
LAN node name or number, see your LAN product manual. The LAN node names are
used in the MicroSCADA configuration to achieve communication between base
systems (see section 5.2), between base systems and workstations and between base
systems and frontends.
The LAN node names are assigned during the installation of the LAN network.
ABB Automation 43
7 Local Area Networks (LANs) Configuration Manual

;LAN link:
;
#CREATE LIN1:B=LIST(-
LT=“LAN”,-
TR=“TCP/IP”)
Front-end Configuration (in MFLCONF.DAT)
PROT1 2
HOST1 90.0.1.124
PROT2 2
HOST2 90.0.1.127
Figure 10. An example of a MicroSCADA configuration for a LAN
44 ABB Automation
Configuration Manual 8 Process Communication System
8 Process Communication System
This chapter describes how to configure the process communication units (NETs) and
how to configure networks of interconnected NETs and base systems:
8.1 How to configure a NET unit (NET): the fundamental configuration of DCP-
NETs and PC-NETs, the configuration of applications known to the unit and
some general rules.
8.2 How to configure a base system and an internal DCP-NET.
8.3 How to configure a base system and a PC-NET.
8.4 How to configure a communication frontend connected to two base systems via
a LAN.
8.5 How to configure networks of connected NETs and base systems.
The configuration measures required for various device connections in NET (stations
and printers) are described in the chapters 10 ...13.
8.1 Configuring a Communication Unit (NET)
Fundamental Configurations, DCP-NETs

To make the communication unit work and communicate with the base system:
1 Define the communication unit itself in the preconfiguration as “This node”:

Device number The node number of the unit (see chapter five)
RAM size 1024 for DCP-286i and DCP-386i type boards, 512 for
DCP/MUXi type NET boards
SA ACP station address of the unit (ACP is the MicroSCADA
internal protocol)
MS Message application for the system message
SE System message enabled
See the definition of "This node" in the examples in the figures of this chapter.
If the RAM size is wrong, the NET unit will not start.
2 Define line 13 (exists in the default configuration) for the common RAM protocol.
3 Define external node for the base system.
LI Line number of the base system; normally 13
ABB Automation 45
8 Process Communication System Configuration Manual
SA Station address of the base system

4 Define at least one application in the base system.
DN Application number in the NET
TN Application number in the base system
NN Node number of the base system
Fundamental Configuration, PC-NETs

The PC_NET.CF1 file is edited with the System Configuration Tool. The default
configuration includes the following definitions:
• The node number (local_node.nn) and station address (local_node.sa) of the NET.
Default: NET node number = 3, station address = 200 + NET node number.
• The node number (ext_node(1).nn) and station address (ext_node(1).sa) of the
base system where the NET will be running. Default: node number = 9, station
address = 209.
• The node number (ext_apl(1).nn) and application number (ext_apl(1).an) of the
application that the NET will initially communicate with (an application within
the same base system). Default: node number = 9, application number = 1.
Other Basic NET Definitions

The following definitions can be done in the preconfiguration (DCP-NETs) or with
SCIL. For PC-NETs, the definitions are made with the System Configuration Tool
(User-Defined Programs).
SX The "destination address" defined in the ANSI stations con-
nected to the NET (has no importance if no ANSI station is
connected to the NET)
MS System message application, see section 13.1
MI System message identification; use as a process object ad-
dress, see section 13.1
SE System message generation
0 = Off
1 = On (recommended if not Hot Stand-by base systems)
2 = Start-up only (recommended in Hot Stand-by base
systems), see section 13.1
Lines (NET Lines)

The definition of a line depends on the protocol to be used on the line which in turn
depends on the device(s) connected to the line.
Each DCP-NET has 8 asynchronous serial lines numbered 1 ... 8. In addition, the
communication program recognises a line number 13 for common RAM interface.
This line is used for the communication between an internal NET unit and the base
system, between a NET unit in a communication frontend and a base system con-
nected to the frontend, and between the separate communication units in a communi-
cation frontend.
46 ABB Automation
The PC-NETs communicate through the serial ports (COM ports) of the host com-
puter and possible PCLTA cards (one or two) or the serial ports of a “RocketPort”.
The COM ports, if used, represent by default NET line numbers 1 to 4, COM1 is line
1, COM2 is line 2, and so on. The NET line numbers of the PCLTA card channels (up
to two per board) can be freely chosen among the free NET line numbers (1 ... 8 if no
COM ports are used). A PC-NET communicates with the base system (kernel)
through line number 13 which is a software link (Integrated link).
A NET unit line is basically defined by assigning it a protocol. This can be done in
the preconfiguration (DCP-NETs) or on-line with the PO attribute.
PC-NETs support the following protocols on the COM lines (lines 1 - 8): ACP, SPA,
LonTalk, RP570 master and slave, RP571 master, IEC 870-5-101 master and slave,
IEC 870-5-103 master and IEC 1107. A COM port is taken into use by assigning line
1 ... 8 one of these protocols. The output channels of the PCLTA cards support only
the LonTalk protocol.
The DCP board based NETs support all protocols supported by MicroSCADA, except
the LonTalk, ALPHA ME, IEC 101 and IEC 103 protocols.
The definition of lines is detailed in the contexts where various installations are de-
scribed.
External Nodes (NET)

All connected base systems and communication units are defined as external nodes
(NET objects). This applies also to base systems and communication units which are
only indirectly connected via other communication units. The definition of the exter-
nal nodes is described in sections 8.2 ... 8.5.
Applications (APL)
As a rule, all applications in all base systems directly or indirectly connected to the
communication unit, must be defined to the NET unit as APL objects. The defined
applications can be configured to receive spontaneous messages from the stations and
system messages generated by NET. The default applications of all connected base
systems (see section 5.1) should be defined in the preconfiguration (DCP-NETs).
In order to define or redefine an application in a connected base system:
1 Define an “Application”, an APL object, in the preconfiguration or online by

means of the NETn:SSY attribute (see the System Objects manual, chapter 14):
Device type APL
Device number Object number
Can be freely chosen within the NET unit (1 ... 32).
As far as possible, use the same application number
as in the base system. If message split is used
(section 11.2), only the applications number 1 ... 9
can be selected in the preconfiguration as receiving
applications.
Node number The node number of the base system where the
application resides
ABB Automation 47
Translated APL number APL number in the base system

2 Assign it the following attributes for the communication supervision (System
Objects, chapter 12):
SU Application suspension time in seconds
SW Application reply wait time in seconds
From SCIL, the SW and SU attributes are accessed as NETn:S attributes.
NET supervises all its application connections by reading cyclically the DS attribute
of all known applications at the interval calculated from the SU attribute. If an appli-
cation does not reply, an error message is produced and the application is suspended.
This happens when the base system is closed, when the application has been set to
"COLD", the application does not exist or the connection is faulty or disturbed, or the
communication does not work. When an application has been suspended, the
S.P.I.D.E.R. RTUs connected to that application are not polled until the communica-
tion with the application has been re-established.
Printers and Stations (PRI and STA)

The configuration of the NET unit for connected printers and stations is described in
chapter 10 (printers) and chapter 11 (stations).
Memory Allocations
The total RAM size of the DCP boards is 1024 kB (512 kB for DCP/MUXi). A part of
this memory space is reserved by the NET program itself, its fixed data areas and
stacks. The rest is allocated for external connections. The amount of free memory in a
unit may restrict the connection of devices to the unit. In order to learn the amount of
free memory space:
1 Start the NET unit for operation and read the existing amount of free memory with
the NETn:SFM attribute or by means of the configuration picture NET SYSTEM
CONFIGURATION, INTERNAL PARAMETERS.
The NET lines and the connected devices (system objects) allocate memory space as
follows:
Lines: About 1 kB per line + 0.33 kB per buffer
External nodes: About 2 kB/node
Stations: About 0.5 kB + memory areas (ANSI stations)
Printers: About 0.5 kB/printer
SPACOM: 1 kB per station + 50 byte/SPA point +
50 byte/event updated SPA point
STA memory areas: About 32 bytes per area
The memory allocation in NET is basically static in a run-time environment. Memory
is allocated and released only at configuration changes.
48 ABB Automation
Buffer Pool Sizes

Each line has a buffer pool, the size of which is specified by the PS attribute (number
of buffers in the pool). One or a few buffers are reserved for message reception. The
rest of the buffer pool is divided between two priority levels.
The buffer pool sizes should be set according to the following principles:
• The pool size of a base system connection should be considerably larger than the
pool sizes of other lines. Recommended value: 50 ... 100.
• For other lines, the pool size should not be larger than necessary. Especially the
total pool size for all printer lines should be much less than the pool size for an
individual base system connection.
See also the recommendations in the System Objects manual, chapter 13.
The general rule in NET is that one buffer is allocated for each message from a pool
of the destination line. For SCIL configuration commands, the buffer is reserved from
the base system line, since the command is handled within NET. For communication
commands, i.e., control commands, setpoint commands, printout commands, etc., an
additional buffer is reserved for the reply message. The buffers are always returned to
their home pools after use.
8.2 Internal NETs (DCP-NETs)
An internal NET is a DCP-NET placed within a base system computer and connected
to this base system through the common RAM interface. The NET unit can be con-
nected to other base systems and communication units through its serial lines. A base
system computer can house up to two internal NETs.
This section describes the configuration of a base system and an internal NET end.
The configuration is illustrated with an example in Figure 11.
In order to use an internal NET, configure the base system which will house the NET
as follows:
1 Create a LINn:B base system object for the RAM interface (’n’ = 1 ... 20) and
assign it the following attributes (see the System Objects manual, chapter seven:
LT "RAM"
SD Device name, "RM00" or "RM01" (see the Installation man-
ual, chapter 5)
EN Enquiry limit (rec.: 3)
NA NAK limit (rec.: 3)
RE Redundancy check: "NONE" or "BCC" (recommended)
TI Time-out length in seconds (recomm. 1 ... 2 seconds)
ABB Automation 49
The EN, NA, RE and TI attributes specify the communication properties and should
have the same values as the corresponding parameters in the communication unit, see
the line definition under the headline "Communication Unit Configuration" below.
2 Create a NODn:B object for the communication unit, where ’n’ is the node number
of the communication unit. Assign it the following NODn:B attributes (see the
System Objects manual, chapter eight):
LI Link number (= LINn:B object number)
SA ACP station address of the communication unit
Concerning node number and station address of NET, see the configuration of the
NET unit below and chapter five.
Figure 11. An example of a configuration with a base system and an internal NET
The example includes only the definitions which are of importance for this particular
configuration.

Base System:
#CREATE SYS:B = LIST(-
ND = 11,-
SA = 211)
………………….
Link 1 (= RAM Interface):

#CREATE LN:V = LIST(-
LT = “RAM”,-
SD = “RM00”,-
RE = “BCC”,-
TI = 2,-
NA = 3,-
EN = 3)
#CREATE LIN1:B = %LIN
………………………
50 ABB Automation
Node 3 (=Communication Unit 3):

#CREATE NOD:V = LIST(-
LI = 1,-
SA = 203)
#CREATE NOD3:B = %NOD
………………………
Application 5:
#CREATE APL:V
………………………;See fig. In chapter 5
#CREATE APL5:B = %APL
Communication Unit Configuration

Configure each internal DCP-NET unit as follows:
1 Perform the fundamental definition of the unit as described in section 8.1.

2 Define line 13 with the RAM protocol (System Objects, chapter 13):
PO 3
MI System message object address, see section 13.1
RE 2 = BCC
TI Time-out length in seconds, 1 ... 2 seconds
NA NAK limit
EN ENQ limit
PS Buffer pool size, see section 8.1
The RE, TI, NA and EN attributes should have the same values as the corresponding
LINn:B attributes in the base system configuration, see the LIN definition in "Base
system Configuration" above.
3 Define an "External node", a NET object, for the base system connected to line 13:
Device type NOD
Device number The node number of the base system
Line number (LI) 13
Station address (SA) Station address of the base system
4 Define an application, an APL object, for each application in the base system as
described in section 8.1.
8.3 Configuring Base Systems with PC-NET
General
A PC-NET is a communication program which runs in the processor of the base sys-
tem computer. As communication lines it utilizes the COM port of the PC or the
channels of the PCLTA card(s) or the ports of a “RocketPort”.
The configuration of a base system and a PC-NET is done with the System Configu-
ration Tool. The configuration is illustrated with an example in Figure 11.
ABB Automation 51
The System Configuration tool includes the following main functions:

• Configuration of the base system and the PC-NET.
• General mechanism for the base system configuration at system start-up.
• General mechanisms for automatic starting and configuration of the PC-NET.
• Online monitoring of the base system and the NET configuration.
• Configuration of transceiver information and node and sub-net numbers of the
PCLTA card.
• Debug support.
For instructions on using the tool and more profound information, please refer to
chapter 14 in this manual and the manual Connecting LONWORKS devices to Micro-
SCADA.

The System Configuration tool can handle base system objects like links, nodes, sta-
tions and station types. It can operate in on-line or off-line mode, a combination is
not supported. Operating in off-line mode means that a configuration can be built-up
without physical connections to the devices. If the tool is switched to on-line mode,
the existing configuration is read from the current MicroSCADA base system. Stop-
ping and starting the NET and the PCLTA initialisation can be done in the on-line
mode only.
During the configuration work, the configuration data is read from permanent con-
figuration file using the off-line reading mechanism, or from the MicroSCADA sys-
tem (SYS 500 or COM 500) using the on-line reading mechanism. After reading
mechanism the current configuration is displayed inside the tool.
The System Configuration tool includes a function that checks the attribute limits. In
the case of an invalid attribute value it returns a string that requests the user to enter a
valid value. The tool also suggests default values for the attributes.
52 ABB Automation
Figure 12. An example configuration of a base system with a PC-NET
PC-NET Configuration
The tool configures the LIN and NOD base system objects needed for the PC-NET.
Also the PC-NET initialisation file pc_net.cf1 is updated automatically.
All configurable attributes of the LIN:B object and the NOD:B object can be changed
from the Tool.
The tool creates procedures for automatic start-up and configuration of the PC-NET.
The automatic starting/configuration can be switched on or off. Manual start-
ing/stopping of the PC-NET can be done in on-line mode.
NET Nodes can contain user-defined SCIL programs. Each program receives its envi-
ronment as an input parameter, which in NET Node level is the NET Number.
8.4 Communication Frontends
General
A communication frontend is a PC/DOS computer containing up to four communica-
tion units. The communication units communicate directly with one to four base sys-
tems. For communication the units uses the common RAM interface, and the LAN or
the serial port COM1 or COM2.
This section describes how to build a configuration composed of base systems and a
communication frontend. The described configuration is illustrated with an example
in Figure 13.
ABB Automation 53
Configure each base system connected to a communication frontend via a LAN as

follows:
1 Create a LINn:B base system object for the LAN connection, see chapter seven.
Only one LAN link per base system is needed, so if a LAN link already exists, you
need not create any new LAN link.
2 Create a NODn:B base system object, where ’n’ is node number, for each of the
communication units in the LAN frontend, and assign it the following NODn:B
attributes:
LI The link number of the LAN link (the LINn:B object num-
ber). All units use the same link.
SA ACP address. Each of the communication units must have a
unique station address, see chapter six.
Create a NOD object for the communication frontend if its attributes should be ac-
cessed from the base system, e.g. if the NETs in the frontend should be restarted from
the base system.

Configure each communication unit as follows:
1 Define the unit to itself as "This node" as described in section 8.1.

2 Define line 13 with the RAM protocol:
PO 3
MI System message identification; use as a process object
address, see section 13.1
RE 2 = BCC
TI Time-out length in seconds
NA NAK limit
EN ENQ limit
3 Define an "External node", a NET object, connected to line 13 for each of the
connected base systems:
Device type NOD
Device number Node number of the base system
LI, Line Number 13
SA Station Address
4 Define an APL object for each application in the connected base systems as
described in section 8.1.
54 ABB Automation
Generally, there is no need for intercommunication between the two communication

units in the frontend and therefore they need not know each others as nodes. This is
necessary only if any of the communication units is connected to one or more other
base systems through the serial lines of the units and these base systems communicate
via both the NETs. In these cases, configure the communication units as follows:
5 Define each of the other communication units as an "External Node" (NET object)
situated on line 13:
Line 13
Device type NOD
Device number Node number of the other communication unit
SA Station address of the other communication unit
Frontend Configuration File

The frontend itself is configured by the file MFLCONF.DAT which can be edited
with a text editor (see section 4.2).
1 Check the following parameters for each of the base system connections and edit if
necessary:
SRC The station address of the frontend
SRCNOD The node number of the frontend
PROT The LAN protocol used on the frontend - base sys-
tem communication: DECnet or TCP/IP
DST1 … 4 Station addresses of the base systems connected to
the frontend via LAN or the COM port
DI1 … DI4 Base system diagnostic interval
NOD1 … NOD4 Base system node numbers
If TCP/IP is used:
HOST1 ... HOST4 TCP/IPhost names or internet addresses of the base
systems
If a COM port is used:
COM Serial communication port number, serial
communication attributes (BR, RE, PY, etc.)
CSRCn Station address of the NET connected via DCP-NET
card on a logical COM port
The index ´n´ in CSRCn depends on the IRQ of the
DCP-NET card in the frontend computer, see Figure
14 and section 4.2
Example
Figure 13 shows a configuration where a communication frontend is used by two base
systems on LAN. The system configuration of base system 1, NET unit 1 and the
frontend are listed below. Base system 2 is configured analogously as base system 1,
and NET unit 2 analogously as NET unit 1.
ABB Automation 55
The example includes only definitions, which are of importance for this particular
configuration.
Figure 13. An example of a communication frontend used by two base systems
Configuration of Communication Unit 1

This Node
RAM Size (kilobytes): 512
Device Number 1
MI Message Ident.: 6001
MS Message Application: 1
SA Station Addr. (Dec.): 201
SE System Message Enabled: 1
Line 13 (=RAM Interface)
PO Protocol: 3
IU In Use: 1
RE Redundancy: 2
TI Timeout Length: 1
NA NAK Limit: 3
EN ENQ Limit: 3
PS Buffer Pool Size: 50
External Node 9 (= Base System 1)
Device Type: NOD
Device Number: 9
LI Line Number: 13
IU In Use: 1
56 ABB Automation
External Node 10 (Base System 2)

Device Type: NOD
Device Number: 10
LI Line Number: 13
IU In Use: 1
Application 1
Device Type: APL
Device Number: 1
Translated APL Number: 1
Node Number: 9
IU In Use: 1
SW Reply Timeout: 5
SU Suspension Time: 30
Application 2
Device Type: APL
Device Number: 2
Node Number: 9
IU In Use: 1
SW Reply Timeout: 5
Application 3
Device Type: APL
Device Number: 3
Node Number: 10
IU In Use: 1
SW Reply Timeout: 5
Application 4
Device Type: APL
Device Number: 4
Node Number: 10
IU In Use: 1
SW Reply Timeout: 5
Frontend Configuration File, MFLCONF.DAT
SRCNOD = 6
SRC = 206
PROT1 = 2
DST1 = 209
HOST1 = 90.0.1.124
PROT2 = 2
DST2 = 210
HOST2 = 90.0.1.127
Configuration of Base System 1

Base System:
#CREATE SYS:V = LIST(-
ND =9,-
SA = 209)
#CREATE SYS:B = %SYS
……………………
Link 1 (LAN link):

#CREATE LIN:V = LIST(-
LT = “LAN”,-
ABB Automation 57
TR = “TCPIP”)
……………………
Node 1 (Communication Unit 1):

LI = 1,-
SA = 201)
…………………………
Node 2 (Communication Unit 2):

LI = 1,-
SA = 202)
…………………………
Application 1:
#CREATE APL:V
………………….See chapter 5
Application 2:
#CREATE APL:V
……………………See chapter 6
8.5 Networks of Interconnected NETs
This section describes how to connect the NETs and base systems into a network.
This means that several communication units - DCP-NETs and PC-NETs - may be
connected in series. For performance reasons, generally, there should not be more
than three communication units in series between a base system and a communicating
device - base system, workstation, printer or RTU. When communication units and
base systems are connected to a network, each NET unit and each base system in the
network must be defined as a node in each other NET unit and base system.
The configuration described in this section is illustrated with an example in Figure 14.
Communication Units Connected in Series

In section 8.3, there was described how to achieve intercommunication between the
communication units within a communication frontend (rarely needed). This is the
only case where the communication link between two communication units is not a
serial lines. In all other cases, the communication goes via serial lines.
In order to connect two communication units through serial lines (e.g., NET unit 2
and 3 in Figure 14) make the following definitions in each of the unit:
1 Select a line for the connection and define it with the ACP protocol as follows:
PO 1
MI System message object address, see section 13.1
BR Baud rate
PY Parity
58 ABB Automation
SB Number of stop bits

RD Read data bits
TD Transmission data bits
ER Embedded response
RE Redundancy
TI Time-out length in seconds (1 + 2400/BR)
NA NAK limit
EN ENQ limit
The communication attributes (BR, etc.) should have the same values as the corre-
sponding parameters in the connected communication unit. If the NET is a PC-NET,
the line numbers 1 ... 4 are available. These lines corresponds to the COM ports.
When selecting one of these lines for the ACP protocol (setting the PO attribute of the
line to 1), the line number cannot be used for any of the LON channels.
2 Define an "External node", a NET object, on the ACP line for the connected
communication unit:
Device type NOD
Device number The node number of the connected communication unit
LI, Line number The number of the selected line
SA Station address of the connected communication unit
Though two communication units are connected indirectly via another unit (e.g.
communication units 1 and 3 in Figure 14, they must be defined to each other. Make
the following definitions in each of the units:
3 Define an "External node" (NET object) connected to the line to the nearest
communication unit:
Device type OD
Device number The node number of the indirectly connected communica-
tion unit
LI, Line number The line to the nearest NET unit in the series
SA Station address of the indirectly connected communication
unit
Base Systems Connected to the Network

Each NET unit which is connected to a base system via one or more other units (e.g.
NET unit 3 and base system 1 in Figure 14) must be defined to the base system as a
node (NODn:B objects):
1 Create a NODn:B base system object corresponding to the indirectly connected

communication unit. The NOD object number (’n’) must be the same as the node
number of the communication unit. The NOD object is given the following
attribute values (Object Description section 12.8):
ABB Automation 59
LI Link number (= LIN object number)

This is the link to the nearest communication unit
SA Station address of the indirectly connected communication
units
Even if there would be no communication between the base system and the indirectly
connected NET, the node definition is necessary for the system diagnostics, on-line
configuration and system maintenance.
Correspondingly, each base system connected to a NET unit indirectly via other units
must be defined to the NET unit as a node (e.g., base system 1 and NET 3 in Figure
14):
2 Define an "External node" (NET object) on the line to the nearest communication
unit:
Device type NOD
Device number The node number of the indirectly connected base system
LI, Line number The line to the nearest communication unit in the series
SA Station address of the indirectly connected base system
3 Define an application for each application in the indirectly connected base system
as described in section 8.1.
Example
Figure 14 shows an example of a network of two communicating NETs and two base
systems. The table below shows the configuration of the NETs and base systems. The
example includes only the definitions which are of importance for this particular con-
figuration and which have not been described in the previous sections.
60 ABB Automation
Figure 14. An example of a configuration with interconnected base systems and

NETs

See Figure 12
Extermal Node 9 (Base System 1)
Device Type: NOD
Device Number: 9
LI Line Number: 13
IU In Use: 1
Application 1
Device Type: APL
Device Number: 1
Node Number: 9
IU In Use: 1
SW Reply Timeout: 5
ABB Automation 61

See Figure 12
Line 2 (ACP line)
PO Protocol: 1
IU In Use: 1
MI Message Ident.; 6202
LT Link Type: 1
BR Baud Rate: 9600
SB Stop Bits: 1
PY Parity: 2
RD Receiver Data Bits: 8
TD Transm. Data Bits: 8
RE Redundancy: 2
NA NAK Limit: 3
EN ENQ Limit: 3
ER Embedded Response: 1
RP Reply Poll Count: 1
Extermal Node 3 (Communication Unit 3)
Device Type: NOD
Device Number: 3
LI Line Number: 2
IU In Use: 1
Device Type: NOD
Device Number: 9
LI Line Number: 13
IU In Use: 1
Device Type: NOD
Device Number: 11
LI Line Number: 2
IU In Use: 1
Application 1
Device Type: APL
Device Number: 1
Node Number: 9
IU In Use: 1
SW Reply Timeout: 5
Application 5
Device Type: APL
Device Number: 5
Node Number: 11
IU In Use: 1
SW Reply Timeout: 5
62 ABB Automation

See Figure 12
Line 3 (ACP line)
PO Protocol: 1
IU In Use: 1
MI Message Ident.; 303
LT Link Type: 1
BR Baud Rate: 9600
SB Stop Bits: 1
PY Parity: 2
RE Redundancy: 2
NA NAK Limit: 3
EN ENQ Limit: 3
RP Reply Poll Count: 1
External Node 2 (=Communication Unit 2)

Device Type: NOD
Device Number: 2
LI Line Number: 3
IU In Use: 1
External Node 9 (= Base System 1)
Device Type: NOD
Device Number: 9
LI Line Number: 13
IU In Use: 1
Application 1
Device Type: APL
Device Number: 1
Node Number: 9
IU In Use: 1
SW Reply Timeout: 5
Application 5
Device Type: APL
Device Number: 5
Node Number: 11
IU In Use: 1
SW Reply Timeout: 5
Configuration of Base System

(See figure in chapter five.)
Link 1 (LAN link):

#CREATE LIN:V = LIST(LT = “LAN”,-
TR = “TCPIP”)
……………….
Node 1 and 2
ABB Automation 63
(Communication units 1 and 2):

See Figure 13.
………………….
Node 3 (Communication unit 3)
#CREATE NOD:V = LIST(LI = 1,-
RN = 6,-
SA = 203)
………………….
Node 11 (Base system 3):
RN = 6,-
SA = 211)
SA = 206)
Configuration of base system 3

…………………see chapter 5
Link 1 (Intergrated link):
Configured with the System Configuration Tool
Node 2 (Communication unit 2):

SA = 202)
Node 3 (Communication unit 3):

SA = 203)
Node 9 (Base system 1):
RN = 3,-
SA = 209)
Frontend Configuration File, MFLCONF.DAT:

SRCNOD 6
SRC 206
PROT1 2
DST1 209
HOST1 90.0.1.124
64 ABB Automation
Configuration Manual 9 Operator Workstations
9 Operator Workstations
This chapter describes how to configure the MicroSCADA operator workstations: the
base system operator workstations and the remote workstations that are based on X
software or Windows NT Terminal Server.
General
When the operator wishes to supervise an application on his monitor screen, he opens
a MicroSCADA monitor. The operator can open the monitor using a standard dialog
or a customised icon, or monitors can be opened automatically at application start-up.
When opening a monitor using the standard icon, the operator can select the Micro-
SCADA monitor number, the application number and picture size. He can also select
the base system he wishes to view. The same parameters are chosen when opening a
monitor with a command.
A display can show several monitors connected to one or more MicroSCADA appli-
cations in the same or in separate base systems.
Windows NT Terminal Server Support

It is possible to do remote administration of the MicroSCADA base system machine
from an NT Workstation. By opening a Terminal Server client window it is possible
to directly access the desktop and tools of the server machine and thus make all ad-
ministration that is needed.
Each MicroSCADA monitor must be defined as a MON object in the connected base
system. In addition, the MON objects must be mapped for the applications, which will
use them. The monitor objects are defined equally whether they will be opened on the
base system monitor or on a workstation. Figure 15 shows an example of a worksta-
tion with three MicroSCADA monitors opened to three applications in two separate
base systems.
Make the following object definitions in each base system:
1 Create MONn:B objects, one for each MicroSCADA application monitor that will
be opened on the base system monitor or on connected workstations, see chapter 6.
Assign the MON objects the following attributes:
DT = “VS” or “X”.
Define the monitor as “VS” type, unless it should be able to
show Motif widgets.
TT = "LOCAL"
You can create up to 50 MON objects per base system.
2 Define monitor numbers for each application, by setting the APLn:BMO attribute
to -1 using freely chosen monitor numbers as indexes.
ABB Automation 65
9 Operator Workstations Configuration Manual
Example:
APL1:BMO(1..5) = (-1,-1,-1,-1,-1)
means that the monitor numbers 1 ... 5 can be opened to view application 1.
MON
Workstation
MON
MON
LAN
Basesystem 1 Basesystem 2
APL1 APL2 APL3 APL4
Configuration of basesystem 1: Configuration of basesystem 2:
........see figure 6-1 ........see figure 6-1
Monitors: Monitors:
#LOOP_WITH I = 1..20 #LOOP_WITH I = 1..20

#CREATE MON’I’:B = LIST(- #CREATE MON’I’:B = LIST(-
DT = "VS",- DT = "VS",-
TT = "LOCAL") TT = "LOCAL")
#LOOP_END #LOOP_END
Application 1: Application 3:
@MON_MAP(1..20) = -1 @MON_MAP(1..20) = -1
#CREATE APL:V = LIST(- #CREATE APL:V = LIST(-
.....see figure 6-1 .....see figure 6-1
MO = %MON_MAP MO = %MON_MAP
.... ....
#CREATE APL1:B = %APL #CREATE APL3:B = %APL
Application 2: Application 4:
@MON_MAP(1..20) = -1 @MON_MAP(1..20) = -1
#CREATE APL:V = LIST(- #CREATE APL:V = LIST(-
.....see figure 6-1 .....see figure 6-1
MO = %MON_MAP MO = %MON_MAP
.... ....
#CREATE APL2:B = %APL #CREATE APL4:B = %APL
Figure 15. An example of a workstation that is connected to two base systems and
four applications
66 ABB Automation
Configuration Manual 10 Peripherals
10 Peripherals
This chapter describes how to configure MicroSCADA for various peripheral equip-
ment:
10.1 Printers: printers connected to a base system computer, to LAN and to a

NET.
10.2 Other peripherals: alarm units and external clocks.
10.1 Printers
This section describes the configuration of printers used by MicroSCADA applica-

tions - printers for automatic continuous event and alarm printout, for hardcopy of
MicroSCADA pictures, for printout of picture based reports, etc. For hardcopy, the
hardcopy functions of eXceed or Windows NT can be used without any configuration
measures in MicroSCADA.
A MicroSCADA printer can be connected as follows:

• Directly to a base system computer or another Windows NT computer on the
network, through the parallel port or a serial port.
• To a LAN via a printer server.
• To a DCP - NET.
Printers connected to a NET can be made accessible to all base systems in the entire
distributed MicroSCADA system. A printer connected directly to a base system can
also be used by other base systems on the LAN, provided that the printer is defined as
“shared” in the operating system configuration of the computer to which it is directly
connected. Printers connected to a LAN can be made accessible to all base systems on
the LAN.
On the application level, the printing can be accomplished according to two different
principles which determines the appearance of the printout:
• Semi-graphic picture based printing.
• Full graphic SCIL defined printing ("transparent" printing).
The full-graphic printout may contain any characters supported by the printer. The
last mentioned type is specified by the SCIL function PRINT_TRANSPARENT.
The semi-graphic printout may be of three types:

• Black-and-white, character-based printout.
• Black-and-white, pixel-based printout.
• Color, pixel-based printout.
The picture based printout produced by printers connected to a Windows NT com-
puter or a LAN is always semi-graphic. Pixel based printout can be obtained only on
ABB Automation 67
10 Peripherals Configuration Manual
printers connected to a NET. The “transparent” printout can be obtained on any print-
ers.
Each base system and each application is able to recognize and use up to 20 printers.
It is possible to configure “virtual printers” without real physical correspondence for
logging in a file on disk. When a printer is defined for printer logging, all printout
sent to the printer is stored on disk. This is useful when configuring an "event log",
i.e., a disk copy of the event list, see section 13.5. A physical printer may also be
given more than one printer object definitions to enable several different types of
printout to the same printer.
The printer operation can be supervised and controlled, e.g. temporarily stopped and
restarted, or the printout can be redirected to another printer, by means of the ST and
CL attributes, see System Objects, section 10.2.
Printers Connected to a Windows NT Computer or LAN

Printers connected to a base system computer or LAN must be configured in all base
systems that will use the printers, see the example in Figure 17. Configure the printer
in each base system as follows:
1 Create a PRIn:B base system object, with at least the following attributes (see
System Objects, section 12.6.):
DT “NORMAL” (black-and-white ASCII based printout) or

“TRANSPARENT” (SCIL defined printout)
DC “LINE”
SD Printer device name including UNC path
(SD="\\My_Computer\My_printer"). The printer must be
shared for the UNC name to be a valid value of the attribute.
TT "LOCAL”
In addition, optional features are defined by the following attributes:
LP Lines per page, this should be > = the number set on the
printer
QM Printer queue length
OD Output destination: "PRINTER", "LOG" (disk files) or
"BOTH”
LD, LL, LF Printer log attributes, specify the management of log files
The attributes are meaningful if OD = "LOG" or "BOTH”
OJ Open on Job Basis, set value to 1
The printer is opened before each print job and closed when
the job is completed
2 If needed, map the printer for an application with the APLn:BPR attribute, see the
headline "Device Mapping" in section 5.1. The printer mapping is required only if
68 ABB Automation
you want to use a logical printer number, which is other than the printer object
number.
Only the printers mapped with the logical printer numbers 1 ... 15 can be used as
alarm and event printers; printer 15 is reserved for event lists.
Figure 16. An example of a configuration where a printer is connected directly to a

base system
Printers Connected to NETs

A printer connected to a NET can be used by all base systems connected to the same
network of frontends. The printer must be defined both in the base systems which will
use it and in the NET unit to which it is directly connected, see the example in Figure
17. It is here assumed that the NET unit has been defined to the base system as a
NODn:B object.
ABB Automation 69
Include the following definitions in each base system which will use the printer:
1 Create a PRIn:B base system object with at least the following attributes:
TT “LOCAL”
ND The node number of the NET unit to which the printer is
directly connected
TN The device number of the printer in the NET unit to
which it is directly connected
DT "COLOR", "NORMAL", or "TRANSPARENT"
Select "NORMAL", if the printer will be used exclu-
sively for black-and-white character-based printout.
Select "COLOR" for all other types of picture based
printout. Even if the printout will be black-and-white,
"COLOR" is preferable as this mode provides a more
picture resembling printout by exchanging graphical
characters to printer specific characters.
Select "TRANSPARENT", if the printout will be SCIL
defined.
DC “NET”
In addition, optional features are defined by the following attributes:

LP Lines per page
QM Queue length maximum
OD Output destination: "PRINTER", "LOG" (disk files) or
"BOTH”
LD, LL, LF Printer log attributes, specify the management of log files
The attributes are meaningful if OD = "LOG" or
"BOTH”
For more information on the attributes of the PRI object, see the System Objects
manual, section 10.2.
2 If needed, map the printer for an application with the APLn:BPR attribute, see the
headline "Device Mapping" in section 5.1. The printer mapping is required only if
you want to use a logical printer number which is another than the printer object
number.
Only the printers mapped with the logical printer numbers 1 ... 15 can be used as
alarm and event printers; printer 15 is reserved for event lists.
70 ABB Automation
Include the following definitions in the NET unit to which the printer is directly con-
nected:
Figure 17. The configuration of a printer connected to the process communication

system
ABB Automation 71
3 Select a line for the printer and define the line with the ASCII protocol:
PO 4
IU 1
LT 0
MS, MI System message handling, see Chapter 15
PS Buffer pool sizes, see section 8.1
BR Baud rate (rec. 2400)
PY 0
RD 8
SB 1
TD 8
OS Output synchronisation, see System Objects manual,
chapter 13
4 Define a printer (a PRI object) on the selected printer line with the attributes:
LI The number of the selected line

IU 1
MI, MS System message handling, see section 13.1
AL, AS 0 (the printer reservation is handled automatically by the
base system
PT Printer type
1 = Character-based, black-and-white
2 = "transparent"
3 = Pixel based, black-and-white
5 = Character-based, black-and-white, graphical
characters replaced by printer characters
6 = Facit 4544
7 = Pixel-based, color
For more information on the attributes of the PRI object, see the System Objects
manual, Chapters 12 and 15.
In some cases, the printout from a printer connected to frontends can be improved
with some system object attributes. These attributes can be applied during operation,
not in the reconfiguration:
• If the printer is color and pixel based, the colors can be converted from screen
colors to printer colors with the PRIn:SCC attribute.
• If the printer is of type 5 (PT = 5), the MicroSCADA characters can be exchanged
to appropriate printer characters by means of the PRIn:SCT attribute.
• For pixel printers, each character can be specified separately by a bit pattern with
the PRIn:SPX attribute.
72 ABB Automation
The three attributes mentioned can be found in System Objects manual, Chapter 15.
When a base system is started, its default application (the application created first in
SYS_BASCON.COM) sends a message to the printers (form feed). Therefore, make
sure that these applications are defined in the NETs.
10.2 Other Peripherals
Alarm Units
To use an alarm unit for audio-visual alarms:
1 Set the SYS:BAA attribute in the base system configuration to any value <> 0, e.g.
1.
Example:
#CREATE SYS:V.......
#SET SYS:BAA = 1
.......
2 Set the SYS:BAD attribute in the base system configuration to be either “NUDAQ
PCI-7250” or “Advantech PCI-1760”. This attribute is necessary only for the PCI
based alarm panel, when using the ISA based panel, it can be omitted. For more
information about the SYS:BAA and SYS:BAD attributes see Chapter 4 in the
System Objects manual.
The alarm unit works only for process objects with a logical printer connection (de-
fined in the process database, see Application Objects manual, Chapter 3).
The following executable can be applied when alarm unit is used.
AUDIO_SET ALARM_CLASS [on | off]
Enables setting alarms on or off manually when using the ISA based Flytech card and
the compatible alarm panel.
'alarm_class' The number of alarm class. Integer expression, 1 … 7, or all
'on | off' Alarm(s) can be set on or off and if neither of these values is
given, alarm(s) will be set off by default
Audio_set can be called using ops_call, ops_process or it can be called directly from
the command line (or called from batch file). The caller receives a return value from
ABB Automation 73
audio_set, which can be used to determine whether the command was successful or
not. Return value 0 means that the execution was successful and any other value
means that an error happened during the execution. When audio_set is run from the
command line, possible error messages are shown in the workstation. These are of
course not seen if ops_call or ops_process are used.
The user should notice that when ops_call and ops_process are used, the commands
should be given so that they wait that the execution of audio_set is finished. If they do
not wait, they cannot get the return value returned by audio_set. More details from
using these SCIL commands can be found from "Programming Language SCIL" man-
ual. The user should also notice that when audio_set is used from the command line,
the user should take care of the return value of audio_set (it cannot be seen automati-
cally).
Examples:
; Set alarm 1 on from SCIL
@a = ops_call("c:\sc\prog\exec\audio_set 1 on")
; Set all alarms off from SCIL

@a = ops_process("c:\sc\prog\exec\audio_set.exe all off", "", "wait")
; This is given from the command line and it sets alarm 1 off
audio_set 1
External Clocks
To use a Meinberg PC31 radio clock in the base system:
1 Set the SYS:BCL attribute to "PC31" and the CA attribute to any value <> 0, e.g.
1.
Example:
#CREATE SYS:V
.......
#SET SYS:BCL = "PC31"
#SET SYS:BCA = 1
.......
To connect an external clock to a communication frontend:
2 Specify the following parameters in the MFLCONF.DAT file (see section 4.2):
COMAG 1 (use COM port 1)

CLOCK The type of the clock
Serial communication parameters: BR, COM, EN, ER, NA, PY, RE, TI.
To connect an external clock to a communication unit:
3 Define a NET line with the following attributes:
74 ABB Automation
PO 15 (General ASCII protocol)

PM 5 (Protocol mode)
SF Sync. format
1 = COMPUTIME
2 = RCC8000
ABB Automation 75
Configuration Manual 11 Configuring Stations
11 Configuring Stations
This chapter describes the general principles for configuring stations in MicroSCADA
and provides some system configuration notes related to certain station types. The
chapter contains the following sections:
11.1 General principles for configuring stations in MicroSCADA.
11.2 Configuration notes for stationes using the ANSI X3.28/A-B protocol:
SRIO, Allen Bradley PLC and SLC-500, Westronic D20, DTU, etc.
The configuration is illustrated with an example. Configuration of SRIO
from MicroSCADA: SRIO system parameters for affecting the behavior
of SRIO, e.g., the spontaneous transmission of data, polling interval and
data format, and SRIO object parameters for the definition and
modification of SRIO objects. The description is valid also for SPSC500,
though this station type is mentioned only where it differs from SRIO.
11.3 Configuration notes related to S.P.I.D.E.R. RTUs. The configuration of

MicroSCADA for S.P.I.D.E.R. RTU 200: base system configuration and
NET unit configuration. The configuration is illustrated with an example.
Building the RTU configuration files for use in MicroSCADA and for
transfer to the RTUs via MicroSCADA.
11.4 Stations in the LONWORKS network; Stations supported by the System

Configuration Tool and protocols supported by the PC-NET; Configuring
the LONWORKS network.
11.1 General Principles
Please note, that the following instructions are not valid when using the System Con-
figuration Tool, which is decribed in chapter 14.
Stations
All process devices that will exchange information with MicroSCADA are regarded
as stations and must be defined as station objects both in the process communication
system (NETs) and in the base systems. The concept station comprises RTUs, PLCs
and bay units of various types. It also comprises procol converters and control centres
which are connected to the NET for data transfer between MicroSCADA and external
devices. However, it does not comprise e.g. the star couplers situated in the
LONWORKS network, as they have no direct data communication with MicroSCADA.
This section presents the general configuration reuquirements for connecting stations
to MicroSCADA.
ABB Automation 77
11 Configuring Stations Configuration Manual

Connecting a station to the MicroSCADA network requires the following definitions
in the base system that will use the station (see the example in Figure 19):
1 Create a STAn:B (n = 1 ... 2000) object with the following attributes:

ND The node number of the NET unit to which the station is di-
rectly connected
ST The station type
TN STA object number in the communication unit
TT "EXTERNAL"
The STAn:B object definition is not necessary if the default station type, defined by
SYS:BDS, is the station type in question and the default node, defined by SYS:BDN,
is the NET unit to which the station is connected and mapping of the stations is direct
(1-1, 2-2 etc.). It is however always recommended that the object definition is made.
2 If needed, map the station for the application which will use it with the APLn:BST
attribute. Station mapping is necessary only if the logical number will be another
than the STAn:B object number, which is the default mapping. The logical station
number is the Unit Number (the UN attribute) of the process objects defined for
the station. See the System Objects manual, chapter five.
Perform the configuration definitions described below in the communication unit to
which the station is directly connected. The station address (SA for the others and SX
for ANSI X3.28 stations) of this unit should be the same as the "destination address"
defined in the station. It is assumed that the NET unit has been defined to the base
system as a NODn:B object, and that the base system has been defined to the NET
unit as an external node, see chapter 8. Define the station to the NET unit as follows
(see the example in Figure 19):
1 Select a line for the station and define it with the protocol that will be used on the
line:
PO Number of line protocol
If the NET is a PC-NET, the COM ports (1...4) or the “RocketPort” ports (1...8) (NET
lines 1...4 and 1 ... 8) can be used for process communication using the SPA, IEC870-
5-101 master and slave, IEC870-5-103 master, IEC1107, ADLP80 slave, RP570 mas-
ter and slave, RP571 master and LCU 500 protocols. When assigning one of the lines
1 ... 8 any of these protocols, the lines will be reserved for process communication.
The used NET line number cannot be used for LONWORKS communication.
2 Depending on the protocol, assign the line appropriate attributes.

3 Define the station of the type in question and assign it desired attributes.
4 Make sure that the application which will receive the spontaneous messages from
the station (the station attribute AS) is defined as an APL object. See chapter eight.
78 ABB Automation
11.2 Stations Using ANSI X3.28 Protocol
11.2.1 MicroSCADA Configuration

Connecting a station using the ANSI X3.28 protocol (ANSI station) to the Micro-
SCADA network requires the following definitions in the base system which will use
the station (see the example in Figure 19):
Create a STAn:B (n = 1 ... 2000) object with the following attributes:

ND The node number of the NET unit to which the station is di-
rectly connected
ST "STA"
TN STA object number in the NET unit
TT "EXTERNAL"
The STAn:B object definition is not necessary if the default station type, defined by
SYS:BDS, is "STA" and the default node, defined by SYS:BDN, is the NET unit to
which the station is connected and the mapping is direct.
If needed, map the station for the application which will use it with the APLn:BST
attribute. Station mapping is necessary only if the logical number will be another than
the STAn:B object number, which is the default mapping. The logical station number
is the Unit Number (the UN attribute) of the process objects defined for the station
(System Objects manual, section 15.2).

Perform the configuration definitions described below in the communication unit to
which the station is directly connected. The SX attribute of this unit should be the
same as the "destination address" defined in the ANSI station. It is assumed that the
NET unit has been defined to the base system as a NODn:B object, and that the base
system has been defined to the NET unit as an external node, see chapter eight.
Define the station to the NET unit as follows (see the example in Figure 19):
1 Select a line for the station and define it with the ANSI X3.28 full duplex (possible
for communication with Allen-Bradley, Westronic, SRIO) or half duplex protocol:
If ANSI X3.28 full duplex is used:
PO 1
LT 0 (RS232), 1 (modem line), 6 or 7
IU 1
EN Enquiry limit
TI Timeout length in seconds
ER Embedded response, see section 4.2.4 in System Objects
manual
ABB Automation 79
NA NAK limit
If ANSI Half Duplex is used:

PO 2
LT 0 (RS232), 1 (modem line), 2, 3, 4, 6, 7 or 8
IU 1
TI Timeout length in seconds: 1 + 2400/BR
EN Enquiry limit (max. number of retries): the product
TI * EN must be << the RT attribute of the station, see be-
low
RE Redundancy
0 = None
1 = CRC
2 = BCC
DE CTS delay, see Figure 18
HT Header Timeout
Default = 700 msec
PD Extra poll delay
Decreases the load on NET, but can be set to 0
PP Polling Period
Regulates the polling frequency of operating stations related
to suspended stations. Note that each polling of a suspended
station is likely to cause a timeout on the line.
RK RTS Keep up padding characters, see Figure 18
Necessary with some modems
RP Reply poll count
The following attributes apply to both ANSI X3.28 Full and Half Duplex:
BR Baud Rate
This must be the same as the baud rateset in the station
PY Parity
0 = None
1 = Odd
2 = Even
This must be the same as the parity in the station
RD 8
SB 1
TD 8
RE Redundancy (0 = None, 1 = CRC, 2 = BCC)
80 ABB Automation
3 Define a station of type STA connected to the ANSI line:
Device type: STA or 3
LI Selected line
AL 1
AS The number of the connected application
IU 1
MI System message identification; use as a process
object address, see section 13.1
SA ANSI station address = the address given in the station
DE Type of diagnostic commands (0 = none)
DI Diagnostic interval in seconds
FS Type of commands allowed during suspension (0 = none)
RT Reply timeout in seconds
SP Message split, see below
ST 1 for all types except for SLC-500 which is = 4
SU Suspension time in seconds
If more stations are connected to the same line, they are defined in the same way and
with the same line number.
4 Define the memory areas in the NET unit and Message Split if needed, see
"Memory Area Definition" and "Message Split" below. In the preconfiguration,
these features are found under the "Memory Rung", where up to 80 memory areas
can be defined. If the preconfiguration tool is used, the memory area definitions of
a STA can be collectively copied to other STAs and then possibly edited. If there
are many stations, the memory area definitions are most conveniently added on-
line with SCIL command procedures using the MR or MC attributes, see the
example in Figure 19 and the System Objects manual, section 4.3.6. By means of
the MC attribute the memory area definitions can be copied collectively on-line
from a station to another.
The SX attribute of the NET must be given as the destination address for spontane-
ous messages in the station configuration.
ABB Automation 81
Figure 18. Illustrations of some ANSI line attributes
Memory Area Definitions

The internal protocol used in the communication between base systems and NET dif-
fers from the protocol used in the communication between NET and the stations. Of-
ten, the data related to different memory areas of a station must be coded in different
ways (e.g., some 4-digit BCD, some 16-bit words). The Allen-Bradley / ANSI X3.28
protocol does not include this coding information in the commands. Therefore, NET
needs the memory area definitions to know how to handle a certain message data.
Each memory area is identified by a number, 1 ... 30, and defined by the following at-
tributes (System Objects, section 4.3.6):
DT Data type of the area
AD Start address of the area
82 ABB Automation
LE Length of the area

CO Data coding
AT The write access to the area
BF Block format
TS Time stamping
SP Split destination, see below
The required memory area definitions depend on the station type. Table 2 shows the
memory area definitions needed for the SRIO communication. If any SRIO feature is
not used, the corresponding area may be omitted. Sequential BI and BO areas may be
combined into a BO-area, and correspondingly sequential AI and AO areas may be
combined into AO areas, if the same coding can be used. NET allows reading the out-
put areas, but not writing to the input areas. Analog access to binary areas is allowed,
but not bit access to analog areas. The diagnostic counters (start address 4704 octal,
length 26 words) need not be defined as a separate memory area, because it is always
possible to read 16-bit analog values outside the memory areas.
For SRIO 1000M (V6.0 or newer) the EV data must be defined as a separate memory
area. The recommended start address for this area is 750 decimal. Thus the DO area is
shorter than in SPSC 500M.
Example
Figure 19 shows an example of an ANSI station connected to line 1 of NET3. The ta-
ble below lists the configuration of the NET and the base system.
Figure 19. An example of a configuration with a base system connected to a station

using the ANSI X3.28 Full Duplex protocol
ABB Automation 83
Table 1. Communication unit configuration (Stations Using ANSI X3.28 Protocol)

Line 1
PO Protocol: 1
IU In Use: 1
LT Link Type: 0
BR Baud Rate: 9600
SB Stop Bits: 1
PY Parity: 2
RE Redundancy: 2
NA NAK Limit: 3
EN ENQ Limit: 3
Process Unit 4/20
Device Type: STA
Physical Device Number: 4
LI Line Number: 1
AL Allocation: 1
AS Allocating Application 5
SA Station Addr. (Dec) 72
DE Diagnostic Enable: 0
DI Diagnostic Interval 0
FS Fast Sel. to Susp.: 0
RT Reply Timeout: 20
SP Message Split: 0

#CREATE STA:V = LIST(-
ST = “STA”,-
ND = 3,-
TN = 4,-
TT = “EXTERNAL”)
#CREATE STA:B = %STA
Online Definition of a Memory Area

#SET STA4:SIU = 0 ;Taking the station out of use
#SET STA4:SMR6 = “CBI” ;Memory area 6 is BI type
#SET STA4:SAS6 = 400^ ;and starts from address 400 octal
#SET STA4:SLE6 = 16 ;The length of the area
#SET STA4:SIU = 1 ;Taking the station into use
Deleting Memory Area

#SET STA4:SIU = 0
#SET STA4:SMR6 = “D”
84 ABB Automation
Table 2. The memory area definitions needed for SRIO and SPSC500
Area Type, Address, AD Lengt Cod- Access Bloc Time
No. DT h, LE ing , AT k, BF Stamping
, CO , TS
Dec oct
Areas for transfer of process data:

1. 2 (BO) 0 0 750 3 0 1 0
2. 4 (AO) 1000 1750 1000 4 0 1 0
Area for event recording:
3. 3 (AI) 2400 4540 4 4 0 1 1
Area for transfer of parameter data:
4. 4 (AO) 2000 3720 168 10 0 1 0
Area for setting the clock:
5. 4 (AO) 2300 4374 9 5 0 1 0
System parameters areas:
6. 4 (AO) 3000 5670 6 3 0 1 0
Object parameters areas:
7. 4 (AO) 5000 1161 5500 3 0 1 0
0
8. 4 (AO) 10500 2440 1000 4 0 1 0
4
9. 4 (AO) 11500 2635 2700 3 0 1 0
4
10. 3 (AI) 750 1356 250 3 0 1 1
For SPSC500, differing from the above, the first memory area is defined:
1. 2 (BO) 0 0 1000 3 0 1 0
Memory area 10 is not used in SPSC500.
Message Split
It is often desired that spontaneous messages from the process stations are sent to sev-
eral applications in one or several base systems. This can be established with the
Message Split feature. Message Split means that a copy of the message is sent not
only to the application defined by the AS attribute, but also to other applications. The
message split feature is memory area specific, i.e., the feature must be defined indi-
vidually for each memory area.
Message Split concerns exclusively the spontaneous messages from the stations. It
does not cause the copying of responses to read messages. Thus, if the Micro-
SCADA databases are continuously updated by getting the data from the stations
(with the #GET command), there is no use with Message Split.
In these cases, each application must get the data from the stations or read it from an-
other application (communicating applications, see section 5.2).
In order to activate Message Split:
1 Make sure that all applications to which the spontaneous messages will be sent
have been defined in the NET unit by APL objects, see chapter eight.
ABB Automation 85
2 Set the SP attribute of the station to 1, 2 or 3, see System Objects, section 14.3.7.
Select receiving applications (up to five) by setting the SL attribute for the memory
area to the desired application numbers. In the preconfiguration the SL attribute is
given as a number of five digits. Therefore, only applications number 1 ... 9 can be
selected as receiving applications. In order to set the attribute on-line with SCIL, see
System Objects, section 14.3.7 and the example below. In the preconfiguration, the
SL attribute is found under "Memory Rung".
Example
Taking Message Split into use on-line:
#SET STA2:SSP=2
#SET STA2:SSL101=2050
#SET STA2:SSL303=2049
The SPLIT function is activated. An error message is produced if the base system de-
fined in the station does not answer. The messages connected to memory area 1 are
sent also to APL2. Messages connected to memory area 3 are sent also to APL1.
11.2.2 SRIO Configuration
SRIO System Parameters

By changing the SRIO 1000M system parameter values, the application programmer
can affect general features of the SRIO 1000M program. The system parameters are
located in the address area from 3000 upwards.
Below are some examples of system parameters, each of which occupies one word.
For further information about SRIO system parameters, refer to the SRIO manuals.
Word 0 (address 3001): Spontaneous event data transmission
1 = Enabled
0 = Disabled
Word 1 (address 3002): Spontaneous transmission of changed data in

database
1 = Enabled
0 = Disabled
Word 2 (address 3003): Store command
1 = Start storing the configuration data into EEROM
0 = No meaning
86 ABB Automation
Word 3 (address 3004): Analog data format
0 = 32 bit integer
1 = 3-digit BCD
2 = 6-digit BCD
Word 4 (address 3005): Analog data scaling
1, 10, 100, 1000 (default) or 10000
Word 5 (address 3006): Time polling interval
30 .. 30000 seconds (default = 60 s)
Examples:
#SET STA1:SME3001=0
Disable spontaneous process data transmission
#SET STA1:SME3002=1
Store SRIO 1000M configuration data into EEROM memory
#SET STA1:SME3003=1
Analog values to be coded as 3-digit BCD numbers
SRIO Object Parameters

The SRIO object parameters allow the MicroSCADA applications to read and write
the definitions of data items, data groups and event data polling.
The start address of object parameters is 5000 in the default configuration. SRIO can
contain up to 500 objects.
For each data item the following attributes are defined (start address means the start
address within the object parameter area, i.e. add 5000 to each address):
Attribute Start address
ANSI address 0
Busnumber 500
SPACOM address 1500
Data type / format 4500
Delta value / bit mask (32 bits) 5500
Status word (16 bits) 6500
ABB Automation 87
Example
A SCIL command procedure for the creation of an AI type SRIO object:
Defining Variables:
@OBJ_IND ;Object nr (index) in the SRIO database
@ANSI_A ;Object address in the MIcroSCADA database
@BUS ;Bus number
@SPA_A ;SPA address as a 6 word vector (see the SRIO manuals)
@DTYPE ;Data type
@DFORM ;Data format
@DELTA ;Delta value
@STATUS ;Status word as an integer
Defining Constants:
@OB_PAR_I=5000
@ANSI_A_I=%OB_PAR_I
@BUS_I=%OB_PAR_I+500
@SPA_A_I=%OB_PAR_I+1500
@DATA_T_F_I=%OB_PAR_I+4500
@DELTA_I=%OB_PAR_I+5500
@STATUS_I=%OB_PAR_I+6500
Creating Object:
#SET STA1:SME(%ANSI_A_I+%OBJ_IND)=%ANSI_A
#SET STA1:SME(%BUS_I+%OBJ_IND)=%BUS
@SPA_STADR=%SPA_A_I+6*%OBJ_IND
#SET STA1:SME(%SPA_STADR..(%SPA_STADR+5))=%SPA_A
@D_T_F_ADR=%DATA_T_F_I+2*%OBJ_IND
@DATA_T_F(1)=%DTYPE
@DATA_T_F(2)=%DFORM
#SET STA1:SME(%D_T_F_ADR..(%D_T_F_ADR + 1))=%DATA_T_F (1..2)
@DELTA_S_A=%DELTA_I+2*%OBJ_IND ;32-BIT ADDRESS
#SET STA1:SME(%DELTA_S_A)=%DELTA
#SET STA1:SME(%STATUS_I+%OBJ_IND)=%STATUS
A data group may consist of 10 data items, and there may be up to 100 data groups.
The data group definition tells the ordinal numbers of the data items in the group. The
data group definitions are found from the address (7000 + object parameter area start
address). Above is an example of a SCIL command procedure which defines a data
group.
The event data polling may comprise up to 300 SPA bus slave units (100 slaves/bus).
In the address range starting from 8000 + object parameter area start address. The
following features of each object to be event polled are defined:
• Bus number.
• Unit number.
• Unit type.
• Status.
88 ABB Automation
Examples:
Creating a SRIO Data Group with SCIL
Defining variables:
@GROUPNR ;Number of the group to be created
@MEMBERS ;Vector containing the ordinal numbers of the group members in the
;SRIO 1000M database.
Defining Constants:
@GROUPDEFSA=12000
@GROUPLEN=10
Creating the data group:

@MEMBCOUNT=LENGTH(%MEMBERS)
@STARTADR=%GROUPDEFSA+%GROUPNR*%GROUPLEN
@ENDADR=@STARTADR+%MEMBCOUNT-1
#SET STA1:SME(%STARTADR..%ENDADR)=%MEMBERS
Adding a SRIO Object to the Event Data Poll List
Variables:
@ENTRYNR ;Nr of the event data poll list entry
@DEF ;@DEF(1)=%BUS
;@DEF(2)=%UNIT_NR
;@DEF(3)=%UNIT_TYPE
;@DEF(4)=%STATUS
Adding the object:

@EP_S_I=13000
@STADR=%EP_S_I+%ENTRY_NR*4
#SET STA1:SME(%STADR .. %STADR+3)=%DEF(1..4)
11.3 S.P.I.D.E.R. and Collector RTUs
11.3.1 MicroSCADA Configuration

Connecting a S.P.I.D.E.R. RTU to a MicroSCADA network requires the following
definitions in the base system which will use the station:
1 Create a STAn:B object with the following attributes:

ND The node number of the NET unit to which the RTU
is directly connected
ST "RTU"
TN Corresponding STA object number in the communi-
cation unit
TT "EXTERNAL"
For more information on the attributes, see the System Objects manual, section 14.4.
ABB Automation 89
The STAn:B object definition is not necessary if the default station type defined by
SYS:BDS is "RTU" and the default node defined by SYS:BDN is the NET unit to
which the RTU is connected and the mapping is direct. However, if no STAn:B object
is defined, the station can not be handled by the MicroSCADA tool pictures.
2 If needed, map the station for the application which will use it with the APLn:BST
attribute. Station mapping is necessary only if the logical number will be another
than the STAn:B object number, which is the default mapping. The logical station
number is the Unit Number (the UN attribute) of the process objects defined for
the station. (System Objects, chapter five).
Perform the configuration definitions described below in the NET unit to which the
station is directly connected. It is assumed that the NET unit has been defined to the
base system as a NODn:B object, and that the base system has been defined to the
NET unit as an external node, see chapter eight.
1 Select a line for the station (several RTUs can be connected to the same line) and
define it with the RP570 protocol:
PO 7
LT 0 (RS232) or 1 (modem line)
IU 1
MS The application receiving system messages
MI The object receiving system messages, see section 13.1
BR Baud rate, should be the same as in the RTU
PY 2
RD 8
TD 8
SB 1
DE CTS delay in milliseconds
EN Enquiry limit time in milliseconds
PD Poll delay in milliseconds
PP Polling of suspended stations
RP Number of consecutive polls
TI Timeout length in seconds
HT Timeout in milliseconds for start of response
reception (default = 700 ms)
RI Time delay in milliseconds before enabling a line
after a message. Default = 0. A time delay must be
used if NET’s transmission echoes back into the receiver.
90 ABB Automation
RK RTS keep up padding characters, see System Object manual,

section 13.4
3 Define a station of type RTU connected to the RP570 line:
Device type = 4
LI Selected line number
AL 1
AS The number of the connected application
MS The application receiving system message
MI The object receiving system messages, see section
13.1
SA RP570 station address (= the address in the RTU)
RT Reply timeout in seconds
If several stations are connected to the same line, define the stations with the same
line number (LI).
The NET unit will recognise an automatically created "station", STA0, as "broadcast
station". The broadcast station notates all S.P.I.D.E.R. RTUs connected to the same
NET.
Regarding communication loops, see section 12.3.
The following RTU200 features must be handled on-line:
4 Synchronize the RTU200 clock with the clock of the NET unit at start-up by
setting the SY attribute, e.g. #SET STAn:SSY (supposing that the NET clock has
been synchronized before). By using the broadcast station number, all RTUs
connected to one NET can be synchronized simultaneously.
5 If needed, change the AW attribute of the RP570 line, see the System Objects
manual, section 13.5. This is normally not necessary.
Sub-RTUs
MicroSCADA revision beginning with 8.2B supports the configuration of hierarchical

RTU structures. Define the sub-RTUs as STA objects in NET and in the base system,
in the same manner as an RTU connected directly to NET as described in the manual.
The only difference between the directly connected RTUs and sub-RTUs is the
STAn:SHR attribute, see the System Objects manual, section 14.4.1 For STA objects
corresponding to sub-RTUs, the HR attribute is the station address of the RTU one
level above in the hierarchy.
Protection Relay Data

The data of ERMFD and ERMIR telegrams is converted into bit stream values, which
are sent to the process database.
ABB Automation 91
In order to register the data in the process database, define bit stream type process
objects with the following object addresses:
For ERMFD : 2304 + block nr
For ERMIR : 1792 + block nr
ERMFD data coding in process object :
Bit stream object value:
Bytes 1..4: VALUE (least sign. byte first)
Byte 5 : STATUS with time quality etc., copied from RP570 telegram
Bytes 6..7: RELATIVE TIME (least sign. byte first)
Bytes 8..9: NUMBER (least sign. byte first)
Byte 10: CAUSE OF TRANSMISSION
Byte 11: FORMAT
Registration time: Stored in RT attribute as normal
ERMIR data coding in process object :
Bit stream object value:
Byte 1: VALUE (least sign. byte first)
Byte 2 : BIT NUMBER
Byte 3 : INDICATION TYPE
Bbyte 4 : STATUS with time quality etc., copied from RP570 telegram
Bytes 5..6 : RELATIVE TIME (least sign. byte first)
Bytes 7..8 : NUMBER (least sign. byte first)
Byte 9 : CAUSE OF TRANSMISSION
Registration time : Stored in RT attribute as normal
The coding of each field, when not explicitly described above, follows the RP570
telegram.
92 ABB Automation
11.3.2 RTU Configuration
Procedure
The RTU configuration can be performed independently of MicroSCADA, which
means that the MicroSCADA process object definition is built separately with no help
from the RTU configuration files. Alternatively, the RTU configuration can be built
via MicroSCADA, which means that the MicroSCADA engineer can utilise the con-
figuration in the process object definitions. Changes in the MicroSCADA process
database can then be loaded down to the RTUs.
The latter configuration method, which is recommended, is performed in the follow-

ing steps (see Figure 19):
• RTU configuration tool for RTU engineering, the EDU (Engineering and Diag-
nostic Unit) tool. The RTU configuration is stored in keyed files. When using
EDU, a file conversion is required.
• Defining the process database objects in the MicroSCADA system using the key
files.
• Loading down the complete configuration, including possible changes made in
the MicroSCADA process database, to the RTU.
Loading the RTU Configuraiton

If your RTU is connected, you can now load the configuration, or you can use the
process definition tool to make changes in the definitions.
The loading is performed in the RTU tool picture:
1 Select OTHER CHOICES.

2 Select DOWNLOAD.
3 Click START to start the loading.
11.4 Stations in the LONWORKS Network
The MicroSCADA base system communicates with a LONWORKS device through the
PC-NET and a LONWORKS network interface card. The interface card can be a
PCLTA card, for example. PC-NET is a communication software, that runs on the
main processor of a Windows NT computer in parallel with the base system. As
communication channels, the PC-NET software may utilise the serial line COM ports
of the PC and the optical lines of the PCLTA card.
Station Types
MicroSCADA recognizes the following station types in the LONWORKS network:
REx A REx station is a unit communicating with MicroSCADA with

vertical communication as defined in LON Applications Guide-
lines (e.g. REF 543 protection terminal)
ABB Automation 93
SPA A SPA station is a SPACOM module connected to the LONWORKS

network via a protocol converter (i.e.an LSG device)
LMK An LMK station comprises all types of devices, except SPA and
REx devices, connected to the LONWORKS network using the stan-
dard LONWORKS interface (e.g. an LSG device or a Weidmüller I/O
device)
Protocols Supported by the PC-NET
PC-NET supports the following protocols:

• ACP (the MicroSCADA internal protocol).
• LonTalk.
• SPA.
• IEC 870-5-101 master and slave.
• IEC 870-5-103 master.
• IEC 1107.
• RP570 master and slave.
• RP571 master.
• ADLP80 slave.
• LCU 500.
Configuring the LONWORKS Network
To enable communication between MicroSCADA and a station in the LONWORKS

network you must:
• Configure the device.
• Configure the LONWORKS network.
• Configure the PC-NET.
• Configure the MicroSCADA base system.
On MicroSCADA point of view the configuration is done with the System Configu-
ration Tool, which is described in chapter 14. The manual Connecting LONWORKS
Devices to MicroSCADA gives more profound information on the configuration
work.
For device configuration, please refer to the specific device configuration manuals
and the LNT 505 manuals.
94 ABB Automation
Configuration Manual 12 Redundancy Configurations
12 Redundancy Configurations
This chapter describes three special configurations which all serve the same purpose -
to raise the operation security and availability of a running MicroSCADA system:
12.1 Hot Stand-By Base Systems.
12.2 Redundant Frontends.
12.3 Communication Loops.
All three configurations can be used combined. The engineering and maintenance of
the configurations are facilitated by tools and application software packages.
12.1 Hot Stand-by Base Systems
The concept ’Hot Stand-by Base systems’ means that two base system computers are
interconnected via a LAN in a redundant relationship where one or both base systems
are prepared for fast take-over at system break-down in the other base system. An ap-
plication in one base system operates as the hot application, while an identical appli-
cation in the other base system is a stand-by application. The stand-by application is
maintained by a continuous shadowing (copying) of data from the hot application.
When a fault occurs in the primary base system (the base system containing the hot
application), the shadowing application in the stand-by base system is started and
takes over all operational functions. After recovery and restart of the former primary
base system, it can either be used as stand-by base system, whereby the former stand-
by base system is the primary base system, or the base systems can be returned to
their original tasks.
During normal operation, the two base systems may function independently, each of
them running one or more applications, e.g. electrical energy distribution and district
heating. Alternatively, one base system may be reserved exclusively for stand-by
duty. Both base systems may contain several applications connected with an applica-
tion in the other base system in a shadowing relationship. In the following description,
it is for simplicity assumed that the base systems contain only one shadowing appli-
cation pair, but the same principles apply to systems with several shadowing applica-
tions.
System Architecture
Two base systems, based on the same or different hardware, are interconnected via a
LAN. The redundant base systems can share the same communication frontends, or
the communication frontends may be doubled as well.
Minimum configuration:
• Two complete base systems connected to a LAN, each including at least two ap-
plications - one main application, which is a part in the hot stand-by relation, and
ABB Automation 95
12 Redundancy Configurations Configuration Manual
one watchdog application which is dedicated for monitoring the main application
and performing a switch-over when needed.
• A LAN, TCP/IP.
• One or two communication frontends connected to the LAN.
• A standard watchdog application software package in each of the base systems.
The watchdog software package contains command procedures and data objects
for monitoring the operation and reconfiguring at switch-over.
Options:
• Printers connected via the communication frontends.
• Additional applications in both base systems.
• Operator workstations.
The most reliable Hot Stand-by configuration is obtained with stations of type
S.P.I.D.E.R. RTU and SPACOM.
Functional Description
During normal operation, the running application in the primary base system sends
continuously shadowing data to an identical application in the stand-by base system.
Shadowing means that the following data is copied from the running application to
the stand-by application:
• All updating, including deletions, on disk under the application subdirectories
(APL_, PICT, FORM, MLIB, etc.), e.g. the process and report databases, the
picture database, text files and RTU configuration files. File handling on operat-
ing system level is not copied.
• Updating of application data stored in RAM, e.g., process and report data, history
buffer and alarm buffer. Updating of cache memories, monitor states, printer
spool and execution queues are not copied.
• Last transaction number, i.e., the number of the last RP570 or SPACOM event
message transferred from NET.
The whole SYS_ folder is not shadowed. So, if customisations are done to parts that
are not shadowed, they are lost at the take over.
An update of an object, constitutes a transaction. A transaction consists of atoms

which are the smallest quantity of data modified in RAM. The primary base system
collects the transactions in a buffer. The data in the buffer is transmitted to the stand-
by system as long messages (64 kB). A transmission is performed when the oldest
transaction in the buffer has been there for a preselected time (the Shadowing Flush
Time (SF) attribute, default = 100 ms), or when the buffer is full. This means that data
is transmitted more often in situations when the databases are updated frequently.
96 ABB Automation
Besides the shadowing data messages, the hot application sends cyclically diagnostic
commands and time synchronisation commands to the stand-by application. If it re-
ceives no acknowledgement to the messages, the connection to the stand-by applica-
tion is regarded as broken, and the shadowing halts until the connection is re-
established.
The watchdog application in the stand-by base system monitors the diagnostic com-
mands and messages from the hot application, and starts an event channel if no mes-
sage nor any diagnostic command is received within a specified time. The event
channel starts a command procedure, which examines the situation and performs a
switch-over if needed.
Switch-over means that the former stand-by application is switched to hot application.
When the stand-by application is set to HOT, an event channel APL_INIT_H is
started (instead of APL_INIT_1 and 2), which may be used, e.g., for reconfigurations
and updating (e.g. updating of the last transactions on RP570 and SPA lines). As de-
part from an ordinary application start-up, no process data is copied from disk to
RAM. The watchdog application in the new primary base system tries to establish
contact with the former hot application (which is now regarded as stand-by applica-
tion) cyclically with a specified time interval. At switch-over, the full graphic work-
stations must be handled by application programs, or manually.
When the former primary computer is restarted after recovery, all files under the re-
dundant application directory are automatically deleted and the application files are
copied from the running application ("file dump"). Likewise, all application data of
the running application stored in RAM (e.g. process object data) is copied to the re-
dundant application in the recovered computer ("RAM dump"). While the RAM data
is copied, which may take some seconds depending on the application, the running
application is out of operation. The recovered computer continues as stand-by com-
puter. A new switch-over is obtained by a simulated error, e.g. by setting the primary
main application to cold.
12.1.1 Base System Configuration Procedure
1 Install the MicroSCADA Technology software as described in the Installation

manual. Do this for both base systems.
2 Edit the SYS_BASCON.HSB template and rename it. This is described in the
section 12.1.2. Do this for both base systems.
3 Configure NET units into the communication frontend. See 12.1.3.
4 Start the base system that should have the hot application.
5 Install the watchdog software. See 12.1.4.
6 Define the external watchdog application and start the main application. See
12.1.5.
7 Repeat the steps 5 and 6 in the other base system.
8 Edit the command procedures in the watchdog applications. See 12.1.6. Do this for
both base systems.
ABB Automation 97
12.1.2 Editing SYS_BASCON.HSB
The MicroSCADA software delivery includes a version of SYS_BASCON.COM

template, SYS_BASCON.HSB, which contains all necessary configuration definitions
for Hot Stand-by. The easiest and most reliable method to build the base system con-
figuration for hot stand-by systems is to customize SYS_BASCON.HSB and rename
it to SYS_BASCON.COM. Except for the node numbers, the SYS_BASCON.COM
files of both base systems can be identical.
; File: Sys_bascon.hsb
;Desription: Standard Base system configuration file
; for Hot Stand-By systems
; Version 8.4.2
;----------------------------------------------------
@SYSTEMS = ("SYS_1","SYS_2") ;SYSTEM NODE NAMES

@THIS_IS = %SYSTEMS(1) ;IP NODE NAME OF BASE SYSTEM (SYS_1/SYS_2)
@APL_NAME = "TUTOR" ;NAME OF MAIN APPLICATION

@APL_NUMS = (1,2,3,4) ;APPLICATION NUMBERS IN THE ORDER:
;(MAIN, WATCH-DOG, ADJ MAIN, ADJ WATCH-DOG)
@NO_OF_VS = 6 ;# OF VS MONITORS
@NO_OF_X = 0 ;# OF X MONITORS
@LINKS = ("*LAN","RAM1","RAM2","INTEGRATED") ;USED LINKS INDICATED WITH PREFIX

"*"
@BS_NODES = (9,10) ;BASE SYSTEM NODES

@FE_NODES = (1,2) ;FRONT-END NODES
@FE_NODE_LINKS = (1,1) ;LINK NUMBER OF FE NODES
@NO_OF_STAS = 5 ;# OF STATIONS
@STA_TYP = "RTU" ;DEFAULT STATION TYPE
@STA_NOD = %FE_NODES(1) ;DEFAULT NODE FOR STA
@NO_OF_PRIS = 2 ;# OF PRINTERS
@PRI_TYP = "NORMAL" ;DEFAULT PRINTER TYPE
@PRI_NOD = %FE_NODES(1) ;DEFAULT NODE FOR PRI
#CASE %THIS_IS
#WHEN %SYSTEMS(1) #BLOCK
@MY_NOD = %BS_NODES(1)
@ADJACENT_NOD = %BS_NODES(2)
#BLOCK_END
#WHEN %SYSTEMS(2) #BLOCK
@MY_NOD = %BS_NODES(2)
@ADJACENT_NOD = %BS_NODES(1)
#BLOCK_END
#CASE_END
To configure the hot stand-by functionality in SYS_BASCON.HSB:
1 Edit the variables in the upper part of the file. See the SYS_BASCON.HSB file
above.
SYSTEMS System node names for both base systems in the hot stand-by
THIS_IS The node name of the base system in question. Note that this num-
ber is different in the other hot stand-by base system configuration.
APL_NAME The name of the main application. Give the main applications the
same name in both base systems.
APL_NUMS = The numbers of the main and watchdog application and the main
and watchdog applications in the partner base system
98 ABB Automation
Other variables define the used links (marked by an asterisk) and the total number of
stations. The default stations defined in SYS_BASCON.HSB are of type S.P.I.D.E.R.
RTU ("RTU") and connected to node 1.
2 Define the base system as a SYS:B object with the Shadowing attribute SH = 1.
3 If the system contains other than default types of stations, or stations connected to
other nodes edit the STA block. If there are several types of stations, or stations
connected to different nodes, copy the STA block and edit the copied block.
You may also want to check the application definitions. The configurations below are
the default values that can often be used as such.
• The local watchdog application, an APLn:B object with:
Shadowing State SS = "NONE"
Application State AS = "HOT"
• The external applications, APLn:B, for the main (partner) and watchdog applica-
tions in the redundant base system. For more information see Chapter 5.
• The main application, an APLn:B object. The following shadowing attributes are
specified:
Application State AS "COLD"
Application Mapping AP
Both the watchdog application and the external appli-
cations are mapped to the application
Monitor Mapping MO
The monitors (windows) are mapped for the applica-
tion
Shadowing Number SN
The logical application number of the shadowing ap-
plication according to the AP attribute
Shadowing Watchdog SW
The logical application number of the watchdog ap-
plication according to the AP attribute
Shadowing Flush Time SF

The maximum time interval between shadowing data
transmission
Shadowing Diagnostic Interval SI

The time interval between diagnostic commands from
the primary system to the hot stand-by
Shadowing Connection Time SC

Time-out for contact taking with the stand-by appli-
cation
Shadowing Receive Timeout SR

Time-out of the hot stand-by connection
ABB Automation 99
Time Synchronization Interval SY

Time synchronisation interval
This base system configuration means that both main applications will be COLD
when the base systems are started, only the watchdog applications are running.
The principles for the initial configuration of Hot Stand-by base systems in
SYS_BASCON.HSB are also shown in Figure 20.
Figure 20. An example of two redundant base systems
Table 3. Startup configurations for two redundant base systems. The example il-
lustrates only the attributes and parameters that are significant for hot
standby.
Configuration of base system 1: Configuration of base system 2:
Base system: Base system:
SH=1 SH=1
Application 1 (Internal): Application 1 (Internal):

NA = “TUTOR” NA = “TUTOR”
AS = “COLD” AS = “COLD”
SN = 3 SN = 3
SR = 5 SR = 5
SW = 2 SW = 2
SY = 0 SY = 0
AP = (1,2,3,4) AP = (1,2,3,4)
Application 2 (Internal, default application): Application 2 (Internal, default application):

NA = “WD” NA = “WD”
AS = “HOT” AS = “HOT”
100 ABB Automation

Application 3 (External): Application 3 (External):

NA = “ADJ_MAIN” NA = “ADJ_MAIN”
TT = “EXTERNAL” TT = “EXTERNAL”
ND = 10 ND = 9
TN = 1 TN = 1
Application 4 (External): Application 4 (External):

NA = “ADJ_WD” NA = “ADJ_WD”
TT = “EXTERNAL” TT = “EXTERNAL”
ND = 10 ND = 9
TN = 2 TN = 2
12.1.3 NET Configuration
Configure the NET units in a communication frontend as follows:
1 Define an APL object for the main application in the primary base system, see
section 8.1.
2 Define an APL object for each of the watchdog applications in both base systems,
see section 8.1.
3 Set the Message Application (MS) attribute to the APL number of the main
application and the System Message Enable (SE) attribute to 2.
12.1.4 Installing Watchdog Application
Application
The watchdog application software package handles the following procedures for all
hot stand-by applications within the base system:
• When a base system is started, it checks which main application was operating
last and sets the state of the application to "HOT_SEND".
• During the operation, it monitors the messages sent from the hot application. If no
messages are received in a specified time defined by the Shadowing Receive
Timeout (SR) attribute a switch-over is started and the stand-by application is set
to "HOT" and "HOT_SEND".
• If the hot system does not get acknowledgments from the stand-by system, it re-
gards the connection as broken, and the shadowing ceases (SS = "NONE"). The
watchdog application then checks the connection by sending commands cyclically
(with an interval of a few minutes) to the stand-by system, and starts shadowing
(SS = "HOT_SEND") when the connection has been re-established.
Installing
To install the watchdog application package:
1 Enter the Base System Configuration tool from the Tool Manager.
2 Select SYSTEM.
3 Click the OBJECT MANAGEMENT...in the SHADOWING text area.
ABB Automation 101

A window appears showing the following information:
INSTALLED PACKAGE The name and revision date of a previously installed

package
STATUS The status of the installed package, running or not

running
DISK PACKAGE The hot stand-by software package installed on disk
STATUS The status of the disk package (OK, incomplete, etc.)
4 Click on INSTALL PACKAGE FROM DISK to install the watchdog software

package.
5 Wait while the watchdog software is installed. The installation creates for example
command procedures (names beginning with SHAD, data objects and time
channels). When the installation is complete, the name and revision date of the
package appears in the INSTALLED PACKAGE field.
12.1.5 Starting the Shadowing
To define the external watchdog application and enable hot stand-by:
1 Click APPLICATIONS. The watchdog applications are shown in the middle of the
dialog that appears.
2 Click the field below the text EXTERNAL WATCH-DOG APPL, next to the
watchdog application whose pair you are about to define.
3 Type the application number of the external watchdog application.
4 Repeat the steps 2-4 if you have several watchdog applications.
5 Change the HSB field from OFF to ON for a watchdog application to enable
starting the main application.
6 Wait while the main application becomes hot.
After the HSB has been enabled for both of the watchdog applications, the file dump
and shadowing starts.
Take over should not be done before the file dump is completed.
The file dump is completed when the File dump time appears to the Shadowing dia-
log, which is opened from the Applications dialog in the Base System Configuration
tool. For more information on supervising and controlling hot stand-by systems, see
Chapter 3 in the System Management manual.
102 ABB Automation

12.1.6 Editing the Command Procedures
The watchdog application package contains command procedures, which are de-
scribed below. Following command procedures can be freely customised meanwhile
the others should not be edited. Note that while editing the command procedures the
first parts of the files should be left as they are, and the modifications are added to the
end of the file.
SHADUSR The generation of alarms and events in the following situa-
tions: when the hot stand-by transmission starts, when the
file and RAM dump is ready, when the connection is lost to
the receiver (in the stand-by system), when a takeover starts,
or when a change of state occurs in the partner application.
SHADMAPMON The shifting of monitors at takeover, e.g. mapping monitors
for the main application, or opening application windows
using the SCIL function OPS_CALL and the mons.exe
command. See the example in System Management manual,
section 2.6.
When a monitor is mapped for an application, an event
channel MON_EVENT is activated. This can also be util-
ized for registering the SD attribute of an X terminal, e.g., in
the Instruction (IN) attribute of a command procedure. At
switch-over, the SD attribute can be used for opening a win-
dow in the same terminal.
SHADMAPNET Reconfiguration of the communication units at takeover.
The following NET reconfiguration should be done at take-
over:
- Check of active NET if redundant frontends
- Redefinition of the APL object in NET corresponding to
the main application, see the example in the figure in
Chapter 14
- Retransmission of the last RP570 and SPA transactions
by writing to the NETn:SLT attribute of the NET (up to
30 transactions are stored in NET)
The reconfiguration can also be done in a command proce-
dure started by the event channel APL_INIT_H which is
executed when the stand-by application is set to HOT (in-
stead of APL_INIT_1 and 2).
SHADGOHOT Specifies whether the main application is allowed to become
HOT when a connection lost has been discovered. The
command procedure may contain a check of the error, e.g.,
if the communication disturbance is due to a communication
fault on the LAN connection to the stand-by system, no
switch over should be performed. Default: the application is
set to HOT.
SHADREMHOT Specifies whether the main application is allowed to remain
HOT when also the stand-by application is HOT. Such a
ABB Automation 103

situation may occur at a break on LAN. Default: the appli-

cation remains HOT.
SHADGLOBAL Defines some global shadowing variables, e.g. time con-
stants, the keeping of a log file on disk and log file name,
etc.
Shadusr Example
In this example the shadusr is used for programming functionality related to the event
list. The texts that should appear in the event list in the following situations transmis-
sion starts, dump done, connection lost to receiver and takeover are specified. Below
this, the texts for different state changes are specified. In the end of the command pro-
cedure different actions are specified for the hot application appearing when the state
changes and in the other events.
SHADUSR - USER DEFINED COMMAND PROCEDURE FOR GENERATING ALARMS AND

; EVENTS IN USER APPLICATION
;
; INPUT PARAMETER:
; %APL (INTEGER 1 .. MAX_APPLICATION_NUMBER,
; APPLICATION NUMBER)
; %EVENT (INTEGER:
; 1 = TRANSMISSION STARTS
; 2 = DUMP DONE
; 3 = CONNECTION LOST TO RECEIVER
; 4 = TAKEOVER
; 5 = EXTERNAL APPLICATION STATE CHANGE,
; STATE STORED IN SHADEXTAS:D(%APL),
; OS == 0 => AVAILABLE,
; OS == 10 => NOT AVAILABLE,
; OV == 0 => COLD,
; OV == 1 => WARM,
; OV == 2 => HOT)
;
;-END-ABB---------------------------------------------------------------------
; *** EVENTLIST UPDATING ***
#ERROR CONTINUE
@NODE_NRO=SYS:BND
@SYS_NAME=SYS:BNN
@APL_NM=APL’APL’:BNA
#ERROR STOP
#CASE %EVENT
#WHEN 1 @TOX ="APL ’APL_NM’ Copying is started "
#WHEN 2 @TOX ="APL ’APL_NM’ Copying is finished "
#WHEN 3 @TOX ="APL ’APL_NM’ Connection is lost "
#WHEN 4 @TOX ="APL ’APL_NM’ The application is started "
#WHEN 5 #BLOCK
#ERROR IGNORE
@S=STATUS
@ST=SHADEXTAS:DOV(%APL)
@S=STATUS
#ERROR STOP
#IF %S==0 #THEN #BLOCK
@STATE=%ST
@TOX_AS="EXT APL ADJ_’APL_NM’ The state changed "
#BLOCK_END
#ELSE #BLOCK
@STATE=10
@TOX_AS="EXT APL ADJ_’APL_NM’ State "
#BLOCK_END
#BLOCK_END
#CASE_END
@ACTION=%EVENT-1
#LOOP_WITH DST_APL=1..2
@APL_ST=APL’DST_APL’:BAS
#IF (%APL_ST=="HOT" AND %ACTION<4) #THEN #BLOCK
#SET WD’NODE_NRO’:’DST_APL’POX’APL’=%TOX
104 ABB Automation

#SET WD’NODE_NRO’:’DST_APL’POV’APL’=%ACTION
#BLOCK_END
#ELSE_IF (%APL_ST=="HOT" AND %ACTION==4) #THEN #BLOCK
#SET WD’NODE_NRO’:’DST_APL’POX5=%TOX_AS
#SET WD’NODE_NRO’:’DST_APL’POV5=%STATE
#BLOCK_END
#ELSE #BLOCK
;
#BLOCK_END
#LOOP_END
12.1.7 An Example Hot Stand-By Configuration
An example of base system configuration for a hot stand-by system is given here. The
system is shown in Figure 21. This example shows the content of the command pro-
cedures that were listed above in this particular configuration. Also it shows the Sys-
bascon.com and monitors.dat files made for this system.
Figure 21. A MicroSCADA system where is 2 SYS 500 System Servers and 4 COM
510 or 530 Communication frontend
Shadusr
In this example configuration there is no modifications made to the Shadusr. So, hot
stand-by functionality related events and alarms are not generated and shown to the
operator.
LN = "SHADUSR",
CM = "USER DEFINED PROCEDURE FOR ALARM AND EVENT HANDLING", IU = 1,
ZT = 98-11-26 11:13:37, EP = 255, SE = 0, TC = "", PE = 0, PQ = 0,
HN = 0, MO = 1, IN =
; SHADUSR - USER DEFINED COMMAND PROCEDURE FOR GENERATING ALARMS AND
; EVENTS IN USER APPLICATION
;
; INPUT PARAMETER:
; %EVENT (INTEGER:
; 1 = TRANSMISSION STARTS
ABB Automation 105

; 2 = DUMP DONE
; 3 = CONNECTION LOST TO RECEIVER
; 4 = TAKEOVER
; 5 = EXTERNAL APPLICATION STATE CHANGE,
; STATE STORED IN SHADEXTAS:D(%APL),
; OS == 0 => AVAILABLE,
; OS == 10 => NOT AVAILABLE,
; OV == 0 => COLD,
; OV == 1 => WARM,
; OV == 2 => HOT)
;
;-END-ABB-----------------------------------------------------------
Shadmapmon
In this example configuration the monitors that are opened at takeover are specified.
The first part of the command procedure ending with the text
;-END-ABB------------------------------------------
is ready made. The text after this is the project specific part made by the project engi-
neer.
In case the base system with the node number 21 becomes hot at the take over, 3 pre-
defined monitors of number 4 and 3 predefined monitors of number 5 are opened with
the ops call to the computer named JSE_SYS1. When base system with the node
number 22 becomes hot at the take over, 3 predefined monitors of number 4 and 3
predefined monitors of number 5 are opened to the computer named JSE_SYS2. For
more information on opening predefined monitor and monitors.dat file, see the Chap-
ter 2 in the System Management.
LN = "SHADMAPMON",
CM = "USER DEFINED PROCEDURE MAPPING MONITORS AT TAKEOVER", IU = 0,
ZT = 99-04-14 13:05:25, EP = 255, SE = 0, TC = "", PE = 0, PQ = 0,
HN = 0, MO = 1, IN =
; SHADMAPMON - USER DEFINED COMMAND PROCEDURE FOR MAPPING MONITORS
; AT TAKEOVER
;
; INPUT PARAMETER:
; %APL (INTEGER 1 .. MAX_APPLICATION_NUMBER)
;
;-END-ABB------------------------------------------------------------
#Error Continue
@HOT=SYS:BND
#CASE %HOT
#WHEN 21 #LOOP_WITH I=1..3
@I=%I+1
@OPS=OPS_CALL("MONS -N -D JSE_SYS1 4",1)
#LOOP_END
#WHEN 22 #LOOP_WITH I=1..3
@I=%I+1
#LOOP_END
#CASE_END
Shadmapnet
In this example configuration the monitors that are opened at takeover are specified.
The first part of the command procedure ending with the text
;-END-ABB------------------------------------------
106 ABB Automation

is ready made. The text after this is the project specific part made by the project engi-
neer.
First the time is specified, during which something should have been received from
the NET. Then the numbers of the NETs, applications and base systems in the appli-
cation named JSE are specified. Then there are programs that translate:
LN = "SHADMAPNET",
CM = "USER DEFINED PROCEDURE FOR CONFIGURING NET’S AT TAKEOVER",
IU = 1, ZT = 99-03-15 01:11:02, EP = 255, SE = 0, TC = "", PE = 0,
PQ = 0, HN = 0, MO = 1, IN =
; SHADMAPNET - USER DEFINED COMMAND PROCEDURE FOR RECONFIGURING
; MICROFRONTENDS AT TAKEOVER
;
; INPUT PARAMETER:
; %APL (INTEGER 1 .. MAX_APPLICATION_NUMBER)
;
;-END-ABB-------------------------------------------------------------------
#ERROR CONTINUE
@DT = 120 ; IF SOMETHING RECEIVED FROM NET WITHIN %DT SECONDS

; CONSIDER IT AS REACHABLE
@My_Nod = SYS:BND
#CASE APL1:BNA
#WHEN "JSE" #BLOCK
@NETS=(1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18)
@APLS=( 5, 6, 7, 8)
@SYSS=(23,24,25,26)
#BLOCK_END
#OTHERWISE #BLOCK
@S=CONSOLE_OUTPUT("SHADMAPNET UNKNOWN APPLICATION")
#BLOCK_END
#CASE_END
#LOOP_WITH I = 1 .. LENGTH(%NETS) ; Switch the NET units
@T=Times
@NET=%NETS(%I)
#If Nodes:P’NET’ == 1 #Then #Block
@a = Console_output("’T’ Shadmapnet NET=’net’ My_Nod = ’my_nod’")
#set Net’NET’:SSY1=(%My_Nod,1)
#Block_end
#LOOP_END
#LOOP_WITH I = 1 .. LENGTH(%APLS) ; Switch the application in the COM Nodes

@COMAPL=%APLS(%I)
@COMNOD=%SYSS(%I)
@A = Timeout(500)
#Error Continue
#Set APL1:’COMAPL’BTT="NONE"
#Set APL1:’COMAPL’BND=%My_Nod
#Set APL1:’COMAPL’BTT="EXTERNAL"
@T=Times
@a = Console_output("’T’ APL1 from Node ’COMAPL’ to Node ’My_Nod’ ")
#LOOP_END
Shadgohot
LN = "SHADGOHOT",
CM = "USER DEFINED CHECKS FOR STARTING STANDBY APPLICATION", IU = 1,
ZT = 99-03-03 18:28:32, EP = 255, SE = 0, TC = "", PE = 0, PQ = 0,
HN = 0, MO = 1, IN =
; SHADGOHOT - USER DEFINED COMMAND PROCEDURE FOR CHECKING WETHER
; APPLICATION IS ALLOWED TO HOT OR NOT WHEN THE SHADOWING
; HAS DISCOVERED A CONNECTION LOST
;
; INPUT PARAMETER:
; OUTPUT PARAMETER:
; %GO_HOT (BOOLEAN, TRUE OR FALSE)
;
;-END-ABB--------------------------------------------------------------
@A = Console_Output("SHADGOHOT:C Begin")
ABB Automation 107

@a = Timeout(500)
@Counter=0
@New_Node = (9,10,11,12,13,14,15,16,1,2,3,4,5,6,7,8,18,17)
#Loop_With J = 1 .. Length(%New_Node)
#error Continue
@nods=Nod’J’:ssa
@Know = status
#If %Know == 0 #Then @Counter = %Counter + 1
#Error Continue
#Loop_End
#If %Counter >= 1 #Then @Go_hot = TRUE

#If %Counter == 0 #Then @Go_hot = FALSE
@a = Timeout(0)
@A = Console_Output("SHADGOHOT:C Go_Hot = ’Go_Hot’")
Shadremhot
LN = "SHADREMHOT", CM = "CHECK IF ALLOWED TO REMAIN HOT", IU = 1,
ZT = 99-03-10 13:48:51, EP = 255, SE = 0, TC = "", PE = 0, PQ = 0,
HN = 0, MO = 1, IN =
; SHADREMHOT - USER DEFINED COMMAND PROCEDURE FOR CHECKING WETHER
; APPLICATION IS ALLOWED TO REMAIN HOT AFTER DISCOVERING
; THAT ALSO THE SHADOWING PARTNER IS HOT
;
; INPUT PARAMETER:
; OUTPUT PARAMETER:
; %REMAIN_HOT (BOOLEAN, TRUE OR FALSE)
;
;-END-ABB----------------------------------------------------------------
@A = Console_Output("SHADREMHOT:C Begin")
@a = Timeout(500)
@NET_CNT = 0
@New_Node = (9,10,11,12,13,14,15,16,1,2,3,4,5,6,7,8,18,17)
@BS_NODE=SYS:BND
@APL_NODE=%BS_NODE*10000+%APL
#Loop_With J = 1 .. Length(%New_Node)
#Error Continue
@NET_NRO = %New_Node(%J)
@ST = NET’NET_NRO’:SSA
@STS = STATUS
#If %STS==0 #Then #Block
#If NET’NET_NRO’:SSY’APL’==%APL_NODE #Then #Block
@NET_CNT=%NET_CNT+1
#Block_End
#Block_End
#Loop_End
#If %NET_CNT >= 1 #Then @REMAIN_HOT=TRUE

#If %NET_CNT == 0 #Then @REMAIN_HOT=FALSE
@a = Timeout(0)
@A = Console_Output("SHADREMHOT:C Rem_Hot = ’Remain_Hot’")
Shadglobal
LN = "SHADGLOBAL", CM = "GLOBAL DEFINITIONS", IU = 1,
ZT = 98-11-26 11:16:49, EP = 255, SE = 0, TC = "", PE = 0, PQ = 0,
HN = 0, MO = 1, IN =
; SHADOW GLOBAL DEFINITIONS
;
;
@MAX_APL = 99 ;MAXIMUM # OF APPLICATIONS

@MAX_NET = 16 ;MAXIMUM # OF NETS
@CHK_NET_START = FALSE ;CHECKS FOR NET CONNECTIONS

;AT FORCED APPLICATION START
@CHK_EXT_SP = FALSE ;CHECKS FOR SHADOWING PHASE FOR

;EXTERNAL APPLICATIONS
@LAPL_START = 60 ;SECONDS TO WAIT FOR LOCAL

;APPLICATION TO START
108 ABB Automation

@EAPL_START = 60 ;SECONDS TO WAIT FOR EXTERNAL

;APPLICATION START RESPONSE
@SHD_RESTART = 200 ;SECONDS BEFORE TRYING TO RESTART

;TRANSMISSION
@NET_CONN = 300 ;SECONDS SINCE LAST MESSAGE FROM NET

;BEFORE CONNECTION CONSIDERED BROKEN
@RCV_MATRIX = ("SHADRCV_M","SHADBCK_M") ;TRANSITION MATRIXES FOR REVEIVER

@XMT_MATRIX = ("SHADXMT_M","") ;TRANSITION MATRIXES FOR TRANSMITTER
;(<EXT SHADOWING>,<INT SHADOWING>)
@BCK_PROC = "SHADBACKUP" ;NAME OF PROCEDURE TO PERFORM BACKUP
@HSB_LOG = TRUE ;ENABLE/DISABLE LOGGING OF HSB EVENTS ON DISK

;IN THE FILE "SYS_SHADOW.LOG"
@LOG_FILE = "SYS_SHADOW.LOG" ;NAME OF LOGFILE
; EVENTS FOR SHADUSR
@TR_START = 1 ;TRANSMISSION STARTS
@DUMP_DONE = 2 ;DUMP DONE
@CONN_LOST = 3 ;CONNECTION LOST TO RECEIVER
@TOVR = 4 ;TAKEOVER
@EXTAS = 5 ;EXTERNAL APPLICATION STATE CHANGE
;USER REDEFINITIONS AFTER THE FOLLOWING LINE
;-END-ABB-------------------------------------------------------------
12.2 Redundant Frontends
The concept ’Redundant Frontends’ means that two communication frontends are
dedicated for the same tasks. One communication frontend is operating, the hot fron-
tend, and the other one is a reserve communication frontend, secondary or stand-by
frontend. The stand-by frontend is not operating but running and ready to take over at
malfunction in the hot one. When take-over occurs, the former stand-by frontend be-
comes the hot one and takes over the communication on all lines. Normally, the com-
munication frontends are equal and the stand-by frontend can be shifted to hot fron-
tend and vice versa.
During operation some RP570 information is transferred between the two frontends
on event basis. Redundant frontends including transfer of event data between the
communication frontends are only supported with S.P.I.D.E.R. RTUs and the RP570
protocol. If other protocols are used, a switch-over between communication frontends
is possible, but such RTU information, which cannot be obtained with a general inter-
rogation may be lost.
In most cases Redundant Frontends are combined with Redundant MicroSCADA ap-
plications, see section 12.1, although these are two independent functions. They can
also be used with communication loops as described in section 12.3. The data transfer
between the communication frontends may slow down the RTU polling compared
with single frontends.
A standard application software package is available for handling redundant fron-

tends. Both the frontend supervision and the application software package are based
on switching one NET pair at a time individually. This means that communication
frontends containing several redundant NET units require additions to the standard
package.
ABB Automation 109

System Architecture
A redundant frontend pair consists of:

• Two communication frontends with one communication board in each. Additional
boards require extensions to the standard redundant frontend application soft-
ware.
• Line switches with 1..7 external RP570 lines for RTU communication. There is
one line switch per Process Station line.
• A standard redundant frontend application software package.
Each of the communication frontends is permanently connected to one or more, up to
four, base systems via a LAN. One base system can be connected via a COM port and
a serial RS-232-C line.
The two frontends must be interconnected for transmission of event data, either via a
COM port or a NET line. If a COM port is occupied for a base system connection, the
communication frontends are connected via a NET line.
Both communication frontends are permanently physically connected to all line

switches. The switches are controlled by a DTR signal issued by the stand-by fron-
tend. As long as the DTR signal from the stand-by frontend is passive, the RTUs are
connected to the hot frontend. When DTR is activated by the stand-by frontend, the
line switches turn towards this one, which hence gets the Process Station connections.
Provided that the line switches are sensitive to the rising DTR edge, the former hot
frontend can take the lines back after recovery. The operation of the RTUs is not ef-
fected by the NET redundancy procedures.
The frontend switching can be initiated by the operator from the NET configuration
tool picture, e.g. for testing purposes.
During normal operation, the hot NET sends the following data cyclically to the
stand-by NET:
• RTU event information and RP570 line status.
• Communication loop configuration data.
Table 4. Information transferred from the running NET to the standby NET
WHEN WHAT
At event reception Event sequence number
When RTU device status changes RTU device status
At line status change Line status of line , comm.. loop data of line if
comm. loop configured on line.
At communication loop configuration Communication loop data of a line
At communication loop build-up Communication loop data of a line substatus
change
When there is no information to send, a diagnostic message is sent cyclically. The

stand-by NET supervises the time between the messages from the hot NET. If a time-
out occurs, it sends a system message to the MicroSCADA application (the message
110 ABB Automation

application, the MS attribute, see section 8.1) telling that the hot NET has failed. The
application decides whether to execute a takeover, and performs it when needed.
If a NET loses its connection to the message application, it will report this as a failure
to the other NET, which tries to inform the application about the failure.
NET Configuration
The NET programs of the both redundant communication units have the same precon-
figuration, except for the node number, ACP station address and system message han-
dling attributes. Both NETs are basically defined as described in section 8.1. The
NETs must know each other as nodes residing on the redundant connection line, i.e.
either a NET line or a serial line via a COM port. Regarding connected stations and
applications, both NETs must have exactly the same configuration.
To build two redundant frontends, configure each of the NETs as follows in the pre-
configuration of the NET programs:
1 Define the fundamental configuration of the NET as described in section 8.1. Use
the default MI values for system message addresses. If there are ANSI stations, the
SX attribute must be the same in both NETs. Define NET system message enabled
attribute SE to value 2.
2 Check that line 13 is defined for the common RAM interface.
3 If the redundancy information will be sent via a NET line, define the line as an
ACP line with the following attributes:
PO Protocol : 00001
IU In Use : 00001
MS Message Application : 00001
MI Message Ident. : 00000
LK 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 Synchronize. : 00000
RE Redundancy : 00002
TI Time-out Length : 00001
ABB Automation 111

NA NAK Limit : 00001
EN ENQ Limit : 00001
DE CTS Delay Length : 00000
ER Embedded Response : 00001
RP Reply Poll Count : 00000
PD Poll Delay : 00000
PS Buffer Pool Size : 00030
PP Polling Period : 00000
CN Connection : [Ign]
4 Define the redundant partner NET as an external node, either on line 13 (if the
COM port is used), or on the NET line reserved for the redundant communication.
5 Define the same STA objects and APL objects in both NETs, see chapters 11 – 13.
All STA definitions in both NETs must also be defined as STA objects in the base
systems.
Possible on-line configuration changes must be done in both communication fron-

tends. The only on-line configuration changes that are automatically transferred be-
tween the communication frontends are communication loop data structures.
To restore the preconfiguration of the running NETs, restart them by setting the RS
attribute of the communication frontend to 3.
Frontend Configuration
Include the following configuration parameters in the MFLCONF.DAT file of each of

the redundant frontends:
1 Set CMOD =2 for the redundant NET.

2 Set CPNOD = the node number of the pair NET in the partner frontend (default =
subsequent numbers, 1 – 2, 3 – 4, etc.).
3 If the redundant communication will go via the COM1 port, define the peer NET
by the DST parameter.
4 Define the base system communication parameters.
112 ABB Automation

Figure 22. An example of two redundant frontends, when the redundancy information is transferred via a
NET line.
Table 5. An example configuration of two redundant frontends when the redundancy information is trans-
ferred via a NET line. If the base systems are doubled, both base systems contain the same con-
figuration regarding the frontends and the RTU:s.
Configuration of NET1 Configuration of NET4
This Node: This Node:
RAM Size (kB): 512 RAM Size (kB): 512
Device Number: 1 Device Number: 4
MI Message Ident.: 6001 MI Message Ident.: 6004
MS Message 1 MS Message 3
Application: Application:
SA Station Addr. 201 SA Station Addr. 204
(dec.): (dec.):
SE System Message 1 SE System Message 1
Enabled: Enabled:
Line 13 (=RAM Interface) Line 13 (=RAM Interface)
PO Protocol: 3 PO Protocol: 3
IU In Use: 1 IU In Use: 1
Applications: Applications:
RE Redundancy: 2 RE Redundancy: 2
TI Time-out Length: 2 TI Time-out Length: 2
NA NAK Limit: 3 NA NAK Limit: 3
NE ENQ Limit: 3 NE ENQ Limit: 3
PS Buffer Pool Size: 50 PS Buffer Pool Size: 50
ABB Automation 113

External Node 4 (NET 4) External Node 1 (=NET 1)

Device Type: NOD Device Type: NOD
Device Number: 4 Device Number: 1
LI Line Number: 3 LI Line Number: 3
SA Station Addr. 204 SA Station Addr. 201
(dec): (dec):
Line 8 (=ACP line) Line 8 (=ACP line)
PO Protocol: 1 PO Protocol: 1
Application: Application:
See section 8.4 See section 8.4
Frontend Configuration Frontend Configuration
DST1 = 209 DST1 = 209
DST2 = 210 DST2 = 210
CMOD1 = 2 CMOD1 = 2
CPNOD1 = 4 CPNOD1 = 1
Standard Application Software Package
The standard application software for redundant frontends controls the communica-
tion between the redundant frontends. It receives system messages from the frontends
and control the frontend modes using the Running Mode (RM) and Shadowing (SH)
attributes of NET. When a communication frontend is started, the initial redundancy
mode is defined by the CMOD parameter in the frontend configuration file, see
above.
If the stand-by NET detects a severe failure in the hot frontend, it sends a system mes-
sage containing a switch-over request to a MicroSCADA application (e.g. the watch-
dog application if hot stand-by). On the basis of the system messages, and possibly
further conditions, the application decides whether to perform a switch-over or not.
The switch-over is executed by the command procedures included in the standard re-
dundant frontend software package. These procedures executes, e.g., the following
steps:
• Changes the stand-by NET to HOT, by setting its RM attribute to 1 and the SH
attribute to 1.
• Takes the RTU lines in use by setting the IU attribute to 1. When a line is taken
into use, DTR is automatically activated and the NET takes hold of the lines.
• Redefines the stations in the base system with the NET node number, e.g. #SET
STAn:BND = 4.
• Commands the new hot NET to send an SCI (status request) to all RTUs using the
SC attribute.
• Takes the RTUs into use by setting the IU attribute = 1.
114 ABB Automation

Installing Standard Software
The MicroSCADA tool software contains a tool pictures (SYSORF_ADM) for in-
stalling and taking into use the standard application software package for redundant
frontends. To take the software package into use:
1 Enter the application which will contain the application software, and enter the
tool menu NET SPECIAL CONFIGURATION and select REDUNDANT
FRONT-END INSTALLATION.
2 Press the INSTALL RF OBJECTS key, which will install command procedures,
datalogs, time channels and event objects into your system. The names of the
created objects start with letters RF_.
3 Press the CREATE/VIEW NET PAIRS key to select the redundant NET pairs.
Type in the group numbers and the node numbers of the NETs. For each redundant
frontend you must use a unique group number. Press the INSTALL key to save
your settings.
4 Press CHOOSE/VIEW RF LINES key. Type in the node number of the NETs and
mark the numbers of the NET lines which are operated by the RF procedures.
5 Press CREATE LIST OF OBJECTS key. This will search your base system
configuration for STA and PRI objects and then it will create two vector variables
into RF_U_BOBJ:C command procedure. RF_STAOBJ variable contains the
numbers of base system station objects that are controlled by RF procedures.
RF_PRIOBJ contains the numbers of base system printer objects that are
controlled by RF procedures. The command procedure can be modified manually
to add or remove objects from the list or it can be created again with the CREATE
LIST OF OBJECTS KEY.
6 If you have a combination of redundant frontend and hot-standby base system, you
should press the INSTALL OBJECTS FOR HSB APL key. This will create a
RF_U_WD:C command procedure into your WD application.
Application Specific Procedures
Redundant frontend command procedures that need application specific modifications

are named with letters RF_U_*.
RF_U_BOBJ:C
This command procedure is used to store an array of base system STA and PRI
objects which are controlled by RF procedures. This is done with two vector vari-
ables:
RF_STAOBJ Contains the numbers of base system station objects

that are controlled by RF procedures
RF_PRIOBJ Contains the numbers of base system printer objects that

are controlled by RF procedures
This procedure can be done manually or from the tool with CREATE LIST OF
OBJECTS key.
ABB Automation 115

RF_U_CHECK:C
This command procedure is used to perform a cyclical check of redundant NETs.

The procedure is executed by a RF_U_CHECK time channel. The following
checks has been included as a default.
• RF_U_WD:C in watchdog application is executed to remap the main applica-

tion. This is necessary only when hot-standby base system is used together
with redundant frontend.
• Checks that the system messages enable attribute (SE) in NET is 1, if not it is
changed to 1.
• Checks that the NET pairs are not in the same running state (both standby or
hot), if they are in the same state the switch over procedure is started.
RF_U_LIN:C
Sets a line of the new hot net in use on switchover. This command procedure is
executed by the switch over procedures for all the NET lines which have been
chosen in the tool picture. This procedure can be used in most applications without
any modifications.
RF_U_NETMS:C
NET system message handling for application specific purposes. This command
procedure receives the three different types of NET system messages (General,
APL diagnostic, NET diagnostic). As a default this procedure is used for following
functions.
• When the main application connection of the hot NET is restored, this proce-
dure is used to map the base system objects to that NET. This is done by exe-
cuting the RF_BOBJ_SB:C command procedure.
• When the main application connection of any NET is restored, this procedure
is used to start the online configuration of the NET, executes the
RF_U_ONLC:C.
RF_U_ONLC:C
This procedure is used if online configuration of the NET is needed.
RF_U_STA:C
Sets the stations in use and makes station specific actions on switchover.
12.3 Communication Loops
A communication loop means that several RTUs are connected on the same line in a
loop to two NET lines in the same or separate communication units, situated in the
same or separate frontends, see Figure 23. The purpose is to secure the contact be-
tween the base system and the RTUs even if the loop line physically is broken in one
116 ABB Automation

location. Communication loop is available exclusively for S.P.I.D.E.R. RTUs,

whereby NET acts as an RP570 master station.
The communication between the base system and the RTUs can go in any loop direc-
tion, but only in one direction at a time. The communication can be redirected with
SCIL. The RTUs also changes the communication direction automatically if they are
not polled within a certain point of time. A loop reconfiguration normally lasts several
minutes and during that time all RTUs are not accessible. The performance of a com-
munication loop line is somewhat slower than normal modem lines, because typically
the telegrams have to pass through several modems on the way.
The communication loop implementation in MicroSCADA involves functions both in

NET and in the MicroSCADA application.
System Architecture
Hardware requirements:
• A Loop control unit DSTC3002 or equivalent and two modems at each RTU.
Software requirements:
• DCP-NET or PC-NET software, rev. 8.2 or 8.4.
• MicroSCADA base system base product software rev. 8.2 or 8.4.
• RTU200 or RTU210 software rel. 2. including loop support.
• Communication loop application software package.
Each RTU is equipped with a loop reversal unit and two modems. The ends of a
communication loop can either be connected to two lines of the same NET unit or to
two lines of different NETs (as in the example configuration of fig. 1). The maximum
number of RTUs per loop is 16. Branched communication loop lines are not sup-
ported.
A maximum of 10 loops is allowed per application.
ABB Automation 117

Figure 23. An example of a communication loop connected to two separate commu-

nication frontend
The loop has a logical breakpoint, normally near the midpoint of the loop. All RTUs
on one side of the breakpoint are polled from that direction and the RTUs on the other
side are polled from the other direction. The breakpoint can be moved to any loop
segment, thus, all the RTUs can even be polled from the same direction.
Each RTU controls its own loop reversal unit and can change the listening direction
by opening or closing its loop reversal unit. The breakpoint is formed where two adja-
cent RTUs are linked to different directions. A NET can command an RTU to change
the state of its loop reversal unit with an RP570 command. If the RTU is not polled
from the current direction with other telegrams than SCI for a certain time, the loop
reversal time, it will automatically turn its loop reversal unit and listen in the other di-
rection. Consequently, under all circumstances, all RTUs must be polled within this
time, otherwise, some RTU may turn to the wrong direction.
The loop reversal time-out is configured in the RTU, and can be set with an FTAB
command. The loop reconfiguration time depends on the number of RTUs in the loop
and the loop reversal unit turn time-out in the RTUs. An automatic reconfiguration of
a loop with 16 RTUs may take a few minutes.
If an RTU polled from one direction is suspended, a system message is sent to the
message application of the RTU in question. The application waits for a while. If one
or more RTUs are still suspended, a loop reconfiguration starts. The breakpoint can
be moved, e.g., so that all suspended RTUs, and all RTUs situated between them on
the loop, are polled from the other direction. During the reconfiguration, the loop re-
versal units of the RTUs are turned according to the physical order of the RTUs on
the loop, and the loop is thus extended step by step.
When a NET starts to poll an RTU which has been shifted from the other direction, it
always starts with a status check (SCI). This means that the latest indication and
measured values are transmitted by the RTU. Events, pulse counter messages and
118 ABB Automation

other queued data (from the four last telegrams if found) is automatically retransmit-
ted by the RTU. Therefore, no RTU information gets lost.
The communication loop configuration is built on-line. The standard loop application
software loads the communication loop configuration each time the NETs have been
restarted. If the NETs controlling the loop have redundant NETs the configuration
commands are forwarded to the stand-by NET. Information is forwarded several times
during a loop reconfiguration procedure.
NET Configuration
Communication loop sets no special requirements on the preconfiguration of the

NETs. No direct communication between the separate NETs which control the two
ends of a loop is required. The NETs are defined to one another as normal nodes as
described in Chapter 8.
5 Define the loop line in both NETs. The line is configured as an ordinary RP570
line, see section 11.1.
6 Define all RTUs in both NETs. The RTUs in the loop are not in use (IU = 0).
Loop Application Software
The MicroSCADA tool software package includes two tool pictures for communica-
tion loop handling, one for the installation and administration of the loop software
(SYSOLOOCON), and one for supervision of the loop operation (SYSOLOOSUP).
To install or edit the loop application software:
1 Enter the application which will contain the software.

2 Enter the tool SYSOLOOCON.
3 Select a loop in the list (1 ... 10) by clicking on it, an empty number to add a new
loop, or a loop name to a view or edit an existing one.
4 Define the loop in the loop window that appears by a freely chosen loop name, the
node numbers of the NET, the loop line numbers and the following loop
communication parameters:
CONFIG. TIME = Time limit for the NETs to get connection to all
RTUs after loop reconfiguration
BREAK TIME = Time from first RTU suspensions to decision if an
automatic reconfiguration will be done or not
SCAN TIME = Maximum scan time, the MT attribute. The time al-
lowed for obtaining connection with the next RTU on
the loop after re-configuration.
5 Select SHOW RTUs to view, add and edit the RTUs of the loop.
6 Add a new RTU to the loop by selecting ADD RTU, clicking on the location of the
RTU on the loop line, and defining the RTU in the window, or edit an existing
RTU by clicking on it on the loop and redefining it in the RTU window. RTUs can
be removed from the loop be clicking on REMOVE RTU and then the RTU
symbol in the loop figure. They cannot be moved. The RTUs are defined by a
ABB Automation 119

freely chosen name, the STA object number, listening direction, and loop switch
state.
7 When the loop is ready, build the application command procedures by clicking on
INSTALL CMD PROCEDURES.
The function keys CHANGE DIRECTION, OPEN/CLOSE, and SET BREAK do not
affect the configuration of the loop.
120 ABB Automation

Configuration Manual 13 Miscellaneous
13 Miscellaneous
13.1 Handling of the system messages generated in the communication units.
13.2 Configuration of auto-dialing.
13.3 Time synchronisation.
13.4 Storing the Event History.
13.1 System Message Handling
System messages are generated by the communication units at the appearance and
disappearance of abnormal situations or events in the communication with connected
stations, printers and applications (STA, PRI and APL objects) or on the communica-
tion lines (NET lines). A system message is always related to a certain object or a line
and indicates:
• A malfunction in the object or line, e.g. an RTU is not responding.
• A recovery after a malfunction.
• An event, e.g. a S.P.I.D.E.R. RTU is restarted.
The system message contains a code, which describes the state of the device or line
The status code 0 indicates OK status. A status code larger than 0 does not necessarily
indicate an error. The codes are listed in the manual Status Codes. The codes related
to system objects are 0 and the codes larger than 10 000. (The explanation can be read
in the Windows NT command prompt window with the command: STATUS ‘error
code’).
The system messages can be sent to an application in a base system, where the codes
can be updated in a process object and used for alarm or printout generation, activa-
tion of control operations, etc.
System Message Generation
The NET unit itself can cause system messages containing the status codes 0, 10 000
... 12 099 and 16 600 ... 20176. System messages are generated, e.g., in the following
situations:
• The communication program has started: code 10001. This message is sent to all
applications defined in the unit.
• The Mail Update Identification (MU) attribute has been updated: code 16633. See
the manual System Objects, section 12.7.
ABB Automation 121

13 Miscellaneous Configuration Manual
The application connection supervision in the NET unit can cause messages with
some special codes in the following situations:
• When the application communication is suspended: the application number. The
message is sent to the application defined by the Message Application (MS) at-
tribute of NET, or to the first application which is responding. See the Applica-
tion Suspension Time (SU) attribute in the manual System Objects, section 12.4.
• When the application communication is recovered: 1000 + application number.
The message is sent both to the recovering application and to the application
which received the suspension message.
NET lines, independent of protocol, can cause system messages with the status codes
0 or 14001 ... 16099 and some of the codes 16101 ... 16599 and 16700 ... 17999 de-
pending on the protocol defined. The lines cause system messages, e.g., in the fol-
lowing situations:
• Various situations on communication lines: protocol dependent codes. E.g. if no
ACK is received on ANSI X3.28 Full Duplex lines, a message with the code
16101 is generated.
• Various situations on dial-up lines: see section 13.2.
• The line is taken into use (IU = 1). This however, does not concern all protocols.
• The NET-NET communication is lost: Peer NET number.
• The NET-NET communication is started: 1000+Peer NET number.
Stations using the ANSI X3.28 protocol (STA) can cause messages with the status
codes 0 or 12301 ... 12399. The stations cause generate messages, e.g., in the follow-
ing situations:
• The station is put into suspended state because it does not respond to poll packets
or messages: codes 12334, 12336, 12337, or 12386.
• The In Use (IU) attribute of the station has been set to 0: code 12339.
• The connection to a station, supervised by the DCD signal, has been lost: code
12333.
• The station connection recovers after a disturbance: code 0.
The S.P.I.D.E.R. RTUs (RTU) can cause messages containing the status codes 0 and
12601 ... 12749. Some situations cause codes which are a running number, 0 ... 999,
kept be the communication unit. The system messages are generated, e.g., in the fol-
lowing situations:
• The station is suspended: code 12602.
• The station recovers from suspension: code 0.
• The station is stopped or restarted: codes 12604 or 12605 respectively.
• Transparent data received: code 12683.
• Terminal status received: codes 12701 .. 12789.
• Terminal message received: codes 0 ... 999.
• Terminal event received: codes 0 ... 999.
122 ABB Automation

A PRI object can cause messages with the status codes 0 and 13101 .. 13100. System
messages are generated, e.g., in the following situations:
• The printer is switched off: code 13119.
• The printer is off line or it has been busy for more than 10 seconds: code 13103.
The printer accepts data again after any of the above situations: code 0.
See the Status Codes manual for specific ranges of system messages.
When a system message is caused by a system object, it is directed to the application

specified by the Message Application (MS) attribute of the object. The code of the
message is updated as the object value for a fictitious process object with the Object
Address (OA) attribute value equal to the value of the Message Identification (MI)
attribute.
To achieve this system message handling in the communication unit:
1 Set the Message Application (MS) attribute of the system object to the number of
the receiving application.
2 Set the Message Identification (MI) attribute of the system object to the value of
object address of the receiving object. The MI attribute has object dependent
default values which are also the recommended values, and should generally not be
changed. The default value is used when the system object is defined on-line and
the MI attribute is not explicitly set, or if the MI attribute is set to 0 in the
preconfiguration. The default values are shown in Table 6.
The transmission of system messages from individual objects can be enabled or dis-
abled by the System Message Enabled (SE) attribute of the objects. The system mes-
sage generation should only be disabled in special cases, e.g. if the base system appli-
cation program often executes commands, which cause undesirable system messages.
Application Requirements
To use the system messages in an application:
1 Create a fictitious process object of type ANSI analog input and set the Unit
Number (UN) attribute to 0. The system message codes of the device will be
registered as the object value of this object.
2 Set the objects Object Address (OA) attribute equal to the Message Identification
(MI) attribute and set Switch State (SS) attribute to Auto.
3 Select direct scale (1-1).
Define the consequential operations by means of event, alarm and printout attributes.
See the manual Application Objects, sections 3.2.6 and 3.2.7 for alarm generation,
3.2.8 for activation of event channel and automatic updating in pictures, 3.2.10 for
printout activation and 3.2.9 for including in the event list.
ABB Automation 123

Table 6. The default Message Identification (MI) attribute values

Object Message MI Default Value
NET itself General messages, e.g. start-up messages 6000 + NET no.
Value: Status code.
Application supervision. 6050 + NET no.
Value: APL no.= failure
1000 + APL no. = recovery
(APL no. as known to NET)
Redundant frontend supervision 5900 + NET no.
Value: Peer NET no. = failure
1000 + peer NET no. = recovery
NET line All NET line messages 6000 + 100 NET no. + line no.
STA, ANSI Stations All STA messages from ANSI stations. 1000 + STA no.
Value: Status code
STA, S.P.I.D.E.R. RTU General messages, e.g. station 8000 + STA no.
suspension, recovery, etc.
Value: Status code.
Terminal status 8500 + STA no.
Value: Status code.
Terminal message 9000 + STA no.
Value: Message tag number, 0 ... 999.
Terminal event 9500 + STA no.
Value: Event tag number, 0 ... 999.
STA, SPA units All STA messages from SPA stations 1000 + STA no.
Value: Status codes
PRI, printers All PRI messages 3000 + PRI no.
Value: Status code
13.2 Auto-dialing
Auto-dialing can be used on all NET serial lines defined for the ANSI X3.28 Half
Duplex or Full Duplex protocols, ACP (MicroPROTOCOL), Modbus, IEC 1107 or
the RP570 protocol. Auto-dialing is for example useful:
• For the connection of remote stations with infrequent data transfer.
• For the connection of home terminals.
• For taking into use a reserve line.
Auto-dialing is possible in both directions.
The auto-dialing line can be defined in the preconfiguration. However, the auto-
dialing feature can not be preconfigured, it must be configured and taken into use on-
line.
Create the line in the preconfiguration or on-line. Depending on the device(s) con-
nected to the line set the Protocol (PO) attribute to 1 for the ANSI X3.28 Full Duplex
protocol, 2 for the ANSI X3.28 Half Duplex protocol, 1 for the MicroPROTOCOL
protocol, 25 for Modbus RTU mode master protocol and 26 for the IEC 1107 proto-
col.
The auto-dialing feature for a line can be added using a tool or SCIL. The dial-up mo-
dem has to be connected in to the line while defining the auto-dialing feature.
124 ABB Automation

To define the auto-dialing with SCIL:
1 Take the line out of use by setting the In Use (IU) attribute of the line to 0, e.g.:
#SET NET1:SIU5 = 0
2 Set the ACE (AC) attribute of the line to 1, e.g.:
#SET NET1:SAC5 = 1
3 If the NET unit is supposed to answer incoming calls which is always the case on
RP570 lines, set the Remote Calls Enabled (RC) attribute to 1, e.g.:
#SET NET1:SRC5 = 1
4 iIf an automatic break of the connection after a specified time is desired, set the
Connection Time Limited (CL) and Connection Time (CT) attributes, e.g.:
#SET NET1:SCL5 = 1
#SET NET1:SCT5 = 500
which means that the connection is broken automatically after 500 seconds.
5 If needed, set the Radio Disconnection Delay (DD), Pulse Dialing (PU), Radio
Connection Wait Time (RW) and ACE AT S Register (SR).attributes See the
manual System Objects, section 13.6.
6 Set the In Use (IU) attribute of the line to 1, e.g.:
#SET NET1:SIU5 = 1
Dialing Procedures
To dial up a workstation or RTU from NET:
1 Set the Connection (CN) attribute in an application program as follows:

#SET NETn:SCNline = "phone"
or when dialing a station:
#SET NETn:SCNline = "phoneSstation"
where
’line’ Line number
’phone’ Phone number of the receiver
’station’ Station number of the receiver
Dialing is done while the line is in use (IU = 1).
When NET is dialing, system messages with codes 16107, 16208 or 16825, depending
on the protocol, are generated. If a station is dialing, the codes 16108, 16209 or 16826
are generated. A failed dial-up generates the code 16704.
The connection to an RTU is broken automatically if the RTU becomes inoperable, if

it hangs up, or when the RTU is the dialing part, if it has nothing to send (after two
subsequent CCR2 responses). In addition, the connection can be broken automatically
according to the Connection Time (CT).attribute. If the connection is not broken
automatically, break it as follows:
ABB Automation 125

2 Set the Connection (CN) attribute to 0:

#SET NETn:SCNline = 0
A succeeded hang-up generates the system message with code 16733. If the hang-up
failed, the code 16702 or 16703 is generated. The status codes 16106, 16107 and
16810 indicates that disconnection has started.
Examples:
Dialing a MicroTERMINAL:
#SET NET1:SCN5 = "1234567"
Dialing station 11 (STA11):
#SET NET1:SCN5 = "1234567S11"
Breaking the connection:
#SET NET1:SCN5 = ""
13.3 Time Synchronisation
For exact and reliable operation, the whole chain between the process and the Micro-
SCADA databases must be synchronised: the stations, the communication units and
the base systems.
The MicroSCADA base system works according to the operating system clock, which
is regularly set according to the physical clock of the base system computer. If an ex-
ternal time synchronisation source such as a radio clock or a GPS clock is used, it sets
the physical clock, and the operating system clock regularly. The operator can also set
the system time, whereby both the operating system clock and the physical clock are
set simultaneously. However, if the computer uses an external time synchronisation
source, the manual time setting will have a temporary effect only, as the time is set
regularly by the external time synchronisation source. An external time synchronisa-
tion source of type radio clock can also be connected to a frontend and a NET unit.
If the base system uses an external time synchronisation source, not only the base
system itself, but also possible internal frontends are synchronized automatically.
Likewise, if a communication frontend contains a radio clock, all communication
units within the frontend are synchronised automatically. In both cases, the accuracy
is about 10 ms. Hence, if both the base system and the communication frontends are
equipped with radio clocks, no procedures for synchronising these are required, only
the stations must be synchronised from the connected NETs.
If the base system, but not the communication frontend, uses a external time synchro-
nisation source, the NET units of the frontend must be synchronised, either by syn-
chronising the units individually, or by synchronising the frontend, whereby all com-
munication units are synchronised as well. The former method may be preferable, as
the accuracy of the NET units is 20 ... 30 ms, while the accuracy of the frontend PC is
about 60 ms. On the other hand, if the units are synchronised via the frontend, the dif-
ference between the NET units will be small (<<= 10 ms). If the frontend, but not the
base system, contains an external time synchronisation source, the base system must
be synchronised from a NET unit within the frontend.
126 ABB Automation

The base system time can be read and written on millisecond level, with an accuracy
of 10 milliseconds, with the SCIL functions HR_CLOCK and SET_CLOCK. For
more information on the functions, see the Programming Language SCIL manual,
section 8.3.
The time of the communication units and frontends can be read and written with the
NETn:STM attribute.
The time of the stations (S.P.I.D.E.R. RTUs and ANSI stations) are synchronised by
means of the Clock Synchronization (SY) attribute. SPACOM units are synchronised
automatically.
Synchronising NET from Base System
The communication units can be manually synchronised from the base system using
NET ON-LINE CONFIGURATION tool, INTERNAL ATTRIBUTES and the func-
tion key SYNC NET FROM SYS. The time synchronisation program regards the de-
lays caused by the transmission and execution of the command. To build an automatic
regular synchronisation of a NET from a base system:
1 Define a time channel with an appropriate time interval.

2 Define a command procedure to be started by the time channel and containing at
least the following commands:
@TIME = HR_CLOCK
#SET NETn:STM(1..2) = (TIME:VCL,ROUND(TIME:VUS DIV 1000))
which read the base system time and copies it to the NET time. In order to get a better
accuracy, regard the transmission and execution delays. Use the program under the
function key SYNC NET FROM SYS in the SYSO_NNET.PIC picture as a model.
Synchronising Stand-alone Frontends
When started, the frontend time is set to the time of the PC clock. To synchronise a
communication frontend from a base system, include at least the following commands
in a SCIL program:
@TIME = HR_CLOCK
#SET NETn:STM = (YEAR, MONTH, DAY, HOUR, MINUTE, -
SECOND, TIME:VUS DIV 1000)
This does not regard the transmission and execution delays. Regarding these requires
a more extensive procedure.
Synchronising a Base System from a NET
If the frontend or a NET unit is connected to an external time synchronisation source,

when the base system is not, the base system must be synchronised from a NET unit.
To synchronise the base system regularly on millisecond level, define a time channel
that starts a command procedure containing at least the following commands:
@NET_TIME = NETn:STM(1..2)
@A =SET_CLOCK(
ABB Automation 127

LIST(CL=CLOCK(%NET_TIME(1)),US=1000*%NET_TIME(2)))
This procedure does not regard the time delay required for executing the command
and communicating with NET.
Synchronising Stations
To synchronise NET and a S.P.I.D.E.R. RTU200 or ANSI station, set the Clock Syn-
chronisation (SY) attribute of the station, e.g. #SET STAn:SSY. For S.P.I.D.E.R.
RTUs, all RTUs connected to one NET can be synchronised simultaneously by using
the broadcast station number. ANSI stations must be synchronised individually.
SPACOM stations need no synchronisation procedures, as they are synchronised

automatically from the connected NET.
The time synchronisation accuracy on SPA and RP570 lines varies from +-5 to +-50
milliseconds, and on ANSI lines from +-10 to 1000 ms, depending on the station type,
the location of the station and the location of the external time synchronisation
source.
13.4 Storing the Event History
There is two ways to store the event history:

• Using history database.
• Using event log and history buffer.
The application engineer chooses one of them when he creates the application. At-
tribute HP determines which one is in use. By default the event log is chosen, for
compatibility reasons. For new applications the value should be changed to
“DATABASE”. For more information about the HP attribute, refer to System Objects
manual, Chapter 5 and for HISTORY_DATABASE_MANAGER function, refer to
the Programming Language SCIL manual, Chapter 8. The application objects related
to the subject are described in the Application Objects manual, Chapter 3.
13.4.1 History Database
History database consists of history database files each containing events of one day.
The files are named according to the date as APL_yymmdd.PHD. For example file
APL_980115.PHD contains the events logged on 15-Jan-1998.
For fast access in time stamp order, there is an index file corresponding each data file.
The name extension of the index file is PHI. The history database is the basis for
event lists made by LIB 500 version 4.0.2.
128 ABB Automation

The maximum size of the file is 32 MB. If database file gets full, the files are re-
named. File extension PHD is renamed to PHX and PHI is renamed to PHZ. New
empty files with extension PHD and PHI are created and the logging continues to
these new files. If PHX or PHZ already exists, the contents of PHD and PHI are lost.
The application is informed by generating an APL_EVENT with the following argu-
ments:
source "HISTORY_DATABASE"
source_nr Status code of the failing write operation
event "FULL"
Each event in the history database contains all the attributes of the process object, ex-
cept for CX attribute. Additionally, it contains extra attributes listed in Table 7.
Table 7. History database specific attribute

ET Event Time
EM Event time Milliseconds
ED Event Daylight saving
HT History logging Time
HM History logging time in Milliseconds
HD Hisroty logging Daylight saving
CA Changed Attribute
EX Event comment teXt
For more information about these attributes, see chapter three in the Application Ob-
jects manual.
Configuration
Define the HP attribute as "DATABASE". History database requires no special con-

figuration, in addition to this. Note that attribute HL has no meaning if APL:BHP ==
"DATABASE".
13.4.2 Event Log
An event log is a disk backup of the event buffer. The events included in the log are
specified on process object basis. Each time an event occurs in a process object de-
fined for the event log, its attributes are written to the log as a text line. The history
buffer or the history log is the basis for event lists made by LIB 500 version 4.0.1 or
earlier versions of application libraries.
Note that event log supports names that contain 10 characters and values of IX < 999
or OA < 99999. If longer names are used, the names will be shortened and the object
name with the following warning is written in Notification Window “WARNING:
Long text has been truncated during event logging.” If longer numerical values are
used, the value is changed to zero and a similar warning is created. For more informa-
tion on logging, see the Application Objects manual section 3.2.9.
ABB Automation 129

Configuration
To build an event log on disk, create a PRIn:B base system object with the following
attributes:
Device Type DT “NORMAL”
Device Connection DC “LINE”
Lines per Page LP 0
Translation Type TT “LOCAL”
Output Destination OD “LOG”
Log Directory LD The directory where the log is stored
Log Flush Timeout LF
Log Length LL “DAY” , “WEEK”, “MONTH” or “YEAR”

The period that the logging is stored in the
same file. Event log handling becomes slower
the lager the file is. Therefore, if the event
frequence is high, “DAY” or “WEEK” should
be used. “MONTH” or “YEAR” can be used
only, if the events occur rarely.
For detailed information on the attributes, see the MicroASCADA System Objects
manual, chapter 10.
The event log files are not destroyed by MicroSCADA, but should be deleted manu-
ally when no longer needed.
1 If needed, map the printer to be known to the application by another number. The
printer must not be used for other printout purposes. If the event list is built with
MicroLIBRARY, the printer should be mapped to logical printer number 15.
2 Set the History Log Number (HL) attribute of each process object that will be
included in the event log. The number is given as a bit mask. For more information
on the HL attribute, see the Application Objects manual.
130 ABB Automation

Configuration Manual 14 System Configuration Tool
14 System Configuration Tool
This chapter describes the System Configuration tool that is situated in the Micro-
SCADA Tool Manager System Configuration page.
This tool manages the configuration of the following objects:

• Integrated link for PC-NET.
• PC-NET.
• LonTalk (LON), SPA, IEC, DNP 3.0, LCU500, RP570, RP571, MODBUS RTU
and MODBUS ASCII protocol lines.
• REx, SPA, LMK, IEC, DNP 3.0, LCU 500, SPI, PLC and RTU stations.
• LON Clock Master and LON Star Coupler.
14.1 Main Functions
System Configuration tool includes the following main functions:

• Configuration of the base system and the PC-NET(s).
• General mechanism for the base system configuration at system start-up.
• General mechanisms for automatic starting and configuration of the PC-NET(s).
• Online monitoring of the base system and the NET configurations.
• Configuration of transceiver information and node and subnet numbers of the
PCLTA card.
• Debug support.
System Configuration tool can handle base system objects such as links, nodes, sta-
tions and station types. It can operate in online or offline mode. A combination of the
two is not supported. When operating in offline mode, a configuration can be set up
without physical connections to the devices. If the tool is switched to online mode, the
existing configuration is read from the current MicroSCADA base system. Stopping
and starting the NET and the initialisation of the PCLTA card can only be done in
online mode.
During the configuration, the configuration data is read from the permanent configu-
ration file using the offline reading mechanism, or from the MicroSCADA system
(SYS 500 or COM 500) using the online reading mechanism. The tool does not dis-
tinguish between the two methods of reading the data. After the data has been read,
the current configuration is displayed in the tool.
System Configuration tool includes a function which checks the attribute limits. If
there is an invalid attribute value, it returns a string, which requests the user to enter a
valid value. The tool also suggests default values for the attributes.
ABB Automation 131

14 System Configuration Tool Configuration Manual
Debug Support
For debug support, System Configuration tool provides a mechanism to view the in-
terpreted command lines, which are constructed from the configuration view.
In the case of invalid configuration interpretation, possible SCIL errors are echoed in
the MicroSCADA Notification window. SCIL errors are also saved in a log file.
14.2 Starting the Tool
To start the System Configuration tool, double-click the System Conf tool icon in the
MicroSCADA Tool Manager System Configuration page. See Figure 24.
Figure 24. System Configuration tool in MicroSCADA Tool Manager System Con-
figuration page
The System Configuration tool page includes a menu bar and a tool bar, which can be
selected from the Settings > Toolbar Visible menu. Below the tool bar, 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 and a status bar at the
bottom of the page.
Figure 25. Menu bar, tool bar, object tree and attribute tree in the System Configu-
ration tool
132 ABB Automation

14.3 How to Handle the Object and Attribute Trees
When an object is selected from the object tree, all attributes linked to it are shown in
the attribute tree (if All Attributes is selected as the View option). See Figure 25. The
working order is from left to right: after selecting an object in the object tree, an at-
tribute 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 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. See Figure 26.
Figure 26. Expand and collapse buttons for the attribute tree
14.4 How to Save a Configuration from a Former Release
If a configuration from a former MicroSCADA release is read into the System Con-
figuration tool, it can be saved with the Configuration > Save Active command. It will
be saved in the default files Sysconf.ini and Signals.ini.
The configuration is available, when MicroSCADA 8.4.2 or subsequent

sys_bascon.com (sys_bascon$com) template is taken in use.
14.5 How to Create a New Configuration
From the menu bar, choose Configuration > New.
This command opens a configuration that is delivered with the System Configuration
tool. It includes an Object tree with Link 3 (INTEGRATED) and Node 3 (NET). See
Figure 25.
If there is a configuration open in the tool already, all the configuration data is cleared
from the tool and the contents of the Object tree is replaced with the default configu-
ration. To save the open configuration first, the Sysconf.ini and Signals.ini files in the
sys/active/sys_ folder should be copied or renamed.
14.5.1 Methods for Adding New Objects
1 From the object tree, select a parent object for the new object.
ABB Automation 133

Figure 27. Node 3 (NET) selected to be the parent object
After you have selected a parent object, there are three ways of adding objects to the
configuration.
2 Use one of the following methods:

• Use the keyboard command Ctrl+N.
• Use the menu bar command Object - New. See Figure 28.
Figure 28. A new object is added by using the menu bar command.
• Click the Object creation tool icon in the toolbar.
3 Select the object type and click Insert.
134 ABB Automation

Figure 29. A LON Line will be added to the configuration
4 Enter the object number in the text box and click OK. See Figure 30.
Figure 30. Number five is entered for the new line object
The new object is added to the object tree.
14.6 Default Configuration
The default configuration is stored in a configuration file called Sysconf.ini.
To open the default configuration file:
From the menu bar, choose Configuration > Open Active.
The default configuration is loaded in the tool. The tool is opened in offline mode,
which is shown in the status bar.
To save a configuration as the default configuration:
From the menu bar, choose Configuration > Save Active.
This command saves the configuration currently open in the tool as the default con-
figuration in the Sysconf.ini file. The configuration can be saved at any time and this
can be done in both online and offline mode.
ABB Automation 135

! In online mode, only the objects that are In Use are saved with Configuration > Save
Active command.
14.7 Online Configuration
The online configuration is the current configuration in the MicroSCADA system.
Loading:
To load the current MicroSCADA system configuration in the tool, choose Con-
figuration > Open Online.
This changes the System Configuration tool to online mode.
Under MicroSCADA Configuration node there is a node called Station Type Defini-
tions. See Figure 31. This object includes all different station types and it appears,
when MicroSCADA Configuration node is expanded. Deletion of this object is not
possible.
136 ABB Automation

Figure 31. Station type definitions in online configuration
Saving:
If the online configuration is saved using the command Configuration > Save Active,
the following notification dialog appears:
"Saving online configuration overrides current active configuration in files. If e.g.

some stations do not communicate in online mode for some reason, they are re-
moved from the active configuration. Proceed?"
• Clicking Yes overrides the current active configuration in the System Configura-
tion tool and saves the online configuration as the default configuration.
• Clicking No cancels the save operation.
! If the menu bar command Configuration > Save Active is selected, the configuration
must include a Link object and a NET Node object related to the Link.
ABB Automation 137

If the Link object and/or the NET Node object are not present, the PC-NET will not
start up successfully. Therefore it is not possible to save this kind of invalid configu-
ration with the Save > Active command.
14.8 How to Change the Attribute Values
When an object is selected from the configuration tree, all attributes linked to that
object are shown in the attribute tree (if All Attributes is selected as the View option).
The attribute tree consists of attribute groups, which can be expanded to show all the
attributes in the group. The attribute tree can be expanded and collapsed using the +
and - buttons that are situated below the tree. The attributes are illustrated by an icon,
a two-letter abbreviation, name and the valid value.
Figure 32. Some of the MicroSCADA Configuration item attributes in the expanded
attribute tree
The attributes are given default values by the tool. Most of the values can be changed.
However, if the value in the editing area is shown dimmed, no editing is allowed.
The working order is from left to right:
1 Select an object in the Object Tree.
138 ABB Automation

2 Click the + button under the attribute tree to expand all the attribute groups.
3 Select the attribute that you want to configure.
4 Change the value in the editing area and press Enter.
In the attribute editing area, the on/off values have a check box. An empty check box
means off (0) and a checked check box means on (1). For integer values, there is a
numeric spinner in the editing area. See Figure 33.
The attribute tree is updated when changes are made in the editing area.
Figure 33. Editing the PS attribute value with the numeric spinner
14.8.1 Station Address
For communication units, the default SA attribute value is 200 + Node number. If
Node number is set bigger than 55, the default SA attribute value set by System Con-
figuration tool is 255.
14.9 How to Take Configuration in Use or Out of Use
When taking LONWORKS lines and stations in use in the PC-NET, it is essential for
the line to be taken in use before any station (on that specific line) is taken in use.
Likewise, all stations must be taken out of use before the line is taken out of use.
To take the configuration in use, you have to change the IU attribute values to In Use
mode in the System Configuration tool:
1 From the menu bar, choose Configuration > Open Active (if it is not open already).
2 In the Object tree, select the line you want to take in use. See Figure 34.
Figure 34. The LON line number five is selected in the Object tree
ABB Automation 139

3 In the Attribute tree double-click the text Basic Line Attributes (or click the + sign
beside the text). See Figure 35.
This will expand the Basic Line Attribute group and show all attributes in it.
Figure 35. Line five (LON) attribute groups
4 If the IU (In Use) attribute value is 0 (Not In Use), change it to 1 (In Use) in the
following way:
1. In the Attribute tree, click the IU attribute line.
2. In the attribute editing area, click the IU check box checked (In Use state).
Figure 36. IU Attribute in the In Use (1) state
5 From the menu bar choose Configuration > Save Active.

After you have taken the line in use, you can take the stations in that line in use as
well.
14.10 How to Delete an Object
Objects can be deleted from the Object tree by selecting the object and choosing Ob-
ject > Delete from the menu bar (or pressing Ctrl+D on the keyboard).
If the object includes user-defined SCIL programs or signals, those are deleted as
well.
140 ABB Automation

Figure 37. Station 2 will be deleted
The main object (MicroSCADA Configuration object) can not be deleted.
14.11 Cut, Copy and Paste Functions; Reallocating Stations
It is possible to cut, copy and paste the already defined objects in the configuration
tree. When Cut operation is chosen the copied object is also deleted from the configu-
ration tree.
During Cut/Copy and Paste operation all the related information is copied and reallo-
cated. This includes attribute values, possible user-defined SCIL programs (stations,
NET Lines and NET Nodes) and signals (REx, LMK and SPA points).
Cut and Copy
1 Select the object to be cut or copied from the configuration tree.

2 From the menu bar choose Edit>Cut or Edit>Copy.
The selected object will be cut or copied to the clipboard.
During the Edit-Cut/Copy operation the contents of the signal data for the REx, LMK,
SPA and LON Clock Master devices, as well the data structure, is assigned to the
clipboard.
! Cutting of an object is not possible, if the selected object includes child objects.
Paste
1 In the configuration tree, select the parent object for the object on the clipboard.
2 From the menu bar choose Edit > Paste.
The pasted object will be a child object for the selected parent object.
ABB Automation 141

During the Edit > Paste sequence, the possible signal data is taken into use from the
clipboard. (This concerns REx, LMK, SPA and LON Clock Master devices only.)
The System Configuration tool guards against incorrect configuration: It is not possi-
ble to paste a SPA device directly under a LON line (an LMK device is needed) or to
paste an LMK device under a SPA line.
Paste As Range
The configuration object that was copied into the clipboard can be pasted several
times. The paste object number collection is based either on the definition of the
minimum and maximum object numbers (e.g. from 1 to 10) or on the definition of in-
dividual object numbers (e.g. 4, 5, 8, 10). The Paste As Range function can be found
in the Edit menu.
Figure 38. The minimum object number is defined one and the maximum object
number 10
If the copied object includes a set of child objects (e.g. copied LMK station includes
several SPA stations), the pasting of the object (LMK station) does not include past-
ing of the child objects (SPA stations). If there is a need to copy also child objects,
they have to be copied separately.
System Configuration tool includes error handling during pasting of objects.
14.12 Preview Function
The contents of a currently open configuration file can be displayed in the tool using
the Preview function. In this function, the data is shown in SCIL clauses.
To show the configuration data:
From the menu bar, choose Configuration > Preview.
142 ABB Automation

Figure 39. Preview options
The SCIL clauses are displayed in the SCIL Editor.
! SCIL programming is NOT possible by using the Preview function.
14.13 User-Defined Programs
It is possible to make user-defined SCIL programs for the NET Node, NET Line and
Stations. With these programs it is possible to modify lines and process units with
features, which are not yet supported by the configuration tool. For the NET, you can
create protocols and devices, which are not yet supported for the lines in the System
Configuration tool.
Figure 40. The symbol for the user-defined programs is disabled
In the status bar of the System Configuration Tool, there is information for user-
defined SCIL programs with the following meanings:
• If an enabled symbol exists, the selected object includes a user-defined SCIL pro-
gram.
• If a disabled symbol exists, it is possible to include a user-defined SCIL program
for the selected object, but nothing has been attached yet.
• If no symbol exists, it is not possible to include a user-defined SCIL program for
the selected object.
1 Select the object to be modified.
ABB Automation 143

If the symbol exists in the status bar, you can modify the SCIL program or create a
new one.
2 From the menu bar, choose Program > User-Defined.... See Figure 41.
Figure 41. The SCIL Editor will be opened
3 Edit your program using the variables listed in the comments of the program.
Figure 42. Net3.scl file in the SCIL Editor
4 Update and exit the program editor.
14.14 General Object Handling Command
This attribute is included in the System Configuration tool, when the tool is used in
online mode.
1 Select a REx station in the Object tree.

2 From the menu bar, choose Tools > General Object Handling Command.... See
Figure 43.
144 ABB Automation

Figure 43. The General Object Handling Command dialog will be opened
A dialog box is opened. See Figure 44.
3 Enter the appropriate values.

If you click Send, the command is sent to the selected REx Station. Close button
closes the dialog without sending any command.
Example:
Figure 44. General Object Handling Command dialog with example values
If you enter the same value definitions that you can see in Figure 44 and click Send
(or press ENTER on the keyboard), the following SCIL command is sent to the REx
station number one:
#SET STA1:SGO = (1, 1342, 3, 4, 2, 0, 1)
14.15 System Self Supervision
System Self Supervision is always dedicated into certain MicroSCADA application,

i.e. into sets of command procedures, event channels, time channels, process objects,
data objects and parameter files. System Self Supervision functionality can be enabled
in the MicroSCADA application, either installing the first picture function from the
LIB500 System Self Supervision package or by selecting the enabled state from the
System Self Supervision dialog in System Configuration Tool.
ABB Automation 145

In the System Configuration tool, choose Settings > System Self Supervision from the
menu bar. The dialog shown in Figure 45 opens.
Figure 45. In this dialog, system self-supervision can be enabled or disabled
When the System Self Supervision functionality is enabled in MicroSCADA applica-

tion, the System Configuration Tool doesn’t create supervision routing objects for all
included configuration objects as a default. This means that the user has to select the
appropriate option from the dialog. To be able to remove the supervision routing ob-
jects from previously included configuration objects, requires also setting of that op-
tion in the System Self Supervision dialog.
If no picture function is installed from the LIB500 System Self Supervision package,
when System Configuration Tool is accessed for the first time and this dialog is
opened, the System Self Supervision is in disabled state. Also as default, to remove
supervision routing from all previously included configuration objects, requires set-
ting of that option in the System Self Supervision dialog.
If the System Self Supervision dialog is accessed, when previous

SYS_BASCON.COM template is being used, an information dialog is displayed. See
Figure 46. To enable the system self-supervision routing, the base system object
definition (SYS:B) has to include a new attribute called B_SSS_MECH_IN_USE. An
example of this attribute can be found from the new template in the file
SYS_BASCON$COM.
146 ABB Automation

Figure 46. This dialog informs the user that the current SYS_BASCON.COM tem-
plate must be replaced to enable the system self-supervision
When the old SYS_BASCON.COM is used during start-up of MicroSCADA, the ed-
iting of the System Self Supervision dialog is disabled.
If new SYS_BASCON.COM template is being used during start-up of MicroSCADA

it is possible to stop and start the run-time supervision routing in the application.
Stopping and starting is occurred by using the appropriate dialog item in the bottom of
System Self Supervision dialog. An information dialog is displayed to tell, whether
the starting or stopping of the run-time supervision was successful or not.
Supervision Log
The System Configuration Tool includes also access to Supervision Log. To enter the
Supervision Log dialog, choose Tools > Supervision Log from the menu bar.
The Supervision Log displays all the different events in MicroSCADA and the Win-
dows NT system. See Figure 47. Different log types are: common system messages,
unknown process objects, system events from operating system, security events from
operating system and application events from operating system.
To select the log type, choose the Log from the menu bar and select the appropriate
log type from the menu items. For the events shown in the view, there is possibility to
set a different filter condition, e.g. events from certain station number.
ABB Automation 147

Figure 47. MicroSCADA Supervision Log in System Configuration tool
14.16 Signal Engineering
System Configuration tool is integrated to subtools for handling signal information for
devices. For each device type, there exists a corresponding configuration tool for
managing signal information. These subtools can be launched by selecting Tools >
Signal Engineering... from the menu bar. The configuration page that is opened in-
cludes all signal information for the selected station.
The signal information transfer from the subtool is executed by choosing Configura-
tion/File > Update from the subtools menu bar. Information is also transferred to the
System Configuration tool, when Configuration/File > Exit is chosen. In each of the
subtools, there is a possibility to cut, copy and paste signal information.
Indicator for Signal Information
In the status bar of the System Configuration Tool, there is an indicator for signal in-
formation with the following meanings:
• If an enabled symbol exists, the selected object includes signal information.
148 ABB Automation

• If a disabled symbol exists, it is possible to include signal information for the se-
lected object, but no signals has been created yet.
• If no symbol exists, it is not possible to include signal information for the selected
object.
Figure 48. The indicator shows that the selected object includes signal information
14.16.1 Signal Engineering on Station Level
The following features are common to all devices:

• When a station is selected in the configuration tree, the attribute area becomes
updated.
• The signal information of the selected station can be seen, if Tools - Signal Engi-
neering... is chosen from the menu bar. This operation opens the station Configu-
ration page.
• Managing the signals is performed via Add..., Edit... and Delete buttons in the
Configuration page.
Add / Edit
Add and edit operations open the signal Add/Edit dialog for entering or changing sig-
nal information. The user interface of this dialog depends on the station type.
OK
OK button accepts the entered values into the signal list of the device and closes the
Add/Edit dialog.
Cancel
Cancel button cancels the add/edit operation and closes the Add/Edit dialog.
Apply
Apply button accepts entered values into the signal list without closing the dialog.
• When a device configuration tool is closed, the signals related to the selected de-
vice are transferred to the System Configuration tool. When Configuration - Save
Active is chosen, these signals are saved into the configuration files and they be-
come a part of the configuration data. The device signals are interpreted auto-
matically, when the NET communication is starting.
ABB Automation 149

• SCIL commands which are constructed from the device signals, can be seen by
choosing Configuration - Preview... from the System Configuration tool menu
bar.
To edit signal information:
1 In the Object Tree, select the station to be engineered.

2 Choose Tools - Signal Engineering... from the menu bar. See Figure 49.
The station configuration page opens and it can be edited.
Figure 49. The station configuration page will be opened
Advanced Page; Topic Configuration
In some stations (PLC, for example), topic configuration is shown in the Advanced
page.
Figure 50. The topic information of a PLC station is shown in the Advanced page of
the System Configuration tool
150 ABB Automation

A new topic item can be added by clicking Add, which opens the Add Topic Item
dialog. See Figure 51. In this dialog, the default topic type is object command or the
type of the last added topic item. The maximum number of topic items for each device
is 100. If the station already includes 100 topic items, the Add button is disabled.
Figure 51. New topic item Object Command is to be added to a PLC station
Existing topic item can be deleted by selecting the appropriate item in the list and
clicking Delete. Before the delete operation is occurred, a notification dialog is dis-
played to the user. Clicking Yes deletes the selected topic item and refreshes the list.
Clicking No cancels the delete operation.
An existing topic item is edited by selecting the appropriate topic item in the list and
clicking Edit... or double-clicking the topic item. The selected topic items are dis-
played in the Topic Configuration Editor with the existing definitions. See Figure 52.
In this dialog, the topic type, allocation, first object address, last object address, base
address, format, interval and deadband are defined.
Figure 52. In this dialog, an existing topic item can be edited
ABB Automation 151

Note that with indication type, one object address (OA) contains 16 bits and it in-
cludes both single and double indications.
Allocation
This item specifies if the topic is in use or not. The memory needed for the topic is re-
served when topic is taken to use. Values: Enabled or disabled.
First Object Address
This parameter specifies the first object address used with this topic. Object address
and object type parameters together specify the actual process object address (OA),
where the first item in the topic is stored. Values: 1 … 4096.
Last Object Address
The object address of the last item of topic. Values: 1 … 4096. The number of items
reserved by the topic is calculated the following way:
Number of items = Last object address - First object address
Base Address
The address of first item of topic in the device's memory. Values: 0 … 4096.
Format
Specifies how the data is stored in an external device.
Interval
The frequency that the data of topic is read from external device. The interval units
are milliseconds. If the interval is 0, the topic is not polled. Values: 0 … 65535.
Deadband
If the type of topic is an analog value, then the deadband value is used to minimize
amount of updating messages from the PC-NET to the base system. The new analog
value is sent to the base system, when the change or sum (integral) of changes is big-
ger than the deadband. Values: 0 … 65535.
152 ABB Automation

Configuration Manual 15 NETCONF Tool
15 NETCONF Tool
This chapter describes the preconfiguration tool, NETCONF. The tool is used for the
preconfiguration of DCP-NET. The tool runs under the DOS operating system. and
performs the same tasks as the NET PRECONFIGURATION tool.
15.1 Requirements
The NETCONF program requires a PC computer running under the MS-DOS operat-
ing system with 286 processor or later and at least 512 kB memory. Running
NETCONF requires at least 1 MB free disk or diskette memory.
15.2 Installation
To install the NETCONF program:
1 Create a subdirectory for NETCONF.

If you want to install NETCONF on the C: drive in the NETCONF directory enter
the following command
MD C:\NETCONF
If you are using the Windows NT operating system:

1. In the Windows NT Explorer (Start - Programs - Windows NT Explorer) select
drive C:.
2. In the menu bar choose File, point New and click Folder.
3. Enter the name NETCONF to the created folder.
2 Copy the NETCONF program from the MicroSCADA installation CD to the
newly created directory. The NETCONF program can be found in directory
\Frontend\netconf on the CD.
If you have the installation CD in drive E: and want to copy the program to
C:\NETCONF enter the following command:
COPY E:\FRONTEND\NETCONF\NETCONF.EXE C:\NETCONF

1. In the Windows NT Explorer:
2. Double-click the CD drive.
3. Double-click the folder FRONTEND.
4. Double-click the folder NETCONF.
5. Select the file NETCONF.EXE, and press Ctrl+C on the keyboard.
6. Select the file NETCONF in the drive C:, and press Ctrl+V on the keyboard.
ABB Automation 153

15 NETCONF Tool Configuration Manual
15.3 NETCONF Tool Basics
Use
The NETCONF tool is applied for viewing, adding, modifying, copying and docu-
menting the preconfiguration parameters stored in the communication programs. It
can also be used for verifying the consistency of communication programs.
The NETCONF tool runs under the DOS operating system. It is therefore convenient
to use NETCONF for the preconfiguration of stand-alone communication units. There
is also a tool for preconfiguration handling during MicroSCADA operation. The tool
performs the same tasks as NETCONF and is to be preferred when internal frontends
are preconfigured. For information on this tool see chapter 15.
The preconfiguration tools should only be used by the system managers.
Files
The NETCONF tool can recognise and handle two types of files:
• Communication program files including configuration data.
• Journal files, which contain only the preconfiguration data, not the entire commu-
nication program. These files are created by NETCONF or the NET
PRECONFIGURATION tool and can be used exclusively by NETCONF and the
NET PRECONFIGURATION tool. The journal files can not be used in a running
communication unit.
Buffers
The NETCONF tool can use two buffers:
• A base buffer containing the configuration data to be modified. This data is called
base data.
• If needed, an extra buffer which can contain configuration data to be viewed or

copied. This data is called extra data.
The base buffer must always be loaded with a communication program. The extra
buffer can contain a communication program or a journal file.
Menu Selections
The NETCONF program is used through a number of menus: one main menu which
goes horizontally uppermost on screen and a number of sub-menus in the shape of
drop-down menus. The drop down menus in turn can contain other sub-menus. A
menu selection is indicated by a highlighted cursor which is moved by the arrow keys,
Home and End, see below. The Esc key performs a return to the previous level of
menus.
154 ABB Automation

In order to select a menu option:
1 Move the highlighted cursor to the menu item.

2 Press Enter.
Figure 53. The NETCONF startup screen
Keyboard Keys
The keyboard keys are used in the following way:
Enter Execution. The key executes the option selected by the highlighted
cursor.
Esc Return. The key exits the current menu and returns to the previous
menu, i.e. the menu one step upwards in the menu hierarchy. In the
main menu this key exits the NETCONF program without storing
the made modifications.
Up/Down Arrow Up/down. In the drop-down menus, the keys move the highlighted
cursor one step up and down respectively.
Left/Right Arrow Left/right. In the main menu, these keys move the highlighted cur-
sor to the left and to the right respectively.
Home First option. The key moves the highlighted cursor to the first op-
tion in the menu.
End Last option. The key moves the highlighted cursor to the last op-
tion in the menu.
F1 Help. The key displays a help text. If no help text is available, an

error message is shown.
F2 , space Direct selection. The key enables a direct selection of another de-
vice of the same type. If you, for example, want to edit line 9 while
ABB Automation 155

you are editing line 3, press F2, type 9 and press Enter. Return to
line 3 by pressing F2, 3 and Enter.
F3, PgDn Next item. The key browses to the next object of the same type.
F4, PgUp Previous item. The key browses to the previous object of the same
type.
F5, Tab This key works only for stations of type Allen-Bradley. The key
displays a window containing the configuration data of the mem-
ory rung of the actual station, starting from memory rung number
1.
F9 Options. This key displays a window with a number of options,

e.g. the display format of the attribute data. See the "Options" in
section 15.4.
F10, Esc Return to previous level.
15.4 Using NETCONF Tool
Start-up
To start the NETCONF program:
1 Move to the NETCONF directory.

If NETCONF was installed an the C: drive in the NETCONF directory, enter the
following commands:
C:
CD \NETCONF
2 Start the NETCONF program by entering:

NETCONF [-M] [file]
Start-up from the Windows NT Explorer:

1. In the C: drive double-click the NETCONF folder.
2. Double-click the file NETCONF.EXE.
By default the program uses colour mode. Including the optional argument -M means
that the program will be run in monochrome mode. The mode can also be selected
during program execution, see the "Options".
The optional argument ’file’ means the name of the file to be loaded to the base buffer.
The file must be a communication program file. The file can also be loaded after the
program has been started.
The screen gets the appearance shown in Figure 53.
156 ABB Automation

Before you load a file to the NETCONF tool, make sure you have a backup copy of
the file.
Loading Base Buffer
If at the start-up no file name was given, a file must now be loaded into the base
buffer. Load the communication program to be configured, viewed, copied, docu-
mented or verified in the following way:
1 Select "Load".
2 Select "Base NET-Data (and File)" and enter the name of the communication pro-
gram to be loaded into the base buffer. The file name should include the path if the
file is located in another directory than the current one.
While NETCONF loads the file, it verifies the consistency of the file.
Checking input file ...

Loading main buffer from file ....
When the file has been loaded successfully, the following message is displayed:
*** File read OK ***

[8.4.2/X8]
[DCP-CARD]
OK
If the loading did not succeed, one of the following messages are displayed:
*** Modules Missing***
Frame Checksum ERROR
or
Can’t access input file: ....
The last error message indicates that the file cannot be found. Check that you have
typed the name of the file correctly.
Now you can continue in any of the following ways:
• By modifying the preconfiguration in the base buffer and storing the new configu-
ration.
• By loading the extra buffer with a communication program or a journal file. This
enables you to easily copy the preconfiguration from another file.
• By viewing the configurations in the base and extra buffers.
• By documenting the base buffer.
ABB Automation 157

Loading Extra Buffer
In order to load a file into the extra buffer:
1 Select "Extra Data from NET-File" in order to load a communication program, or

select "Extra Data from Journal-File" in order to load a journal file.
2 Enter the name of the file, including the path if the file is located in another direc-
tory then the current one.
Options
The appearance and function of the NETCONF program itself can be changed in the
following way:
1 Select "Options" in the main menu, or press F9. F9 can be pressed any time.
The following options can be selected:
Toggle Screen Colors This item toggles between colour and monochrome display
mode
Disable Field Check Toggles the field check state
Enable Field Check When field check is on, the cursor cannot be moved up and
down with the arrow keys, unless the Enter key has been
pressed
Display Format The attribute values can be displayed and entered in three
different ways:
Numeric 5-Dig: The values are displayed with five
digits with leading zeroes
Numeric: Values are displayed numerically
without leading zeroes
Text-format: Values are displayed as texts where
applicable
Disable This NET Conf. Normally, it is possible to change the attributes of the cur-
rent NET. By means of this option changes can be disabled.
Enable This NET Conf. Enables attribute changes in the current NET
The "Options" menu also provides means for using DOS without exiting NETCONF,
see "Using DOS Gateway" in this section.
Viewing the Configuration
To view the configuration:
1 Select "Show" in the main menu.

2 Select "Summary" to get a summary of both the base data and the extra data.
158 ABB Automation

or
3 Select "Base Data" to get a detailed description of the configuration in the main
buffer.
or
4 Select "Extra Data" to get a detailed description of the configuration in the extra
buffer.
The detailed descriptions have the same appearance and menu structure as the "Mod-
ify" option, except that no changes can be performed. For more information on the
"Modify" option, see below.
Modifying the Configuration
To modify the configuration:
1 Select "Modify" in the main menu.

2 Select the item, which you are going to configure:
"This node" For modifying the attributes of the current NET
"Lines" For adding and modifying the lines
"Stations" For adding and modifying stations (STA objects)
"Printers" For adding and modifying printers (PRI objects)
"Applications" For defining applications to NET
"External Nodes" For defining other NETs, base systems and
NET objects
"Memory Rungs" For modifying the memory rungs of stations of ANSI
type
"Digitizers" and "Monitors" are not used in the current version of MicroSCADA.
When a new device is added, a "Device Type" is requested. NETCONF uses the fol-
lowing names and code numbers for the device types:
1 APL Application
2 NOD Node: a communication unit or a base system
3 STA Stations on ANSI lines
4 RTU S.P.I.D.E.R. RTUs
5 SIN Stations of type SINDAC using the ADLP80 protocol
6 PCL Stations of type P214
7 SID Stations of type SINDAC using the ADLP180 protocol
8 PAC Stations of type PAC-5
ABB Automation 159

9 SAT Stations of type SATTCON using the COMLI

protocol
11 PRI Printer
20 LCU Stations of type Load Control Unit
21 SPA SPACOM
22 SPI S.P.I.D.E.R./RP570
To modify an attribute line:
1 Move the highlighted cursor to the line and press Enter.

2 Type a new value for the selected attribute and press Enter.
The attributes of the own NET ("This Node") can not be changed if the option "Dis-
able this NET Conf." has been selected.
To delete an object:
1 Set the "Device type" to "not" or 0.

The line protocol can be given by a code number or a text abbreviation. The following
code numbers and abbreviations are used:
1 XF ANSI X3.28 Full Duplex or MicroPROTOCOL
2 XH ANSI X3.28 Half Duplex
3 RM Common RAM
4 AS ASCII
7 SR RP570
8 AD ADLP80
9 PR P214
10 AL ADLP180
11 CL COMLI
12 LC LCU500
13 AM ALDP180 Master
160 ABB Automation

14 SP SPA
15 AG ASCII General
16 RP RP570 Slave
Copying the Configuration
1 Select "Copy" in the main menu.

The configuration of the extra buffer can be copied to the configuration of the base
buffer and vice versa. In order to copy the configuration of the extra buffer to the base
buffer:
2 Select "Ext. -> Base".

3 Confirm the copy operation by selecting "OK".
In order to copy the data from the extra buffer to the base buffer:
4 Select "Base -> Ext.".

5 Confirm by pressing Enter.
The configuration is always copied completely. Individual devices can not be copied,
neither inside a buffer nor between buffers.
Documenting the Configuration
The NETCONF tool can be used to create a text file containing the preconfiguration
in text format. To do this:
1 Select "Save" in the main menu.

2 Select "In Document File".
3 Select the format: of the document "Brief Doc.", "Normal Doc." or "Full Doc.".
The "brief" document gives an overview of the configuration, including line protocols
and connected devices, but no attributes. The "normal" document lists all devices and
line including their attributes. "Full" means that both types of documents are pro-
duced.
4 Enter file name. Recommendation: give the file name the extension .DOC to dis-
tinguish it from the program and journal files.
Saving the Configuration
The configuration can be saved in the communication program, whereby the former
configuration is lost, or it can be saved as a journal file. If the configuration will not
be used directly in a communication program, a journal file is recommended because
the journal files are smaller than the communication files.
ABB Automation 161

To save the configuration:
1 Select "Save" in the main menu.

In order to save the preconfiguration in the communication program which must have
been loaded as base buffer:
2 Select "In NET file" and enter the name of the file.
Recommendation: Give the communication program such a name that the node num-
ber appears from it, e.g., NETnn.84, where ’nn’ is the node number.
In order to store the preconfiguration as a journal file:
1 Select "In Journal File" and enter the name of the file.
Recommendation: Use the extension .JOU for journal files.
Using DOS Gateway
This option is found in the "Options" menu. It enables the use of DOS commands
without exiting the NETCONF program:
1 Select "DOS Gateway".

2 Enter the DOS commands.
In order to return to NETCONF:
3 EXIT and press Enter.
162 ABB Automation

Configuration Manual 16 NET Tool
16 NET Tool
This chapter describes the online preconfiguration tool, which is used for the precon-
figuration of the DCP-NET. The tool is located in the Tool Manager System Configu-
ration page.
Figure 54. Starting the NET configuration tool
16.1 NET Tool Basics
Use
The NET tool is applied for viewing, adding, modifying, copying and documenting
the preconfiguration parameters stored in the communication programs. It can also be
used for verifying the consistency of communication programs.
The preconfiguration tool should be used by the system managers only.
Files
The NET preconfiguration tool can recognize and handle two types of files:
• Communication program files including configuration data.
• Journal files, which contain only the preconfiguration data, not the entire commu-
nication program. These files are created by the NET configuraton tool and can
be used by this tool exclusively. The journal files can not be used in a running
communication unit.
Buffers
The NET preconfiguration tool uses three buffers. Each of these buffers can be loaded
with a communication program or a journal file.
ABB Automation 163

16 NET Tool Configuration Manual
Function Keys
Start the NET preconfiguration tool by clicking the NET PRECONFIGURATION

button in the NET CONFIGURATION page.
Figure 55. The NET CONFIGURATION page
The NET PRECONFIGURATION tool provides a menu of function keys at the bot-
tom of the screen, see Figure 56.
LOAD Loads the program and journal files into the buffers and
stores
SAVE Allows the user to save the files
VIEW Allows the user to view the configuration of the buffers. The
configurations can be displayed in brief or full format.
MODIFY Allows the user to modify the preconfiguration of selected
buffers
COPY Allows the user to copy the complete preconfiguration from
one buffer to another or individual devices of the precon-
164 ABB Automation

figuration within the same buffer or from one buffer to an-

other
MISCELLANEOUS Allows the user to change the display mode of the precon-
figuration data, include or exclude attribute names when
displaying configuration data and check the configuration
Figure 56. The NET PRECONFIGURATION tool
16.2 Using the NET PRECONFIGURATION Tool
Startup
To open the NET PRECONFIGURATION tool:
1 The NET PRECONFIGURATION tool is opened by clicking the NET icon located
on the System Configuration page of the Tool Manager (Figure 54).
2 Click the NET PRECONFIGURATION button (Figure 55).
The window gets the appearance shown in Figure 56.
ABB Automation 165

Before you load a file to the NET PRECONFIGURATION tool, make sure you have
a backup copy of the file.
Loading Buffers
Load the communication programs or the journal files to be configured, viewed, cop-
ied, documented or verified in the following way:
1 Click LOAD SAVE.

2 If you have loaded one or more files into the buffers, select the buffer to load. The
first file loaded is always loaded into buffer 1. A window appears.
3 Enter the name of the file to be loaded. The tool assumes that the file is located in
the SYS_ directory. Change the path if the file is in any other directory.
While NET PRECONFIGURATION loads the file, it verifies the consistency of
the file. If the loading did not succeed, an error message is displayed. e.g.:
*** Modules Missing***
Frame Checksum ERROR
Can’t access input file: ....
The last error message indicates that the file can not be found. Check that you have
typed the name of the file correctly.
Now you can continue in any of the following ways:

• By loading other buffers with a communication program or a journal file.
• By viewing the configurations in the buffers.
• By copying the preconfigurations from one buffer to another.
• By modifying the preconfiguration in the buffers. The configuration of individual
devices can be copied.
• By storing the new configuration.
• By documenting the configurations in the buffers.
Display Mode
The attribute values can be displayed and entered in two ways:

• In numeric format. This is the format used in the attribute descriptions in the
manual System Objects.
• In text format, which means that the attribute values are displayed as short de-
scriptive texts where applicable.
In order to change the view mode of the attribute values:
1 Click MISCELLANEOUS
2 Click CHANGE VIEW MODE.
166 ABB Automation

If desired, the two-letter attribute names can be included in the list of the configura-
tion data. In order to include or exclude the attribute names:
3 Click MISCELLANEOUS.
4 Click ATTRIBUTE NAMES.
Viewing the Configuration
To view the configuration:
1 Click VIEW.
2 Click SUMMARY to get a summary of the configuration in two buffers.
or
Click BUFFER1, BUFFER2 or BUFFER3 to get a detailed description of the con-

figuration in respective buffers.
The detailed descriptions have the same appearance as in the MODIFY option, see
below, except that no changes can be performed.
Modifying the Configuration
To modify the configuration:
1 Click MODIFY.
2 Select the buffer if several buffers have been loaded.
3 Click in the window with the text: PRESS HERE TO SELECT DEVICE TYPE!
4 Select the device type:
THIS NODE For modifying the attributes of the current DCP-NET
LINES For adding and modifying the lines
STATION For adding and modifying stations (STA objects)
PRINTER For adding and modifying printers (PRI objects)
APPLICATION For defining applications to NET
EXTERNAL NODE For defining other NETs and base systems (NET objects)
MEMORY RUNGS For modifying the memory rungs of stations of ANSI type
The device type can be changed any time by clicking the text PRESS HERE TO
SELECT DEVICE TYPE!
The tool uses the following names and numbers for the device types:
1 APL = Application
2 NOD = Node: communication unit or base system
3 STA = Stations on ANSI lines
4 RTU = S.P.I.D.E.R. RTUs
5 SIN = Stations of type SINDAC using the ADLP80 protocol
6 PCL = Stations of type P214
ABB Automation 167
7 SID = Stations of type SINDAC using the ADLP180 protocol

8 PAC = Stations of type PAC-5
9 SAT = Stations of type SATTCON using the COMLI protocol
11 PRI = Printer
20 LCU = Stations of type Load Control Unit
21 SPA = SPACOM
22 SPI = S.P.I.D.E.R./RP570
In order to create a new device of the selected type:
1 Browse to a free device number by clicking on the arrow keys in the upper part of
the window.
2 Click CREATE.
The attributes of the new object get the default values.
In order to modify an attribute:
1 Click the attribute field.

A window appears with a list of possible values.
2 Enter a new value or select one from the list.
In order to delete an object:
1 Browse to the object and click DELETE.
Copying the Configuration
The total configuration of one buffer can be copied to another buffer, or individual
devices can be copied between the buffers or within the same buffer.
In order to copy the complete configuration from one buffer to the other:
1 Click COPY.
2 Enter the number of the source buffer and the number of destination buffer.
3 Click EVERYTHING, CLEARING DEST. BUFFER FIRST. This option clears
the destination buffer before copying the configuration to it.
or
Click EVERYTHING; MERGE. This option adds the configuration definitions

from the source buffer to the destination buffer. If a devices is defined in the
source and destination buffer the definition in the destination buffer will be
changed.
4 Click COPY INFO.
168 ABB Automation

In order to copy individual devices:
1 Click COPY.
2 Enter the number of the source buffer and the number of the destination buffer.
3 Select the device type by clicking on the type.
4 Enter the number of the device to be copied.
5 Enter the destination device number.
6 Click COPY INFO.
Documenting the Configuration
The NET PRECONFIGURATION tool can be used to create an ASCII file containing
the preconfiguration in text format. To document the configuration:
1 Click LOAD SAVE.

2 Click SAVE DOCUMENT FILE.
3 Select the buffer to be documented.
4 Enter the file name.
Recommendation: give the file name the extension .DOC to distinguish it from the
program and journal files.
5 Select the documentation format: “Brief”, “normal” or “full” document by clicking

BRIEF, NORMAL or FULL.
The “brief” document gives an overview of the configuration, including line proto-
cols and connected devices, but no attributes. The “normal” document lists all de-
vices and lines including their attributes. “Full” means that both types of document
are produced.
6 Click CREATE DOCUMENT FILE.
Saving the Configuration
The configuration can be saved in the communication program or it can be saved as a

journal file. If the configuration will not be used directly in a communication pro-
gram, a journal file is recommended because the journal files are smaller than the
communication files.
In order to save the preconfiguration in a communication program:
1 Click LOAD SAVE.

2 Click SAVE IN NET FILE and enter the name of the file.
ABB Automation 169

Recommendation: Give the communication program such a name that the node
number appears from it, e.g., NETnn.84, where ’nn’ is the node number.
In order to save the preconfiguration as a journal file:
1 Click LOAD SAVE.

2 Click SAVE IN JOURNAL FILE and enter the name of the file.
Recommendation: Use the extension .JOU for journal files.
170 ABB Automation

Configuration Manual 17 REx Configuration Tool
17 REx Configuration Tool
The REx Configuration tool is used for making the necessary system object defini-
tions to the PC-NET for the REx type of protection relay units. The definitions are
mostly involving LON/SPA communication and parameters related to command han-
dling of the protection relay. Using REx configuration tool is an alternative for the de-
fault PC-NET configuration stored into PC_NET.COM file. REx configuration tool
produces a file with .cfg extension containing the STA object definitions. To utilize
the configuration file the SCIL command line program proc_rex.scl. must be run.
Although the REx Configuration tool still exists in the Tool Manager, it is recom-
mended to use the System Configuration Tool instead!
17.1 Using REx Configuration Tool
Figure 57 shows the REx Configuration Tool. It is composed of menu bar at the top,
an area for selecting Device Number and two pages. The pages are named Device At-
tributes and SPA Points.
Figure 57. The REx Configuration Tool
The menu bar consists of File, Edit, Device and Help menus. The File menu contains
options for file handling and exiting the tool. The Edit menu contains options for
copying and moving. The Device menu contains options for adding, renaming and
deleting devices. In the Help menu you can choose About dialog, which displays in-
formation about the tool.
Operation
The REx Configuration tool is used according to the same principles as other Win-
dows based applications. The tool is used for off-line REX station configuration to the
PC-NET.
ABB Automation 171
17 REx Configuration Tool Configuration Manual
Opening and Closing
The REx Configuration Tool is opened by clicking the REx Config icon in the System
Configuration page of the Tool Manager.
To close the tool, choose Exit from the File menu.
Opening Files
The configurations are saved in a configuration file.
You can either open a file that already exits or create a new one. To open a file:
1 Choose Open from the File menu. The file chooser appears on the screen.
2 Choose a folder and a file. The default extension for the file is .cfg.
3 Click OK. The configuration file is loaded. If you have not saved changes to the
previous file, you can do it at this point.
Saving Files
To save a file choose Save or Save As from the File menu. The Save option saves the
file with the current name.
The Saves As saves the file with a name user specifies. The default file extension is
.cfg. The default folder and path is \sc\sys\active\sys_. If the specified path does not
exist, a notification appears. If the folder already contains a file with that name, you
are asked if you want to replace the existing file.
Copying
You can copy devices, characters and SPA points. To copy:
1 Select the part you want to copy.

2 Choose Copy from the Edit menu. The part is copied to the clipboard.
3 Place the cursor at the position where you want to insert the copied part.
4 Choose Paste from the Edit menu. A new SPA Point is added to the end of the
SPA Points list.
Moving
You can move devices, characters and SPA points. To move:
1 Select the part you want to move.

2 Choose Cut from the Edit menu. The text is moved to the clipboard.
3 Place the cursor at the position where you want to insert the part.
4 Choose Paste from the Edit menu. A new SPA Point is added to the end of the
SPA Points list.
172 ABB Automation

Adding Devices
To add a device:
1 Choose Add from the Devices menu.

2 In the dialog box that appears, type the name of the device.
3 Click OK. If the device number exists, a notification appears on screen. Click Yes
if you want to replace the previous device with that number. Otherwise click Can-
cel.
Renaming Devices
To change the number of the device:
1 Select the device.

2 Choose Rename from the Device menu and type the new number. Click OK.
Deleting Devices
To delete a device:
1 Select the device.

2 Choose Delete from the Device menu and confirm the deletion by clicking Yes.
17.2 Defining the Device
Device Attributes
The device attributes are defined in the Define Attributes page. The following attrib-
utes can be defined (for more information on the attributes, see the MicroSCADA
System Objects manual):
Allocation AL
In Use IU
Message Identification MI
This attribute is automatically calculated when a new device
is added. The automatic calculation is based on the formula
(1000 + Device Number).
Node Number NN
REx Line Number RX

Running Mode RM
Subnet Number SN
Unit Number UN
Unit Type UT
ABB Automation 173
17 REx Configuration Tool Configuration Manual
SPA Points
The binary output objects of the REX stations are defined in NET as SPA points.
REX commands and SYS process objects are tied together using the SPA point defi-
nition. The main purpose of this definition is to create a cross reference between SPA
items and SYS process object addresses. The purpose of this definition is also to tell
NET how to convert command from SYS to the corresponding SPA command.
The SPA points for REx devices are defined in the SPA Points page. See Figure 58.
One device number can consist several SPA points. To add a new SPA point, click
Add. The point is appended to the end of the list. Enter the following information:
Type 10 (transparent-SPA command def.)
Channel 1 A value between 0...999
Channel 2 A value between 0...999
Data Category The available values are I, O, S, V, M, C, F, T, D, F, T, D,
L, B
Data 1 A value between 1 ... 999999
Data 2 A value between 1 ... 999999
Data Format The available values are bits, hexadecimal, real and longin-
teger
Object Address The base system process object address that is connected to
this SPA point
For more information on the SPA point definition, see the corresponding manual for
the relay.
To modify an existing SPA point, double-click its row in the list or select the row and
click Edit. To delete selected SPA point, click Delete.
Figure 58. The SPA Points page in the REx Configuration Tool
174 ABB Automation

Interpreting the Definitions
To utilize the definitions a interpreter is used. The interpreter is a SCIL command line
program, which takes as input parameter the configuration file name and the default
net number. The output of the interpreter is a collection of #SET commands, which
are automatically executed.
Argument 1 The configuration file name
Argument 2 The default net number
Example:
@rex_test = do(read_text("sys_tool/proc_rex.scl"),"sys_/example.cfg",1)
The interpreter is located in the folder that is referred with logical name sys_tool. The
file name is proc_rex.scl.
An example of the result of the configuration file interpretation.

#SET NET1:SRX1=1
#SET STA1:SAL=1
#SET STA1:SNN=1
#SET STA1:SRM=7
#SET STA1:SSN=1
#SET STA1:SUT=1
#SET STA1:SUN=1
#SET STA1:SMI=1001
#SET STA1:SSP1=(10,12,12,"I",221,221,4,1)
#SET STA2:SSP2=(10,12,12,"I",241,241,4,2)
#SET STA2:SSP3=(10,12,12,"I",261,261,4,3)
#SET STA2:SSP4=(10,12,12,"I",281,281,4,4)
#SET STA2:SSP5=(10,12,12,"I",301,301,4,5)
#SET STA2:SSP2=(10,12,12,"I",321,321,4,6)
#SET STA2:SSP2=(10,12,12,"I",341,441,4,7)
#SET STA2:SSP2=(10,12,12,"I",361,361,4,8)
#SET NET1:SRX2=1
#SET STA2:SAL=1
#SET STA2:SNN=3
#SET STA2:SRM=7
#SET STA2:SSN=1
#SET STA2:SUT=1
#SET STA2:SUN=2
#SET STA2:SMI=1002
#SET STA1:SIU=1
#SET STA2:SIU=1
#SET NET1:SIU1=1
ABB Automation 175

Configuration Manual 18 LMK Configuration Tool
18 LMK Configuration Tool
We recommend that you use the System Configuration tool instead of the LMK Con-
figuration tool.
The LMK Configuration tool is used for making the necessary on-line system object
definitions to PC-NET for LMK stations.
18.1 Using LMK Configuration Tool
Figure 59 shows the LMK Configuration Tool. It is composed of menu bar at the top,
an area for selecting Device Number and three pages. The pages are named Device
Attributes, Diagnostic Counters and LON Points.
The menu bar consists of Configuration, Edit, Device, Net and Help menus. The Con-
figuration menu contains options for fetching the attributes of defined LMK stations
and exiting the tool. The Edit menu contains options for copying and moving. The
Device menu contains options for fetching, sending messages, adding, renaming and
deleting devices.The Net menu contains an option for defining NET Properites. In the
Help menu you can choose About dialog, which displays information about the tool.
Figure 59. The LMK Configuration Tool
Operation
The LMK Configuration tool is used according to the same principles as other Win-
dows based applications. The tool is used for on-line configuring of LMK station, e.g.
LSG devices connected to LON and LONWORKS devices other than REX type sta-
tions.
ABB Automation 177

18 LMK Configuration Tool Configuration Manual
Opening and Closing
The LMK Configuration Tool is opened by clicking the LMK Config icon located on
the System Configuration page of the Tool Manager.
To close the tool, choose Exit from the Configuration menu.
Fetching
Fetching reads the LMK stations from PC-NET. The stations that were found are
listed in ascending order in a device list. If no LMK stations are found, a notification
appears.
Copying
You can copy devices, characters and LON points. To copy:
1 Select the text you want to copy.

2 Choose Copy from the Edit menu. The text is copied to the clipboard.
3 Place the cursor at the position where you want to insert the copied part.
4 Choose Paste from the Edit menu. If you paste a station, you should rename it.
This because every station should have a different number. If you paste a LON
Point, you should edit the NV Index. This because every LON Point should have
its own NV index. A new LON Point is added to the end of the LON Points list.
Moving
You can move devices, characters and LON points. To move:
1 Select the text you want to move.

2 Choose Cut from the Edit menu. The text is moved to the clipboard.
3 Place the cursor at the position where you want to insert the part.
4 Choose Paste from the Edit menu. A new LON Point is added to the end of the
LON Points list.
Cutting the Device or LON Point from the list copies its contents to clipboard. At the
same time it is deleted in the PC-NET. If the cut or deleted LON Point is not the last
one in the list, all points after that are collapsed one index.
Fetching Devices
Fetching reads latest information for a selected device from NET. To fetch, select the
device and choose Fetch from the Device menu. The information appears on screen.
Adding Devices
To add devices:
1 Choose Add from the Devices menu.
178 ABB Automation

2 In the dialog box that appears type the number of the device.
3 Click OK. If the device number exists, a notification appears on screen. Click Yes
if you want to replace the previous device with that number. Otherwise click
Cancel.
When a device is added into configuration, it is expected that the corresponding sta-
tion object is already defined in the base system. A notification appears if it is not de-
fined.
Renaming Devices
You can change the number of the device by choosing Rename from the Device menu
and typing the new number. Then click OK.
Deleting Devices
You can delete a device by choosing Delete from the Device menu and confirming the
deletion by clicking Yes.
Sending Messages
Using the LMK Configuration Tool you can send a LONTALK message to a selected
device. To send a message:
1 Choose Send Message from the Device menu.

2 In the dialog box that appears type the message as hex string.
3 Click Send. The response message is displayed to the received message field. If an
error occurs, a notification appears.
4 Click Close.
NET Properties
Using the NET properties you can specify the default NET number. It is used when a
line is changed from on state to off state. The default NET link number is used when
LON stations are added to the NET. When a LON station is added to a different link,
the default link number should be changed before adding.
To define the NET properties:
1 Choose Properties from the NET menu.

2 In the dialog box that appears type Net Number and Default Net Link Number.
3 Click OK. If an invalid value for NET Properties is given, a notification appears.
The values are accepted, if they do not generate SCIL error code.
It is assumed that when the NET number is changed, the base system contains the de-
finiton for node object with specified number. It is also assumed that when the default
link number is changed, the base system includes the definition for the link object
with the specified number.
ABB Automation 179

18.1.1 Defining the Device
When a station is selected from the Device list, the latest information for that device
is read from PC- NET.
Defining the Device Attributes
The device attributes can be defined by using Define Attributes page in the LMK
Configuration Tool. These attributes are specific to every device number. The fol-
lowing attributes can be defined (for more information on the attributes, see the Mi-
croSCADA System Objects manual):
In Use IU
Allocation Enabled AL
Allocation Application AS
Consistency Check Time CT
Diagnostic Interval DI
Link Number LI
When changing the link number, the link line is first
stopped and then started during set operation.
Message Identification MI
The Message Identification is automatically calculated
when a new device is added
Message System MS
Node Number NN
Object Status OS
Reply Timeout RT
Subnet Number SN
Unit Type UT
General Interrogation GI
Defining Diagnostic Counters
Diagnostic Counters are used to collect information concerning different counters for
the selected device number. The current diagnostic counter value is displayed under
the label Current Value for the specified counter.
The current values for the diagnostic counters can be stored to a data log. To store,
click Store Data Log. Stored diagnostic counter values are displayed under the label
Stored Value for specified counter. Reset Counters operation resets current diagnostic
counter values. To remove the stored diagnostic counter values from data log, click
Remove Data Log. When a data log is stored for the current device number, the values
from the data log are displayed when you open Diagnostic Counters page.
180 ABB Automation

When Diagnostic Counters page is open, the LMK Configuration Tool reads the
counters from NET after every 2 second.
Defining LON Points
LON Points for devices can be defined using the LON Points page. One device num-
ber can consist of none, one or multiple LON points. When a new LONWORKS point
is added, it is appended to the end of the list. The valid LON Point definitions are:
• Digital input.
• Aanalog input.
• Digital output.
• Analog output.
• Struct input.
When the selected LON Point definition does not have some of basic attributes (NV
Index, LON Base Type, SD String, SNVT Type, Process Object Address or Dead-
band), it is displayed as dimmed in LON Point definitions dialog.
To modify an existing LON point, double-click its row in the list or select the row and
click Edit. To delete selected LON point, click Delete.
Figure 60. The LON Points page in the LMK Configuration tool
Initialization File
The initialization file of the LMK Configuration tools uses the Windows initializa-
tion file format. The file is read during the starting procedure of the tool. If an attrib-
ute definition does not exist, the default values are used (Default Net Number is 1,
Default Net Link Number is 1). Below is an example of the initialization file:
[LMKStation]
Default_Net_Number=3
Default_Net_Link_Number=2
ABB Automation 181

The definition for attributes is the following:
Default_Net_Number ;Specifies the default net number used when adding

;or deleting LMK Stations in net.
E.g.
#SET NET3:SLM1=2
Default_Net_Link_Number ;Specifies the default net link number used
;when adding or deleting LMK Stations to link object.
E.g.
#SET NET3:SLM1=2
182 ABB Automation

Configuration Manual Index
Index
Page
#
#CREATE ............................................................................................................................10
#SET ....................................................................................................................................16
A
AA........................................................................................................................................30
ACP......................................................................................................................................39
alarm.......................................................................................................................................4
Allen-Bradley PLC...............................................................................................................77
ANSI X3.28 .......................................................................................................................122
ANSI X3.28/A-B protocol ...................................................................................................77
AP ..................................................................................................................................32, 99
APL ..........................................................................................................................31, 42, 47
APLn
BPR.................................................................................................................................68
APLn:BMO ..........................................................................................................................65
application..............................................................................................................................1
Apply button.......................................................................................................................149
AS...................................................................................................................................32, 99
Attribute group ...................................................................................................................138
Attribute Tree .....................................................................................................................138
Auto-dial ............................................................................................................................124
B
base system.........................................................................................................................1, 2
configuration ..................................................................................................................79
Base System configuration ...................................................................................................29
base system objects ................................................................................................................9
base systems ...........................................................................................................................1
Baud Rate.............................................................................................................................25
BR ........................................................................................................................................25
BREAK TIME ...................................................................................................................119
buffer pool............................................................................................................................49
C
CA ............................................................................................................................27, 30, 74
Cancel button .....................................................................................................................149
CF...................................................................................................................................27, 30
CL.........................................................................................................................................68
CL.........................................................................................................................................30
CLOCK ..........................................................................................................................27, 74
Clock address .......................................................................................................................27
Clock read frequency............................................................................................................27
Clock Type ...........................................................................................................................27
Clock, external .....................................................................................................................74
CMOD..........................................................................................................................23, 112
COM.....................................................................................................................................25
ABB Automation
Index Configuration Manual
COM Port for ASCII General .............................................................................................. 26

COMAG ........................................................................................................................ 26, 74
common RAM ..................................................................................................................... 46
Communicating applications................................................................................................ 33
communicating NETs
example .......................................................................................................................... 60
communication board........................................................................................................... 46
communication front-end ..................................................................................................... 53
Communication loop.......................................................................................................... 116
System architecture ...................................................................................................... 117
Communication Port ............................................................................................................ 25
communication system........................................................................................................... 2
communication system objects............................................................................................. 16
Communication System Objects .......................................................................................... 13
communication unit
configuration............................................................................................................ 78, 79
Communication unit configuration....................................................................................... 51
CONFIG. TIME................................................................................................................. 119
configuration software ........................................................................................................... 6
Copy/Paste ......................................................................................................................... 141
CPNOD........................................................................................................................ 24, 112
CSRC ................................................................................................................................... 24
CT ...................................................................................................................................... 125
Cut ..................................................................................................................................... 141
D
data files
file format....................................................................................................................... 21
data files configuration......................................................................................................... 21
DCD................................................................................................................................... 122
DCP/MUXi .......................................................................................................................... 46
DCP-NET ............................................................................................................................ 14
DD ..................................................................................................................................... 125
DE........................................................................................................................................ 29
Debug support.................................................................................................................... 132
Default configuration ......................................................................................................... 135
Default values .................................................................................................................... 138
Delete................................................................................................................................. 140
DELETE .............................................................................................................................. 10
device................................................................................................................................... 31
DI ......................................................................................................................................... 22
Diagnostic Command Interval ............................................................................................. 22
dial-up ................................................................................................................................ 122
DM....................................................................................................................................... 30
DN ....................................................................................................................................... 29
DS ........................................................................................................................................ 29
DST.............................................................................................................................. 23, 112
DT........................................................................................................................................ 65
DTR ................................................................................................................................... 110
DTU ..................................................................................................................................... 77
DU ....................................................................................................................................... 30
E
EM ....................................................................................................................................... 32
Embedded Response ............................................................................................................ 25
EN...................................................................................................................... 25, 49, 51, 54
ENQ Limit ........................................................................................................................... 25
ABB Automation
ER ..................................................................................................................................25, 29
ERMFD................................................................................................................................91
ERMIR .................................................................................................................................91
event log .............................................................................................................................129
external clock .......................................................................................................................26
external node ........................................................................................................................47
F
front-end configuration.........................................................................................................22
FS .........................................................................................................................................29
FTAB .................................................................................................................................118
G
General Object Handling Command ..................................................................................144
GPS ....................................................................................................................................126
H
HB ........................................................................................................................................32
History Database ................................................................................................................128
HL ......................................................................................................................................130
HOST .............................................................................................................................24, 43
HOST1 .................................................................................................................................55
Hot Stand-by ........................................................................................................................95
NET configuration ........................................................................................................101
HOT_SEND .......................................................................................................................101
HP ......................................................................................................................................129
HR_CLOCK.......................................................................................................................127
I
Initial mode of NET .............................................................................................................23
Interconnected NETs............................................................................................................58
internal NET,........................................................................................................................49
interoperability .......................................................................................................................5
IU .................................................................................................................................17, 122
K
kernel......................................................................................................................................1
L
LAN .....................................................................................................................................43
LI..............................................................................................................................36, 50, 54
line..................................................................................................................................46, 47
link .......................................................................................................................................30
Link ....................................................................................................................................133
LMK...................................................................................................................................177
LONWORKS ...................................................................................................................93
LOAD_DCP .........................................................................................................................17
local application ...................................................................................................................31
log ......................................................................................................................................129
LT.........................................................................................................................................49
M
Mapping ...............................................................................................................................32
Memory allocation ...............................................................................................................48
memory area.........................................................................................................................82
Memory tuning .....................................................................................................................33
message split ........................................................................................................................85
ABB Automation
MFLCONF.DAT ..................................................................................................... 21, 55, 74

MI ............................................................................................................................ 46, 51, 54
MicroPROTOCOL............................................................................................................... 39
MO................................................................................................................................. 32, 99
Mode.......................................................................................................................... 131, 135
MODE ................................................................................................................................. 27
MODIFY.............................................................................................................................. 10
MON.................................................................................................................................... 41
MS ................................................................................................................... 46, 51, 54, 122
MU..................................................................................................................................... 121
MWCONF.DAT .................................................................................................................. 21
N
NA ............................................................................................................... 25, 32, 49, 51, 54
NAK Limit ........................................................................................................................... 25
ND ....................................................................................................................................... 29
NET Station addresses ......................................................................................................... 24
NETn:SSY ........................................................................................................................... 47
Network ............................................................................................................................... 58
example .......................................................................................................................... 60
NN ....................................................................................................................................... 36
NOD..................................................................................................................................... 23
Node....................................................................................................................... 30, 39, 133
node number ........................................................................................................................ 39
Node number of base system ............................................................................................... 23
Node number of Frontend .................................................................................................... 22
O
Object................................................................................................................................. 134
object number ...................................................................................................................... 41
off-line configuration ........................................................................................................... 13
OK button .......................................................................................................................... 149
Online ................................................................................................................................ 136
on-line configuration...................................................................................................... 14, 15
on-line reconfiguration......................................................................................................... 18
Operator workstation ........................................................................................................... 65
P
Parity.................................................................................................................................... 26
Paste................................................................................................................................... 141
Paste As Range .................................................................................................................. 142
PC ........................................................................................................................................ 29
PC_NET.CF1....................................................................................................................... 46
PC-NET ............................................................................................................................... 15
Peer node number of NET ................................................................................................... 24
PM ................................................................................................................................. 32, 75
PO ............................................................................................................................ 51, 54, 75
PQ ........................................................................................................................................ 32
PR ........................................................................................................................................ 32
preconfiguration................................................................................................................... 14
Preview function ................................................................................................................ 142
PRI ....................................................................................................................................... 41
PRIn:SCC ............................................................................................................................ 72
PRIn:SCT............................................................................................................................. 72
PRIn:SPX............................................................................................................................. 72
printer..................................................................................................................................... 4
Printer connection ................................................................................................................ 67
ABB Automation
Programs ............................................................................................................................143
PROT .......................................................................................................................23, 43, 55
Protection Relay ...................................................................................................................91
Protocol ................................................................................................................................23
PS ...................................................................................................................................51, 54
PU ......................................................................................................................................125
PY ........................................................................................................................................26
Q
QL ........................................................................................................................................32
R
Radio clock ............................................................................................................................4
RAM size .............................................................................................................................45
RC ........................................................................................................................................29
RE ......................................................................................................................26, 49, 51, 54
Redundancy..........................................................................................................................26
redundant base system..........................................................................................................95
Redundant Frontend ...........................................................................................................109
REX
LONWORKS ...................................................................................................................93
RF_PRIOBJ .......................................................................................................................115
RF_STAOBJ ......................................................................................................................115
RF_U_CHECK:C...............................................................................................................116
RF_U_LIN:C......................................................................................................................116
RF_U_NETMS:C...............................................................................................................116
RF_U_ONLC:C .................................................................................................................116
RF_U_STA:C.....................................................................................................................116
RN ........................................................................................................................................36
RTU configuration ...............................................................................................................93
RW .....................................................................................................................................125
S
S.P.I.D.E.R. RTU
base system configuration ..............................................................................................89
NET unit configuration...................................................................................................90
SA.................................................................................................................29, 36, 45, 50, 54
Save Active ........................................................................................................................149
SC.........................................................................................................................................99
SCAN TIME ......................................................................................................................119
SCI .....................................................................................................................................114
SCIL commands .................................................................................................................150
SCIL Editor ........................................................................................................................143
SCIL errors.........................................................................................................................132
SCIL programs ...................................................................................................................143
SD ..................................................................................................................................30, 49
SE .................................................................................................................................46, 123
serial communication............................................................................................................25
SET ......................................................................................................................................10
SET_CLOCK .....................................................................................................................127
SF .............................................................................................................................75, 96, 99
SH ..................................................................................................................................29, 99
SHADGLOBAL.................................................................................................................103
SHADGOHOT ...................................................................................................................103
SHADMAPMON ...............................................................................................................103
SHADMAPNET ................................................................................................................103
Shadowing............................................................................................................................96
ABB Automation
SHADREMHOT................................................................................................................ 103
SHADUSR......................................................................................................................... 103
SI.......................................................................................................................................... 99
Signal ................................................................................................................................. 148
Signal Engineering
Station level.................................................................................................................. 149
Signal Information .............................................................................................................149
Indicator....................................................................................................................... 148
Signal information transfer ................................................................................................ 148
SLC-500............................................................................................................................... 77
SN ........................................................................................................................................ 99
SP......................................................................................................................................... 30
SPA
LONWORKS................................................................................................................... 93
SR ................................................................................................................................ 99, 125
SRC................................................................................................................................ 22, 55
SRCNOD ....................................................................................................................... 22, 55
SRIO .................................................................................................................................... 77
system parameters .......................................................................................................... 86
SS......................................................................................................................................... 99
ST .................................................................................................................................. 32, 68
STA...................................................................................................................................... 42
STAn:BND ........................................................................................................................ 114
station
connecting ...................................................................................................................... 77
Station ................................................................................................................................ 149
Station Address of Frontend ................................................................................................ 22
Station Addresses of Connected Base Systems.................................................................... 23
Station Type....................................................................................................................... 136
Station Type Definitions .................................................................................................... 136
station types ......................................................................................................................... 77
SU ................................................................................................................................ 48, 122
Subtools ............................................................................................................................. 148
SW ................................................................................................................................. 48, 99
Switch-over .......................................................................................................................... 97
SX ................................................................................................................................ 46, 111
SY .............................................................................................................................. 100, 127
Synchronization Mode ......................................................................................................... 27
synchronize ........................................................................................................................ 127
SYS
BAA ................................................................................................................................ 73
SYS:BAD ............................................................................................................................ 73
SYS:BCL ............................................................................................................................. 74
SYS_BASCON.COM...................................................................................................... 9, 10
SYS_BASCON.HSB ........................................................................................................... 98
SYS_NETCON.COM.......................................................................................................... 17
Sysconf.ini ......................................................................................................................... 135
SYSOLOOCON................................................................................................................. 119
system configuration .............................................................................................................. 7
System Configuration tool ................................................................................................. 131
System message ................................................................................................................. 121
system objects ...................................................................................................................... 13
T
TCP/IP Host Name .............................................................................................................. 24
TCP/IP interface .................................................................................................................. 24
TF ........................................................................................................................................ 30
ABB Automation
TI..................................................................................................................26, 29, 49, 51, 54

Time synchronization .........................................................................................................126
Time zone (minutes).............................................................................................................27
Timeout Length ....................................................................................................................26
TT.............................................................................................................................32, 36, 65
TZ.........................................................................................................................................30
TZ_MIN ...............................................................................................................................27
U
User-Defined ......................................................................................................................144
User-Defined Programs......................................................................................................143
V
Virtual printer.......................................................................................................................68
W
watchdog ..............................................................................................................................96
Westronic D20 .....................................................................................................................77
workstation .........................................................................................................................2, 3
ABB Automation
Configuration Manual Customer Feedback
Customer Feedback
About This Chapter
This chapter contains information on how to send customer feedback and how to get
technical support from the SA Help Desk.
Customer Feedback Database
Customer Feedback is a Lotus Notes database, using which ABB companies can re-
port errors, make improvement proposals and queries related to products manufac-
tured by ABB Substation Automation Oy. Customer Feedback database is connected
to the change management system of ABB Substation Automation Oy, which handles
all error corrections and improvements made to the products.
Please note that the Customer Feedback database is primarily intended for writing re-
ports about released products. If you are using for example a beta release in a pilot
project, this should be clearly stated.
Writing A Customer Feedback Report
When writing a Customer Feedback report, the following general instructions should
be taken in consideration:
• Write the report in English.
• Write only one error report, query or improvement proposal in a Customer Feed-
back report.
• If you are reporting an error, try to isolate the error as well as possible. Describe
the sequence of events and actions that lead to the error. If any error messages or
other debug information is provided by the system, please write it down. Include
also information of the system, e.g. a system diagram, revision information and
configuration data.
• If you are making an improvement proposal, try to describe how the improved
function should work and avoid providing solutions. Information about the im-
portance of the improvement, e.g. number of projects that require the improve-
ment, helps us to make the decision whether and when the improvement should be
implemented.
To make a Customer Feedback report, select Feedback Report from the Create menu.
This opens an empty Customer Feedback document. Fill out the fields listed below. A
question mark next to a field provides help for filling out the field.
1 Subject. This should contain a short description of the issue. A more detailed
description can be given in the Description of Feedback field below.
2 Type of Feedback: Comment/Improvement, Query or Complaint/Error.
3 Customer Information.
ABB Automation
Customer Feedback Configuration Manual
4 Reporting Information. This should contain detailed information of the product the
report is about.
5 The person who you want to send the feedback to and whether you want to get a
reply from that person.
6 Information related to internal handling of the report (not obligatory).
7 Category.
You can issue the report by clicking the Issue Feedback button. This will send the re-
port to the selected person and change its status to “in progress”.
Actions
When ABB Substation Automation Oy receives a Customer Feedback report, it is

analysed by a sales person or a representative of the technical support. The analyser
may ask for additional information in order to completed the analysis. After the report
has been analysed, one of the following actions is taken:
• In case of a clear error, the report is moved to the change management system of
ABB Substation Automation Oy. In this system, the error is analysed in detail and
corrected in a future patch release or major release depending on the severity and
impact of the error.
• In case of an improvement proposal, the report is also moved to the change man-
agement system, where it is taken as a requirement to future releases.
• In case of a query, an answer is provided.
When Customer Feedback reports are handled in the change management system, the
outcome can be one of the following:
No Actions It is decided that the report re-

quires no further action. If, for ex-
ample, the problem is caused by a
configuration error, it belongs to
this category.
Will be implemented in patch/current release This result means that the correc-
tion or new feature will be avail-
able in the next official program
release.
Moved to future release This result means that the new
feature will be available in some
new program release in the near
future.
SA Help Desk
ABB Substation Automation Oy provides a technical support service called SA Help

Desk to support local engineering centres in their system projects. The purpose of SA
Help Desk is to provide support for urgent issues such as:
• Year 2000 issues.
ABB Automation
Configuration Manual Customer Feedback
• High-priority issues concerning systems at customers’ sites.

For other kind of technical support, please use the Customer Feedback database. SA
Help Desk is available every day from 06:00 to 21:00 Central European Time.
SA Help Desk can be contacted by telephone. The number is:
+358 50 334 1900
ABB Automation

Microscada System Configuration: 1Mrs751248-Men

Uploaded by

Copyright:

Available Formats

Microscada System Configuration: 1Mrs751248-Men

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Microscada System Configuration: 1Mrs751248-Men

Uploaded by

Copyright:

Available Formats

1MRS751248-MEN MicroSCADA

Issue date: 29.02.00 System Configuration

Copyright © 2000 ABB Substation Automation Oy.

This document version complies with the program revision 8.4.3.

Related MicroSCADA Technology Manuals

2 Base System Object Definitions ................................................... 9

3 Communication System Object Definitions .............................. 13

4 Configuration Data Files.............................................................. 21

7 Local Area Networks (LANs)....................................................... 43

8 Process Communication System ............................................... 45

9 Operator Workstations ................................................................ 65

12 Redundancy Configurations ....................................................... 95

14 System Configuration Tool ....................................................... 131

14.1 Main Functions ................................................................................131

15 NETCONF Tool ........................................................................... 153

16 NET Tool ..................................................................................... 163

17 REx Configuration Tool ............................................................. 171

18 LMK Configuration Tool ............................................................ 177

18.1.1 Defining the Device................................................................... 180

About this Chapter

1.2 The MicroSCADA configuration principles: the MicroSCADA configuration

1.1 System Description

A MicroSCADA system is composed of one or more base systems, a process commu-

i Windows NT is a trademark of Microsoft Corporation

Process Communication System

The process communication is handled by a number of parallel or serially intercon-

Figure 1. The main system components of MicroSCADA

A MicroSCADA workstation is a PC that runs the MicroSCADA HMI (Human Ma-

External alarm units can be connected to the base systems.

Figure 2 shows an example of a MicroSCADA system. The system can be regarded as

There may be several communication units in a series between two communicating

Figure 2. An example of a MicroSCADA network. Most configuration possibilities

An essential feature of MicroSCADA is the interoperability between separate base

1.2 Configuration Principles

The MicroSCADA configuration software handling is detailed in part II of this man-

Building System Configuration

As a rule, when a device is added to the MicroSCADA system, several configuration

ii LONWORKS is a registered trademark of Echelon Corporation.

Figure 3. The configuration software modules in MicroSCADA

2 Base System Object Definitions

This chapter describes:

Base System Objects

Principles for Defining Base System Objects

‘attribute’ Attribute name

‘value’ The value assigned to the attribute

Creating a SYS object:

The SYS_BASCON.COM file is an ASCII file that is located in the

#CREATE APL:V = LIST(-

The SYS_BASCON.COM file is composed of SCIL commands, which create base

A portion of the standard SYS_BASCON.COM file (version 8.4.2):

;Base System Object

#CREATE SYS:B = List(-

#CREATE LIN:V = LIST(- ;Link to DCP-NET (requires DCP driver)

#CREATE LIN:V = LIST(- ;Link to other SYS or LAN frontend (re-

The creation of a base system object in SYS_BASCON.COM comprises two steps;

! The System Configuration tool writes directly to the SYS_BASCON.COM file.

3 Communication System Object Definitions

Communication System Objects

Defining Communication System Objects