protocols and design - aotewell
TRANSCRIPT
IndustrialIT800xA - Control and I/O
System Version 4.1
CommunicationProtocols and Design
IndustrialIT800xA - Control and I/O
System Version 4.1
CommunicationProtocols and Design
NOTICEThe information in this document is subject to change without notice and should not beconstrued as a commitment by ABB. ABB assumes no responsibility for any errors thatmay appear in this document.
In no event shall ABB be liable for direct, indirect, special, incidental or consequentialdamages of any nature or kind arising from the use of this document, nor shall ABB beliable 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 usedfor any unauthorized purpose.
The software or hardware described in this document is furnished under a license andmay 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 LowVoltage Directive 72/23/EEC.
Copyright © 1999 - 2004 by ABB. All rights reserved. Release: May 2005Document number: 3BSE035982R4101 -d1
TRADEMARKSRegistrations 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 BookGeneral ............................................................................................................................13
Use of Warning, Caution, Information, and Tip Icons ....................................................14
Document Conventions ...................................................................................................15
Terminology.....................................................................................................................16
Section 1 IntroductionProduct 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 MMSIntroduction .....................................................................................................................31
Services Provided.................................................................................................32
MMS Server .........................................................................................................32
3BSE035982R4101 -d1 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 300Introduction ..................................................................................................................... 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
Troubleshooting............................................................................................................... 52
6 3BSE035982R4101 -d1
Table of Contents
Section 4 SattBus on TCP/IPIntroduction .....................................................................................................................53
Services Provided.................................................................................................53
Design..............................................................................................................................54
Introduction ..........................................................................................................54
Redundancy .....................................................................................................................54
Limitations.......................................................................................................................54
Performance.....................................................................................................................54
Advanced .........................................................................................................................55
Section 5 COMLIIntroduction .....................................................................................................................57
Services Provided.................................................................................................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 INSUMIntroduction .....................................................................................................................67
Services Provided.................................................................................................68
Design..............................................................................................................................69
Introduction ..........................................................................................................69
Design Example ...................................................................................................70
INSUM Alarms ...............................................................................................................71
3BSE035982R4101 -d1 73BSE035982R4101 -d1 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
Troubleshooting............................................................................................................... 78
Section 7 Siemens 3964RIntroduction ..................................................................................................................... 79
Services Provided................................................................................................. 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 RTUIntroduction ..................................................................................................................... 85
Services Provided................................................................................................. 86
Design ............................................................................................................................. 86
Introduction.......................................................................................................... 86
Design Examples ................................................................................................. 87
Redundancy..................................................................................................................... 88
Limitations ...................................................................................................................... 88
Performance .................................................................................................................... 88
8 3BSE035982R4101 -d1
Table of Contents
Hardware .........................................................................................................................89
Advanced .........................................................................................................................89
Troubleshooting...............................................................................................................89
Section 9 FOUNDATION Fieldbus HSEIntroduction .....................................................................................................................91
Advantages ...........................................................................................................91
Services Provided.................................................................................................92
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 DriveBusIntroduction ...................................................................................................................103
Services Provided...............................................................................................103
Advantages ....................................................................................................................104
Design............................................................................................................................104
Design Example .................................................................................................105
Redundancy ...................................................................................................................107
Limitations.....................................................................................................................108
3BSE035982R4101 -d1 93BSE035982R4101 -d1 9
Table of Contents
Performance .................................................................................................................. 108
Hardware ....................................................................................................................... 109
Advanced....................................................................................................................... 110
Section 11 PROFIBUS DPIntroduction ................................................................................................................... 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 CommunicationIntroduction ................................................................................................................... 121
Short Distance Modem.................................................................................................. 121
Dial-Up Modem ............................................................................................................ 122
Limitations .................................................................................................................... 123
Performance .................................................................................................................. 123
Troubleshooting............................................................................................................. 123
10 3BSE035982R4101 -d1
Table of Contents
Appendix A OSI Profile for MMS
Appendix B Configuration of HART DevicesIntroduction ...................................................................................................................129
Configuration Example..................................................................................................130
Nested Communication .................................................................................................131
Appendix C PROFIBUS-PA
Appendix D ABB DrivesIntroduction ...................................................................................................................135
Types of ABB Drives.....................................................................................................136
ABB Standard Drives ........................................................................................136
ABB Engineered Drives ....................................................................................136
Parameter Group Configuration ....................................................................................137
INDEX
3BSE035982R4101 -d1 113BSE035982R4101 -d1 11
Table of Contents
12 3BSE035982R4101 -d1
About This Book
GeneralThis 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.
3BSE035982R4101 -d1 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 IconsThis 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:
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.
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
14 3BSE035982R4101 -d1
About This Book Document Conventions
Document ConventionsThe 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
3BSE035982R4101 -d1 15
Terminology About This Book
TerminologyThe 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 3BSE035982R4101 -d1
About This Book Terminology
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
Term Description
3BSE035982R4101 -d1 17
Terminology About This Book
MMS Server for AC 800M
The server provides services to the MMS Client. 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
Term Description
18 3BSE035982R4101 -d1
About This Book Terminology
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
Term Description
3BSE035982R4101 -d1 19
Terminology About This Book
20 3BSE035982R4101 -d1
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.
3BSE035982R4101 -d1 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 3BSE035982R4101 -d1
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.
Protocol AC 800MAC 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)
(1) Both master and slave
YES YES
Siemens 3964R(2)
(2) Master only
YES YES
ModBus RTU(3)
(3) Master only
YES YES
FOUNDATION Fieldbus HSE YES NO
PROFIBUS DP-V0 YES YES
PROFIBUS DP-V1 YES YES
DriveBus YES NO
INSUM YES YES
3BSE035982R4101 -d1 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.
ProtocolAccess method
Sep
arat
e C
PU
fo
rco
mm
un
icat
ion
Dia
l-u
p m
od
em
Variable types(1)
(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
Max
. nu
mb
er o
fb
its/
reg
iste
rs o
rby
tes
per
mes
sag
e
Bo
ole
an
Inte
ger
Rea
l
Str
ing
Str
uct
(2)
(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.
MMS on Ethernet Ethernet × × × × × (3)
(3) See Table 4 on page 42.
MMS on RS-232C (PPP) Point-to-point × × × × × (3)
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 Communication Library
Point-to-point × × × × × 140 bytes
24 3BSE035982R4101 -d1
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.
3BSE035982R4101 -d1 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.
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.
Clock Synchronization
Control Network
MB 300 TS
AC 400AC 800MAC 800M
On-time switch
CNCPCNCP*)
Plant Explorer Workplace
CNCP w.medium accuracy
MasterBus 300*) The direction depends on which controller is the master (the left AC 800M or AC 400).
High-precisionSNTP
26 3BSE035982R4101 -d1
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 accuracySlave 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
3BSE035982R4101 -d1 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 3BSE035982R4101 -d1
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.
Protocol MB 300SattBus
on TCP/IP
COMLI(1) Siemens 3964R
ModBus
Self-def. in SerialComm. Library
MMS
SattLine 200 × × x
AC 210 × ×
AC 250 withACB ver. 1
× × ×
AC 250 withCB 2 or later
× × × ×
AC 800C × × × ×
AC 55 ×
AC 70 × ×
AC 110 × × ×
AC 160 × × ×
AC 410 × × × ×
AC 450 × × × ×
SattCon05 ×(2) ×
SattCon15 × ×
SattCon31 × ×
SattCon35 × ×
SattCon60 × ×
SattCon90 × ×
3BSE035982R4101 -d1 29
Prerequisites and Requirements Section 1 Introduction
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 UserThe reader is assumed to have general knowledge of control methods and relevant literature regarding specific protocols and fieldbuses.
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.
Protocol MB 300SattBus
on TCP/IP
COMLI(1) Siemens 3964R
ModBus
Self-def. in SerialComm. Library
MMS
30 3BSE035982R4101 -d1
Section 2 MMS
IntroductionControl 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.
Figure 3. The MMS protocol defines communication messages transferred between controllers as well as between engineering stations and controllers.
Engineering stations
Controllers
3BSE035982R4101 -d1 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 3BSE035982R4101 -d1
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.
The IP address and IP subnet mask are standard IP terms, whereas the remaining parameters are used by the Redundant Network Routing Protocol (RNRP).
Figure 4. Ethernet parameter list in Control Builder
For more information on RNRP setup, see the manual Automation System Network, Design and Configuration.
3BSE035982R4101 -d1 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.
Figure 5. Non-redundant Control Network with three network areas which are connected via AC 800M controllers used as routers.
A path connection between two nodes must not contain more than three routers (a hop count greater than 3 is not permitted).
Network area 1
Network area 2 Network area 3
1 3
5 8
10 11 12 20 21 22
Network area 3
Node numbersRouters
34 3BSE035982R4101 -d1
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.
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:
Figure 6. AC 800M used as a router between two network areas.
Port 2
Port 1
3BSE035982R4101 -d1 35
MMS on RS-232C (PPP) Section 2 MMS
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 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).
Figure 8. MMS on RS-232C.
36 3BSE035982R4101 -d1
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.
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.
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.
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.
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.
3BSE035982R4101 -d1 37
Redundancy Section 2 MMS
RedundancyThe 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.
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
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.
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
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.
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 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.
38 3BSE035982R4101 -d1
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.
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.
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.
Figure 9. Example of redundant CPU configuration.
CEX bus
Redundant network
Dual AC 800M
PM861PM861
RCU link
3BSE035982R4101 -d1 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 3BSE035982R4101 -d1
Section 2 MMS Performance
PerformancePerformance 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.
3BSE035982R4101 -d1 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.
Variable type Size in telegramMaximum number of variables in one telegram
Bool 3 bytes 319
Dint, Int, word, dword 6 bytes 159
Real 7 bytes 136
String 4 bytes header +1 byte/character
190 string [1]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 3BSE035982R4101 -d1
Section 2 MMS Hardware
HardwareAll 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.
3BSE035982R4101 -d1 43
Default Gateway Section 2 MMS
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.
2
1 3 (IP=172.16.4.8)4
6
Network area
InternetServiceProvider
Internet
44 3BSE035982R4101 -d1
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.
TroubleshootingThe 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).
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
3BSE035982R4101 -d1 45
Troubleshooting Section 2 MMS
46 3BSE035982R4101 -d1
Section 3 MasterBus 300
IntroductionMasterBus 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.
3BSE035982R4101 -d1 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 3BSE035982R4101 -d1
Section 3 MasterBus 300 Communication Function Blocks
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.
Figure 12. AC 800M connected to MasterBus 300 and Control Network.
MasterBus 300 network may be either redundant or singular.
MasterBus 300 Control Network
CI855
AC 800MOther controllers on MasterBus 300
3BSE035982R4101 -d1 49
Communication Function Blocks Section 3 MasterBus 300
Figure 13. Exchange of DataSets (DS) via MB 300 by means of function blocks.
Table 6. Mapping of data types
Data types in other controllers on MB 300
Data types in AC 800M
Boolean32 dint
16-bit integer int
32-bit integer dint
real real
CAPosId
Controllers on MB 300
Id
MB300Connect
MB300DSReceive
DataSetId
Rd
NodePos
Id
MB300DSSend
DataSetId
Sd
CIPos
AC 800MCI855 Interface
unit
DSReceive
DSSend
Sd
Rd
50 3BSE035982R4101 -d1
Section 3 MasterBus 300 Redundancy
RedundancyThe 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.
LimitationsMasterBus 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).
PerformanceTransmission 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.
3BSE035982R4101 -d1 51
Advanced Section 3 MasterBus 300
AdvancedTime 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.
TroubleshootingThe 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 3BSE035982R4101 -d1
Section 4 SattBus on TCP/IP
IntroductionSattBus 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.
3BSE035982R4101 -d1 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.
RedundancySattBus does not support redundancy.
LimitationsPhysical SattBus is not supported.
For SattBus on a TCP/IP connection, the valid node number range is 2-127, for example '88'.
PerformanceIf 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 3BSE035982R4101 -d1
Section 4 SattBus on TCP/IP Advanced
AdvancedWhen 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
3BSE035982R4101 -d1 55
Advanced Section 4 SattBus on TCP/IP
56 3BSE035982R4101 -d1
Section 5 COMLI
IntroductionCOMLI (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)
3BSE035982R4101 -d1 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 3BSE035982R4101 -d1
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.
Figure 14. Example of multipoint communication.
RS-232C/485 converter
Slave ID 247
Slave ID 125
Slave ID 1
MasterChannel n
3BSE035982R4101 -d1 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.
RedundancyRedundancy 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).
Figure 15. Example of point-to-point communication.
MasterChannel n
MasterChannel m
Slave ID 1Slave ID 1
60 3BSE035982R4101 -d1
Section 5 COMLI Performance
PerformancePerformance 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.
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.
Table 7. Different interfaces and speeds
Speed (bps)Distance (m)
RS-232C RS-485
2400 150 1200
4800 75 1200
9600 40 1200
19200 20 1200
38400 1200
3BSE035982R4101 -d1 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.
HardwareA 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 3BSE035982R4101 -d1
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.
3BSE035982R4101 -d1 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 3BSE035982R4101 -d1
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.
3BSE035982R4101 -d1 65
COMLI Message Format Section 5 COMLI
66 3BSE035982R4101 -d1
Section 6 INSUM
IntroductionINSUM (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.
3BSE035982R4101 -d1 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 3BSE035982R4101 -d1
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.
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.
Figure 16. Project explorer.
3BSE035982R4101 -d1 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.
Figure 17. INSUM integration with Control Network.
TCP/IP Ethernet
AC 800M controllers
INSUMTCP/IP gateway
Router RouterRouter Router
Subnet 1 Subnet 2 Subnet 3 Subnet 4
MCU 2/01
MCU 2/32
MCU 1/32
MCU 1/01
MCU 3/01
ITS 3/32
CB 4/32
CB 4/01
LonWorks
Control Network
CI857 CI857
MMI
INSUMoperatorstation
70 3BSE035982R4101 -d1
Section 6 INSUM INSUM Alarms
INSUM AlarmsAll 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.
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.
3BSE035982R4101 -d1 71
Creating an Application that Handles INSUM Alarms Section 6 INSUM
Creating an Application that Handles INSUM AlarmsThis 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 3BSE035982R4101 -d1
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.
3BSE035982R4101 -d1 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 3BSE035982R4101 -d1
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.
3BSE035982R4101 -d1 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 3BSE035982R4101 -d1
Section 6 INSUM Limitations
LimitationsINSUM 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
PerformanceBecause 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.
3BSE035982R4101 -d1 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.
TroubleshootingThe 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 3BSE035982R4101 -d1
Section 7 Siemens 3964R
IntroductionSiemens 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.
3BSE035982R4101 -d1 79
Design Section 7 Siemens 3964R
The following services are provided.
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.
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
Figure 18. Siemens 3964R network principle.
PLC1 PLC2 PLCn
Siemens 3964R
Simatic controllers
80 3BSE035982R4101 -d1
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.
RedundancyRedundancy is not built in, but can be implemented on application level or physical (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.
Figure 19. Siemens 3964R, schematic design example.
Siemens system 1
Siemens system 2Serial port 2Serial port 1
AC 800M controller
3BSE035982R4101 -d1 81
Performance Section 7 Siemens 3964R
PerformanceSimilar to COMLI, see Performance on page 61.
HardwareA 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 3BSE035982R4101 -d1
Section 7 Siemens 3964R Communicating Bits
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.
Table 8. I/O-bits, integers and data blocks.
I/O bits in the controller (max 512/message)
I/O bits in Siemens
Integers in the
controller
Data blocks in Siemens
Word for S5
system
Word for S7
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
3BSE035982R4101 -d1 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 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.
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.
Figure 20. Code word for the writing of a bit.
Destination byte address 15-8
Destination bit 2-0Not usedType of data Newvalue
15 12 11 10 9 8
7
1314
2 14 06 5 3
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
84 3BSE035982R4101 -d1
Section 8 ModBus RTU
IntroductionModBus 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.
3BSE035982R4101 -d1 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:
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.
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)
(1) Some slaves do not understand FC8. To avoid problems, set Poll Time to zero (0).
Diagnostic request
FC4 Read input registers FC15 Force multiple coils
FC5 Force single coil FC16 Preset multiple registers
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 3BSE035982R4101 -d1
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
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).
Figure 21. Master/slave in a point-to-point communication configuration.
Figure 22. Point-to-point communication between a controller and several slaves.
Master channel Slave channel
Master channelsSlavechannels
3BSE035982R4101 -d1 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.
RedundancyRedundancy 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.
PerformanceSimilar to COMLI, see Performance on page 61.
Figure 23. Master/slaves in a multidrop communication configuration.
SlavechannelsMaster channel RS-232C/485
converter
88 3BSE035982R4101 -d1
Section 8 ModBus RTU Hardware
HardwareAn 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.
AdvancedMore information and references to literature concerning ModBus can be accessed from http://www.modicon.com.
TroubleshootingThe operator can monitor the status of all hardware units using the Project Explorer in the Control Builder.
3BSE035982R4101 -d1 89
Troubleshooting Section 8 ModBus RTU
90 3BSE035982R4101 -d1
Section 9 FOUNDATION Fieldbus HSE
IntroductionFOUNDATION 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
3BSE035982R4101 -d1 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.
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.
For a description of client/server and publisher/subscriber communication methods, see Connection Methods on page 97.
92 3BSE035982R4101 -d1
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.
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.
FF HSE configuration requires Control Builder M Professional.
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.
3BSE035982R4101 -d1 93
Design Example Section 9 FOUNDATION Fieldbus HSE
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
Fieldbus Builder FF
Operator station network (Client Server Network)
Controller network (Control Network)
Connectivity ServerOPC Server AC 800M
AC 800M AC 800M
CI860 CI860
OPC Server FF OPC Server FF
FF HSE subnet FF HSE subnet
FF HSE FF HSELD 800HSELinking DeviceLD 800HSE
Linking Device
FF H1Links
FF H1 Field Devices FF H1 Field Devices
Linking DeviceLD 800HSE
FF H1 Field Devices
FF H1Links
FF H1Links
Control Builder MPlant Explorer Workplace
Fieldbus Builder FFControl Builder MPlant Explorer WorkplaceAspect Server
Connectivity Server Connectivity Server
94 3BSE035982R4101 -d1
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.
– 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.
Fieldbus Builder FF provides tool routing only if no OPC server FF has been added to the HSE subnet configuration in Fieldbus Builder FF.
3BSE035982R4101 -d1 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.
FOUNDATION Fieldbus HSE Subnets must never be combined with the controller network. FOUNDATION Fieldbus HSE multicasts create too much load on the controller network.
96 3BSE035982R4101 -d1
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.
• 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
Standard routers without multicast routing functionality may not be used.
FOUNDATION Fieldbus HSE Subnets must never be combined with the controller network. FOUNDATION Fieldbus HSE multicasts create too much load on the controller network.
3BSE035982R4101 -d1 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.
Figure 25. Example of a typical usage of the publisher/subscriber method with FOUNDATION Fieldbus analog control modules.
ControlConnection data types FFRealConnection data type(2xRealIO)
FFRealConnection data type(2xRealIO). Only one component used.
AnalogOutCCToFFAnalogInFFToCC *
A PID controller control module
Control modules executing in an AC 800M controllerFunction block
executing in a FOUNDATION Fieldbus device.
Function block executing in a FOUNDATION Fieldbus device.
* can be omitted by using the CI860 channel directly (RealIO) since no backward signal is used
FF AI FBFF PID FB
98 3BSE035982R4101 -d1
Section 9 FOUNDATION Fieldbus HSE Redundancy
Figure 26. Example of a typical usage of the publisher/subscriber method with FOUNDATION Fieldbus digital function blocks.
RedundancyThe 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.
FF DO FB
FFBoolConnection data type(2xBoolIO)
BoollOToFFOut
FFToBoolIOIn *
Motor Block
BoolIO
Function blocks executing in a AC 800M controller
FB
OUT
BoolIO
FF DI FB
Function blocks executing in a FOUNDATION Fieldbus device.
* can be omitted by using the CI860 channel directly (BoolIO) since no backward signal is used.
3BSE035982R4101 -d1 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).
• 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.
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.
100 3BSE035982R4101 -d1
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.
HardwareThe communication interface unit CI860 can only be used in AC 800M controllers.
AdvancedFor more information, please refer to Device Integration FF and FOUNDATION Fieldbus HSE documentation.
3BSE035982R4101 -d1 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 3BSE035982R4101 -d1
Section 10 DriveBus
IntroductionThe 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.
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,
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.
3BSE035982R4101 -d1 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.
DesignDriveBus 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 3BSE035982R4101 -d1
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.
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.
Drive
BranchingUnits
Up to 24 Drives
MSTR
MSTRCH0
CH1 CH2 CH3
• • • • • •
CH0CH0
CH0
• • •
DriveDrive
NDBU
Drive
CH1 CH2 CH3
CH0CH0
CH0
DriveDrive
NDBU
Special I/O
Special I/O
D D C S C I858
Drive Tool
Up
to 1
2 I/O
’s
Drive channelI/O channelPC Tool channel
3BSE035982R4101 -d1 105
Design Example Section 10 DriveBus
Figure 28. Dataset communication.
RMIO
CH0
CH0
DriveBus
DriveBus
DS10out channel 1out channel 2out channel 3
AC 800M/CI858
Dataset tableDS Value
11VAL 1VAL 2VAL 3
Address assignment of datasetsGroup Index92 0192 0292 03
AMC tableIn_variable1
In_variable2In_variable3
Application controller software
DS11in channel 1in channel 2in channel 3
Out_variable1Out_variable2Out_variable3
Dataset tableDS Value
10VAL 1VAL 2VAL 3
Address assignment of datasetsGroup Index90 0190 0290 03
AMC table7.0123.0125.01
106 3BSE035982R4101 -d1
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.
RedundancyRedundancy is not supported.
DriveBus communication may be halted during download. Refer to the Control Builder M on-line help for further details.
3BSE035982R4101 -d1 107
Limitations Section 10 DriveBus
LimitationsWhen 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.
PerformanceFor 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 3BSE035982R4101 -d1
Section 10 DriveBus Hardware
HardwareThe 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,
3BSE035982R4101 -d1 109
Advanced Section 10 DriveBus
• NWIO-01 Watchdog I/O,
• Special I/O applications, with user-defined number of datasets.
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.
AdvancedFor more information regarding DriveBus communication, see CI858 and DriveBus communication.
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.
110 3BSE035982R4101 -d1
Section 11 PROFIBUS DP
IntroductionPROFIBUS (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.
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.
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.
3BSE035982R4101 -d1 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 3BSE035982R4101 -d1
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.
3BSE035982R4101 -d1 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 3BSE035982R4101 -d1
Section 11 PROFIBUS DP Redundancy
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
Redundancy is not built in, but can be implemented on application level or physical (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.
Figure 29. PROFIBUS DP-V0 network with I/O units.
PROFIBUS
slave
CI830 + S800 I/O
CI920 + S900 I/O
200-APB12 + S200 I/O
Controller
3BSE035982R4101 -d1 115
Limitations Section 11 PROFIBUS DP
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.
Figure 30. PROFIBUS DP-V1 network with I/O units.
PROFIBUS
slave
CI830 + S800 I/O
CI854
CI840 + S800 I/O
CI920 + S900 I/O
116 3BSE035982R4101 -d1
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.
PerformanceCyclic 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.
HardwareA 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
CI854 supports S800 online changes, that is, modules can be added/changed without data being sent to ISP or OSP.
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.
3BSE035982R4101 -d1 117
Advanced Section 11 PROFIBUS DP
A separate master unit is used for each controller according to the following table:
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
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
118 3BSE035982R4101 -d1
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 InterfaceCI854 communication interface units can be configured via a web interface. For information on configuration via this interface, see PROFIBUS documentation.
3BSE035982R4101 -d1 119
CI854 Web Interface Section 11 PROFIBUS DP
120 3BSE035982R4101 -d1
Section 12 Modem Communication
IntroductionThere 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 ModemThere 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.
3BSE035982R4101 -d1 121
Dial-Up Modem Section 12 Modem Communication
Dial-Up Modem
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:
• ModemDialUpInitiates a Hayes dial-up operation
• ModemHangUpInitiates a Hayes hang-up operation
• ModemConnStatInitiates 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.
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.
122 3BSE035982R4101 -d1
Section 12 Modem Communication Limitations
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.
PerformanceRefer to manufacturer documentation
TroubleshootingRefer to manufacturer documentation
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.
3BSE035982R4101 -d1 123
Troubleshooting Section 12 Modem Communication
124 3BSE035982R4101 -d1
Appendix A OSI Profile for MMS
This appendix lists the available MMS services and describes the reduced OSI-profile used.
Table 11. MMS services supported in version 4.0of 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
3BSE035982R4101 -d1 125
Appendix A OSI Profile for MMS
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
Table 11. MMS services supported in version 4.0of Control Software for AC 800M
126 3BSE035982R4101 -d1
Appendix A OSI Profile for MMS
Table 12. Reduced OSI implementation
OSI model layer
Specification Comments
Application ISO/IEC 9506: Manufacturing Message Specification (MMS)
ISO 8650: Protocol Specification for the Association Control Service Element
At application level only ISO/IEC 9506 is supported; i.e. ISO 8650 is not implemented
Presentation ISO/IEC 8823: Connection Oriented Presentation Protocol Specification.
Not implemented, i.e. NULL layer
Session ISO/IEC 8327: Basic Connection Oriented Session Protocol Specification.
Not implemented, i.e. NULL layer
Transport IETF RFC1006 (OSI over TCP)
IETF RFC 793 (TCP)
Fully implemented
Fully implemented
Network RFC 791(IPv4)
RNRP(1)
(1) In addition to MMS, the ABB Redundant Network Routing Protocol operates as network layer.
Fully implemented
Data link ISO/IEC 8802: Logical Link Control
ISO/IEC 8802-3: Carrier Sense Multiple Access with Collision Detection.
CNCP(2)
(2) ABB time synchronization.
Ethernet(3)
(3) PPP can also be used as data link with RS-232 as physical layer.
Physical ISO/IEC 8802-3: Carrier Sense Multiple Access with Collision Detection.
The services are connection-oriented. Connection-less or multicast services for MMS are not supported.
3BSE035982R4101 -d1 127
Appendix A OSI Profile for MMS
128 3BSE035982R4101 -d1
Appendix B Configuration of HART Devices
IntroductionHART (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.
AC 800M communication interface
Fieldbus communication
interfaceI/O units
CI854 for PROFIBUS DP-V1 CI840 AI895, AO895
CI920 AI930, AO930
AC 800M CPU Modulebus AI895, AO895
3BSE035982R4101 -d1 129
Configuration Example Appendix B Configuration of HART Devices
Configuration ExampleAn 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.
Figure 31. Configuration example.
ModuleBus
CB
FAS TRS
AC 800M
Control Network
CI854
ModuleBus
CI920
S800 I/O
S900 I/O
PROFIBUS DP-V1
CI840
S800 I/O
130 3BSE035982R4101 -d1
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 CommunicationIn 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.
3BSE035982R4101 -d1 131
Nested Communication Appendix B Configuration of HART Devices
Figure 32. Nested communication.
SlaveDTM
Unit DTM
DeviceDTM
DeviceDTM
ModuleBus DTM
Unit DTM
DeviceDTM
DeviceDTM
CI854 DTM AC 800MTRS
132 3BSE035982R4101 -d1
Appendix C PROFIBUS-PA
PROFIBUS-PA (Process Automation) uses physical media according toIEC 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.
Figure 33. Segment coupler for PROFIBUS-PA.
Segmentcoupler
Transmitters
PROFIBUS-PA
PR
OF
IBU
S-D
P
CI830 + S800 I/O
CI920 + S900 I/O
200-APB12 + S200 I/O
Controller
3BSE035982R4101 -d1 133
Appendix C PROFIBUS-PA
134 3BSE035982R4101 -d1
Appendix D ABB Drives
IntroductionABB 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.
3BSE035982R4101 -d1 135
Types of ABB Drives Appendix D ABB Drives
Types of ABB DrivesThe ABB Standard Drives and ABB Engineered Drives families comprise the following types of drives and the applications they are directed to.
ABB Standard Drives
ABB Engineered 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
Table 15.
Name Application
ACS600 IGBT supply (ISU) application
ACS600 System application
ACS600AD Asynchronous drive
ACS600C Cyclo converter drive
ACS600SD Synchronous drive
136 3BSE035982R4101 -d1
Appendix D ABB Drives Parameter Group Configuration
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.
ACS800 IGBT supply (ISU) application
ACS800 System application
ACS1000 Standard drive
DCS600 System application
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)
Table 15.
Name Application
3BSE035982R4101 -d1 137
Parameter Group Configuration Appendix D ABB Drives
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.
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
Table 17.
Parameter Group Parameter Name Setting
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)
Table 16.
Parameter Group Parameter Name Setting
138 3BSE035982R4101 -d1
INDEX
AABB Drives 135
configure communication 137DriveBus 135PROFIBUS DP 135
ABB Engineered Drives 136ABB Standard Drives 136AC 800M
limitations 30access modes 24adapters
CI840 116CI920 116
address space 37addressing
explicit 35implicit 35
alarmsINSUM 71
Ccable length
Siemens 3964R 82cables
SattBus 55channel
drives 109PC Tool 110Special I/O 109
CI854web interface 119
CI858firmware upgrade 110
class CIP address 37
Client Server NetworkFF HSE 96
client/server 37client/server method
FF HSE 98clock synchronization 25CNCP 25COMLI
function blocks 62hardware 62link to control system 63message format 64multipoint communication 62over SattBus 53protocol 57RS-232C 62RS-485 62SattBus messages 53
communicationmulti-drop 57point-to-point 57
communication interfacesCI840 116CI851 116, 118CI854 116, 118CI855 47CI857 67CI858 103CI860 92CI920 116
3BSE035982R4101 -d1 139
Index
communication profileFF H1 91FF HSE 91
configureABB Drive communication 137CI854 119
Control Builder 33Control Network 21, 31, 37
troubleshooting 45controllers
supported 23
Ddefault gateway 43default process number 45design
DriveBus 104FF HSE 93INSUM 69MB 300 48MMS 33ModBus RTU 86PROFIBUS DP 113SattBus 54Siemens 3964R 80
design examplesDriveBus 105FF HSE 93INSUM 70MB 300 48ModBus RTU 87PROFIBUS DP 114Siemens 3964R 81
direct addressingSattBus 54
document conventions 15
DriveBusABB Drives 135design 104design example 105protocol 103services 103
Eeditor
parameters 33EN 50 170 112end block 65Ethernet 31, 33
IEEE 803.2 standard 43explicit addressing 35
FFF H1
communication profile 91FF HSE
Client Server Network 96client/server method 98communication profile 91connection methods 97design 93design example 93H1 Links 97hardware 101limitations 100performance 100protocol 91publisher/subscriber method 97redundancy 99services 92troubleshooting 102
Fieldbus Builder FF 92files
GSD 113hardware definition 114
140 3BSE035982R4101 -d1
Index
firmwareCI858 110
FOUNDATION Fieldbus HSEprotocol 91
function blocksCOMLI 62INSUM 68MB 300 48 to 49modem 122SattBus 54
GGSD file 113
Hhardware
FF HSE 101ModBus RTU 89PROFIBUS DP 117Siemens 3964R 82
HART 112Hayes modem 122Hirschmann modem 121HSE Subnet 96hubs 43
IIEC 1158-2
PROFIBUS DP 111IEC 61131-5 86IEC 61158-2 133IEEE 803.2 standard 43implicit addressing 35, 37information block 65
INSUMalarms 71CI857 67design 69design example 70function blocks 68protocol 67services 68
integersSiemens 3964R 82
intended user 30IP address 33
class C 37remote 37
IP subnet mask 33ISO 9506 31
Llibraries
Serial Communication Library 28limitations
AC 800M 30FF HSE 100MB 300 51ModBus RTU 88modem 123PROFIBUS DP 116SattBus 54Siemens 3964R 81
linkcontrol system to COMLI 63
Mmaster
ModBus RTU 86PROFIBUS DP 116
MasterBus 300 47maximum message size 24
3BSE035982R4101 -d1 141
Index
MB 300design 48design example 48function blocks 48 to 49limitations 51performance 51protocol 47redundancy 51services 47
MB 300 TS 25message format
COMLI 64MMS 31
design 33troubleshooting 45
MMS Server 32MMS Time Service 25ModBus RTU
design 86design example 87hardware 89limitations 88master 86multi-drop 88performance 88point-to-point 87protocol 85redundancy 88RS-232C 88RS-485 88services 86slave 86troubleshooting 89
modemdial-up 122function blocks 122Hayes 122limitations 123performance 123troubleshooting 123US Robotics modem 122Westermo 122
multi-drop 57ModBus RTU 88
Nnamed SattBus 54network area 21, 34
OOPC Server 32OPC Server FF 92optical link
PROFIBUS DP 118
Pparameters
editor 33parity 123PC Tool 110performance
FF HSE 100MB 300 51ModBus RTU 88modem 123PROFIBUS DP 117SattBus 54Siemens 3964R 82
plant intranet 37point-to-point 57
ModBus RTU 87PPP 36
142 3BSE035982R4101 -d1
Index
process numberdefault 45
PROFIBUS DP 112ABB Drives 135calculation of master parameters 113design 113design example 114hardware 117IEC 1158-2 111limitations 116master 116optical link 118performance 117protocol 111protocol layers 118redundancy 115RS-485 111, 117services 112slave 116
Project Explorer 22, 33protocol layers
PROFIBUS DP 118protocols
COMLI 57DriveBus 103FF HSE 91FOUNDATION Fieldbus HSE 91INSUM 67MB 300 47ModBus RTU 85PPP 36PROFIBUS DP 111SattBus 53serial 28Siemens 3964R 79supported 23
publisher/subscriber methodFF HSE 97
Rredundancy
FF HSE 99MB 300 51ModBus RTU 88PROFIBUS DP 115SattBus 54Siemens 3964R 81
remote IP address 37RNRP 33, 38RNRP monitor 45router 34routers 43RS-232C 31, 36
COMLI 62ModBus RTU 88Siemens 3964R 79
RS-485COMLI 62ModBus RTU 88PROFIBUS DP 111, 117Siemens 3964R 79
SSattBus
cables 55design 54direct addressing 54function blocks 54limitations 54named 54performance 54protocol 53redundancy 54services 53
SattCon 57serial protocol 28server 37
3BSE035982R4101 -d1 143
Index
servicesDriveBus 103FF HSE 92INSUM 68ModBus RTU 86PROFIBUS DP 112SattBus 53Siemens 3964R 79
Setup Wizard 33shielded cable 61Siemens 3964R
cable lengths 82design 80design example 81hardware 82integers 82limitations 81performance 82protocol 79redundancy 81RS-232C 79RS-485 79services 79
SIMATIC 82slave
ModBus RTU 86PROFIBUS DP 116
SNTP 25Special I/O 109start block 65subnetwork 34supported
controllers 23protocols 23
switches 43
TTCP/IP 32terminology list 16time synchronization 25TimeSync Master 25transceiver 43troubleshooting
Control Network 45FF HSE 102MMS 45ModBus RTU 89modem 123
twisted-pair cableshielded 61, 117
UUDP 55US Robotics 122User Datagram Protocol 55
Vvariable types 24
Wweb interfaces
CI854 119Westermo modem 121 to 122
144 3BSE035982R4101 -d1
BackCover.fm Page 19 Wednesday, October 20, 2004 10:27 AM
3BSE035982R4101 -d1. Printed in Sweden May 2005Copyright © 1999 - 2004 by ABB. All Rights Reserved® Registered Trademark of ABB.™ Trademark of ABB.
Automation Technology ProductsMannheim, Germanywww.abb.de/processautomationemail: [email protected]
Automation Technology Products Västerås, Swedenwww.abb.com/processautomationemail: [email protected]
Automation Technology ProductsWickliffe, Ohio, USAwww.abb.com/processautomationemail: [email protected]
http://www.abb.com/control