3BSE035982R4001 CIO ComMan

IndustrialIT
800xA - Control and I/O

System Version 4.0
Communication
Protocols and Design
IndustrialIT
800xA - Control and I/O
System Version 4.0
Communication
Protocols and Design
NOTICE
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 errors that
may appear in this document.
In no event shall ABB be liable for direct, indirect, special, incidental or consequential
damages of any nature or kind arising from the use of this document, nor shall ABB be
liable for incidental or consequential damages arising from use of any software or hard-
ware described in this document.
This document and parts thereof must not be reproduced or copied without written per-
mission from ABB, and the contents thereof must not be imparted to a third party nor used
for any unauthorized purpose.
The software or hardware described in this document is furnished under a license and
may be used, copied, or disclosed only in accordance with the terms of such license.
This product meets the requirements specified in EMC Directive 89/336/EEC and in Low
Voltage Directive 72/23/EEC.
Copyright © 1999 - 2004 by ABB.

All rights reserved.
Release: October 2004

Document number: 3BSE035982R4001
TRADEMARKS
Registrations and trademarks used in this document include:
Windows Registered trademark of Microsoft Corporation.
Industrial IT Trademark of ABB.
INSUM Trademark of ABB.
FOUNDATION Fieldbus Trademark of Fieldbus Foundation.
PROFIBUS Registered trademark of PROFIBUS International.
ModBus Registered trademark of Modicon Inc.
Simatic Registered trademark of Siemens AG.

TABLE OF CONTENTS
About This Book

General ............................................................................................................................13
Use of Warning, Caution, Information, and Tip Icons ....................................................14
Document Conventions ...................................................................................................15
Terminology.....................................................................................................................16
Section 1 Introduction
Product Overview ............................................................................................................21
Product Scope.......................................................................................................21
Network Communication .....................................................................................21
Protocols and Controllers Supported by Control Builder ....................................23
Properties of Different Protocols..........................................................................24
Clock Synchronization .........................................................................................25
Self-defined Serial Protocol .................................................................................28
Methods of Access to Legacy Controllers ...........................................................29
Prerequisites and Requirements ......................................................................................30
AC 800M .............................................................................................................30
Intended User...................................................................................................................30
Section 2 MMS
Introduction .....................................................................................................................31
Services Provided.................................................................................................32
MMS Server .........................................................................................................32
3BSE035982R4001 5
Table of Contents
Design ............................................................................................................................. 33
Configuration Parameters .................................................................................... 33
Network Areas ..................................................................................................... 34
Explicit and Implicit Addressing ......................................................................... 35
MMS on RS-232C (PPP) ..................................................................................... 36
Separation of Plant Intranet, Client/Server and Control Network ....................... 37
Redundancy..................................................................................................................... 38
CPU Redundancy................................................................................................. 38
Limitations ...................................................................................................................... 40
Performance .................................................................................................................... 41
Hardware ......................................................................................................................... 43
Advanced......................................................................................................................... 43
Default Gateway .................................................................................................. 43
Default Process Number ...................................................................................... 45
Troubleshooting............................................................................................................... 45
Section 3 MasterBus 300

Introduction ..................................................................................................................... 47
Services Provided................................................................................................. 47
Design ............................................................................................................................. 48
Introduction.......................................................................................................... 48
Design Example ................................................................................................... 48
Communication Function Blocks ........................................................................ 49
Redundancy..................................................................................................................... 51
Limitations ...................................................................................................................... 51
Performance .................................................................................................................... 51
Hardware ......................................................................................................................... 51
Advanced......................................................................................................................... 52
6 3BSE035982R4001
Table of Contents
Section 4 SattBus on TCP/IP

Introduction .....................................................................................................................53
Design..............................................................................................................................54
Introduction ..........................................................................................................54
Redundancy .....................................................................................................................54
Limitations.......................................................................................................................54
Performance.....................................................................................................................54
Advanced .........................................................................................................................55
Section 5 COMLI
Introduction .....................................................................................................................57
Design..............................................................................................................................58
Introduction ..........................................................................................................58
Design Examples..................................................................................................59
Redundancy .....................................................................................................................60
Limitations.......................................................................................................................60
Performance.....................................................................................................................61
Hardware .........................................................................................................................62
Advanced .........................................................................................................................63
Procedure for Linking Control Systems with COMLI.........................................63
COMLI Message Format .....................................................................................64
Section 6 INSUM
Introduction .....................................................................................................................67
Design..............................................................................................................................69
Introduction ..........................................................................................................69
Design Example ...................................................................................................70
INSUM Alarms ...............................................................................................................71
3BSE035982R4001 7
Table of Contents
Creating an Application that Handles INSUM Alarms................................................... 72

Receiving INSUM Alarms in the Application..................................................... 72
Generating Alarms for Alarm Lists ..................................................................... 72
Choose Alarm Handling Method ......................................................................... 75
Limitations ...................................................................................................................... 77
Performance .................................................................................................................... 77
Hardware ......................................................................................................................... 78
Section 7 Siemens 3964R

Introduction ..................................................................................................................... 79
Design ............................................................................................................................. 80
Introduction.......................................................................................................... 80
Design Examples ................................................................................................. 81
Redundancy..................................................................................................................... 81
Limitations ...................................................................................................................... 81
Performance .................................................................................................................... 82
Hardware ......................................................................................................................... 82
Advanced......................................................................................................................... 82
Communicating Integers...................................................................................... 82
Communicating Bits ............................................................................................ 83
Section 8 ModBus RTU

Introduction ..................................................................................................................... 85
Design ............................................................................................................................. 86
Introduction.......................................................................................................... 86
Design Examples ................................................................................................. 87
Redundancy..................................................................................................................... 88
Limitations ...................................................................................................................... 88
Performance .................................................................................................................... 88
8 3BSE035982R4001
Table of Contents
Hardware .........................................................................................................................89
Advanced .........................................................................................................................89
Troubleshooting...............................................................................................................89
Section 9 FOUNDATION Fieldbus HSE

Introduction .....................................................................................................................91
Advantages ...........................................................................................................91
Design..............................................................................................................................93
Introduction ..........................................................................................................93
Design Example ...................................................................................................93
Connection Methods ............................................................................................97
Redundancy .....................................................................................................................99
Limitations and Performance ........................................................................................100
High Integrity Controllers ..................................................................................100
Dimensioning Limits, Linking Device...............................................................100
Dimensioning Limits, FOUNDATION Fieldbus HSE Communication Interface
Module CI860 ...................................................................................100
Dimensioning Limits, FF HSE Communication Configuration.........................101
Hardware .......................................................................................................................101
Advanced .......................................................................................................................101
Troubleshooting.............................................................................................................102
Status of Hardware Units ...................................................................................102
Section 10 DriveBus
Introduction ...................................................................................................................103
Services Provided...............................................................................................103
Advantages ....................................................................................................................104
Design............................................................................................................................104
Design Example .................................................................................................105
Redundancy ...................................................................................................................107
Limitations.....................................................................................................................108
3BSE035982R4001 9
Table of Contents
Performance .................................................................................................................. 108

Hardware ....................................................................................................................... 109
Advanced....................................................................................................................... 110
Section 11 PROFIBUS DP
Introduction ................................................................................................................... 111
Services Provided............................................................................................... 112
Advantages......................................................................................................... 112
Design ........................................................................................................................... 113
Introduction........................................................................................................ 113
Design Examples ............................................................................................... 114
Redundancy................................................................................................................... 115
Limitations .................................................................................................................... 116
Performance .................................................................................................................. 117
Hardware ....................................................................................................................... 117
Advanced....................................................................................................................... 118
Layers .......................................................................................................... 118
Optical Link ....................................................................................................... 118
Troubleshooting............................................................................................................. 118
Automatic Calculation of PROFIBUS-DP Parameters...................................... 118
CI854 Web Interface ..................................................................................................... 119
Section 12 Modem Communication

Introduction ................................................................................................................... 121
Short Distance Modem.................................................................................................. 121
Dial-Up Modem ............................................................................................................ 122
Limitations .................................................................................................................... 123
Performance .................................................................................................................. 123
Troubleshooting............................................................................................................. 123
10 3BSE035982R4001
Table of Contents
Appendix A OSI Profile for MMS
Appendix B Configuration of HART Devices

Introduction ...................................................................................................................129
Configuration Example..................................................................................................130
Nested Communication .................................................................................................131
Appendix C PROFIBUS-PA
Appendix D ABB Drives

Introduction ...................................................................................................................135
Types of ABB Drives.....................................................................................................136
ABB Standard Drives ........................................................................................136
ABB Engineered Drives ....................................................................................136
Parameter Group Configuration ....................................................................................137
INDEX
3BSE035982R4001 11
Table of Contents
12 3BSE035982R4001
About This Book
General
This guide describes criteria for selecting networks and communication protocols
and is intended for engineers who are planning the design of a new network or the
expansion of an existing one. Note, however, that pictures of devices are for
illustrative purposes only. Refer to the relevant hardware user’s guides for
information on how to connect cables.
The described functions are designed but may not be fully implemented in all
details. Please refer to the current products guides and release notes regarding
possible restrictions.
The recommended alternative is Control Network, which is described in detail. This
uses the MMS protocol with Ethernet and/or RS-232C as physical media. However,
with regard to existing equipment or other circumstances other protocols and
fieldbuses are also discussed. MB 300, COMLI, Siemens 3964R, ModBus RTU,
and SattBus are standard protocols for general data communication between
controllers. FOUNDATION Fieldbus, PROFIBUS-DP, DriveBus, and INSUM are
dedicated to I/O communication.
For detailed information on the use of the programming tool Control Builder M,
refer to the online help system and Control Builder M documentation. For more
information on Control Network setup, see the manual Automation System Network,
Design and Configuration.
The Warning, Caution, Information, and Tip symbols are explained in this section.
Section 1, Introduction, presents an overview of communication protocols
supported by Control Builder, and the main criteria for selection.
3BSE035982R4001 13
Use of Warning, Caution, Information, and Tip Icons About This Book
The remaining sections describe the MMS protocol and other communication
protocols supported, and well as modem communication. The appendices deal with
the OSI profile for MMS, HART devices, PROFIBUS-PA, and ABB Drives. There
is also an index.
Use of Warning, Caution, Information, and Tip Icons

This publication includes Warning, Caution, and Information where appropriate
to point out safety related or other important information. It also includes Tip to
point out useful hints to the reader. The corresponding symbols should be
interpreted as follows:
Warning icon indicates the presence of a hazard which could result in personal
injury.
Caution icon indicates important information or warning related to the concept

discussed in the text. It might indicate the presence of a hazard which could
result in corruption of software or damage to equipment/property.
Information icon alerts the reader to pertinent facts and conditions.
Tip icon indicates advice on, for example, how to design your project or how to
use a certain function
Although Warning hazards are related to personal injury, and Caution hazards are
associated with equipment or property damage, it should be understood that
operation of damaged equipment could, under certain operational conditions, result
in degraded process performance leading to personal injury or death. Therefore,
comply fully with all Warning and Caution notices.
14 3BSE035982R4001
About This Book Document Conventions
Document Conventions
The following conventions are used for the presentation of material:
• The words in names of screen elements (for example, the title in the title bar of
a window, the label for a field of a dialog box) are initially capitalized.
• Capital letters are used for the name of a keyboard key if it is labeled on the
keyboard. For example, press the ENTER key.
• Lowercase letters are used for the name of a keyboard key that is not labeled on
the keyboard. For example, the space bar, comma key, and so on.
• Press CTRL+C indicates that you must hold down the CTRL key while
pressing the C key (to copy a selected object in this case).
• Press ESC E C indicates that you press and release each key in sequence (to
copy a selected object in this case).
• The names of push and toggle buttons are boldfaced. For example, click OK.
• The names of menus and menu items are boldfaced. For example, the File
menu.
– The following convention is used for menu operations: MenuName >
MenuItem > CascadedMenuItem. For example: select File > New > Type.
– The Start menu name always refers to the Start menu on the Windows
Task Bar.
• System prompts/messages are shown in the Courier font, and user
responses/input are in the boldfaced Courier font. For example, if you enter a
value out of range, the following message is displayed:
Entered value is not valid. The value must be 0 to 30.
You may be told to enter the string TIC132 in a field. The string is shown as
follows in the procedure:
TIC132
Variables are shown using Italics.
Setpoint
3BSE035982R4001 15
Terminology About This Book
Terminology
The following is a list of terms associated with Control Software and Control
Builder M. The reader should familiarize himself with these terms before going
further. The list contains only those terms and abbreviations that are unique to ABB
or have a usage or definition different from standard industry usage.
Term Description
Access variables Variables that can be accessed remotely, for example
from another controller
Applications Applications contain the program code to be compiled
and downloaded for execution in the controller.
Applications are displayed in the Project Explorer
CNCP Control Network Clock Protocol, an ABB protocol for
time synchronization in Control Network
Cold retain Cold retain variable values are maintained after a warm
or cold restart. The Cold Retain attribute overrides the
retain attributes in a structured data type
Control Builder M The programming tool described in this product guide,
referred to as Control Builder throughout this document
Control module Control modules are program units that support object-
oriented data flow programming with code sorting, free-
layout graphical programming and static parameter
connections. Instances of control modules are created
from control module types
Control Software ABB control software offering, including controller
firmware, libraries and executable control applications
Data type A variable’s data type defines its characteristics, set of
values and set of permitted operations. Data types are
simple or structured, either predefined or user defined
DTM Device Type Manager, software module used to manage
devices via HART using Fieldbus Builder P, via the Tool
Routing Service (TRS)
16 3BSE035982R4001
About This Book Terminology
Term Description
FBD Function Block Diagram, one of the five languages
defined in the IEC-61131 standard
FF HSE FOUNDATION Fieldbus High Speed Ethernet is a high-
performance fieldbus system. FF HSE subnets can
communicate with FF H1 links via a linking device.
Global variable A variable that can be used by all programs
GSD file Geräte Stamm Datei, a hardware description file for a
PROFIBUS-DP or PROFIBUS DP-V1 slave type
HART Highway Addressable Remote Transducer, a protocol for
communication with and configuration of remote devices
with HART support
IEC 61131-3 An IEC standard for control languages; includes
Structured Text (ST), Ladder Diagram (LD), Instruction
List (IL), Function Block Diagram (FBD), and Sequential
Function Chart (SFC)
IL Instruction List, one of the five languages defined in the
IEC-61131 standard
Instance An instance is an individual object that behaves in
accordance with the rules of the corresponding type
INSUM INtegrated System for User-optimized Motor control, an
ABB system for motor control
LD Ladder Diagram, one of the five languages defined in the
IEC-61131 standard
LON Local Operating Network, a protocol used for INSUM
fieldbus communication
MMI Man-Machine Interface
MMS Manufacturing Message Specification. a standard for
messages used for industrial communication
3BSE035982R4001 17
Term Description
MMS Server for The server provides services to the MMS Client.
AC 800M Examples of services provided are transfer of variable
content and start of programs
OPC OLE for Process Control, a standard for exchange of
process control information
PROFIBUS-DP PROcess FIeldBUS-DP is a fieldbus standard, designed
for communication between systems and process
objects. This protocol is an open, vendor-independent
fieldbus for time-critical communication between
controllers and distributed peripherals (remote I/O).
Program A program contains written execution code. Programs
are connected to tasks with the same name
Project A source code representation of the configuration data
entered by an engineer to build a control solution
Project Explorer The part of the Control Builder M user interface used to
create, modify and navigate a project. All objects such
as data types, functions and function block types can be
selected and displayed in an editor. All software and
hardware is configured in the Project Explorer
RNRP Redundant Network Routing Protocol, an ABB protocol
for redundancy handling and routing in Control Network
RS-232C Standard No. 232 for PC communication, established by
EIA (Electronics Industries Association, USA)
RS-485 A communication interface standard from EIA
(Electronics Industries Association, USA), operating on
voltages between 0V and +5V. RS-485 is more noise-
resistant than RS-232C, handles data transmission over
longer distances, and can drive more receivers
SFC Sequence Functional Chart, one of the five languages
defined in the IEC-61131 standard
SNTP Simple Network Time Protocol, a protocol used for time
synchronization in Control Network
18 3BSE035982R4001
About This Book Terminology
Term Description
SOE Sequence-Of-Events, a logging method involving time-
stamping at digital inputs
ST Structured Text, one of the five languages defined in the
IEC-61131 standard
Task A task is a ‘work schedule’ for a program.Three default
tasks are available; Fast, Normal and Slow. At run time,
tasks are executed according to interval time, priority
and offset
TRS Tool Routing Service, a service that allows the user to
use Fieldbus Builder PROFIBUS/HART to configure
HART devices, via AC 800M
Type The type is a general description of a unit that defines
the behavior of an instance of the type
3BSE035982R4001 19
20 3BSE035982R4001
Section 1 Introduction
Product Overview
Product Scope
The products described are utilized for general network communication of real-time
data between controllers and computers in an industrial environment.
Network Communication
The recommended alternative, Control Network, is a private IP network domain
especially designed for industrial applications. This means that all communication
handling will be the same, regardless of network type or connected devices. Control
Network is scalable from a very small network with a few nodes to a large network
containing a number of network areas with hundreds of addressable nodes (there
may be other restrictions such as controller performance).
Control Network uses the MMS communication protocol on Ethernet and/or
RS-232C to link workstations to controllers. MMS (Manufacturing Message
Specification) is an ISO 9506 standard. In order to support Control Network on RS-
232C links, the Point-to-Point Protocol (PPP) is used. The Redundant Network
Routing Protocol (RNRP) developed by ABB handles alternative paths between
nodes and automatically adapts to topology changes. MMS is described in Section
2, MMS.
In addition, other protocols such as MB 300, COMLI, Siemens 3964R, ModBus
RTU, and SattBus can be used. Fieldbuses such as FOUNDATION Fieldbus HSE,
PROFIBUS-DP (according to IEC 1158-2 and EN 50170), DriveBus, and INSUM
can be connected to the network via communication interface units.
3BSE035982R4001 21
Network Communication Section 1 Introduction
Table 1– Table 3 give concise information to be used when selecting protocols.

Subsection Prerequisites and Requirements on page 30 provides details on specific
products. For further information (regarding performance, for example) refer to the
following sections.
The Control Network-as well as other protocols and fieldbuses-is configured by
means of the project explorer in Control Builder (see the figure below). The Control
Network is specified by settings in the parameter lists, accessed by right-clicking the
symbols for the CPUs and the Ethernet and/or PPP symbols (see Section 2 for
further information). How to specify the hardware configuration is explained in the
Control Builder online help. PC nodes are specified in the PC setup wizard (from
the Start menu, select ABB Industrial IT 800xA > Engineering> Utilities >
Setup Wizard).
Figure 1. Project Explorer.
22 3BSE035982R4001
Section 1 Introduction Protocols and Controllers Supported by Control Builder
Protocols and Controllers Supported by Control Builder

The table below lists controllers and protocols supported by the current version of
Control Builder.
Table 1. Protocols and Controllers supported by Control Builder.
AC 800M
Protocol AC 800M
HI
MMS on Ethernet YES YES
MMS on RS-232C (PPP) YES YES
MasterBus 300 YES YES
SattBus on TCP/IP YES YES
COMLI(1) YES YES
(2)
Siemens 3964R YES YES
ModBus RTU(3) YES YES
FOUNDATION Fieldbus HSE YES NO
PROFIBUS DP-V0 YES YES
PROFIBUS DP-V1 YES YES
DriveBus YES NO
INSUM YES YES
(1) Both master and slave
(2) Master only
(3) Master only
3BSE035982R4001 23
Properties of Different Protocols Section 1 Introduction
Properties of Different Protocols

Table 2 below shows access modes used, variable types handled and maximum
message size permitted for various protocols, as well as which protocols that require
interface units with separate CPUs ,and protocols that support dial-up modems.
FOUNDATION Fieldbus HSE, PROFIBUS-DP, DriveBus, and INSUM are I/O
fieldbuses that are not used for general data communication. They use
communication interfaces with separate CPUs and perform according to the
master/slave principle.
Table 2. Properties of the different protocols.
Variable types(1)
bytes per message

Separate CPU for
bits/registers or
Dial-up modem
Max. number of
communication
Access
Protocol
method Boolean
Struct(2)
Integer
String
Real
MMS on Ethernet Ethernet × × × × × (3)
(3)
MMS on RS-232C (PPP) Point-to-point × × × × ×
MasterBus 300 Ethernet × × × × ×
SattBus on TCP/IP Token passing × × × × × 31 bytes
COMLI Multidrop × × × 512/32
Siemens 3964R Point-to-point × × 512/32
ModBus RTU Multidrop × ×
Self-defined in Serial Point-to-point × × × × × 140 bytes
Communication Library
(1) When transferring variables it is important to use data types having the same range on both client and
server. However, a dInt variable on the server can be connected to an Int variable on the client if the
values are within the Int variable's range
(2) MMS and SattBus can transfer structured variables of the data types given in the table. No protocol can
transfer variables of types ArrayObject or QueueObject.
(3) See Table 4 on page 42.
24 3BSE035982R4001
Section 1 Introduction Clock Synchronization
Clock Synchronization
Depending on the type of controller, it is possible to perform clock synchronization
by four different protocols: CNCP, SNTP, MB 300 TS, and MMS Time Service. The
preferred protocol of service is chosen in the Hardware Editor of the Control
Builder M.
CNCP is the base protocol for clock synchronization on the Control Network. An
AC 800M controller selected as Clock Master multicasts synchronization messages
on the network (see Figure 2). All nodes that have CNCP “enabled” gets
synchronization from the Clock Master.
AC 800M controllers that needs to be synchronized from an external time server are
configured as SNTP clients. The time server is typically an GPS Time Server
connected to the network.
Custom devices that needs synchronization from the Control Network can get time
from the SNTP server function running in every AC 800M controller.
CNCP and SNTP can both operate at the same time on the network.
MMS Time Service supported for small systems where no AC 800M is used for
backward compatibility with older products.
MB 300 TS is a protocol for clock synchronization of Advant/Master products on a
MasterBus 300 network.
If a GPS time source exists, time is sent from the GPS to all AC 800M controllers in
the system. One of the AC 800M controllers then acts as a TimeSync Master for the
rest of the controllers and distributes the time to them.
3BSE035982R4001 25
Clock Synchronization Section 1 Introduction
If no external time source exists, the controller which is set up as TimeSync Master
gives the reference time for the system.
Clock Synchronization
Plant Explorer Workplace
CNCP w. On-time
medium accuracy switch
High-precision
Control Network SNTP
CNCP*) CNCP
AC 400
AC 800M AC 800M
MB 300 TS
*) The direction depends on which controller
MasterBus 300 is the master (the left AC 800M or AC 400).
Figure 2. Clock Synchronization
Intermediate Clock Master

An Intermediate Clock Master (a node that can relay time synchronization between
two Network Areas) shall have a Clock Master order number that is at least two
numbers higher than any ordinary Clock Master (AC 800M).
The standard and recommended synchronization interval is 20 seconds.
26 3BSE035982R4001
Section 1 Introduction Clock Synchronization
Clock Synchronization in Controllers

The controllers are synchronized in the following ways:
• AC 800M:
An AC 800M is set up to be the TimeSync Master which can be set up to either
give the reference time to the system, or receive the reference time from an
external time source. The time is distributed from the TimeSync Master to the
other controllers.
For AC 800M, the following is valid:
– SNTP:
Slave with high precision for synchronization from an external source.
Master with less accuracy for synchronization of third part equipment.
– CNCP:
Master and Slave with high accuracy
– MB 300 TS:
Master with high accuracy
Slave with high accuracy
• Advant Controller 400:
Time is sent to every AC 400 controller via MB 300 TS from the TimeSync
Master.
• Plant Explorer Workplace:
The following is valid:
– CNCP:
Slave with medium accuracy. Synchronization from AC 800M (TimeSync
Master).
• External Source:
Clock Synchronization from an external source where the external source is
SNTP:
– Accuracy depends on the selected source
3BSE035982R4001 27
Self-defined Serial Protocol Section 1 Introduction
Self-defined Serial Protocol

Function blocks in the Serial Communication Library allow implementation of a
personal character-oriented protocol on a serial port and writing an application that
both controls the characters sent and checks that the correct answer is received by
using various checksum algorithms.
The following function block types are available:
• SerialConnect
• SerialSetup
• SerialWriteWait
• SerialListenReply
• SerialWrite
• SerialListen
Maximum 140 characters supported.
Preferably ASCII telegrams, since binary telegrams are difficult to implement.
28 3BSE035982R4001
Section 1 Introduction Methods of Access to Legacy Controllers
Methods of Access to Legacy Controllers

The table below indicates protocols that can be used for communication between
Control Network and earlier ABB controllers not belonging to ControlIT.
Table 3. Methods of access to legacy controllers.
Self-def.
SattBus
Siemens Mod in Serial
Protocol MB 300 on COMLI(1) MMS
3964R Bus Comm.
TCP/IP
Library
SattLine 200 × × x
AC 210 × ×
AC 250 with × × ×
ACB ver. 1
AC 250 with × × × ×
CB 2 or later
AC 800C × × × ×
AC 55 ×
AC 70 × ×
AC 110 × × ×
AC 160 × × ×
AC 410 × × × ×
AC 450 × × × ×
SattCon05 ×(2) ×
SattCon15 × ×
SattCon31 × ×
SattCon35 × ×
SattCon60 × ×
SattCon90 × ×
3BSE035982R4001 29
Prerequisites and Requirements Section 1 Introduction
Self-def.
SattBus
Siemens Mod in Serial
Protocol MB 300 on COMLI(1) MMS
3964R Bus Comm.
TCP/IP
Library
SattCon115 × ×
SattCon125 × ×
SattCon200 × × ×
(1) Supported message types differ between the controllers; refer to the relevant programmer’s
manuals.
(2) With control board CU05-25, CU05-45 or CU05-65.
Prerequisites and Requirements

When selecting communication methods and hardware in a control network the
following features of and restrictions on the currently available hardware must be
considered.
AC 800M
• Max. two Ethernet links integrated in the CPU unit are supported.
• A maximum of four PPP links are allowed:
One tool port link and one PPP link (integrated in the CPU unit), plus
additional PPP links via a CI853 unit, can be used.
Intended User
The reader is assumed to have general knowledge of control methods and relevant
literature regarding specific protocols and fieldbuses.
30 3BSE035982R4001
Section 2 MMS
Introduction
Control Network uses the MMS protocol and a reduced OSI stack with the TCP/IP
protocol in the transport/network layer, and Ethernet and/or RS-232C as physical
media. MMS (Manufacturing Message Specification) is an ISO 9506 standard. This
means that all communication handling will be the same, regardless of network type
and connected devices. The protocol defines communication messages transferred
between controllers as well as between the engineering station (such as Control
Builder) and the controller (e.g. downloading an application or reading/writing
variables). It has been developed especially for industrial applications. See also
Appendix A, OSI Profile for MMS.
Engineering stations
Controllers
Figure 3. The MMS protocol defines communication messages transferred between

controllers as well as between engineering stations and controllers.
3BSE035982R4001 31
Services Provided Section 2 MMS
Services Provided
The MMS protocol provides several services1 within a network:
• Downloading an application, e.g. executable code and data from an engineering
station (such as Control Builder) to a controller.
• Creating, deleting, starting, and stopping programs over the network.
• Reading and writing variables located in other systems on the network.
• Obtaining information about applications being executed and about error
conditions in remote systems.
• Reading and writing files over the network.
• Handling alarm conditions.
• Obtaining information on remote system capability, model identification and
revision of remote systems.
Main advantages:
• The MMS protocol is an ISO 9506 standard protocol, which means all
communication handling will be the same, regardless of network type and
connected devices.
• The protocol can be used on many different networks, but preferably on the
TCP/IP network, which is the most commonly used network today.
MMS Server
The function of the MMS Server resembles a multiplexer between Control Builder,
OPC Server and controllers, see OPC Server documentation. The MMS Server is
automatically installed with Control Builder or OPC Server.
1. See also Appendix A, OSI Profile for MMS.
32 3BSE035982R4001
Section 2 MMS Design
Design
Configuration Parameters
The Control Network is configured by means of the Project Explorer in Control
Builder. Any controller supported by Control Builder can also be connected to
Ethernet. The different alternatives are described in the hardware manual for the
respective controller. Settings for the controller and the communication channel
(Ethernet or PPP) are entered via the Control Builder. PC nodes are configured in
the PC setup wizard (see the Setup Wizard Online Help and the manual Automation
System Network, Design and Configuration).
To display the parameter list from the hardware tree, expand Controllers, find your
controller, expand Hardware AC 800M, expand the processor unit, click the
Ethernet channel and select the Settings tab.
Figure 4. Ethernet parameter list in Control Builder
The IP address and IP subnet mask are standard IP terms, whereas the remaining
parameters are used by the Redundant Network Routing Protocol (RNRP).
For more information on RNRP setup, see the manual Automation System
Network, Design and Configuration.
3BSE035982R4001 33
Network Areas Section 2 MMS
Network Areas
The Control Network normally covers one manufacturing plant. A large Control
Network can be divided into network areas (subnetworks), for example to keep
most of the time-critical communication within smaller areas, thereby improving
performance.
Network areas must be interconnected by controllers (used as routers). A controller
running the RNRP protocol with two Ethernet ports having the same node number
connected to different network areas, has router capability. If the node detects that it
is connected to more than one network area, it automatically starts routing without
any need for extra configuration data.
A path connection between two nodes must not contain more than three routers
(a hop count greater than 3 is not permitted).
1 3
Network area 1
5 8 Node numbers
Routers
10 11 12 20 21 22
Network area 2 Network area 3
Figure 5. Non-redundant Control Network with three network areas which are
connected via AC 800M controllers used as routers.
34 3BSE035982R4001
Section 2 MMS Explicit and Implicit Addressing
Example:
The two Ethernet channels of an AC 800M with node number 8 are used to connect
network areas 1 and 3.
Port 1
Port 2
Figure 6. AC 800M used as a router between two network areas.
Explicit and Implicit Addressing

In the example above we used the explicit addressing method. That is, in addition to
calculating the IP address we explicitly entered the parameters network area, path
number and node number in the parameter list. However, if we use the RNRP
conventions, these parameters will automatically be extracted from the IP address
and mapped onto the RNRP parameters if the corresponding entries in the parameter
list are left zero. This is called implicit addressing. The parameter list for network
area 3 above will have the following appearance:
3BSE035982R4001 35
MMS on RS-232C (PPP) Section 2 MMS
Figure 7. Parameter list when the implicit addressing method is used.
In order to obtain supervision of the Network connection, and the PPP

connection done with explicit addressing, RNRP must be configured (enabled at
all time).
MMS on RS-232C (PPP)

RS-232C is a point-to-point communication link for direct interconnection of two
controllers. The PPP protocol is used to support the IP network.
Figure 8. MMS on RS-232C.
36 3BSE035982R4001
Section 2 MMS Separation of Plant Intranet, Client/Server and Control Network
Clicking PPP displays a parameter list similar to that for Ethernet, but the
destination must be known and entered as the remote IP address.
Implicit addressing cannot be used, consequently network area number, path
number, and node number have to be entered in the parameter list.
How to configure a PPP connection is described in detail in Control Builder

online help.
In order to be able to communicate with most products on the market, you must
select an address from the class C private internet address space 192.168.0.0–
192.168.255.0 with the subnet mask 255.255.255.0. Allowed node numbers are 1–
254 and must be the same as the host ID part (the last part) of the IP address.
PPP communication must not use the same network id as Control Network
communication. Using the same network id will result in IP addressing conflicts.
Changes to PPP network interface settings will not take effect until a controller
cold restart or a controller warm restart has taken place.
Separation of Plant Intranet, Client/Server and Control Network

The Control Network must be protected from foreign traffic that can be a security
risk and also cause undesired load on both the nodes and network. To avoid these
risks the Control Network should be physically separated from the Plant Intranet
and protected by servers and/or firewalls. In large configurations such separation
may also be desirable between the Control Network and client/server networks.
3BSE035982R4001 37
Redundancy Section 2 MMS
Redundancy
The RNRP protocol is based on alternative redundant paths between systems in
order to be able to quickly respond to network failures. If one path becomes faulty,
another path will be used instantly. All paths use different physical networks to
maximize the redundancy.
Devices connected with redundancy must have one interface to the primary
network and one to the secondary network. The node number must be the same
on both networks.
A Control Network may contain both redundant and non-redundant network areas.
Moreover, nodes with redundant interfaces and those with a single interface can be
mixed in the same network area. A node with only one interface must be connected
to the primary network
Network applications must always have address nodes on the primary network.
In the case of an error the RNRP redirects traffic to the secondary network
without involving an application program.
CPU Redundancy
AC 800M can have two redundant processor units working in dual CPU mode with
the same functionality as a system running with only one CPU. The backup CPU is
running in standby mode, ready to smoothly take over execution from the primary
CPU in case of hardware failure.
CPU redundancy in a non-redundant network requires that Ethernet port 1 (CN1)
on both CPU units are connected to the same network.
CPU redundancy in a configuration with redundant networks requires that

Ethernet port 1 (CN1) on both units are connected to the primary network, and
that Ethernet port 2 on both units are connected to the secondary network.
The assignment of IP addresses for the Ethernet ports (CN1 and CN2) of the
primary CPU unit is performed from Control Builder, in the same manner as for a
non-redundant processor unit. The Ethernet ports of the secondary CPU unit will
have to be assigned another IP address, using the IPConfig tool. The IP address of
the secondary CPU unit is only used for internal communication and is never used
38 3BSE035982R4001
Section 2 MMS CPU Redundancy
by other nodes in the control network.When the backup processor becomes the
primary processor, it automatically takes over the primary IP address. In this way,
the IP address used for communication throughout the network stays the same.
Which IP addresses to use for the secondary CPU unit depends on the strategy
used for redundant units throughout the network. For more information about
how to set IP addresses, see online help for the IPConfig tool.
The user application need not be aware of the redundant CPU option. It is possible
to reconfigure a system running in single mode to include a backup CPU without
any changes to the application.
CEX bus
PM861 PM861
Dual AC 800M
RCU link
Redundant network
Figure 9. Example of redundant CPU configuration.
3BSE035982R4001 39
Limitations Section 2 MMS
Limitations
• Redundancy on PPP-link is not supported.
• CPU redundancy is not supported for the PM851, PM856 and PM860
AC 800M processor units.
• Routing is only allowed in the following situations:
– Routing of MMS via an OPC Server PC between Control Network and the
Operator Workplace network is allowed.
– Routing via PPP from one controller to another is allowed, but only to the
far ends in the network (only one hop). Using PPP to connect different
Ethernet Control Networks is not allowed.
• The maximum number of RNRP nodes in a network area is limited to 50
nodes.
40 3BSE035982R4001
Section 2 MMS Performance
Performance
Performance is affected by transmission speed, message length and application
load.
For RS-232C channels the baud rate can be selected between 2400 and 19200 bits
per second. To send a byte requires 11 bits (start bit, 8 data bits, parity bit and stop
bit). Consequently 9600/11 = 872 bytes per second can be sent if the baud rate is
9600.
For Ethernet channels AC 800M currently supports 10 Mbit/s transmission speed
(half duplex).
In AC 800M, servicing the S800 I/O via ModuleBus has highest priority. Execution
of the application program (IEC 1131-code written by the user) has next highest
priority. Depending on the amount of code and the requested execution intervals, the
application program may require up to 70% of CPU capacity. Communication
handling has lowest priority, though normally at least 30% of CPU capacity will be
reserved for this purpose.
Master functionality is implemented by function blocks provided by the
communication libraries, such as MMSWrite and MMSRead-used to write/read
data between controllers. In a system acting as master, the communication
performance is of course affected by the execution interval of the communication
function blocks in the application program. The response is handled in the
background; it is not triggered by the application program in the slave system, but
slowed if the application load is high.
If the network is disconnected from the controller, the parameter Valid is true for
15 seconds. During this time, the MMSRead block will show Valid and status 2
(=success with warning). This means that if there has not been any traffic within a
period the TCP will strobe the other end to check if the connection is up. The
following settings have been selected for a connection:
Period time is 7 seconds; the strobe is eight messages with one second
separating them. This will give a time-out of; 7 seconds + 8 messages * 1
second = 15 seconds.
3BSE035982R4001 41
Performance Section 2 MMS
A long message takes longer to transmit than a short one, but it is always more
efficient to use long messages if a large data area is to be transmitted. With the
MMS protocol, the maximum message size is 1024 bytes. Variables require
different amounts of message space depending on the variable type (see the table
below). In addition, the message header requires 60-70 bytes.
Table 4. Space requirements of different variable types.
Maximum number
Variable type Size in telegram of variables in
one telegram
Bool 3 bytes 319
Dint, Int, word, dword 6 bytes 159
Real 7 bytes 136
String 4 bytes header + 190 string [1]
1 byte/character 6 string [140]
Struct 4 bytes header +
components as above
The Ethernet standard allows bandwidth transmission at 10 Mb/s, 100 Mb/s (fast
Ethernet), and 1000 Mb/s (gigabit Ethernet), but ControlIT for AC 800M
currently supports only 10 Mb/s (half duplex).
42 3BSE035982R4001
Section 2 MMS Hardware
Hardware
All hardware complying with the Ethernet IEEE 803.2 standard can be used for
MMS communication. Typical hardware units that can use MMS are Ethernet
transceivers, hubs, switches, and routers.
Although the Ethernet standard used in automation technology is the same as in an
office environment, the requirements for network products differ considerably. In
industrial applications, networks are expected to work reliably under extreme
conditions, such as electromagnetic interference, high operating temperatures and
mechanical loads.
Advanced
Default Gateway
Instead of RNRP the alternative routing method default gateway can be used.
In the example (Figure 10) node No. 1 has direct access to the nodes on the same
Ethernet network, that is to say nodes 2 and 3. Additionally node 1 requires access
to node 4 etc. This can be achieved by default gateways for nodes 1-3, 3-4, etc. The
default gateway IP address for node 1 is specified in the controller parameter list
Figure 11.
Nodes 2 and 6 belong to a network area handled by RNRP, which is not accessible
from nodes 1 and 3.
3BSE035982R4001 43
Default Gateway Section 2 MMS
1 3 (IP=172.16.4.8)
4 Internet
Service Internet
Provider
2 6
Network area
Figure 10. Routing to external servers.
Figure 11. Parameter list specifying default gateway.
It is possible to define two static routing paths. These are defined using the
IPConfig help tool, which is installed with the system and can be accessed via the
Windows Start menu. For more information, see online help for IPConfig.
44 3BSE035982R4001
Section 2 MMS Default Process Number
Default Process Number

When a PC has several applications running and another PC wants to communicate
with either of these applications, a process number must be taken into consideration.
This number is added to the system ID, separated by a colon, for example
172.16.84.1:2. For default process numbers, see Table 5.
Table 5. Default process number.
Product Default process number

MMS Server 0
Control Builder 1
OPC Server 22
Tool Routing 30
AC 800M 1
Soft Controller 2
Troubleshooting
The following sources indicate the communication status of Control Network nodes.
1. The Control Builder hardware tree shows the status of interfaces.
2. In Control Builder, right-click the controller to show Remote System. This is
used to list the systems connected to a particular network.
3. Controller log file. Print-outs of node failures and complete network failures.
4. In Command Prompt on PC, use the command "ipconfig/all" to list installed
interfaces and show routes to accessible networks.
5. RNRP monitor that can be installed from the Industrial IT 800xA CD-ROMs.
6. The function block SystemDiagnostics (Basic library), shows Ethernet
statistics (number of received/lost and transmitted/lost packages).
3BSE035982R4001 45
Troubleshooting Section 2 MMS
46 3BSE035982R4001
Section 3 MasterBus 300
Introduction
MasterBus 300 (MB 300) can be used for communication between AC 800M and
controllers such as AC 400 Master, MasterPiece 200 and other AC 800M
controllers. A communication unit CI855 for AC 800M provides connectivity to AC
400 via MB 300. Refer to the relevant user’s guides and reference manuals
regarding the process interface that can be used with AC 400.
The CI855 unit is configured by means of Control Builder in the hardware
configuration tree.
CI855 has two Ethernet channels to provide network redundancy.
Services Provided
• DataSet (DS) communication with other controllers on MasterBus 300.
• Function blocks in the AC 800M are used to cyclically send and receive
DataSets on MB 300.
• Time synchronization on MB 300 is supported in the AC 800M with the
accuracy provided on MB 300.
• The CI855 unit status, watchdog supervision and logged system messages are
reported to the AC 800M for display in the Control Builder and the
Plant Explorer Workplace status system.
• Support of MB 300 network redundancy.
3BSE035982R4001 47
Design Section 3 MasterBus 300
Design
Introduction
The three function blocks MB300Connect, MB300DSSend and MB300DSReceive,
handle communication between DataSets belonging to different controllers
connected to MasterBus 300. A DataSet consists of an address part and up to 24
elements (32-bit values). A value can be a 32-bit integer, a 16-bit integer or a real or
32 Boolean. The address part is the destination network node, the source network
and a DataSet identity.
Each CI855 unit behaves as a unique node on the MB 300 network to which it is
connected and must be configured accordingly in the Control Builder hardware
configuration tree. Parameters downloaded to CI855 are:
• A personal node number
• Network numbers for the two network links
• The MB 300 Protocol type, i.e. MB 300, MB 300E or MB 300F
• End node or no end node
• Clock-synchronization function
Design Example
An AC 800M controller is connected to a redundant MasterBus 300 network via a
CI855 unit and can exchange DataSets with other controllers connected to the
MasterBus 300 network, such as AC 410 and AC 450. The same AC 800M
controller can also communicate with other controllers on Control Network. For
small applications, MB 300 and Control Network may use the same physical
Ethernet cable.
48 3BSE035982R4001
Section 3 MasterBus 300 Communication Function Blocks
Other controllers on MasterBus 300 AC 800M
CI855
MasterBus 300 Control Network
Figure 12. AC 800M connected to MasterBus 300 and Control Network.
MasterBus 300 network may be either redundant or singular.
Communication Function Blocks

An AC 800M on Control Network connects to a controller on MB 300 by means of
an MB300Connect function block. The MB300DSReceive and MB300DSSend
function blocks with the same Id parameter value as the MB300Connect function
block can then be used repeatedly for communication with that controller. See the
example in Fig. 13. Refer to the online help for an explanation of the function block
parameters.
The CIPos parameter specifies the position number of the CI855 unit in the
hardware tree (identical to its position on the CEX bus). CAPos specifies the MB300
network number, and NodePos the node position of the controller on the network.
DataSetId is an integer specifying the DataSet identity. SupTime specifies the time
interval between receive or send operations. The extensible parameters Rd and Sd of
AnyType data type indicate the total number of application variable names. They
allow the user to specify personal parameters, the only restriction being that the total
number of parameters must equal the total number of allocated elements in the
DataSet.
Table 6 indicates the mapping between data types used in AC 800M and data types
used in other controllers on MB 300.
3BSE035982R4001 49
Communication Function Blocks Section 3 MasterBus 300
Controllers CI855 AC 800M

on MB 300 Interface
MB300Connect
unit
CIPos
CAPos
NodePos Id
DSSend MB300DSReceive
DataSetId
Sd Id
Rd
DSReceive MB300DSSend
DataSetId
Rd Sd Id
Figure 13. Exchange of DataSets (DS) via MB 300 by means of function blocks.
Table 6. Mapping of data types
Data types in other Data types in AC 800M

controllers on MB 300
Boolean32 dint
16-bit integer int
32-bit integer dint
real real
50 3BSE035982R4001
Section 3 MasterBus 300 Redundancy
Redundancy
The CI855 unit houses two Ethernet channels to provide network redundancy. The
routing tables in CI855 that indicate the network, node address and port to use when
sending to an MB 300 node, are continuously recalculated according to the latest
topology information in the routing messages. In the case of link/node failures,
switch-over to redundant links is automatic.
Limitations
MasterBus 300 in AC 800M is used for communication with other nodes such as
AC 400 Master, MP 200 and AC 800M.
A DataSet consists of up to 24 elements (32-bit values).
Performance
Transmission speed: 200 packets/sec.
Clock synchronization: 3 ms.
Hardware
• MasterBus 300 interface unit CI855 connects to the CEX bus of the AC 800M.
• Twisted pair 10BASE-T Ethernet cable with RJ45 connector is used. The
installation should comply with Category 5 specification according to IEEE
802.3.
3BSE035982R4001 51
Advanced Section 3 MasterBus 300
Advanced
Time synchronization on MasterBus 300 is supported in the AC 800M by the
accuracy provided on MB 300.
The CI855 editor in the Control Builder is used to specify the clock synchronization
mode:
• No synchronization
• CI855 is synchronized by AC 800M; CI855 does not synchronize MB 300
network.
• CI855 is synchronized by MB 300; AC 800M may be synchronized by CI855.
• CI855 is synchronized by AC 800M; CI855 is clock-master in the MB 300
network.
If AC 800M is to be synchronized from the CI855 unit, it is also necessary to select
MB 300 as clock synchronization type in the CPU hardware editor.
Troubleshooting
The CI855 device status, watchdog supervision and logged system messages are
reported to the AC 800M for displaying in the Control Builder and Plant Explorer
Workplace status system.
Watchdog mechanisms are used by the AC 800M to supervise the CI855, which
supervises the AC 800M. The watchdog function is cyclically called and interrupts
the CI855 unit, which, if it does not receive an interrupt within a certain time, stops
communication at its ports. The CI855 responds with a watchdog signal to the AC
800M, which expects the CI855 unit to cyclically generate watchdog interrupts. The
unit is considered out of function if an interrupt is missing. The CI855 operating
system has its own watchdog/stall handling, which will halt the CI855 processor in
the event of hardware or software errors.
52 3BSE035982R4001
Section 4 SattBus on TCP/IP
Introduction
SattBus is a robust communication network for linking controllers, intelligent I/O
devices, sensors, etc.
SattBus is an open protocol, easy to configure and connect to, and can be
implemented by any manufacturer. Due to its low memory requirements, SattBus
can be integrated with an application in a single-chip microcontroller. Different
types of interfaces, for example for PCs, are also available.
The multimaster operation allows event communication, which increases the
efficiency and lowers utilization of the network. SattBus is optimized for the
transfer of small amounts of data. All this contributes to making SattBus a high-
performance network for systems with highly distributed data reaching a maximum
effective data transmission rate of 3000 bytes per second.
Services Provided
SattBus provides the following services:
• Variable names.
• Managing and accessing variables in remote nodes.
• COMLI transparent messages over SattBus (see also Section 5, COMLI,
subsection Services Provided on page 57).
In total, 16 services are defined in the SattBus protocol. The most important ones
relate to variable transfer.
All nodes on SattBus are equipped with the basic ability to identify the node by a
short, five-character name. This service also provides the program version and
defines the other SattBus services the node can handle. Nodes with different sets of
variables have different identities.
3BSE035982R4001 53
Design Section 4 SattBus on TCP/IP
Design
Introduction
Communication is performed via SattBus function blocks, e.g. SBConnect, SBRead
and SBWrite or COMLI function blocks. COMLI function blocks are used for
directly addressed communication (e.g. X100, R1000). SBRead/SBWrite are used
for named SattBus communication.
In named SattBus, a structured variable can have 254 components of simple data
types.
Redundancy
SattBus does not support redundancy.
Limitations
Physical SattBus is not supported.
For SattBus on a TCP/IP connection, the valid node number range is 2-127, for
example '88'.
Performance
If each node is allowed a maximum of one message frame per token rotation, then
the SattBus data link layer can transfer up to 3000bps within message frames.
Transfer efficiency is over 30%. SattBus is stable in an overload situation, i.e. the
throughput does not decrease as the load increases and the system does not become
blocked.
54 3BSE035982R4001
Section 4 SattBus on TCP/IP Advanced
Advanced
When SattBus communication uses the Ethernet network, SattBus messages are
transferred using TCP/IP. Communication is also possible using COMLI function
blocks via SattBus on TCP/IP.
SattBus application messages are sent ‘as is’ using the User Datagram Protocol
(UDP) of the TCP/IP suite. A small heading is added for a transport protocol
implemented on top of UDP. This protocol is responsible for sequence and transport
control, assuring that SattBus messages are received in order, and that they are
transmitted up to 4 times until they are acknowledged (on the transport level) by the
receiver.
The node status supervision of physical SattBus is simulated on the transport level
above UDP by sending background supervision traffic a number of times per minute
(in the absence of other traffic). This enables node status reports to perform in a
similar way to physical SattBus, although the time resolution is lower. However, this
applies only to nodes where logical connections exist
3BSE035982R4001 55
Advanced Section 4 SattBus on TCP/IP
56 3BSE035982R4001
Section 5 COMLI
Introduction
COMLI (COMmunication LInk) is a standard protocol, designed by ABB
Automation, for data transmission/communication between controllers. It is a
conventional communication link using serial, asynchronous data transmission
according to the master/slave principle, in one direction at a time (half duplex
mode). It is used mainly for reading and writing variables between control network
devices, using point-to-point communication or multidrop communication. COMLI
can be used in serial communication (RS-232C and RS-485) as well as in SattBus-
TCP/IP.
COMLI is suitable for communication with controllers such as SattConXX, and has
been adapted to ensure that:
• maximum use is made of the communication line, resulting in compact storage
of data transmitted or received,
• by checking every character as well as the entire message, the transmission is
secure.
Services Provided
Master
• COMLI ReadPhys (Read Physical Value) (message G)
• COMLI WriteDT (Write Date and Time) (message J)
• Read and Write in registers and bits (messages 0, 2, 3, 4)
Slave
• Only Read and Write in registers and bits (messages 0, 2, 3, 4)
3BSE035982R4001 57
Design Section 5 COMLI
Design
Introduction
Master and slave can be linked together in different ways to achieve the desired
function, e.g. point-to-point or multidrop (multipoint).
Master and slave are linked via the serial channels on the different systems that are
to communicate with each other. The master and slave need not use the same
physical channel numbers in both systems. They must, however, have the same
character format, transmission speed, etc.
When the slave receives a message, it responds either by sending the information
requested or by acknowledging the information received. The slave does not
respond if it receives an error message.
To change the status of a system/device from master to slave, a new configuration
must be downloaded from Control Builder.
58 3BSE035982R4001
Section 5 COMLI Design Examples
Design Examples
Multipoint Communication
In multipoint communication several slave systems are connected to a master.
Communication takes place between the master and one slave at a time. Direct
communication between slave systems is not possible. A particular message from
the master is sent to all slaves, but only the slave whose unique identity corresponds
to the identity contained in the message accepts the data. The number of slaves that
can be connected to each master is limited by the communication interface. The RS-
485 interface must be used in multipoint communication. The master transmit line is
connected to all slave receive lines and all slave transmit lines are made common
and connected to the master receive line.
Master
Channel n
RS-232C/485
converter
Slave ID 1 Slave ID 247
Slave ID 125
Figure 14. Example of multipoint communication.
3BSE035982R4001 59
Redundancy Section 5 COMLI
Point-to-Point Communication
In point-to-point communication, only one slave system is connected to the master
via one communication interface. Several slaves can be connected to the master but
this must take place via different communication interfaces. This form of point-to-
point configuration can reach a capacity higher than that achieved with multipoint
communication.
The electrical interface can be either RS-232C or RS-485.
Master Master
Channel n Channel m
Slave ID 1 Slave ID 1
Figure 15. Example of point-to-point communication.
Redundancy
Redundancy is not built in, but can be implemented on application level or physical
(cable) level by the user.
Limitations
• A maximum of 31 slave systems can be connected to each serial channel via
the RS-485 electrical communication interface (the COMLI communication
protocol can administer a maximum of 247 slave identities, see Figure 14).
• The maximum message size is 512 bits or 32 16-bit registers (integer reading).
60 3BSE035982R4001
Section 5 COMLI Performance
Performance
Performance is affected by transmission speed, message length and application
load.
For RS-232C channels a baud rate can be selected between 2400 and 19200 bits per
second. To send a byte requires 11 bits (start bit, 8 data bits, parity bit and stop bit).
Consequently 9600/11 = 872 bytes per second can be sent if the baud rate is 9600.
The maximum transmission distance depends on the interface used (RS-232C or
RS-485) and the transmission speed. The table below provides guidelines for the
different interfaces and speeds. Note that a noisy electrical environment may require
shorter distances.
Table 7. Different interfaces and speeds
Distance (m)
Speed (bps)
RS-232C RS-485
2400 150 1200
4800 75 1200
9600 40 1200
19200 20 1200
38400 1200
Values given for shielded, twisted pair cables of type Belden 8723 or Belden 9502.
Longer distances require a short-range modem.
In AC 800M, servicing the S800 I/O via ModuleBus has highest priority. Execution
of the application program (IEC 1131-code written by the user) has next highest
priority. Depending on the amount of code and the requested execution intervals, the
application program may require up to 70% of CPU capacity. Communication
handling has lowest priority, though normally at least 30% of CPU capacity will be
reserved for this purpose.
3BSE035982R4001 61
Hardware Section 5 COMLI
Communication takes place serially and asynchronously according to the

master/slave (or client/server) principle. The master channel of a system initiates
the message transmission sequence, while a system acting as a slave simply
responds to the calls from the master via a slave channel.
Master functionality is implemented by function blocks provided by the
communication libraries, such as COMLIWrite and COMLIRead, used to
write/read data between controllers. In a system acting as master, the
communication performance is of course affected by the execution interval of the
communication function blocks in the application program. Response is handled in
the background; it is not triggered by the application program in the slave system,
but is slowed if the application load is high.
The terms register (16 bit integer 0-65535) and bits refer to the COMLI protocol and
are mapped to the data types dint (double integer) and bool (Boolean) in the AC
800M world. The number of variables that can be sent in one COMLI message is 1-
512 bool or 1-32 dint. Boolean variables must be transferred either as a single
variable or in multiples of eight, maximum 512. Variables of type bool and dint
cannot be mixed within the same function block. A long message takes longer to
transmit than a short one, but it is always more efficient to use long messages if a
large data area is to be transmitted.
For more information on performance refer to Control Software documentation.
Hardware
A standard RS-232C/485 communication channel is required. The cable length can
be extended considerably (to several km) using a fiber optic converter.
One of the following standard communication interfaces is used for serial
communication with COMLI:
• RS-485
• RS-232C
• When using multipoint communication, ports must support RTS (hardware
handshake) or CTS.
62 3BSE035982R4001
Section 5 COMLI Advanced
Advanced
Procedure for Linking Control Systems with COMLI
The procedure for connecting different control systems to a common COMLI
communication network can be summarized as follows:
• Select the message types by establishing the type of information to be
transmitted between systems.
• Select the network configuration. Select multipoint or point-to-point and the
communication interface to be used, i.e. RS-485 or RS-232C.
• Select the channel (channels) to be used. The choice depends on which
channels are available and whether the channel can transfer the required
information at the required speed.
• Decide which system is to be master and which is to be slave. This is specified
in the channel parameter list. The master controls data transmission operations
since only the master can initiate a message transmission sequence.
• Connect the systems to the network with suitable cables.
When the above has been completed, the various communication parameters can be
defined in a number of data fields.
3BSE035982R4001 63
COMLI Message Format Section 5 COMLI
COMLI Message Format
General
COMLI defines the handshaking procedure, the message start and stop characters
used, whether or not the message has a header, the contents of the acknowledgement
message, etc.
The formats for different types of messages are similar. Each message starts with a
start character (STX) followed by characters for destination, time stamp, message
type and data.
Messages are divided into the following types of transactions:
• Request message from master to slave (13 characters), followed by a
Transmission message,
• Transmission message from master to slave or slave to master (14–77
characters), followed by an Acknowledgement message,
• Acknowledgement message (transfer OK) from slave to master (8 characters).
A master only transmits a request when it requires data from a slave. If the slave
cannot carry out the request or an error occurs in the request message, no reply is
sent by the slave.
A master or a slave can transmit a transfer message. When a master needs to change
data in a slave, it transmits a message, which results in an acknowledgement by the
slave. The slave does not respond if the message is not received correctly or if the
data transmitted cannot be processed. A reply from a slave to a master can be sent as
a result of a request for data. In this case, the reply containing the data is also an
acknowledgement that the request was received and processed correctly.
A slave will only send an acknowledgement when data from the master is correctly
received.
64 3BSE035982R4001
Section 5 COMLI COMLI Message Format
Message Format
Regardless of whether it consists of a request, a transfer of data, or an
acknowledgement, a message is made up of three blocks: start block, information
block, and end block. The start and end blocks have the same format in all types of
messages, whereas the information block varies depending on message type. The
characters in the start and end blocks are always in ASCII format, the contents of the
information block in binary format.
Start Block
The start block comprises three parts, namely STX, identity and stamp. For further
information, refer to the COMLI System description.
Binary Communication
In supported binary communication, two characters occupy one byte, thereby
doubling the packing density of the data block. Any combination of eight bits can be
used. Thus the eight bits representing a character can assume any value between 00
and FFH.
Channel Definition
Each channel to be used for communication must then be defined so the channels
used in the different systems are set up in the same manner. This is specified in the
channel parameter list.
Channel definition also includes selecting which system is to control the network,
i.e. the master station. Each network contains only one master, but several slaves can
be included. When more than one slave is included, the channel definition for each
slave must stipulate the slave identity. This identity must be unique in each
communication network.
3BSE035982R4001 65
COMLI Message Format Section 5 COMLI
66 3BSE035982R4001
Section 6 INSUM
Introduction
INSUM (INtegrated System for User-optimized Motor control) utilizes
microprocessor-based technology for protection and control of motors and
switchgear, and for the transmission of messages and measured values.
Each motor has a motor control unit (MCU) located in the motor starter module.
The INSUM devices (such as MCUs) are arranged in up to four subnets, each one
supporting up to 32 units at a 78kb/s transfer rate. A network (LonWorks) transfers
messages at 1.25Mbps between the subnet units via routers. One INSUM MMI
(man-machine interface) can be connected to LonWorks; also one or more AC
800M controllers equipped with INSUM TCP/IP interface units CI857.
3BSE035982R4001 67
Services Provided Section 6 INSUM
Services Provided
• Multiple controllers can access the same MCU in an INSUM system.
• Three IEC 61131 function blocks are available for initialization of and
exchanging data with the INSUM system, namely INSUMConnect (establishes
connection), INSUMReceive (reads a process data value from an INSUM
device), and INSUMWrite (writes a value to an INSUM device).
• A number of different motor types are supported, such as reversing motors,
two-speed drives, actuators, and solenoid valves.
• Protection against thermal overload, underload, phase loss, ground fault, high
motor temperature, locked rotor, etc.
• Protection functions can be parameterized to specify pre-warnings before a
motor is tripped. The reset can be selected as automatic, remote, local or
remote and local.
68 3BSE035982R4001
Section 6 INSUM Design
Design
Introduction
INSUM hardware is configured by means of the project explorer in Control Builder
(see figure below). The AC 800M is equipped with two INSUM TCP/IP CI857
interface units, located as numbers 3 and 4 to the left of the PM860 CPU unit. Unit
No. 3 is connected to three INSUM gateways, each supervising an INSUM motor
control system.
Figure 16. Project explorer.

Gateway No. 2 has three MCUs and one tier switch connected to its subnet No. 1,
with node numbers 1, 2, 3 and 32. Two MCUs are also connected to subnet No. 2
and one circuit breaker to subnet No. 4.
The CI857 units and the INSUM gateways have IP addresses that must be specified
in the parameter lists.
3BSE035982R4001 69
Design Example Section 6 INSUM
Design Example
AC 800M controllers with INSUM TCP/IP CI857 interface units serve as routers
between Control Network and the separate INSUM Ethernet network running
TCP/IP at 10Mbps. An INSUM TCP/IP gateway connects the Ethernet to the
LonWorks network that communicates via routers with the INSUM devices
arranged in four subnets. A complete INSUM system is shown with 128 INSUM
devices (motor control units [MCU], circuit breakers [CB] and intelligent tier
switches [ITS]). An MMI (man-machine interface) is connected to LonWorks.
Control Network
INSUM
AC 800M
operator
controllers
station
CI857 CI857
TCP/IP
Ethernet
INSUM
MMI
TCP/IP gateway
LonWorks
Router Router Router Router
Subnet 1 Subnet 2 Subnet 3 Subnet 4
MCU MCU MCU CB

1/01 2/01 3/01 4/01
MCU MCU ITS CB

1/32 2/32 3/32 4/32
Figure 17. INSUM integration with Control Network.
70 3BSE035982R4001
Section 6 INSUM INSUM Alarms
Due to performance considerations, the Control Network and the TCP/IP

Ethernet between CI857 and the INSUM TCP/IP gateways must be kept
separate! Also, see INSUM documentation.
INSUM Alarms
All INSUM devices (MCU, Circuit Breaker etc.) have supervision functions that
can report alarms. The different device types supervise and report specific alarm
types. The alarms are reported in specific Network Variables.
MCUs report the alarms in the Network Variable NVAlarmReport.
Circuit Breakers report the alarms in the Network Variable NVNodeAlarmRep.
The user can decide to use the information from these alarm report variables in two
different ways:
1. Receiving INSUM alarms in the application program.
Receive the actual state with an INSUMReceive block in the IEC 61131
application. This way the information can be used in the application and be
displayed for the operator on the Plant Explorer Workplace. The user has to
decide how to use and how to display this information. It could for example be
in a faceplate for a motor.
2. Generating alarm to the alarm lists.
Define one or more AlarmCond function blocks and let the Controller system
software (the INSUM Protocol Handler) generate alarms to the alarm and event
lists are displayed at the operator station based on the updates of the INSUM
alarm information. The user can decide if each single alarm type should
generate a separate entry in the alarm list or if there should be one summary
entry that tells that there are some alarms (one or more) in the device.
In the INSUM system a system clock can be used to synchronize the clocks in the
INSUM devices. The network variables for alarm reports contain a time stamp that
is set by the device.
3BSE035982R4001 71
Creating an Application that Handles INSUM Alarms Section 6 INSUM
Creating an Application that Handles INSUM Alarms

This subsection discusses both methods, receiving INSUM alarms in the application
program, and, generating alarm to the alarm lists. You can decide to use either
methods or just one of them.
Receiving INSUM Alarms in the Application

To receive alarms in the application program the INSUMReceive function block is
used in the same way as when receiving other input network variables from an
INSUM device, choose the correct NVindex and data type. The data type should in
this case be NVAlarmReport (see also the MCUAlarmTrips/WarningsStructs
regarding how to interpret the bits).
The time stamp set by the INSUM device in the alarm variable is presented in the
two time fields of the NVAlarmReport. This time information is only correct if the
clock in the INSUM device is synchronized. The system software does not fill in
these fields if the time stamp received from the INSUM device is incorrect. (See
below).
Generating Alarms for Alarm Lists

The Controller system software generates alarms for the alarm and event lists in the
Plant Explorer Workplace, based on the updates of the INSUM alarm information if
the parameter "Generate Alarms" on the device is set to Enabled or Enabled
Detailed.
If the time stamp received from the INSUM device is correct (a valid time) this time
stamp is used for the generated alarm message. If it is not, the system software tags
the generated alarm message with the current controller time.
Note. If the parameter "Generate Alarms" is set to disabled, alarm information can
anyway be sent to the alarm and event lists by the application. This can be done by
creating an AlarmCond function block and to connect information received from an
INSUM device to the parameter "Signal" and to set
"External Time Stamp" = FALSE.
In this case, the alarm messages are time stamped in the controller.
72 3BSE035982R4001
Section 6 INSUM Generating Alarms for Alarm Lists
If this time accuracy is sufficient, this method is probably to be recommended. One

of the main advantages of letting the system software generate the alarms is that it
can use the time stamp given by the INSUM devices.
In both cases an AlarmCond block has to be created if the messages in the alarm
lists should be understandable, see below.
Collection Alarms, One Alarm Object Per Device

Generate Alarms = "Enabled" means that the system software internally (without
needing INSUMReceive) creates a subscription of the alarm variable from the
INSUM device. When this variable is updated from the INSUM system, the system
software evaluates the content.
If a bit (one or more) which is classified as an alarm (e.g. not the bit "Started1") is
set and no such bit previously was set, the system software generates one alarm
message.
If an alarm update is received with the change that no alarm classified bits are set
any more, the system software generates the "alarm-off" message.
Detailed Alarms
Generate Alarms = "Enabled Detailed". The difference compared to the handling for
"Enabled" (see Collection Alarms, One Alarm Object Per Device on page 73) is that
for each alarm classified bit which is set (and previously was not set) the system
software generates one separate alarm message.
If an alarm update is received with the change that an alarm classified bit that
previously was set now is reset, the system software generates the "alarm-off"
message for that bit.
Note. Using "Enabled Detailed" means that one AlarmCond block should be created
for each alarm type that the INSUM device sends. For a large INSUM configuration
where more than just a few alarm types per device should be supervised this easily
leads to a very large number of AlarmCond blocks.
3BSE035982R4001 73
Generating Alarms for Alarm Lists Section 6 INSUM
Creating AlarmCond Blocks for Generated Alarms

The function block AlarmCond should be used to get descriptive messages in the
event and alarm list and get an association with an alarm object. AlarmCond is
associated with the alarm messages that the system generates by setting
ExternalTimeStamp=TRUE and to identify the alarm object with the parameter
SignalId.
When Alarm Generation = Enabled, the SignalId should be a string that specifies
the hardware position for the INSUM device.
This is done with the syntax: "C.G.D", where:
• C is the position of the CI857,
• G is the position of the INSUMGateway, and,
• D is the position of the INSUM device. The position numbers are separated by
a dot '.'.
Examp1e:
"2.1.204" means the alarm for device #204 connected via Gateway #1 on CI857 #2.
When Alarm Generation = Enabled Detailed, the SignalId should be a string that, in
addition to the hardware position for the INSUM device, also specifies the alarm
word and bit within the word. This is done with the syntax: C.G.D-X/B, where:
• C, G, and D as above, and,
• X is the word within NVAlarmRep,
• B is the bit within the word. The word is preceded by a dash '-' and the word
and the bit are separated by a slash '/'.
The words are called W0, W1, W2, W3, T0, T1, T2, and T3, that is, 4 words with
Warnings and 4 words with Trips. The bits are numbered from 0 to 15.
Example:
"2.1.204-W1/3" means the alarm bit 3 in word W1 in device #204 connected via
Gateway #1 on CI857 #2.
The INSUM documentation describes the different bits in the alarm words. For a
MCU, the data types MCUAlarmWarnings0Struct, MCUAlarmTrips4Struct etc.,
can also give this information and for Control Builder M CBAlarmWarnings0Struct
74 3BSE035982R4001
Section 6 INSUM Choose Alarm Handling Method
and CBAlarmTrips0Struct can be used. However, it should be noted that the

elements in these structures are numbered from 1 to 16. The bit number is thus
achieved by the element number minus one.
Example2:
"No Load Trip" for an MCU is signaled with bit 5 in Trip word 0. This means that
the corresponding SignalId should end with "-T0/5”.
If an alarm message is generated for, a SignalId that has not been defined by any
AlarmCond block the message is sent to the event list as an undeclared event. The
SignalId is then printed in the list.
Note. If the parameter "Generate Alarms" is set to Disabled, alarms can still be
received by the application with INSUMReceive. It is just the generated alarm
message that is disabled by the system software.
Choose Alarm Handling Method

This section contains some suggestions about choosing and handling INSUM
alarms. Whether to send alarms to alarm list or not:
• If Alarms should be possible to view, but are not necessary to see in the Alarm
lists:
– Set Generate Alarms = Disabled.
– Do not create any AlarmCond blocks.
• If the INSUM Alarms should be sent to the alarm list:
– Use AlarmCond function blocks. See INSUM Alarms in Alarm Lists
below.
3BSE035982R4001 75
Choose Alarm Handling Method Section 6 INSUM
INSUM Alarms in Alarm Lists

Time stamping:
• If local (in the INSUM devices) time stamping should be used:
– Use a system clock in the INSUM system.
– Set Generate Alarms = Enabled/Enabled Detailed
– Use an AlarmCond block with External Time Stamp = TRUE.
• If it is sufficient with time stamping in the application in the controller:
– Set Generate Alarms = Disabled
– Use an AlarmCond block with External Time Stamp = FALSE.
– Connect it to the variable with the INSUM device information to be
supervised. The accuracy of this time stamping cannot be better than the
cycle time of the application where the AlarmCond is executed.
Separation of alarms in the alarm list:
• If the timing between different alarms within a device must be possible to see
in the alarm list than it is required to:
– Set Generate Alarms = Enabled Detailed.
– Use one AlarmCond per alarm type.
• If it is sufficient to be able to identify the device than it is possible to:
– Set Generate Alarms = Enabled
– Use one AlarmCond per INSUM device.
Number of devices:
• If there is a lot of devices needing external time stamping than required for:
– Use one AlarmCond per INSUM device.
– Set Generate Alarms = Enabled
• If there is a few devices that need external time stamping than it is possible to:
– Use one AlarmCond per alarm type.
– Set Generate Alarms = Enabled Detailed
76 3BSE035982R4001
Section 6 INSUM Limitations
Limitations
INSUM system limits:
• Maximum 128 INSUM devices per INSUM TCP/IP gateway
• Four LonWorks subnets per INSUM TCP/IP gateway
• Maximum 32 devices per LonWorks subnet.
• Circuit breakers (CBs) require a special router and cannot be mixed with other
INSUM devices on the same subnet.
• Time Synchronisation of the INSUM system via TCP/IP is not supported.
There is however an INSUM system Clock for time synchronisation from GPS.
Limitations of the INSUM integration in Control IT:
• AC 800M is the only Control IT controller that can be connected to INSUM.
Advant Controller 410/450 can, however, be connected to one INSUM system.
Limitaions due to CPU load and memory consumption in the AC 800M (verified
with PM861):
• Maximum 128 MCUs (or other INSUM devices) per AC 800M
• Maximum 6 CI857 per AC 800M
Limitaions due to CPU load and memory consumption in the CI857:
• Maximum 128 MCUs (or other INSUM devices) per CI857
• Maximum 2 INSUM TCP/IP Gateways per CI857
Performance
Because the INSUM system is well separated from Control Network and other
IndustrialIT topology, the performance of the basic functions is not affected.
Subnetting in LonWorks helps to optimize the network load by localizing the traffic.
Only changed data is sent via the gateway. Digital data is sent when its binary value
changes, and analog data when the value changes more than the dead band. The
Ethernet connection between the AC 800M controllers and the INSUM TCP/IP
gateways can be favorably designed as a switched network to avoid transmit
collisions and increase the bandwidth when more than one controller is connected.
3BSE035982R4001 77
Hardware Section 6 INSUM
Hardware
• INSUM TCP/IP interface units CI857 connect to the CEX bus of the AC 800M.
• Twisted pair 10BASE-T Ethernet cable with RJ45 connector. The installation
should comply with the Category 5 specification according to IEEE 802.3.
• The LonWorks bus is integrated in the INSUM system backplane.
• INSUM routers and gateways, power supply, motor control units, circuit
breakers, tier switches and man-machine interfaces are devices belonging to
the INSUM system.
• INSUM routers, gateways and power supplies are connected directly to the
INSUM backplane. Motor control units, circuit breakers, tier switches and
man-machine interfaces are connected by means of prefabricated cables.
Troubleshooting
The INSUM TCP/IP CI857 interface units and the INSUM routers and gateways
have LEDs indicating communication activity and unit error states. The Control
Builder hardware tree shows the status of the different hardware units. The function
blocks have outputs indicating error condition and status code.
78 3BSE035982R4001
Section 7 Siemens 3964R
Introduction
Siemens 3964R1 is a rather widespread communication protocol designed by
Siemens. It is a standard serial point-to-point master/slave protocol. No special
hardware is required apart from standard RS-232C/485 communication channels.
Siemens 3964R is convenient for communication with instruments (e.g. scales) or
controllers also using this protocol.
Services Provided
• Multiple registers can be read/written.
• Multiple I/O bits can be read.
• One message can handle a maximum of 512 I/O bits or a maximum of 32
registers.
• Writing of single I/O bits is also supported, with the following limitation:
writing of a single I/O bit is done to data block 222, using a special bit message
which is not implemented in Siemens 3964R. Special application software is
needed in the Siemens system to handle this. It is possible to change the data
block via the SiemensBitTransferDB system variable in the controller.
• Messages can have 32 registers, but they must not exceed data block
boundaries. This means that the data blocks in Siemens systems
communicating with this system are limited to data blocks 3-14.
1. Protocol 3964R can be distinguished from 3964 simply by the presence of the control character (BCC),
providing more reliable transmission.
3BSE035982R4001 79
Design Section 7 Siemens 3964R
The following services are provided.
Service Direction Comment

“E” message, data type D Controller to Siemens Request for data, register
“E” message, data type E, A, M Controller to Siemens Request for data, byte
“E” message, data type E, A, M Controller to Siemens Request for data, bit
“E” message, data type D, E, A, M Siemens to controller Answer to request for data
“A” message, data type D Controller to Siemens Transfer of data, register
“A” message, data type D Controller to Siemens Transfer of data, bit
“A” message, data type D Siemens to controller Answer to transfer of data
In the above table, controller means AC 800M acting as the client, and Siemens
means Siemens PLC as a server.
Design
Introduction
Communication is performed via function blocks. The controller sends one read or
write message to the subsystem and then awaits the answer. This means only one
message will be outstanding per channel, i.e. master/slave principle
The figure below shows a Siemens 3964R network in principle.
Siemens 3964R
PLC1 PLC2 PLCn Simatic controllers
Figure 18. Siemens 3964R network principle.
80 3BSE035982R4001
Section 7 Siemens 3964R Design Examples
Before Siemens 3964R communication can be started, the normal RS-232C

parameters must be set for the Control Builder Com port. Refer to the online help
for details.
Design Examples
Figure 19 shows a typical design example involving an AC 800M controller and two
Siemens systems.
Siemens system 1 AC 800M controller
Siemens system 2
Serial port 1 Serial port 2
Figure 19. Siemens 3964R, schematic design example.
Redundancy
(cable) level, by the user.
Limitations
• The controller can act only as master; i.e. only client functionality is supported
for Siemens systems.
• Only point-to-point communication is possible; i.e. only one slave may be
connected to each communication channel.
• “Interpreter RK512” must be installed on the Siemens system (the slave).
• Writing of multiple I/O bits is not supported.
3BSE035982R4001 81
Performance Section 7 Siemens 3964R
Performance
Similar to COMLI, see Performance on page 61.
Hardware
A standard RS-232C/485 communication channel is required.
Cable lengths: RS-232C: 15m, RS-485: 1200m. The length can be extended
considerably (to several km), using a fiber optic converter.
Both 2-thread and 4-thread communication can be used for the RS-485 port.
Advanced
Communicating Integers
Integers can be read and written. The value range for integers fetched from
controller subsystems is 0-65535, while the range for data words in SIMATIC is -
32768 to +32767. This means that a value between 0 and 32676 in an integer that is
loaded down to a data word in SIMATIC will be interpreted correctly, while values
greater than 32767 will be interpreted as negative.
Messages can have 32 integers but must not exceed data block boundaries. This
means that the data blocks in Siemens systems communicating with a controller
must keep to data blocks 3-14 (see Table 8).
82 3BSE035982R4001
Section 7 Siemens 3964R Communicating Bits
Table 8. I/O-bits, integers and data blocks.
I/O bits in the Integers Data Word Word

I/O bits in
controller (max in the blocks in for S5 for S7
Siemens
512/message) controller Siemens system system
0 Inputs 0.0 0 3 0 0
1 0.1 ... 3 ... ...
7 0.7 255 3 255 510
10 1.0 256 4 0 0
... ... ... 4 ... ...
1777 127.7 511 4 255 510
... ... ... ...
3000 Outputs 0.0 ... ... ... ...
... ... 3071 14 255 510
4777 127.7
6000 Flag 0.0

... ...
11777 255.7
Communicating Bits
Groups of bits can only be read, not written. During reading of bit values and
reading and writing of integer values, communication takes place directly with the
bit and data block areas in the SIMATIC system. Up to 512 bits per message are
handled during reading of bits, and up to 32 integers per message are handled during
reading or writing of integers.
When a large number of bits need to be sent concurrently it is better to use registers
for the actual transmission and then convert them to and from bits in the controller
and the SIMATIC system.
3BSE035982R4001 83
Communicating Bits Section 7 Siemens 3964R
When using function block 3964RWrite to write a single bit to the subsystem, the
controller will pack the type of bit value, the bit number and the new value in a word
and send it to data word zero in a specific data block in the SIMATIC system.
The message is unpacked by a controller program in the SIMATIC system. This

program must always be included in the SIMATIC control system. The program
must be executed often enough to be able to handle a message before the next
message can arrive from the controller.
Type of data New Not used Destination bit 2-0

value
7 6 5 4 3 2 1 0
15 14 13 12 11 10 9 8
Destination byte address 15-8

The type of data is defined by bits 7 and 6
Type of data bit 7 bit 6
Input bit 1 1
Output bit 1 0
Flag bit 0 1
Figure 20. Code word for the writing of a bit.
The receiving data block number in the Siemens system is set in the controller with
the system variable SiemensBitTransferDB. The default value is 222 and the range
1-255.
84 3BSE035982R4001
Section 8 ModBus RTU
Introduction
ModBus RTU is a standard protocol widely spread because of its ease of use and the
fact that it supports communication over a wide variety of media, such as wire, fiber
optics, radio and the telephone.
ModBus is executed serially and asynchronously according to the master/slave
principle, and in one direction at a time. However, only master functionality is
implemented in the ControlIT controllers. Modbus is used mainly for reading and
writing variables between control network devices, using point-to-point or
multidrop communication. Message framing is implemented in RTU mode, which is
a binary format. The ModBus protocol is designed to transfer data securely by
checking each byte as well as the entire message for transmission errors.
3BSE035982R4001 85
Services Provided Section 8 ModBus RTU
Services Provided
A number of ModBus commands are supported. The application programmer can
access the protocol functions through function blocks, according to the IEC 61131-5
standard. The protocol software translates the request from connect, exception, read,
and write blocks into ModBus protocol commands. The following protocol
commands are supported:
Table 9. ModBus protocol commands
Protocol Description Protocol Description

FC1 Read coil status FC6 Preset single register
FC2 Read input status FC7 Read exception status
FC3 Read holding registers FC8(1) Diagnostic request
FC4 Read input registers FC15 Force multiple coils
FC5 Force single coil FC16 Preset multiple registers
(1) Some slaves do not understand FC8. To avoid problems, set Poll Time to zero (0).
Design
Introduction
Communication with ModBus takes place serially and asynchronously according to
the master/slave principle.
• The master channel of a system controls the communication of devices with
slave function.
• A device with slave function is connected via a slave channel and its
communication is controlled from a master channel.
Note that a specific device may have some channels specified for a master and
some for a slave. Consequently the device may act as master in relation to some
devices and as slave in relation to others. See also Figure 21 & 22 for a graphical
view of the concept.
86 3BSE035982R4001
Section 8 ModBus RTU Design Examples
Design Examples
Point-to-Point Communication
Point-to-point communication means that only one slave system is connected to the
master channel, as shown in Figure 21
Master channel Slave channel
Figure 21. Master/slave in a point-to-point communication configuration.
Each channel has a channel definition defining the method of communication.

Master and slave must not use the same channel number or address for
communication. However, the channels must be set up in the same way with regard
to character format and baud rate.
Several slaves may be connected to a controller, but via different serial channels (see
Figure 22). This network configuration offers higher speed than multidrop
communication. RS-232C or RS-485 (via a converter) is used as the electrical
communication interface. Communication is controlled in the master by defining a
communication area which indicates the information the master must transmit to or
receive from the slave(s).
Slave
Master channels
channels
Figure 22. Point-to-point communication between a controller and several slaves.
3BSE035982R4001 87
Redundancy Section 8 ModBus RTU
Multidrop Communication
Multidrop communication means that several slaves are connected in parallel to the
serial master channel (see Figure 23). Note that the master can only address one of
the slaves at a time. Also note that, unlike the point-to-point design, only one RS-
485 master channel or an RS-232C channel with a standard RS-232C/485 converter
is needed.
Slave
Master channel RS-232C/485 channels
converter
Figure 23. Master/slaves in a multidrop communication configuration.
Redundancy
Redundancy is not supported in this release.
Limitations
• Only master functionality is implemented.
• Only RTU mode is implemented (only binary values are used).
• Communication using a dial-up modem is not possible.
Performance
Similar to COMLI, see Performance on page 61.
88 3BSE035982R4001
Section 8 ModBus RTU Hardware
Hardware
An RS-232C communication channel is required (and possibly an RS-232C/485
converter). Maximum cable lengths are 15m for RS-232C and 1200m for RS-485.
Cable length can be extended considerably (to several km) using a fiber optic
converter.
Advanced
More information and references to literature concerning ModBus can be accessed
from http://www.modicon.com.
Troubleshooting
The operator can monitor the status of all hardware units using the Project Explorer
in the Control Builder.
3BSE035982R4001 89
Troubleshooting Section 8 ModBus RTU
90 3BSE035982R4001
Section 9 FOUNDATION Fieldbus HSE
Introduction
FOUNDATION Fieldbus, developed by The Fieldbus Foundation, was introduced in
1995. It is a bi-directional protocol used for control system communication and
meets ISA SP50 requirements. It is a fieldbus used for communication with
distributed I/O units and fulfills the rigorous regulations and safety demands in
high-risk (explosive) environments, and supports process control without involving
a controller. It is an open protocol, which means that devices from different certified
manufacturers are compatible (interoperability).
FF defines two communication profiles, H1 and HSE The H1-Profile with a data
transmission rate of 31.25 kBit/s is preferably used for direct communication
between field devices in one link (H1 link). The HSE profile with a transmission
rate of 100 Mbit/s serves first and foremost as a powerful backbone for the link
between H1 segments. The first devices that are already available on the market and
support the HSE profile are FF linking devices. They serve as a gateway between
the field devices on the H1 segments and the HSE backbone.
Advantages
FOUNDATION Fieldbus H1
According to the Fieldbus Foundation (http://www.fieldbus.org), the benefits of
FOUNDATION Fieldbus include reduced wiring (many devices can be connected to
a single wire-pair), multi variables from a single field instrument, enhanced field
level control, as well as facilitated integration and system maintenance procedures
such as calibration and asset optimization predictive maintenance. For example,
through function blocks, FOUNDATION Fieldbus offers PID control via process
objects (even if the controller goes down). FOUNDATION Fieldbus is widely
supported by process object suppliers and allows integrated distribution of process
3BSE035982R4001 91
Services Provided Section 9 FOUNDATION Fieldbus HSE
object functionality. The distribution of control between the process objects may
reduce the number of I/O units and other control devices. Furthermore,
FOUNDATION Fieldbus is convenient for slow processes. It can communicate
large packets of device data and is suitable for complex control/automation
applications. FOUNDATION Fieldbus has no distortion (no A/D or D/A
conversion) and provides very reliable control functionality. In addition, the loop
performance is improved because the control is kept within the devices themselves.
FOUNDATION Fieldbus HSE

Fieldbus Foundation claims the same life cycle benefits for FOUNDATION
Fieldbus HSE as for H1. In addition HSE provides the control backbone that
integrates all of the systems in the plant. FOUNDATION Fieldbus offers the
performance needed by those users employing permanently connected online asset
management software and other maintenance management operations gathering
large amounts of information in real-time. Due to the open protocol, plant
subsystems, even from different suppliers, may be easily integrated and information
can be accessed without custom programming as data integrity, diagnostics and
redundancy management are part of HSE. Linking devices bring data from one or
more H1 links directly onto the HSE backbone. Thus HSE can bridge information
between devices on different H1 links. Communication requires no central
computer. HSE can replace enterprise, control and remote-I/O networking levels,
thus flattening the enterprise communication structure. Standard Ethernet cable and
wiring practises are used for HSE devices. Standard Commercial Off-The-Shelf
Ethernet components may be used, which guarantees for extremely low costs,
compared to proprietary solutions.
Services Provided
The CI860 communication interface unit provides publisher/subscriber services for
FF HSE signal traffic to communicate with FF devices.
For a description of client/server and publisher/subscriber communication
methods, see Connection Methods on page 97.
To access FF function block data the OPC server FF, which uses client/server
communication, is required. For HSE subnet configuration the Fieldbus Builder FF,
which also uses client/server communication, is required.
92 3BSE035982R4001
Section 9 FOUNDATION Fieldbus HSE Design
Design
Introduction
FOUNDATION Fieldbus is flexible, supporting function block scheduling, which
means that basic control and measurement features can be implemented similarly
regardless of the device manufacturer.
Self-test and communication capabilities of microprocessor-based fieldbus devices
reduce downtime and improve plant safety.
FOUNDATION Fieldbus (FF) is integrated into the controllers by the
communication interface module for FOUNDATION Fieldbus HSE (CI860). In
Control Builder, the CI860 is a hardware object created and configured in the
project explorer.
FF HSE configuration requires Control Builder M Professional.
The configuration of FF HSE subnets is carried out with the Fieldbus Builder
FOUNDATION Fieldbus (FBB FF). Thus configuration of CI860 requires both
Fieldbus Builder FF and Control Builder M.
Design Example
Figure 24 shows the architecture of a system including engineering and operator
station workplaces, controllers with FOUNDATION Fieldbus HSE CI860
communication interface units, linking devices, FF HSE devices, and H1 devices.
In larger configurations, it is important to separate operator station and controller
networks. In smaller configurations, operator stations and controllers may use the
same network.
As an alternative, in smaller configurations, operator stations and FF HSE
devices may use the same network.
FOUNDATION Fieldbus HSE Subnets must never be combined with the
controller network. FOUNDATION Fieldbus HSE multicasts create too much
load on the controller network.
3BSE035982R4001 93
Design Example Section 9 FOUNDATION Fieldbus HSE
Aspect Server Plant Explorer Workplace Plant Explorer Workplace

Control Builder M Control Builder M
Fieldbus Builder FF Fieldbus Builder FF
Operator station network (Client Server Network)
Connectivity Server
OPC Server AC 800M
Controller network
(Control Network)
CI860 CI860
Connectivity Server Connectivity Server
OPC Server FF OPC Server FF
AC 800M AC 800M
FF HSE subnet FF HSE subnet
LD 800HSE LD 800HSE FF HSE LD 800HSE FF HSE

Linking Device Linking Device Linking Device
FF H1 FF H1 FF H1
Links Links Links
FF H1 Field Devices FF H1 Field Devices FF H1 Field Devices
Figure 24. Example of system structure for FOUNDATION Fieldbus HSE.
General
• Multiple HSE subnets may be connected to a system.
• The CPU module of the AC 800M Controller must be connected to the
controller network.
• The FOUNDATION Fieldbus HSE CI860 communication interface units in the
AC 800M Controller must be connected to a HSE Subnet.
• Up to six FOUNDATION Fieldbus HSE Communication Interface Modules
may be connected to one AC 800M controller
94 3BSE035982R4001
Section 9 FOUNDATION Fieldbus HSE Design Example
• The FOUNDATION Fieldbus HSE Communication Interface Module CI860

may be used in redundant controllers, but it does not support module
redundancy.
• The Linking Device LD 800HSE connects H1 links to an HSE subnet.
• FOUNDATION Fieldbus HSE subnets should be physically separated from
other networks as FOUNDATION Fieldbus HSE multicasts cause high load on
the network.
• OPC Server FF provides tool routing functionality.
Fieldbus Builder FF provides tool routing only if no OPC server FF has been
added to the HSE subnet configuration in Fieldbus Builder FF.
– If the Client Server Network and FOUNDATION Fieldbus HSE subnet(s)

are separated from each other, which is the recommended configuration,
the Connectivity Server(s) running OPC Server FF are required, to
provide tool routing functionality for the workplaces running Fieldbus
Builder FF, so that these can access the FF subnet(s).
– If the Client Server Network and a FOUNDATION Fieldbus HSE subnet
are separated from each other without a Connectivity Server running OPC
Server FF, the workplace running Fieldbus Builder FF needs to be
connected directly to the HSE subnet, and to the Client Server network.
This is not recommended and should be used in small configurations only.
Only a single HSE Subnet can be configured.
– If the Client Server Network and a FOUNDATION Fieldbus HSE subnet
are not separated from each other (separating the networks is
recommended in production environments) and no OPC Server FF is
configured, the Fieldbus Builder FF provides tool routing functionality.
3BSE035982R4001 95
Design Example Section 9 FOUNDATION Fieldbus HSE
Operator Station Network (Client Server Network)

• The following components are connected to the operator station network:
– Aspect Server,
– Plant Explorer workplaces with Control Builder M and
Fieldbus Builder FF,
– Connectivity server with OPC Server AC 800M.
Controller Network (Control Network)

• The following components are connected to the controller network:
– Engineering station(s) with Control Builder M, Fieldbus Builder FF,
– Operator station(s) with Plant Explorer Workplace,
– AC 800M Controller(s),
– AC 800M OPC Server.
• For further information please refer to Control Builder M and AC 800M

documentation.
Device Network (HSE Subnet)

• The following components are connected to the HSE subnet:
– FOUNDATION Fieldbus HSE communication interface unit(s) CI860,
– Connectivity Server(s) with OPC Server FOUNDATION Fieldbus,
– FOUNDATION Fieldbus linking device(s) LD 800HSE.
• Multiple FOUNDATION Fieldbus Linking Devices can be used in an HSE
Subnet. It is recommend that a maximum of 10 Linking Devices is connected
to a single HSE Subnet.
96 3BSE035982R4001
Section 9 FOUNDATION Fieldbus HSE Connection Methods
• Multiple HSE Host Devices may be connected to an HSE Subnet.

• HSE Subnets are based on the Ethernet standard. Therefore standard Ethernet
components can be used to build an HSE subnet.
• All components used in an HSE Subnet must be capable of handling multicasts
as FOUNDATION Fieldbus uses multicast.
Standard routers without multicast routing functionality may not be used.
• During network dimensioning for HSE Subnets the additional load caused due
to multicasts has to be taken into account.
H1 Links
• Per FOUNDATION Fieldbus Linking Device LD 800HSE, up to 4 FF H1
Links may be connected.
• Experience has shown that a maximum of 8–10 devices may be connected to
each FF H1 Link.
Connection Methods
The publisher/subscriber method signifies scheduled traffic on the FF H1 bus using
publisher/subscriber connections between FF devices and the CI860. This
connection must be setup in the Fieldbus Builder FF. Fieldbus Builder FF is used to
map publisher/subscriber communicated FF signals to CI860 I/O channels. Thereby
access to FF function block inputs and outputs being connected to an FF signal in
Fieldbus Builder FF and being published or subscribed is possible. Only FF data
types DS65 and DS66 can be communicated with Publisher/Subscriber
communication.
A local connection between the controller and the CI860 must be setup using the
Control Builder M. Therefore Control Builder M allows variables to be mapped to
CI860 I/O channels. Dedicated Control Modules and function blocks allow for
comfortable FF signal handling. The publisher/subscriber method means higher
3BSE035982R4001 97
Connection Methods Section 9 FOUNDATION Fieldbus HSE
performance and efficient use of the FF H1 bus. See illustrations of the

publisher/subscriber method in Figure 25 for analog control modules, and in
Figure 26 for digital function blocks.
The client/server method describes unscheduled data traffic on the FOUNDATION
Fieldbus. The client/server method involves less configuration work but is slower
and uses the FF H1 bus less efficiently. The OPC server FOUNDATION Fieldbus
must be used for client/server communication. This allows access to all FF function
block parameters. All FF data types can be communicated. For detailed information,
please refer to the OPC Server FF documentation: FOUNDATION Fieldbus Device
Integration - Configuration.
Control modules executing in

Function block an AC 800M controller Function block
executing in a executing in a
FOUNDATION FOUNDATION
Fieldbus device. A PID controller Fieldbus device.
control module
AnalogInFFToCC * AnalogOutCCToFF
FF AI FB
FF PID FB
FFRealConnection data type ControlConnection data types FFRealConnection data type

(2xRealIO). Only one (2xRealIO)
component used.
* can be omitted by using the CI860 channel directly (RealIO)

since no backward signal is used
Figure 25. Example of a typical usage of the publisher/subscriber method with

FOUNDATION Fieldbus analog control modules.
98 3BSE035982R4001
Section 9 FOUNDATION Fieldbus HSE Redundancy
Function blocks executing in a AC 800M controller Function blocks executing in a

FOUNDATION Fieldbus device.
Motor Block BoollOToFFOut

BoolIO
OUT FF DO FB
FFBoolConnection data type

FB
FFToBoolIOIn * (2xBoolIO)
BoolIO
FF DI FB
* can be omitted by using the CI860 channel directly (BoolIO) since no

backward signal is used.
Figure 26. Example of a typical usage of the publisher/subscriber method with

FOUNDATION Fieldbus digital function blocks.
Redundancy
The CI860 communication interface unit supports redundancy.
For more information on how to set up redundancy for FF HSE linking devices, see
the Device Integration FF documentation and the FF Linking Device LD 800HSE
hardware documentation.
3BSE035982R4001 99
Limitations and Performance Section 9 FOUNDATION Fieldbus HSE
Limitations and Performance

High Integrity Controllers
The CI860 communication interface unit cannot be used in an AC 800M High
Integrity controller.
Dimensioning Limits, Linking Device

For information on linking device limitations, please refer to the FF Linking Device
LD 800HSE documentation.
Dimensioning Limits, FOUNDATION Fieldbus HSE Communication Interface

Module CI860
FOUNDATION Fieldbus HSE Communication Interface Module CI860, HSE

Level
• The CI860 can handle a maximum of 1000 VCRs (Virtual Communication
Relationships).
The CI860 Hardware Editor contains 3000 channels, but only 1000 can be used at
the same time. See Dimensioning Limits, FF HSE Communication Configuration
on page 101.
• Each VCR can be assigned to an I/O channel.

• For each CI860 a maximum of 500 signals per second can be read/written.
FOUNDATION Fieldbus HSE Communication Interface Module CI860,

Controller Level
• Please refer to the AC 800M hardware documentation.
100 3BSE035982R4001
Section 9 FOUNDATION Fieldbus HSEDimensioning Limits, FF HSE Communication Configuration
Dimensioning Limits, FF HSE Communication Configuration
Control Builder M, CI860 Configuration

The I/O channels are used to map variables to CI860 channels. Analog channels are
mapped to the RealIO data type whereas discrete channels can be mapped to either
the BoolIO or the DwordIO data type. The number of CI860 channels to which
variables can be mapped is limited to the following numbers:
• 1000 channels of type Real for analog inputs,
• 500 channels of type Real for analog outputs,
• 500 channels of type Bool and 500 channels of type Dword for discrete inputs,
• 250 channels of type Bool and 250 channels of type Dword for discrete
outputs.
The overall number of channels that can be used is limited to 1000.
Fieldbus Builder FF, CI860 Configuration

In Fieldbus Builder FF, FF signals can be mapped to CI860 channels in the HSE
Host Device CI860 object. For numbers and detailed information, please refer to
please refer to Device Integration FF documentation.
Hardware
The communication interface unit CI860 can only be used in AC 800M controllers.
Advanced
For more information, please refer to Device Integration FF and FOUNDATION
Fieldbus HSE documentation.
3BSE035982R4001 101
Troubleshooting Section 9 FOUNDATION Fieldbus HSE
Troubleshooting
Status of Hardware Units
The user can monitor the status of AC 800M hardware units using the Control
Builder Project Explorer in online mode. The Fieldbus Builder FF can be used to
monitor FF HSE and H1 devices as well as the H1 links. Some status information is
automatically collected by the system in the controller; some is collected if so
programmed and some can only be viewed using the Fieldbus Builder FF or the
OPC Server FF.
102 3BSE035982R4001
Section 10 DriveBus
Introduction
The DriveBus protocol is used for communication between ABB Drives and Special
I/O units on the one side, and an AC 800M controller, via the CI858 communication
interface unit, on the other side. The data exchange between the units is cyclic.
Special I/O is a separate product, supported by ABB Drives, Helsinki, Finland.
How to configure and use Special I/O is described in the Special I/O
documentation. This documentation, together with the Special I/O library and
Special I/O Hwd file, is delivered with the Special I/O product.
Special I/O is not part of the Control and I/O functionality in the System version
4.0, released and owned by ABB Automation Technology Products AB.
DriveBus communication is especially designed for sectional drive applications, for

example ABB rolling mill drive systems and ABB paper machine control systems.
Supported media:
• DDCS (Distributed Drives Communication System) protocol,
• Optical fibers for improved interference immunity and large network distances,
• The CI858 communication interface unit is CE-marked, and meets the
requirements specified in EMC Directive 89/336/EEC according to the
standards EN 50081-2 and EN 61000-6-2.
Services Provided
• Dataset communication,
• Cyclic output/input to/from drives,
• Cyclic data to/from I/O units,
3BSE035982R4001 103
Advantages Section 10 DriveBus
Advantages
• Supports many different types of drives and I/O units.
• Time synchronization of drives to common calendar time,
• Easy configurability of drives and Special I/O’s, to be used with AC 800M,
• Identification method, self-checking and preventive systems to avoid incorrect
configurations,
• Communication diagnostics for the application,
• No additional adapters required.
Design
DriveBus has specific definition parameters, required for device configuration.
Examples of such parameters are Configured application ID and Dataset priority.
The user connects all inputs and outputs to variables. DriveBus communication is
automatically created when the application is downloaded to the controller.
104 3BSE035982R4001
Section 10 DriveBus Design Example
Design Example
A DriveBus network typically consists of one or more drives, and one or more
Special I/O’s, see Figure 27.
DDCS CI858
PC Tool channel I/O channel Drive channel
Branching
Units
Drive
Tool MSTR
CH0 MSTR
Special NDBU NDBU •••
Up to 12 I/O’s
I/O CH1 CH2 CH3 CH1 CH2 CH3
Special CH0 CH0

I/O CH0 CH0
CH0 CH0
Drive ••• Drive • • •

Drive Drive
Drive Drive
Up to 24 Drives
Figure 27. DriveBus system topology. The PC Tool channel can be used for
downloading firmware to the CI858 communication interface unit.
Dataset Communication
The data exchange between AC 800M, ABB Drives and I/O units, via CI858,
consists of dataset pairs, which include input and output datasets. One dataset (DS)
consists of three 16-bit words, called data words (DW).
Datasets are read from ABB Drives. Therefore, datasets need to be defined by
setting ABB Drive dataset parameters during the system configuration. See
Configuration on page 107.
3BSE035982R4001 105
Design Example Section 10 DriveBus
AC 800M/CI858 RMIO
Application controller Address
software
assignment of
DS11 Dataset table datasets AMC
in channel 1 DS Value Group Index table
In_variable1 CH0
in channel 2 DriveBus VAL 1 92 01
In_variable2
in channel 3 11 VAL 2 92 02
In_variable3
VAL 3 92 03
Address
assignment of
DS10 Dataset table datasets AMC
Out_variable1 out channel 1 DriveBus DS Value Group Index table
CH0 90 01
Out_variable2 out channel 2 VAL 1 7.01
Out_variable3 out channel 3 10 VAL 2 90 02 23.01
VAL 3 90 03 25.01
Figure 28. Dataset communication.
106 3BSE035982R4001
Section 10 DriveBus Redundancy
Configuration
To activate communication between the AC 800M, CI858, ABB Drives and I/O
units, the system must be configured with valid parameters:
• Configure DriveBus communication using the Control Builder M engineering
tool,
• Define datasets by setting ABB Drive dataset parameters, for example
parameter groups 90…93 for Engineered Drives. See ABB Drives Firmware
documentation for dataset and other required parameter settings.
The Control Builder configuration includes the following steps:
• Add units to the hardware tree,
• Define parameters,
• Connect variables,
• Download the project to the controller when all the required steps have been
completed.
DriveBus communication may be halted during download. Refer to the Control
Builder M on-line help for further details.
Redundancy
Redundancy is not supported.
3BSE035982R4001 107
Limitations Section 10 DriveBus
Limitations
When a modified hardware configuration is downloaded to the controller,
communication with hardware units may be interrupted:
• If modified CI858 parameters are downloaded to the controller, DriveBus
communication is interrupted, and the affected CI858 will reboot.
• If modified drive parameters are downloaded to the controller, communication
with the drive is interrupted, and a drive fault message, indicating
communication loss, might be activated. If BusManager is not selected to
monitor the connection, the fault can be avoided by adjusting the time delay of
the drive communication loss supervision.
• If modified I/O parameters are downloaded to the controller, communication
with the I/O unit is interrupted.
• If a drive or an I/O unit is added to or deleted from the hardware tree, and the
changes are downloaded to the controller, the affected CI858 will reboot.
• If the hardware tree positions of different types of drives or I/O's are changed,
and the changes are downloaded to the controller, the affected CI858 will
reboot. Switching the position of two similar units will not result in a reboot of
the affected CI858.
• Changing the connected channels of a drive or an I/O causes recalculation of
the connections.
• The CI858 communication unit cannot be used in an AC 800M High Integrity
controller.
Performance
For each drive connected to the CI858 communication interface unit, 8 dataset pairs
can be defined. The number of datasets per drive can be extended using special
applications.
DriveBus is able to transfer a maximum of 8 dataset pairs/ms.
108 3BSE035982R4001
Section 10 DriveBus Hardware
Hardware
The maximum number of CI858 units connected to the AC 800M is two.The unit
has three channels:
Drive channel can be used for controlling up to 24 drives. The following drives are
supported.
• ACS 800 / ACS 600 SingleDrive,
• ACS 800 / ACS 600 MultiDrive,
• ACS 800 / ACS 600 IGBT supply units,
• ACS 600 thyristor supply units,
• ACS 140 … ACS 400,
• DCS 600 and DCS 400,
• ACS 6000 product family / large drives,
• ACS 1000 product family,
• future drive types which are provided with DDCS interface,
• special drive applications which require more than eight dataset pairs (the
number of datasets is user-defined).
Special I/O channel can be used to connect up to 12 I/O per unit. The following
drives are supported.
• NAIO-03 Analogue I/O Extension,
• NBIO-21 Basic I/O Unit 2,
• NBIO-31 Basic I/O Unit 3,
• NCTI-01 Crane Transducer Interface,
• NDIO-02 Digital I/O Extension,
• NPCT-01 Pulse Counter and Timer,
• NTAC-02 Pulse Encoder Interface,
3BSE035982R4001 109
Advanced Section 10 DriveBus
• NWIO-01 Watchdog I/O,

• Special I/O applications, with user-defined number of datasets.
Special I/O is a separate product, supported by ABB Drives, Helsinki, Finland.
How to configure and use Special I/O is described in the Special I/O
documentation. This documentation, together with the Special I/O library and
Special I/O Hwd file, is delivered with the Special I/O product.
Special I/O is not part of the Control and I/O functionality in 800xA system
version 4.0, released and owned by ABB Automation Technology Products AB.
The PC Tool channel can be used for downloading firmware to CI858 units. CI858
firmware is downloaded with a special loading package, which does not involve
Control Builder M. For instructions on how to download CI858 firmware, see the
ControlIT for AC 800M CD-ROMs.
CI858 connects to its units via three optical receiver/transmitter pairs. HP/Agilent
Technologies Versatile Link Series (HFBR family) optical transmitter/receivers are
used. The transmission speed of the fibre optic cables is 4 Mbit/s.
Advanced
For more information regarding DriveBus communication, see CI858 and DriveBus
communication.
110 3BSE035982R4001
Section 11 PROFIBUS DP
Introduction
PROFIBUS (PROcess FIeld BUS) is a fieldbus standard, especially designed for
communication between systems and process objects. This protocol is open and
vendor-independent. With PROFIBUS, devices from different manufacturers can
communicate without special interface adjustments. PROFIBUS can be used for
both high-speed, time-critical transmission and extensive, complex communication
tasks.
The CI854 communication interface unit supports both PROFIBUS DP-V0 and
PROFIBUS DP-V1. The CI851 communication interface unit is only included in
this manual for legacy reasons.
Supported media:
• RS-485 transmission for universal applications in manufacturing automation
• IEC 61158-2 transmission for use in process automation
• Optical fibers for improved interference immunity and large network distances
The PROFIBUS DP (Decentralized Peripheral) fieldbus is based on European
standard EN 50 170, and has been designed especially for communication between
automation control systems and distributed peripherals at the device level.
3BSE035982R4001 111
Services Provided Section 11 PROFIBUS DP
PROFIBUS DP-V0
The PROFIBUS DP communication profile is designed for efficient data exchange
at the field level. The central automation devices, such as controllers, communicate
through a fast serial connection with distributed field devices such as I/Os, drives,
valves and measuring transducers. Data exchange with distributed devices is mainly
cyclic. The communication functions required are defined by the basic
PROFIBUS DP functions in accordance with EN 50170.
PROFIBUS DP-V1
PROFIBUS DP-V1 is suitable as a replacement for conventional, parallel-signal
transmission with 24V in manufacturing automation, as well as for analog signal
transmission with 4-20mA or HART in process automation.
The PROFIBUS- DP-V1 communication profile is designed for efficient data
exchange at the field level. The central automation devices, such as controllers,
communicate through a fast serial connection with distributed field devices such as
I/Os, drives, valves and measuring transducers.
Services Provided
• PROFIBUS DP-V0 and PROFIBUS DP-V1 are supported.
• For PROFIBUS DP-V0, only cyclic services are supported. The master unit is
of Class 1.
• For PROFIBUS DP-V1, acyclic services are supported. The master unit is of
Class 2.
Advantages
PROFIBUS DP-V0
• High information transfer rate,
• Supports many different types of I/O units.
112 3BSE035982R4001
Section 11 PROFIBUS DP Design
PROFIBUS DP-V1
• High information transfer rate,
• Supports many different types of I/O units,
• Acyclic services (Tool Routing),
• Master redundancy,
• PROFIBUS Diagnostics,
• Line redundancy,
• Slave redundancy.
Design
Introduction
PROFIBUS DP-V0
A PROFIBUS DP-V0 device has specific definition parameters required for device
configuration. Examples of such parameters are device version, baud rate, data
format and I/O length. For ABB devices - such as the S800 I/O, S900 I/O, and S200
I/O unit families - these parameters are already defined and delivered in the Control
Builder M hardware definition file.
Automatic calculation of PROFIBUS master parameters is performed for all
controllers in a project and for all PROFIBUS masters connected to the respective
controllers. For further information see Troubleshooting on page 118.
For a device from another manufacturer the configuration parameters are stored in a
.GSD file delivered with the device. The ControlIT for AC 800M software includes
GSD Import Tool (included on the ControlIT for AC 800M CD-ROMs), which
translates the information contained in the .GSD file. The .GSD file format is given
in European standard EN 50170.
3BSE035982R4001 113
Design Examples Section 11 PROFIBUS DP
The user connects all inputs and outputs to variables. The PROFIBUS-DP
communication is automatically created when the application is downloaded to the
controller. PROFIBUS-DP is primarily used for cyclic I/O communication. When
communication is defined, the master will begin to cyclically ask the slaves for data
and send data.
The two outermost nodes must be terminated.
PROFIBUS DP-V1
A PROFIBUS DP-V1 device has specific definition parameters, required for device
configuration. Examples of such parameters are device version, baud rate, data
format and I/O length. For ABB devices - such as the S800 I/O, and S900 I/O unit
families - these parameters are already defined and delivered in the Control Builder
hardware definition file.
Automatic calculation of PROFIBUS master parameters is performed for all
controllers in a project and for all PROFIBUS masters connected to the respective
controllers. For further information see Troubleshooting on page 118.
For a device from another manufacturer the configuration parameters are stored in a
.GSD file delivered with the device. The ControlIT for AC 800M software includes
GSD Import Tool (included on the Control IT for AC 800M CD-ROMs) which
translates the information contained in the .GSD file. The .GSD file format is given
in European standard EN 50170.
The two outermost nodes must be terminated.
Design Examples
PROFIBUS DP-V0
A PROFIBUS DP-V0 network typically consists of one or more masters and many
slave devices, see Figure 29.
Before PROFIBUS communication can be started, certain parameters must be set
for the master in the Control Builder. Refer to the on-line help for further details.
114 3BSE035982R4001
Section 11 PROFIBUS DP Redundancy
Controller
CI830 + S800 I/O
CI920 + S900 I/O
200-APB12 + S200 I/O
PROFIBUS
slave
Figure 29. PROFIBUS DP-V0 network with I/O units.
PROFIBUS DP-V1
A PROFIBUS DP-V1 network typically consists of one or more masters and many
slave devices, see Figure 30.
Redundancy
PROFIBUS DP-V0
(cable) level by the user.
PROFIBUS DP-V1
Both line redundancy and slave redundancy are built in. Using two CI854A
communication interface units adds master redundancy.
3BSE035982R4001 115
Limitations Section 11 PROFIBUS DP
CI854
CI830 + S800 I/O
CI840 + S800 I/O
CI920 + S900 I/O
PROFIBUS
slave
Figure 30. PROFIBUS DP-V1 network with I/O units.
Limitations
• PROFIBUS DP-V0 can only act as Class 1 master.
• PROFIBUS DP-V1 can only act as master.
• The network can have a maximum of 126 nodes.
• CI854, connected to CI840 and/or CI920, supports cable redundancy without
using fiber optic modems.
• If a PROFIBUS master unit, CI851 or CI854, loses contact with a slave unit,
for example due to a disconnected cable, input values are set according to ISP
configuration. If the I/O unit does not support ISP, all input values will freeze.
• If the PROFIBUS DP-V0 is reconfigured, for example when an I/O unit is
added or removed or if certain parameters are changed, then the PROFIBUS
DP-V0 master, CI851, will automatically reset, affecting the whole network.
116 3BSE035982R4001
Section 11 PROFIBUS DP Performance
• Reset of PROFIBUS DP-V1 master, CI854, and the complete PROFIBUS is

done, if one of the following bus parameter settings are changed: Node address
of CI854, Baudrate or Highest station address (HSA). A change of the other
bus parameters does not affect the running communication.
• When using CI851, data might be lost if the slave configuration is changed.
CI854 supports S800 online changes, that is, modules can be added/changed
without data being sent to ISP or OSP.
Performance
Cyclic communication can be as fast as 1ms and is typically less than 2ms. The
minimum cycle time, however, is configuration-dependent (for example on baud
rate, number of slaves and the amount of data to be sent).
PROFIBUS-DP messages connect to devices with addresses from 0-125. They can
be used to transfer up to 244 bytes of data per in-message and 244 bytes of data per
out-message.
Hardware
A shielded twisted pair cable with terminating resistors, or a fiber optic cable with
optical link units is required.
The physical medium for PROFIBUS-DP is RS-485, which allows 32 nodes in a
segment and 126 nodes in a network. Cable length may vary from 100-1200m
depending on transmission speed. Cable length can be extended using fiber optic
modems (yielding a more robust network).
Segment couplers can be used to attach PROFIBUS-PA devices.
For a product guide presenting all available hardware, visit the PROFIBUS web site:
http://www.profibus.com
The CI854 and CI854A communication interface units support both PROFIBUS
DP-V0 and PROFIBUS DP-V1. The CI851 communication interface unit is only
included in this manual for legacy reasons.
3BSE035982R4001 117
Advanced Section 11 PROFIBUS DP
A separate master unit is used for each controller according to the following table:
Table 10. Hardware for PROFIBUS-DP.
Controller PROFIBUS DP-V0 PROFIBUS DP-V1

AC 800M CI851, CI854 CI854, CI854A(1)
(1) CI854A offers master redundancy
Advanced
Layers
PROFIBUS is located both at the cell supervisor level, named Layer 7 (application
layer) and at the field network level Layer 1 (physical layer) and Layer 2 (data link
layer).
Optical Link
For electrical media (half-duplex), an error in a single wire of the two-wire cable
blocks data transfer in both directions. To get the same functional behavior in case
of a disturbed optical medium, the fibre optical converter (full duplex) must be able
to switch off the receiver port when detecting an error at the transmitting port, and
vice versa. Otherwise it may happen that the PROFIBUS slave will not detect an
error and activate the OSP mode.
Troubleshooting
Automatic Calculation of PROFIBUS-DP Parameters
During compilation and simulation, PROFIBUS master parameters will be
automatically calculated.
The calculation is performed for all controllers in the project and for all PROFIBUS
masters connected to the controllers. The result is sent to a text file named
'Profibus_DP_Calculation.txt' or ‘Profibus_DPV1_Calculation.txt’, which is stored
118 3BSE035982R4001
Section 11 PROFIBUS DP CI854 Web Interface
in the same place as the Control Builder log files. The text file has no backup, and is
replaced at every compilation and simulation.
The parameters are calculated according to the formulas in the PROFIBUS-DP
specification, and should be regarded as suggestions. The calculations are based on
the actual hardware configuration and settings supplied by the user, such as baud
rate and quiet time. For every printout, the complete set of parameters is presented,
including those given by the user. To use the automatically-calculated parameters
for PROFIBUS masters, read the text file and manually edit the parameters in the
HW editor.
Due to limitations in error handling by the Control Builder, the first controller with
master parameters that cannot be compiled will stop the calculation for any
remaining controller in the project.
CI854 Web Interface

CI854 communication interface units can be configured via a web interface. For
information on configuration via this interface, see PROFIBUS documentation.
3BSE035982R4001 119
CI854 Web Interface Section 11 PROFIBUS DP
120 3BSE035982R4001
Section 12 Modem Communication
Introduction
There are two types of modem:
• Short distance modems for point-to-point private links (copper or fiber optic
cable) and which can be used with twisted pair Ethernet, PPP, COMLI,
Siemens 3964R, ModBus RTU or PROFIBUS-DP.
• Dial-up modems that use the public telephone system. COMLI is the only
protocol that supports dial-up modems.
Short Distance Modem

There are two main reasons for using short distance modems:
• Permitted increase of the allowed maximum length of RS-232C, RS-485 and
twisted pair Ethernet connections.
• Elimination of the risk of electromagnetic interference and unauthorized
intrusion by use of fiber optic modems.
There are a large number of modems on the market with different types of
connectors that can convert within a range of networks. Recommended types are
Westermo, and for fiber optic modems Hirschmann.
Fiber optic modems are available that support cable redundancy.
Communication via twisted pair Ethernet must be half duplex. In Hirschmann
modems this must be selected by setting a hardware switch.
3BSE035982R4001 121
Dial-Up Modem Section 12 Modem Communication
Dial-Up Modem
In this section, the term “modem” refers to modems that are configured and
controlled by a controller. It does not refer to modems that are transparent to the
controller.
The COMLI master function can use a dial-up modem (Hayes modem).
Recommended types are Westermo, for industrial applications, and US Robotics for
office environments.
Two types of function block are associated with the COMLI modem function:
• ModemDialUp
Initiates a Hayes dial-up operation
• ModemHangUp
Initiates a Hayes hang-up operation
• ModemConnStat
Initiates a Hayes connection operation
Connection diagrams for modem cables are provided in the hardware and operation
guides of the different controllers.
The procedures initiate a Hayes modem operation. These procedures are
asynchronous; i.e. only one dial or hang-up operation is permitted at a time.
The DTR signal (data terminal ready) from the controller must be high, or the
modem disconnects the communication. The DCD signal (data carrier detect) from
the modem is high when the carrier wave is present. The RTS and CTS signals are
used for hardware flow control. The RTS signal (request to send) is high when the
controller has data to send, and the CTS signal (clear to send) is high when the
modem is ready to receive data.
The modem must be set for echo off, verbal result codes, and auto answer.
The Hayes init command in the parameter list has the default value ATE0V1S0=1,
which means no echoing, verbal result codes, and auto answer. If the modem's
default factory settings do not imply normal use of DTR and DCD, add the
commands &D2 and &C1 to the init string. To use 9600 baud, add the command F8
for the Westermo modem and &N6 for US Robotics. For other modem
manufacturers, refer to the relevant manual.
122 3BSE035982R4001
Section 12 Modem Communication Limitations
The init command is sent only to the modem connected to the dialing controller.
To apply the same settings to the modem at the other end, at least one dial-up
must also be performed from that controller. Also note that US Robotics modems
use only one type of parity and that you must adapt the communication settings
accordingly.
As an alternative to using function blocks, the Automatic Connect parameter can be

set to imply automatic connection to the default phone number when data is sent
through the serial port.
Limitations
• Communication with short distance modems via twisted pair Ethernet must be
half duplex.
• COMLI is the only protocol that supports dial-up modems.
• PPP via modem must use RS-232.
Performance
Refer to manufacturer documentation
Troubleshooting
Refer to manufacturer documentation
3BSE035982R4001 123
Troubleshooting Section 12 Modem Communication
124 3BSE035982R4001
This appendix lists the available MMS services and describes the reduced OSI-
profile used.
Table 11. MMS services supported in version 4.0

of Control Software for AC 800M
Environment and general management

Initiate Yes
Conclude Yes
Abort No
VMD management
GetNameList Yes
GetCapabilityList Yes
Domain management
InitiateDownloadSequence Yes
DeleteDomain Yes
3BSE035982R4001 125
Table 11. MMS services supported in version 4.0

of Control Software for AC 800M
Variable access
Read Yes
Write Yes
InformationReport No
GetVariableAccessAttributes No
DefineNamedVariable No
DeleteNamedVariable No
GetNamedVariableListAttributes No
DefineNamedVariableList No
DeleteNamedVariableList No
ServiceError Yes
Journals
InitializeJournal No
ReadJournal No
File management
FileOpen Yes
FileRead Yes
FileDelete Yes
FileClose Yes
FileDirectory No
126 3BSE035982R4001
Table 12. Reduced OSI implementation
OSI model
Specification Comments
layer
Application ISO/IEC 9506: Manufacturing At application level only
Message Specification (MMS) ISO/IEC 9506 is supported;
ISO 8650: Protocol Specification for i.e. ISO 8650 is not
the Association Control Service implemented
Element
Presentation ISO/IEC 8823: Connection Oriented Not implemented, i.e. NULL
Presentation Protocol Specification. layer
Session ISO/IEC 8327: Basic Connection Not implemented, i.e. NULL
Oriented Session Protocol layer
Specification.
Transport IETF RFC1006 (OSI over TCP) Fully implemented
IETF RFC 793 (TCP) Fully implemented
Network RFC 791(IPv4) Fully implemented
RNRP(1)
Data link ISO/IEC 8802: Logical Link Control Ethernet(3)
ISO/IEC 8802-3: Carrier Sense
Multiple Access with Collision
Detection.
CNCP(2)
Physical ISO/IEC 8802-3: Carrier Sense
Multiple Access with Collision
Detection.
(1) In addition to MMS, the ABB Redundant Network Routing Protocol operates as network layer.
(2) ABB time synchronization.
(3) PPP can also be used as data link with RS-232 as physical layer.
The services are connection-oriented. Connection-less or multicast services for

MMS are not supported.
3BSE035982R4001 127
128 3BSE035982R4001
Appendix B Configuration of HART Devices
Introduction
HART (Highway Addressable Remote Transducer) is an open system
communication protocol that makes possible remote configuration and supervision
of I/O devices with HART support. Scaling and calibration of I/O values is an
implementation of Tool Routing and can be performed from workstations running
OperateIT via the AC 800M controller and ModuleBus or PROFIBUSDP/V1. ABB
provides units with HART support in the S800 I/O and S900 I/O families, though
units from other vendors may also be used.
Tool routing functions are supplied on the ControlIT for AC 800M CD-ROMs
(DVD). Installation procedures are described in the 800xA System Installation
manual.
Table 13. Units with HART support.
Fieldbus
AC 800M communication
communication I/O units
interface
interface
CI854 for PROFIBUS DP-V1 CI840 AI895, AO895
CI920 AI930, AO930
AC 800M CPU Modulebus AI895, AO895
3BSE035982R4001 129
Configuration Example Appendix B Configuration of HART Devices
Configuration Example
An AC 800M has S800 I/O units locally connected directly via ModuleBus, S900
I/O remotely connected via a CI854 PROFIBUS DP-V1 communication interface
and a CI920 fieldbus communication interface. The workstation must be able to
communicate directly with the controller.
CB
FAS TRS
Control Network
ModuleBus
ModuleBus
CI854
AC 800M
S800 I/O
PROFIBUS
DP-V1
CI920
S900 I/O
CI840
S800 I/O
Figure 31. Configuration example.
130 3BSE035982R4001
Appendix B Configuration of HART Devices Nested Communication
The Fieldbus Aspect System (FAS), the Control Builder (CB) and the Tool Routing
Service (TRS) must run on the same workstation. TRS communicates with the
AC 800M controller via MMS. The only measure necessary is to enable the Tool
Routing parameter belonging to the controller CPU in the project explorer.
DTMs (Device Type Managers) are device-specific software components, supplied
by the field device manufacturer with the device. User interface device parameters,
configuration data, etc., for a device, can be accessed through the DTM. It is the
manufacturer's decision as to which services the DTM is to offer the user. Because
DTMs typically are made by different vendors, data is supplied in XML format.
A device such as AC 800M, which supports gateway functionality, must have one
DTM for each type of protocol: in our example one AC 800M ModuleBus DTM and
one CI854 DTM for PROFIBUS.
Nested Communication
In order to establish nested communication when devices with gateway
functionality are involved, these must have DTMs in the FAS, with a
communication interface for each channel.
Figure 32 demonstrates data transfer from the device DTM to the AC 800M
controller. The slave DTM can be a DTM for CI840 (S800 I/O) or for CI920 (S900
I/O). I/O units AI895, AO895, AI 930 and AO 930 also require DTMs.
3BSE035982R4001 131
Nested Communication Appendix B Configuration of HART Devices
CI854
DTM TRS AC 800M
ModuleBus
DTM
Slave
DTM
Unit
DTM
Unit
DTM
Device
Device
DTM
DTM
Device
Device
DTM
DTM
Figure 32. Nested communication.
132 3BSE035982R4001
PROFIBUS-PA (Process Automation) uses physical media according to

IEC 61158-2. This standard has a much slower transmission speed (31.25kbit/s) in
order to obtain quieter communication. It is used for process automation by means
of function blocks, often in environments where there is a considerable risk of
explosion.
A subset of PROFIBUS-PA (cyclic services) can be controlled from Control
Network if a segment coupler (such as a repeater or DP/PA coupler) is used as a
gateway between PROFIBUS-DP and PROFIBUS-PA.
Controller
CI830 + S800 I/O

PROFIBUS-DP
CI920 + S900 I/O
200-APB12 + S200 I/O
Segment PROFIBUS-PA
coupler
Transmitters
Figure 33. Segment coupler for PROFIBUS-PA.
3BSE035982R4001 133
134 3BSE035982R4001
Appendix D ABB Drives
Introduction
ABB Standard Drives and ABB Engineered Drives can be connected to AC 800M
in the following ways.
• Modulebus optical link (not electrical)
• PROFIBUS DP/V0 via CI851-CI830 (configuration similar to Modulebus,
standard drive only)
• PROFIBUS DP/V0 via NPBA-12 or RPBA-01
• PROFIBUS DP/V1 via CI854-CI830 (configuration similar to Modulebus,
standard drive only)
• PROFIBUS DP/V1 via NPBA-12 or RPBA-01
• DriveBus via CI858 (configuration almost similar to Modulebus)
For more information regarding ABB Standard Drives and ABB Engineered Drives,
see vendor documentation. See also Section 10, DriveBus.
3BSE035982R4001 135
Types of ABB Drives Appendix D ABB Drives
Types of ABB Drives

The ABB Standard Drives and ABB Engineered Drives families comprise the
following types of drives and the applications they are directed to.
ABB Standard Drives

Table 14.
Name Application
ACS400 Standard drive
ACS600 Crane application
ACS600 Pump and fan application
ACS600 Standard application
ACS800 Crane application
ACS800 Pump and fan application
ACS800 Standard application
DCS400 Standard drive
DCS500 Standard drive
ABB Engineered Drives

Table 15.
Name Application
ACS600 IGBT supply (ISU) application
ACS600 System application
ACS600AD Asynchronous drive
ACS600C Cyclo converter drive
ACS600SD Synchronous drive
136 3BSE035982R4001
Appendix D ABB Drives Parameter Group Configuration
Table 15.
Name Application
ACS800 IGBT supply (ISU) application
ACS800 System application
ACS1000 Standard drive
DCS600 System application
Parameter Group Configuration

The ABB drives units are identified in the controller by their respective cluster and
position address on the ModuleBus.
To establish the communication between the ABB drives and AC 800M, at least the
following parameter groups shall be considered to be reconfigured in the ABB drive
systems.
Table 16.
Parameter Group Parameter Name Setting

10.1 Ext1 Strt/Stp Dir COMM. MODULE (CW)
10.2 Ext2 Strt/Stp Dir COMM. MODULE (CW)
10.3 Direction Request
11.2 Ext1/Ext2 Select COMM. MODULE (CW)
11.3 EXT REF1 Select COMM. REF or FAST
COMM
11.6 EXT REF2 Select COMM. REF or FAST
COMM
16.1 RUN Enable Yes or COMM. MODULE
(CW)
16.4 Fault Reset Select COMM. MODULE (CW)
3BSE035982R4001 137
Parameter Group Configuration Appendix D ABB Drives
Table 16.

30.18 COMM FLT Function Fault
70.1 Channel 0 Addr See Drives Addressing in
the online help for Control
Builder M
98.2 COMM. MODULE Link Advant
Example
The following parameter groups define the type of data you receive from the drive.
This is only an example and you may find other configuration that suits your
purpose.
Table 17.

92.2 Main DS ACT1 102 (Speed) Max value
20000
92.3 Main DS ACT2 105 (Torque) Max value
10000
92.4 AUX DS ACT 3 305 (Fault word 1)
92.5 AUX DS ACT 4 308 (Alarm word 1)
92.6 AUX DS ACT 5 306 (Fault word 2)
138 3BSE035982R4001
INDEX
A class C
ABB Drives 135 IP address 37
configure communication 137 Client Server Network
DriveBus 135 FF HSE 96
PROFIBUS DP 135 client/server 37
ABB Engineered Drives 136 client/server method
ABB Standard Drives 136 FF HSE 98
AC 800M clock synchronization 25
limitations 30 CNCP 25
access modes 24 COMLI
adapters function blocks 62
CI840 116 hardware 62
CI920 116 link to control system 63
address space 37 message format 64
addressing multipoint communication 62
explicit 35 over SattBus 53
implicit 35 protocol 57
alarms RS-232C 62
INSUM 71 RS-485 62
SattBus messages 53
C communication
cable length multi-drop 57
Siemens 3964R 82 point-to-point 57
cables communication interfaces
SattBus 55 CI840 116
channel CI851 116, 118
drives 109 CI854 116, 118
PC Tool 110 CI855 47
Special I/O 109 CI857 67
CI854 CI858 103
web interface 119 CI860 92
CI858 CI920 116
firmware upgrade 110
3BSE035982R4001 139
Index
communication profile DriveBus

FF H1 91 ABB Drives 135
FF HSE 91 design 104
configure design example 105
ABB Drive communication 137 protocol 103
CI854 119 services 103
Control Builder 33
Control Network 21, 31, 37 E
troubleshooting 45 editor
controllers parameters 33
supported 23 EN 50 170 112
end block 65
D Ethernet 31, 33
default gateway 43 IEEE 803.2 standard 43
default process number 45 explicit addressing 35
design
DriveBus 104 F
FF HSE 93 FF H1
INSUM 69 communication profile 91
MB 300 48 FF HSE
MMS 33 Client Server Network 96
ModBus RTU 86 client/server method 98
PROFIBUS DP 113 communication profile 91
SattBus 54 connection methods 97
Siemens 3964R 80 design 93
design examples design example 93
DriveBus 105 H1 Links 97
FF HSE 93 hardware 101
INSUM 70 limitations 100
MB 300 48 performance 100
ModBus RTU 87 protocol 91
PROFIBUS DP 114 publisher/subscriber method 97
Siemens 3964R 81 redundancy 99
direct addressing services 92
SattBus 54 troubleshooting 102
document conventions 15 Fieldbus Builder FF 92
files
GSD 113
hardware definition 114
140 3BSE035982R4001
Index
firmware INSUM
CI858 110 alarms 71
FOUNDATION Fieldbus HSE CI857 67
protocol 91 design 69
function blocks design example 70
COMLI 62 function blocks 68
INSUM 68 protocol 67
MB 300 48 to 49 services 68
modem 122 integers
SattBus 54 Siemens 3964R 82
intended user 30
G IP address 33
GSD file 113 class C 37
remote 37
H IP subnet mask 33
hardware ISO 9506 31
FF HSE 101
ModBus RTU 89 L
PROFIBUS DP 117 libraries
Siemens 3964R 82 Serial Communication Library 28
HART 112 limitations
Hayes modem 122 AC 800M 30
Hirschmann modem 121 FF HSE 100
HSE Subnet 96 MB 300 51
hubs 43 ModBus RTU 88
modem 123
I PROFIBUS DP 116
IEC 1158-2 SattBus 54
PROFIBUS DP 111 Siemens 3964R 81
IEC 61131-5 86 link
IEC 61158-2 133 control system to COMLI 63
IEEE 803.2 standard 43
implicit addressing 35, 37 M
information block 65 master
ModBus RTU 86
PROFIBUS DP 116
MasterBus 300 47
maximum message size 24
3BSE035982R4001 141
Index
MB 300 modem
design 48 dial-up 122
design example 48 function blocks 122
function blocks 48 to 49 Hayes 122
limitations 51 limitations 123
performance 51 performance 123
protocol 47 troubleshooting 123
redundancy 51 US Robotics modem 122
services 47 Westermo 122
MB 300 TS 25 multi-drop 57
message format ModBus RTU 88
COMLI 64
MMS 31 N
design 33 named SattBus 54
troubleshooting 45 network area 21, 34
MMS Server 32
MMS Time Service 25 O
ModBus RTU OPC Server 32
design 86 OPC Server FF 92
design example 87 optical link
hardware 89 PROFIBUS DP 118
limitations 88
master 86
P
multi-drop 88
parameters
performance 88
editor 33
point-to-point 87
parity 123
protocol 85
PC Tool 110
redundancy 88
performance
RS-232C 88
FF HSE 100
RS-485 88
MB 300 51
services 86
ModBus RTU 88
slave 86
modem 123
troubleshooting 89
PROFIBUS DP 117
SattBus 54
Siemens 3964R 82
plant intranet 37
point-to-point 57
ModBus RTU 87
PPP 36
142 3BSE035982R4001
Index
process number R
default 45 redundancy
PROFIBUS DP 112 FF HSE 99
ABB Drives 135 MB 300 51
calculation of master parameters 113 ModBus RTU 88
design 113 PROFIBUS DP 115
design example 114 SattBus 54
hardware 117 Siemens 3964R 81
IEC 1158-2 111 remote IP address 37
limitations 116 RNRP 33, 38
master 116 RNRP monitor 45
optical link 118 router 34
performance 117 routers 43
protocol 111 RS-232C 31, 36
protocol layers 118 COMLI 62
redundancy 115 ModBus RTU 88
RS-485 111, 117 Siemens 3964R 79
services 112 RS-485
slave 116 COMLI 62
Project Explorer 22, 33 ModBus RTU 88
protocol layers PROFIBUS DP 111, 117
PROFIBUS DP 118 Siemens 3964R 79
protocols
COMLI 57 S
DriveBus 103 SattBus
FF HSE 91 cables 55
FOUNDATION Fieldbus HSE 91 design 54
INSUM 67 direct addressing 54
MB 300 47 function blocks 54
ModBus RTU 85 limitations 54
PPP 36 named 54
PROFIBUS DP 111 performance 54
SattBus 53 protocol 53
serial 28 redundancy 54
Siemens 3964R 79 services 53
supported 23 SattCon 57
publisher/subscriber method serial protocol 28
FF HSE 97 server 37
3BSE035982R4001 143
Index
services T
DriveBus 103 TCP/IP 32
FF HSE 92 terminology list 16
INSUM 68 time synchronization 25
ModBus RTU 86 TimeSync Master 25
PROFIBUS DP 112 transceiver 43
SattBus 53 troubleshooting
Siemens 3964R 79 Control Network 45
Setup Wizard 33 FF HSE 102
shielded cable 61 MMS 45
Siemens 3964R ModBus RTU 89
cable lengths 82 modem 123
design 80 twisted-pair cable
design example 81 shielded 61, 117
hardware 82
integers 82 U
limitations 81 UDP 55
performance 82 US Robotics 122
protocol 79 User Datagram Protocol 55
redundancy 81
RS-232C 79
V
RS-485 79
variable types 24
services 79
SIMATIC 82
slave W
ModBus RTU 86 web interfaces
PROFIBUS DP 116 CI854 119
SNTP 25 Westermo modem 121 to 122
Special I/O 109
start block 65
subnetwork 34
supported
controllers 23
protocols 23
switches 43
144 3BSE035982R4001
3BSE035982R4001. Printed in Sweden October 2004
Copyright © 1999 - 2004 by ABB. All Rights Reserved
® Registered Trademark of ABB.
™ Trademark of ABB.
http://www.abb.com/control
Automation Technology Products Automation Technology Products Automation Technology Products

Västerås, Sweden Wickliffe, Ohio, USA Mannheim, Germany
www.abb.com/processautomation www.abb.com/processautomation www.abb.de/processautomation
email: processautomation@se.abb.com email: industrialitsolutions@us.abb.com email: marketing.control-products@de.abb.com

3BSE035982R4001 CIO ComMan

Uploaded by

Document Information

Original Description:

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

3BSE035982R4001 CIO ComMan

Uploaded by

Copyright:

Available Formats

IndustrialIT

800xA - Control and I/O

Copyright © 1999 - 2004 by ABB.

Release: October 2004

Windows Registered trademark of Microsoft Corporation.

Industrial IT Trademark of ABB.

INSUM Trademark of ABB.

FOUNDATION Fieldbus Trademark of Fieldbus Foundation.

PROFIBUS Registered trademark of PROFIBUS International.

ModBus Registered trademark of Modicon Inc.

Simatic Registered trademark of Siemens AG.

About This Book

Section 3 MasterBus 300

Section 4 SattBus on TCP/IP

Creating an Application that Handles INSUM Alarms................................................... 72

Section 7 Siemens 3964R

Section 8 ModBus RTU

Section 9 FOUNDATION Fieldbus HSE

Performance .................................................................................................................. 108

Section 12 Modem Communication

Appendix A OSI Profile for MMS

Appendix B Configuration of HART Devices

Appendix D ABB Drives

Use of Warning, Caution, Information, and Tip Icons

Caution icon indicates important information or warning related to the concept

Information icon alerts the reader to pertinent facts and conditions.

Table 1– Table 3 give concise information to be used when selecting protocols.

Figure 1. Project Explorer.

Protocols and Controllers Supported by Control Builder

Table 1. Protocols and Controllers supported by Control Builder.

Properties of Different Protocols

bytes per message

Figure 2. Clock Synchronization

Intermediate Clock Master

Clock Synchronization in Controllers

Self-defined Serial Protocol

Methods of Access to Legacy Controllers

Prerequisites and Requirements

Figure 3. The MMS protocol defines communication messages transferred between

1. See also Appendix A, OSI Profile for MMS.

Figure 4. Ethernet parameter list in Control Builder

Network area 2 Network area 3

Figure 6. AC 800M used as a router between two network areas.

Explicit and Implicit Addressing

Figure 7. Parameter list when the implicit addressing method is used.

In order to obtain supervision of the Network connection, and the PPP

MMS on RS-232C (PPP)

Figure 8. MMS on RS-232C.

How to configure a PPP connection is described in detail in Control Builder

Separation of Plant Intranet, Client/Server and Control Network

CPU redundancy in a configuration with redundant networks requires that

Figure 9. Example of redundant CPU configuration.

Table 4. Space requirements of different variable types.

Figure 10. Routing to external servers.

Figure 11. Parameter list specifying default gateway.

Default Process Number

Table 5. Default process number.

Product Default process number

Other controllers on MasterBus 300 AC 800M

MasterBus 300 Control Network

Figure 12. AC 800M connected to MasterBus 300 and Control Network.

MasterBus 300 network may be either redundant or singular.