PROFIdrive Profile V4 0

Start
Version 4.0
PROFIBUS
and
PROFINET
Profile Drive Technology
PROFIdrive Profile
Version 4.0
August 2005
Order No: 3.172
Copyright PNO 2005 - All Rights Reserved Page 1 of 271

Content Start
Version 4.0
Document Identification: TC3-05-0005

File name : Profile-PROFIdrive_3172_V40_Aug05
Prepared by the PROFIBUS Working Group 6 PROFIdrive in the Technical Committee 3

Application Profiles.
The attention of adopters is directed to the possibility that compliance with or adoption of PI (PROFIBUS
International) specifications may require use of an invention covered by patent rights. PI shall not be
responsible for identifying patents for which a license may be required by any PI specification, or for conducting
legal inquiries into the legal validity or scope of those patents that are brought to its attention. PI specifications
are prospective and advisory only. Prospective users are responsible for protecting themselves against liability
for infringement of patents.
NOTICE:
The information contained in this document is subject to change without notice. The material in this document
details a PI specification in accordance with the license and notices set forth on this page. This document does
not represent a commitment to implement any portion of this specification in any company's products.
WHILE THE INFORMATION IN THIS PUBLICATION IS BELIEVED TO BE ACCURATE, PI MAKES NO
WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS MATERIAL INCLUDING, BUT
NOT LIMITED TO ANY WARRANTY OF TITLE OR OWNERSHIP, IMPLIED WARRANTY OF
MERCHANTABILITY OR WARRANTY OF FITNESS FOR PARTICULAR PURPOSE OR USE.
In no event shall PI be liable for errors contained herein or for indirect, incidental, special, consequential,
reliance or cover damages, including loss of profits, revenue, data or use, incurred by any user or any third
party. Compliance with this specification does not absolve manufacturers of PROFIBUS or PROFINET
equipment, from the requirements of safety and regulatory agencies (TV, BIA, UL, CSA, FCC, IEC, etc.).
PROFIBUS and PROFINET logos are registered trade marks. The use is restricted for
members of Profibus International. More detailed terms for the use may be found on the
web page www.profibus.com/libraries.html. Please select button "Presentations &
logos".
In this specification the following key words (in bold text) will be used:
may: indicates flexibility of choice with no implied preference.
should: indicates flexibility of choice with a strongly preferred implementation.
shall: indicates a mandatory requirement. Designers shall implement such

mandatory requirements to ensure interoperability and to claim
conformance with this specification.
Publisher:
PROFIBUS Nutzerorganisation e.V.
Haid-und-Neu-Str. 7
D-76131 Karlsruhe
Phone: +49 721 / 96 58 590
Fax: +49 721 / 96 58 589
E-mail: pi@profibus.com
Web site: www.profibus.com
No part of this publication may be reproduced or utilized in any form or by any means, electronic or
mechanical, including photocopying and microfilm, without permission in writing from the publisher.

Content Start
Version 4.0
Content
1 General ........................................................................................................................17
1.1 Background .........................................................................................................17
1.1.1 Requirements ..........................................................................................17
1.1.2 Goals of the PROFIdrive Profile................................................................18
1.1.3 New Functions of Version 4 ......................................................................18
1.1.4 Structure of the Document........................................................................18
1.2 Definitions ...........................................................................................................19
2 Integration of drives in automation systems ...................................................................20
2.1 General ...............................................................................................................20
2.2 Base Model .........................................................................................................20
2.2.1 Communication Devices ...........................................................................20
2.2.2 Communication Relationship ....................................................................20
2.2.3 Communication Network...........................................................................21
2.2.4 Functional Object .....................................................................................22
2.2.5 Object Model ...........................................................................................23
2.2.6 Layer Model .............................................................................................24
2.2.7 Communication Services ..........................................................................25
2.2.7.1 General .....................................................................................25
2.2.7.2 Cyclic Data Exchange ................................................................25
2.2.7.3 Acyclic Data Exchange ..............................................................25
2.2.7.4 Alarm Mechanism ......................................................................25
2.2.7.5 Clock Synchronous Operation ....................................................26
2.2.7.6 Base Model State Machine.........................................................28
2.3 Drive Model .........................................................................................................29
2.3.1 Drive Unit ................................................................................................29
2.3.2 Drive Object.............................................................................................29
2.3.3 Axis type Drive Object ..............................................................................31
2.3.4 Drive Unit classification ............................................................................32
2.4 Application Model and Application Classes...........................................................33
2.4.1 AC 1: Standard Drive ...............................................................................34
2.4.2 AC 2: Standard drive with distributed technology controller .......................35
2.4.3 AC 3: Single Axis positioning drive with local Motion Control .....................36
2.4.4 AC 4: Motion Control with central interpolation and speed setpoint
interface ..................................................................................................37
2.4.5 AC 5: Motion Control with central interpolation and position setpoint
interface ..................................................................................................38
2.4.6 AC 6: Motion Control for clocked processes, or distributed angular
synchronism ............................................................................................39
3 Parameter model ..........................................................................................................40
3.1 Parameter definition ............................................................................................40
3.1.1 Parameter value ......................................................................................40
3.1.2 Parameter description ..............................................................................40
3.1.3 Text .........................................................................................................45
3.2 Data types ...........................................................................................................46
3.2.1 Data types overview .................................................................................46
3.2.2 Profile-specific data types ........................................................................47

Content Start
Version 4.0
3.3 Global and Local Parameters ...............................................................................51

3.4 Base Mode Parameter Access .............................................................................52
3.4.1 General characteristics ............................................................................52
3.4.2 DO addressing modes ..............................................................................52
3.4.3 Parameter requests and parameter responses ..........................................53
3.4.4 Coding .....................................................................................................57
3.4.5 Telegram sequences for Parameter Access ..............................................60
4 Drive control application process ..................................................................................71
4.1 General Axis type Drive Object architecture .........................................................71
4.2 Control and Status words .....................................................................................73
4.2.1 Control word 1 (STW1).............................................................................74
4.2.2 Control word 2 (STW2).............................................................................76
4.2.3 Status word 1 (ZSW1) ..............................................................................76
4.2.4 Status word 2 (ZSW2) ..............................................................................79
4.2.5 Status bit "Pulses Enabled/Disabled" ........................................................79
4.3 Operating Modes and State Machine....................................................................79
4.3.1 General state diagram..............................................................................80
4.3.2 Speed control mode .................................................................................82
4.3.2.1 Speed control mode for Application Class 1................................82
4.3.2.2 Speed control mode for Application Class 4................................85
4.3.2.3 Jogging functionality in speed control mode ...............................86
4.3.3 Positioning mode .....................................................................................87
4.3.3.1 Homing Procedure .....................................................................89
4.3.3.2 Traversing Task Active ..............................................................90
4.4 Process Data (PZD).............................................................................................91
4.4.1 Signals ....................................................................................................91
4.4.2 Standard telegrams ..................................................................................93
4.4.3 Configuring the Process Data ...................................................................95
4.4.4 Process data normalization ......................................................................98
4.5 Dynamic Servo Control (DSC) ............................................................................ 101
4.5.1 Features ................................................................................................ 101
4.5.2 Structure................................................................................................ 101
4.5.3 Mode of operation .................................................................................. 102
4.5.4 Additional features ................................................................................. 103
4.5.5 Using multiple sensors ........................................................................... 103
4.5.6 Interface ................................................................................................ 104
4.5.7 Operating states .................................................................................... 104
4.5.8 Implementation information .................................................................... 105
4.6 Position feedback interface ................................................................................ 106
4.6.1 Overview ............................................................................................... 106
4.6.2 Actual positions ..................................................................................... 106
4.6.2.1 Structure of parameter 979 sensor format .............................. 107
4.6.2.2 Examples of the actual value format ......................................... 110
4.6.3 Assigning the actual values in the telegram ............................................ 113
4.6.4 Error codes in Gx_XIST2........................................................................ 113
4.6.5 Position feedback control word ............................................................... 114
4.6.6 Position feedback status word ................................................................ 115
4.6.7 State diagram of the position feedback interface ..................................... 117
4.6.7.1 State diagram .......................................................................... 117
Content Start
Version 4.0
4.6.7.2 States...................................................................................... 118

4.6.7.3 Transitions .............................................................................. 120
4.6.8 Device-specific expansions .................................................................... 124
4.7 Periphery .......................................................................................................... 127
4.8 Warnings, messages, faults, diagnostics ............................................................ 128
4.8.1 Overview ............................................................................................... 128
4.8.2 Warning mechanism............................................................................... 128
4.8.3 Fault buffer mechanism .......................................................................... 129
4.8.4 Fault classes mechanism ....................................................................... 135
4.9 Identification...................................................................................................... 137
4.9.1 Device identification ............................................................................... 137
4.9.2 Profile identification ............................................................................... 137
4.9.3 Drive Object identification ...................................................................... 138
4.9.4 I&M Parameter definition ........................................................................ 139
4.10 Drive reset (power-on reset) .............................................................................. 140
4.11 Operation priority of parameters and control priority ........................................... 142
4.12 User data reliability............................................................................................ 143
4.12.1 Controller's Sign-Of-Life (C-LS) .............................................................. 143
4.12.2 DOs Sign-Of-Life (DO-LS) ..................................................................... 145
4.12.3 Counting strategy for the Sign-Of-Life failure counter .............................. 146
4.13 Specified DO functions for the Application Classes............................................. 148
5 Parameter Definition ................................................................................................... 150
5.1 PROFIdrive Parameter listed by function ............................................................ 150
5.1.1 Life sign monitoring................................................................................ 150
5.1.2 PZD-Telegram Selection and Configuration ............................................ 150
5.1.3 Sensor Interface .................................................................................... 150
5.1.4 Fault buffer handling .............................................................................. 151
5.1.5 Warning signals ..................................................................................... 151
5.1.6 Spontaneous messages ......................................................................... 151
5.1.7 Closed loop control operating mode........................................................ 151
5.1.8 Set and store local parameter set ........................................................... 152
5.1.9 Set and store complete parameter set .................................................... 152
5.1.10 Drive Reset............................................................................................ 152
5.1.11 Operation priority for write parameters.................................................... 153
5.1.12 DO-identification and setup .................................................................... 153
5.1.13 Parameter Database Handling and Identification ..................................... 153
5.1.14 Device Identification............................................................................... 154
5.1.15 Alternative Supervisor PZD Control Channel........................................... 154
5.2 PROFIdrive Parameter listed by number ............................................................ 155
6 PROFIBUS DP Communication Layer ......................................................................... 172
6.1 Base Model at PROFIBUS DP............................................................................ 172
6.1.1 Communication Devices ......................................................................... 172
6.1.2 Communication Relationship .................................................................. 173
6.1.3 Communication Network......................................................................... 174
6.1.4 Communication Services ........................................................................ 175
6.1.4.1 Cyclic Data Exchange .............................................................. 175
6.1.4.2 Acyclic Data Exchange ............................................................ 175
6.1.4.3 Alarm Mechanism .................................................................... 176

Content Start
Version 4.0
6.1.4.4 Clock Synchronous Operation .................................................. 176

6.1.5 Drive Unit Communication Model ............................................................ 177
6.1.6 Base Model State Machine ..................................................................... 177
6.1.7 Definition of the CO ............................................................................... 178
6.2 Drive Model at PROFIBUS DP ........................................................................... 179
6.2.1 Drive Unit .............................................................................................. 179
6.3 Process Data..................................................................................................... 180
6.3.1 COs for Process Data configuration ........................................................ 180
6.3.2 Standard telegram configuration ............................................................. 181
6.3.3 Slave-to-slave Communication (DXB) ..................................................... 183
6.3.3.1 Overview ................................................................................. 183
6.3.3.2 Application example................................................................. 185
6.3.3.3 User model and configuration................................................... 186
6.3.3.4 Device internal data mapping ................................................... 188
6.3.3.5 Subscriber table ...................................................................... 189
6.3.3.6 Timing characteristics .............................................................. 190
6.3.3.7 Monitoring and diagnostics....................................................... 190
6.3.3.8 Configuring, GSD extensions ................................................... 191
6.4 Parameter Access ............................................................................................. 193
6.4.1 PAP for Parameter Access ..................................................................... 193
6.4.2 DPV1 parameter channel for Parameter Access...................................... 194
6.4.2.1 General ................................................................................... 194
6.4.2.2 DPV1 telegram sequences for Base Mode Parameter
Access .................................................................................... 194
6.4.2.3 DPV1 telegram frame............................................................... 196
6.4.2.4 Data block lengths ................................................................... 198
6.4.2.5 Scalability of the functionality ................................................... 199
6.4.2.6 GSD parameters for DPV1 ....................................................... 200
6.5 Drive Unit Configuration..................................................................................... 200
6.5.1 Drive Unit Configuration on PROFIBUS DP............................................. 200
6.5.2 Getting the Drive Object ID (DO-ID) ..................................................... 202
6.6 Alarm Mechanism .............................................................................................. 204
6.6.1 General ................................................................................................. 204
6.7 Clock Synchronous Operation ............................................................................ 205
6.7.1 Sequence of an isochronous DP cycle .................................................... 205
6.7.2 Time settings ......................................................................................... 206
6.7.2.1 Example (simplest DP cycle) .................................................... 208
6.7.2.2 Example (optimized DP cycle) .................................................. 209
6.7.2.3 Example (optimized DP cycle, T MAPC = 2 * T DP ) ......................... 210
6.7.3 Running-up, cyclic operation .................................................................. 211
6.7.4 Parameterization, configuring (Set_Prm, GSD) ....................................... 221
6.7.5 Clock cycle generation (Global_Control) and clock cycle save................. 222
6.7.5.1 Definition of the Global_Control service (current
functionality) ............................................................................ 222
6.7.5.2 Clock jitter ............................................................................... 223
6.7.5.3 PLL for clock regeneration in the slave ..................................... 224
6.7.6 Monitoring mechanisms.......................................................................... 226
6.8 PROFIBUS DP specific Parameter ..................................................................... 228
6.8.1 Overview of the communication interface related parameters .................. 228
Content Start
Version 4.0
6.8.2 Definition of the specific parameters ....................................................... 229

6.9 Specified communication functions for the Application Classes ........................... 230
7 PROFINET IO Communication Layer........................................................................... 231
7.1 Base Model at PROFINET IO ............................................................................. 231
7.1.1 Communication Devices ......................................................................... 231
7.1.2 Communication Relationship .................................................................. 232
7.1.3 Communication Network......................................................................... 233
7.1.4 Communication Services ........................................................................ 234
7.1.4.1 Cyclic Data Exchange .............................................................. 234
7.1.4.2 Acyclic Data Exchange ............................................................ 234
7.1.4.3 Alarm Mechanism .................................................................... 234
7.1.4.4 Clock Synchronous Operation .................................................. 235
7.1.5 Drive Unit Communication Model ............................................................ 236
7.1.6 Base Model State Machine ..................................................................... 238
7.1.7 Definition of the CO ............................................................................... 239
7.2 Drive Model at PROFINET IO............................................................................. 240
7.2.1 Drive Unit .............................................................................................. 240
7.2.2 Drive Unit Architecture ........................................................................... 240
7.2.3 Definition of the Module Ident Number and API ....................................... 242
7.2.4 Definition of the Submodule Ident Numbers ............................................ 242
7.3 Process Data..................................................................................................... 244
7.3.1 COs for Process Data configuration ........................................................ 244
7.3.2 Process Data Producer and Consumer Status ........................................ 244
7.4 Parameter Access ............................................................................................. 244
7.4.1 PAPs for Parameter Access ................................................................... 244
7.4.2 Base Mode Parameter Access ................................................................ 245
7.4.2.1 General ................................................................................... 245
7.4.2.2 Properties Base Mode Parameter Access - Local...................... 245
7.4.2.3 Properties Base Mode Parameter Access - Global .................... 245
7.4.2.4 Data flow for the Base Mode Parameter Access ....................... 246
7.5 Drive Unit Configuration..................................................................................... 247
7.5.1 Drive Unit Configuration on PROFINET IO .............................................. 247
7.5.2 Getting the Drive Object ID (DO-ID) ..................................................... 247
7.6 Alarm Mechanism .............................................................................................. 248
7.6.1 Use of the Diagnosis Objects ................................................................. 248
7.6.2 Use of the Alarm Mechanism .................................................................. 248
7.6.3 Use of the ChannelDiagnosisData Structure ........................................... 249
7.6.4 Use of the ChannelErrorType ................................................................. 249
7.6.5 On demand access of Diagnosis Information .......................................... 250
7.7 Clock Synchronous Operation ............................................................................ 251
7.7.1 Sequence of an isochronous Data Cycle................................................. 251
7.8 PROFINET IO specific Parameter ...................................................................... 252
7.8.1 Overview of the communication interface related Parameters .................. 252
7.8.2 Definition of the specific parameters ....................................................... 253
7.9 Specified communication functions for the Application Classes ........................... 254
8 Integration of drives in process technology (VIK-NAMUR)............................................ 255
8.1 General ............................................................................................................. 255
8.2 Commands and Checkback signals .................................................................... 256

Content Start
Version 4.0
8.2.1 Control word1 ........................................................................................ 256

8.2.2 Status word1.......................................................................................... 257
8.2.3 Drive status/fault word ........................................................................... 258
8.3 State diagrams .................................................................................................. 259
8.3.1 General state diagram............................................................................ 259
8.3.2 Setpoint channel for VIK-NAMUR operating mode................................... 259
8.4 Inevitable line interruption and external interlock ................................................ 260
8.5 Standard telegram ............................................................................................. 262
Annex A (informative) Bibliography (Normative references)................................................ 263
Annex B (informative) Definitions and abbreviations .......................................................... 264
B.1 Abbreviated terms ............................................................................................. 264
B.1.1 General ................................................................................................. 264
B.1.2 Timing Parameters ................................................................................. 266

Content Start
Version 4.0
Figures
Figure 1 Basic structure of the document..........................................................................19
Figure 2 PROFIdrive Devices and there relationship .........................................................20
Figure 3 General Communication Model of a PROFIdrive Automation System ...................21
Figure 4 The PROFIdrive Device consists out of one or several Functional Objects ...........22
Figure 5 Hierarchical order in the Object Model ................................................................23
Figure 6 PROFIdrive Base Model contains the Application Layer and
Communication Layer .......................................................................................................24
Figure 7 Typical use case for Clock Synchronous Operation .............................................26
Figure 8 General Model for Clock Synchronous Operation ................................................27
Figure 9 Base Model State Machine .................................................................................28
Figure 10 General Drive Unit model..................................................................................29
Figure 11 General Drive Object architecture .....................................................................30
Figure 12 Principle functional model of an Axis type Drive Object .....................................31
Figure 13 Classes of PROFIdrive Drive Units....................................................................32
Figure 14 Overview about the available Communication Services between the
PROFIdrive Devices ...........................................................................................................33
Figure 15 Application Class 1 ...........................................................................................34
Figure 21 Example overview of global and local parameters of a Multi-Axis/Modular
Drive Unit ...........................................................................................................................51
Figure 22 General functional elements of the PROFIdrive Axis type DO ............................72
Figure 23 Functional block diagram of the PROFIdrive Axis type DO .................................73
Figure 24 General state diagram for all operating modes ..................................................81
Figure 25 General functionality of a PROFIdrive Axis DO with Application Class 1
functionality ........................................................................................................................83
Figure 26 Speed setpoint channel for use in Application Class 1 and 4 .............................84
functionality ........................................................................................................................85
Figure 28 Reduced speed setpoint channel for use in Application Class 4 (optional)..........86
functionality ........................................................................................................................87
Figure 30 State diagram of the positioning mode ..............................................................88
Figure 31 Homing Procedure stopped by the controller .....................................................89
Figure 32 Homing Procedure: Home Position Set..............................................................89
Figure 33 Traversing Task Active .....................................................................................90
Figure 34 Change of the traversing tasks immediately ......................................................90
Figure 35 Example for configuring a telegram ...................................................................98
Figure 36 Structure of the position control circuit based on the velocity setpoint
interface without DSC ....................................................................................................... 101

Content Start
Version 4.0
interface with DSC ............................................................................................................ 102
Figure 38 Example of the sensor interface (Sensor-1: two actual values / Sensor-2:
one actual value) .............................................................................................................. 106
Figure 39 State diagram of the position feedback interface with designations of the
states and transitions ........................................................................................................ 117
Figure 40 Timing diagram: Measurement on the fly ......................................................... 125
Figure 41 Timing diagram: Reference mark search ......................................................... 126
Figure 42 Overview about the diagnostic mechanisms of PROFIdrive.............................. 128
Figure 43 Working of the warning mechanism ................................................................. 129
Figure 44 Overview about the fault buffer mechanism ..................................................... 130
Figure 45 Fault acknowledgement for the fault buffer mechanism .................................... 131
Figure 46 Processing of the fault messages in the fault buffer mechanism....................... 132
Figure 47 Fault buffer (subsequent system) with example ............................................... 134
Figure 48 Fault number list with example........................................................................ 135
Figure 49 Drive reset: Direct initiation (P972 = 1)............................................................ 141
Figure 50 Example: Long term Sign-Of-Life failure of the controller ................................. 144
Figure 51 Example: Temporary failure of the controller LS (negative deviation) ............... 144
Figure 52 Example: Temporary failure of the controller LS (positive deviation; double
step)................................................................................................................................. 145
Figure 53 Example: Permanent failure of the DO LS ....................................................... 146
Figure 54 Example: Temporary failure of the DO LS (negative deviation) ........................ 146
Figure 55 Example: Temporary failure of the DO LS (positive deviation; double step) ...... 146
Figure 56 Value of the DO Sign-Of-Life failure counter (axis-specific) with respect to
the transferred controller Sign-Of-Life ............................................................................... 147
Figure 57 PROFIBUS DP Devices in a PROFIdrive drive system ..................................... 172
Figure 58 PROFIdrive Devices and there Relationship for PROFIBUS DP ....................... 173
Figure 59 General Communication Model for PROFIdrive at PROFIBUS DP .................... 174
Figure 60 PROFIBUS DP slave-to-slave communication designations ............................. 175
Figure 61 Clock cycle synchronous communication for PROFIdrive at PROFIBUS DP ..... 176
Figure 62 Overview about the Drive Unit Communication Model on PROFIBUS ............... 177
Figure 63 Mapping of the Base Model State Machine at PROFIBUS DP .......................... 178
Figure 64 PROFIBUS DP specific Logical Drive Unit model (multi axis drive) .................. 179
Figure 65 Mapping of PROFIBUS Slot to the PROFIdrive DO .......................................... 180
Figure 66 Application example of slave-to-slave communication...................................... 185
Figure 67 Dataflow inside a Multi-Axis or Modular Device with DXB relations .................. 188
Figure 68 Structure of a subscriber table (inside a Prm-Block) ........................................ 189
Figure 69 Timing diagram of PROFIBUS with slave-to-slave communication.................... 190
Figure 70 PAP and Parameter Access mechanism for PROFIdrive at PROFIBUS ............ 193
Figure 71 Telegram sequence via DPV1 ......................................................................... 195
Figure 72 Drive Unit Structure ........................................................................................ 201
Figure 73 Configuration and communication channels for the Modular Drive Unit type
at PROFIBUS DP.............................................................................................................. 202
Figure 74 Meaning of parameter P978 "list of all DO-IDs" for the DU at PROFIBUS
DP 203
Content Start
Version 4.0
Figure 75 Example of P978 for a complex Modular Drive Unit at PROFIBUS DP.............. 204
Figure 76 Sequence of an isochronous DP cycle ............................................................ 205
Figure 77 Time settings.................................................................................................. 206
Figure 78 Example: Simplest DP cycle ........................................................................... 208
Figure 79 Example: Optimized DP cycle ......................................................................... 209
Figure 80 Example: Optimized DP cycle (T MAPC = 2 * T DP ) ............................................... 210
Figure 81 Running-up (sequence with respect to time) .................................................... 212
Figure 82 Phase 1: Slave parameterization, configuration ............................................... 213
Figure 83 Phase 2: Synchronization of the PLL to the Clock Global_Control .................... 213
Figure 84 Phase 3: Synchronizing the slave application with the master's Sign-Of-
Life 215
Figure 85 State diagram of phases 2 and 3 of the run-up ................................................ 217
Figure 86 Phase 4: Synchronization of the master application to the slave's Sign-Of-
Life 217
Figure 87 Example: Running-up to cyclic operation (T MAPC /T DP = 2/1) .............................. 219
Figure 88 PLL for clock save in the slave........................................................................ 224
Figure 89 Run time compensation .................................................................................. 226
Figure 90 Example: Clock failure .................................................................................... 228
Figure 91 PROFINET IO Devices in a PROFIdrive drive system ...................................... 231
Figure 92 PROFIdrive Devices and there Relationship for PROFINET IO ........................ 232
Figure 93 General Communication Model for PROFIdrive at PROFINET IO ..................... 233
Figure 94 Clock cycle synchronous communication for PROFIdrive at PROFINET IO....... 235
Figure 95 Overview about the Drive Unit Communication Model on PROFINET IO........... 236
Figure 96 Contents of IO AR and Supervisor AR ............................................................. 237
Figure 97 M CR used for Cyclic Data Exchange between Drive Units .............................. 238
Figure 98 Mapping of the Base Model State Machine at PROFINET IO ........................... 239
Figure 99 PROFINET IO specific Logical Drive Unit model (multi axis drive).................... 240
Figure 100 Representation of the PROFIdrive DO by PROFINET IO Submodules
(CO) ................................................................................................................................. 241
Figure 101 Hierarchical model of the Drive Unit on PROFINET IO ................................... 242
Figure 102 - Modularity of the PZD data block (example) ................................................... 244
Figure 103 Data flow for request and response for the Base Mode Parameter Access ..... 246
Figure 104 Configuration and communication channels for the Modular Drive Unit
type at PROFINET IO ....................................................................................................... 247
Figure 105 Meaning of parameter P978 "list of all DO-IDs" for the DU at PROFINET
IO 248
Figure 106 Sequence of isochronous Data Cycle ............................................................ 251
Figure 107 Functionality and Interfaces for drive integration according to VIK-
NAMUR ............................................................................................................................ 255
Figure 108 Principle structure of the drive interface according to VIK-NAMUR
guideline .......................................................................................................................... 256
Figure 109 Speed setpoint channel for VIK-NAMUR process technology operating
mode ................................................................................................................................ 259
Figure 110 Process technology operating mode, control word 1 bit 15 and status
word 1 bit 10,11,13,14 ...................................................................................................... 260

Content Start
Version 4.0
Figure 111 Process technology operating mode, inevitable line interruption and
external interlock .............................................................................................................. 261

Content Start
Version 4.0
Tables
Table 1 Application Classes .............................................................................................33
Table 2 Parameter definition ............................................................................................40
Table 3 Parameter description elements ...........................................................................40
Table 4 Parameter description element "Identifier (ID)" .....................................................41
Table 5 Parameter description element "variable attribute................................................42
Table 6 Parameter Description Elements Process Data Reference Value/Process
Data Normalization ...........................................................................................................44
Table 7 Text array for parameter description ....................................................................45
Table 8 Text array for the data type Boolean ....................................................................45
Table 9 Text array for data type V2 (bit sequence)............................................................46
Table 10 Data types .........................................................................................................46
Table 11 Base mode parameter request ...........................................................................53
Table 12 Base mode parameter response.........................................................................54
Table 13 Permissible combinations consisting of attribute, number of elements and
subindex (see also [10]) ......................................................................................................56
Table 14 Coding of the fields in parameter request/parameter response of Base
Mode Parameter Access .....................................................................................................57
Table 15 Error numbers in Base Mode parameter responses.............................................58
Table 16 Overview on the assignment of the bits of control word 1 ....................................74
Table 17 Detailed assignment of the common control word 1 bits (STW1) for speed
control/positioning ..............................................................................................................74
Table 18 Detailed assignment of the special control word 1 bits (STW1) for speed
control mode.......................................................................................................................75
Table 19 Detailed assignment of the special control word 1 bits (STW1) for the
positioning mode ................................................................................................................76
Table 20 Overview on the assignment of the bits of control word 2 ....................................76
Table 21 Overview on the assignment of the bits of status word 1 .....................................76
Table 22 Detailed assignment of the common status word 1 bits (ZSW1) for the
speed control /positioning mode ..........................................................................................77
Table 23 Detailed assignment of the special status word 1 bits (ZSW1) for the speed
control mode.......................................................................................................................78
Table 24 Detailed assignment of the special status word 1 bits (ZSW1) for the
positioning mode ................................................................................................................78
Table 25 Overview on the assignment of the bits of status word 2 .....................................79
Table 26 Signal list assignment .....................................................................................91
Table 27 Parameters for configuring a telegram................................................................95
Table 28 Structure of parameter 979 (sensor format) ...................................................... 107
Table 29 Subindex 0 (header) of parameter 979 ............................................................. 108
Table 30 Subindex 1 (sensor type) of parameter 979 ...................................................... 108
Table 31 Subindex 2 (sensor resolution) of parameter 979.............................................. 108
Table 32 Assigning Gx_XIST2 (sensor-x position actual value-2) .................................... 113
Table 33 Error codes in Gx_XIST2 ................................................................................. 113
Table 34 Sensor control word ......................................................................................... 114
Table 35 Sensor status word .......................................................................................... 115

Content Start
Version 4.0
Table 36 Fault buffer parameters.................................................................................... 133

Table 37 Definition of the fault classes attribute.............................................................. 135
Table 38 Definition of the PROFIdrive fault classes ........................................................ 136
Table 39 Structure of parameter 964 (Device identification) ............................................ 137
Table 40 Definition of the Profile identification number.................................................... 138
Table 41 Structure of parameter 975 (DO identification).................................................. 138
Table 42 Structure of P975.5.......................................................................................... 138
Table 43 DO type class definition in P975.5.................................................................... 139
Table 44 Assignment of the bits of DO sub class 1 identification in P975.6 ...................... 139
Table 45 PROFIdrive I&M parameter definition ............................................................... 140
Table 46 Specified DO functions for the Application Classes ........................................... 148
Table 47 Parameter for Life sign monitoring ................................................................. 150
Table 48 Parameter for PZD-Telegram selection and configuration ............................... 150
Table 49 Parameter for Sensor interface ...................................................................... 150
Table 50 Parameter for Fault buffer handling................................................................ 151
Table 51 Parameter for Warning mechanism ................................................................ 151
Table 52 Parameter for Spontaneous message mechanism .......................................... 151
Table 53 Parameter for Closed loop control operating mode ......................................... 151
Table 54 Parameter for Set and store of the local parameter set ................................... 152
Table 55 Parameter for Set and store complete parameter set ...................................... 152
Table 56 Parameter for Drive reset .............................................................................. 152
Table 57 Parameter for Operation priority for write parameters ..................................... 153
Table 58 Parameter for DO identification and setup ...................................................... 153
Table 59 Parameter for Parameter set identification ..................................................... 153
Table 60 Parameter for Device identification ................................................................ 154
Table 61 Parameter for Alternative supervisor PZD control channel .............................. 154
Table 62 DP IDs and PROFIdrive IDs of the standard telegrams (refer to 4.4.2) .............. 181
Table 63 Parameters (Set_Prm, GSD) for slave-to-slave communication (Data-
eXchange Broadcast)........................................................................................................ 191
Table 64 Services used for Parameter Access on PROFIBUS DP.................................... 194
Table 65 Defined PAPs for Parameter Access ................................................................ 194
Table 66 State machine for slave processing .................................................................. 195
Table 67 DPV1 Error class and code for PROFIdrive ...................................................... 197
Table 68 Limits due to the DPV1 data block length ......................................................... 199
Table 69 GSD parameters for the DPV1 Parameter Access............................................. 200
Table 70 Parameters (Set_Prm, GSD) for "Clock-Cycle Synchronous Drive Interface ..... 221
Table 71 Possible synchronization type combinations ..................................................... 223
Table 72 Conditions for Isochronous Mode ..................................................................... 224
Table 73 Input signals of the PLL ................................................................................... 225
Table 74 Output signals of the PLL................................................................................. 225
Table 75 Overview of the specific PROFIBUS DP parameters for Communication
system interfaces ............................................................................................................ 228
Table 76 Coding of the baud rate in Parameter 963 ........................................................ 229

Content Start
Version 4.0
Table 77 Specified communication functions for the Application Classes ......................... 230
Table 78 Definition of Submodul-IDs .............................................................................. 243
Table 79 Definition of Parameter Access Modes ............................................................. 245
Table 80 Use of the AlarmNotification-PDU .................................................................... 249
Table 81 Use of ChannelDiagnosisData.......................................................................... 249
Table 82 Use of ChannelErrorType................................................................................. 249
Table 83 Use of the DiagnosisData ................................................................................ 250
Table 84 Overview of the specific PROFINET IO parameters for Communication
system interfaces ............................................................................................................ 252
Table 85 Specified communication functions for the Application Classes ......................... 254
Table 86 Overview on the assignment of the bits of control word1 for the process
technology operating mode ............................................................................................... 256
Table 87 Overview on the assignment of the bits of status word1 for the process
technology operating mode ............................................................................................... 257
Table 88 Overview on the assignment of the bits of drive status/fault word for the
process technology operating mode .................................................................................. 258

Content Start
Version 4.0
Revision Log
Identification Version Originator Date Change Note / History / Reason

S1 4.0 Step1 PROFIdrive 20.04.2005 Initial Version
AK / Uhl
S2 4.0 Step2 PROFIdrive 04.05.2005
AK / Uhl
S3 4.0 Step3 PROFIdrive 17.05.2005
AK / Uhl
S4 3.9 Step4 PROFIdrive 24.06.2005 Version for PNO Review
AK / Uhl
S5 4.0 Step5 PROFIdrive 23.08.2005 Final Version V4.0
AK / Uhl

Content Start
Version 4.0
1 General
1.1 Background
The PROFIBUS and PROFINET profile for drive technology, PROFIdrive, Version 4, is a
further development of the proven PROFIBUS profile for drive technology, Version 3.1.2,
which is based on the PROFIBUS profile for variable-speed drives, PROFIdrive, Version 2 [5].
Today, this is the standard for all manufacturers to implement PROFIBUS interfaces for
drives. It was generated by the PNO, and involved many renowned drive manufacturers. The
Edition, based on PROFIBUS-FMS, was published in 1991 and included the definitions for the
closed-loop speed control function. In 1997, the profile was extended by the positioning
function and the faster PROFIBUS protocol was added. In 2002 with the Version 3.1, DP V2
and the isochronous operation was added. With the latest Version 3.1.2 also Slave-to-slave
communication was specified.
The actual PROFIdrive Version 4 comprises all the PROFIdrive functionality from its former
Version 3 and additionally comprises the usage of PROFIdrive at PROFINET.
The PROFIdrive profile defines, as a supplement to the PROFIBUS and PROFINET standard,
a unified device behaviour and access technique to the drive data. For the user, this means
that engineering costs are reduced when planning and implementing plants and systems, as
the various drives respond the same way to control instructions. The programming costs are
significantly reduced by using standardized program blocks in the open-loop and closed-loop
control systems for controlling the Drive Units via PROFIBUS or PROFINET. For drive
manufacturers, as a result of the profile definition, development costs are reduced and the
implementation of non-proprietary standardized interface improves the chances of being
successful in the market.
1.1.1 Requirements
Today, variable-speed electric drives from basic AC drive converters up to high-dynamic

performance servo controllers are being increasingly connected to higher-level open-loop and
closed-loop control systems in automated plants and systems via digital interfaces.
In today's systems, the speed interface is standard. The speed setpoint is entered from a
higher-level automation system which controls the drive. Generally, the speed actual value is
signalled back to the automation system to monitor the drive.
In order that the digital field bus interface in distributed automation concepts may also be
used in the area of Motion Control with several drive axes, today's standard field busses shall
be expanded by specific features. This involves fulfilling the following requirements:
Clock cycle synchronism: If a central motion controller is being used which handles the
interpolation and closed-loop position control, the control loop shall be closed via the bus. The
speed setpoint is transferred to the drive in the setpoint direction. In the actual value
direction, the drive provides a position actual value. In order to implement sufficiently high
loop gains to fulfil the required dynamic performance, the delays shall be minimal and it is
especially important that they are absolutely constant. If the Motion Control task requires the
coordination of several axes, the position actual values shall be acquired precisely at the
same time and evaluated in synchronism in the motion controller. Furthermore, the setpoints
shall take effect precisely at the same time in the axes. The actual value acquisition, transfer
and setpoint activation are in clock cycle synchronism with the closed-loop position controller.
Drive-to-Drive communication: State-of-the-art automation solutions with digital Drive Units

use also distributed concepts where the open-loop and closed-loop control tasks, which were
previously implemented centrally, are shifted into intelligent drives. Examples are single-axis-
positioning drives or drives with integrated software for winding functions or synchronous
operating applications.
Content Start
Version 4.0
If automation functions are to be decentralized and distributed, then data shall be directly
transferred between the drives, which, for example for an electronic shaft, shall be realized
with precise angular synchronism and also with clock cycle synchronism.
Acyclic communication: The acyclic services of PROFIBUS and PROFINET are used to
transfer parameter requests for operator control and monitoring of drives in parallel to the
Cyclic Data Exchange.
With modern automation profiles it is a strong requirement to support state of the art
Communication Systems. For the PROFIdrive profile this means to be able to adapt also to
the PROFIBUS successor PROFINET IO.
1.1.2 Goals of the PROFIdrive Profile
Until PROFIBUS specification DP-V2, it was not possible to realize all of the requirements
using just one system. In drive applications several different field bus systems often had to be
used in parallel. For instance, if in addition to drive control, distributed I/O and operator
control functions were to be implemented via different buses. In addition to PROFIBUS, which
is used to control the drive, a proprietary system had to be used to synchronize the drives or
to implement a setpoint cascade.
Since the Version 3 PROFIdrive Profile it is possible to use one field bus system (PROFIBUS)
to match all of the above requirements of electric drives, using the field bus system
PROFIBUS.
To protect investments in engineering tools, automation program libraries and training of staff,
it is important to have a stable generic application profile functionality which migrates to future
enhanced field bus systems by keeping its application platform interface stable. With the
Version 4 of the PROFIdrive Profile, the PROFIdrive application platform interface known from
the PROFIdrive Version 3 is also merged with the currently evolving PROFINET field bus
system. This makes it possible to run the PROFIdrive application platform interface also on
the PROFIBUS and the PROFINET field bus system.
As a result of the generic migration from the PROFIdrive Profile from PROFIBUS to
PROFINET, in many drive applications the engineering costs will be able to be further
reduced and also significant cost savings will be able to be achieved for service/maintenance,
training and spare parts inventory.
1.1.3 New Functions of Version 4
The new functions to the PROFIdrive application interface platform with the Version 4 are the
definition of the PROFIdrive fault classes and the extension of the measurement system state
machine. Completely new for Version 4 is the usage of the PROFIdrive Profile also for the
PROFINET IO field bus system.
1.1.4 Structure of the Document
According to Figure 1 the PROFIdrive specification Version 4 is structured in three main parts.
The first part contains the PROFIdrive Base Model, the Application Model and the PROFIdrive
Parameter Definition. This part defines the basic structure of a PROFIdrive automation system
and the functionality of the application processes and there interfaces independent of any
Communication System.

Content Start
Version 4.0
PROFIdrive
PROFIdrive Base Modell
PROFIdrive Applikation Modell
PROFIdrive Parameter Definition
PROFIBUS PROFINET
PROFIdrive PROFIdrive
mapping on mapping on
PROFIBUS DP PROFINET IO
Figure 1 Basic structure of the document
The second and third part define the mapping of the PROFIdrive Base Model on the two
Communication Systems PROFIBUS DP and PROFINET IO.
1.2 Definitions
General information
Output data: Data, which a device cyclically receives from the

master and which it outputs to the device
application or the peripherals.
Input Data: Data, which a slave cyclically sends to the master.
Process data: For Drive Units, all Input and Output Data
Technological functions: Closed-loop controls and sequence control to
automate application-specific processes.
Drive-to-Drive communication
Drive-to-Drive communication: Drive-to-Drive communication refers to the

communication between Drives from the user's
perspective.
Clock synchronous Operation
Synchronization: Establish synchronism

Clock cycle synchronization, Clock cycle synchronization designates the
Clock cycle synchronous synchronization of sampling times in the closed-
application: loop control software in digital drives and control
systems. The starting instance and the length of the
sampling times in the various devices are precisely
synchronized with one another.
Equidistance: Equal distance. This is used as a synonym for
isochronous mode.
Isochronous mode: Communication system service for clock cycle
synchronism which generates a constant (timing)
bus cycle with a clock cycle signal at the start of the
cycle.

Content Start
Version 4.0
2 Integration of drives in automation systems
2.1 General
This chapter specifies the abstract modelling and different variants for integration of
PROFIdrive drive Axis in automation systems. This PROFIdrive model is generally
independent of the Communication System used as network platform (PROFIBUS,
PROFINET). Depending on the communication system limitations to the general model and
functionality may be possible.
2.2 Base Model
2.2.1 Communication Devices
The PROFIdrive Base Model defines as basic elements the following three classes of devices:
Controller: The Controller is a controlling device which is associated with one or more
drives (axes). Related to the automation system, the Controller is the host for the
overall automation.
Drive Unit: The Drive Unit is a field device and the host for the drive (closed loop
control, inverter). The Drive Unit typically is associated with one or more Controller
devices.
Supervisor: The Supervisor typically is an engineering device which manages
provisions of configuration data (parameter sets) and collections of diagnosis data
from Drive Units and/or Controllers.
2.2.2 Communication Relationship
The PROFIdrive Base Model defines the following types of communication relationships
between the Devices:
Device -Device Communication

Relationship
Communication Supervisor
Device
Device
ve Unit
it
Un
e
r iv
-D
Supervisor - Dri
or
is
rv
pe
Su
Controller Controller
Co
it
Un
it
tro
Un
e
riv
e
lle
riv
-D
-D
r
er
-D
oll
er
ntr
riv
oll
Co
eU
ntr
Co
nit
Drive Unit - Drive Unit

Drive Unit Drive Unit
Figure 2 PROFIdrive Devices and there relationship

Content Start
Version 4.0
Figure 2 shows the PROFIdrive Devices and the defined relationships between them in the
context of the PROFIdrive Base Model.
2.2.3 Communication Network
Station
Device ... Device
(Drive Unit, Controller
(Drive Unit, Controller
or Supervisor) or Supervisor)
Station Station
Network Interface ...
Network Interface Connector
Network
Figure 3 General Communication Model of a PROFIdrive Automation System
Figure 3 shows the general architecture of the automation system and the location of the
PROFIdrive Devices as components of the Station. The physical model generally consists out
of physical Stations embedded in a Communication Network system. Though every Station
comprises a Network Interface Connector to physically connect the Station to the Network and
a Network Interface functionality, which provides the Communication Service to the Devices.
Therefore the PROFIdrive Device is precisely defined by the following address information:
Network
Station (Identifier for Station inside the Network)
Device (Identifier for Device inside the Station)

Content Start
Version 4.0
2.2.4 Functional Object
The PROFIdrive Device consists out of one or more Functional Objects. The Functional
Objects are logical Objects which represent a special functionality inside the automation
system. Figure 4 shows the general architecture of the PROFIdrive Device containing
Functional Objects.
If the Device is of Drive Unit type, the Functional Objects inside the Drive Unit are of Drive
Object type (see Figure 4). The typical functionality of the Drive Object is the drive
functionality itself (motor, inverter stage, closed loop current and speed control, Input and
output functionality). For example one drive axis is related to a Drive Object.
PROFIdrive Device
(e.g. Drive Unit)
Functional Functional Functional

Object Object Object
( e.g. Drive Object) ( e.g. Drive Object)
... ( e.g. Drive Object)
Figure 4 The PROFIdrive Device consists out of one or several Functional Objects

Content Start
Version 4.0
2.2.5 Object Model
Based on the Objects defined in the Base Model the hierarchical order and dependencies
between them are specified in the Object Model (see Figure 5).
Every Station consists out of the Network Interface and one or more Devices. The Network
Interface is related to the Network to which the Station is connected. The Devices are
classified in three types, Controller, Drive Unit and Supervisor. If the Device is of Drive Unit
type, the Drive Unit consists out of one or more Drive Objects.
Additional the Communication Object (CO) is defined, which has a relationship to the
Network Interface and also to the Functional Object (e.g. Drive Object). The purpose of the
Communication Object is to be a Communication System addressable communication end
point, which may be associated to a Functional Object.
Network
Station
1...n
PROFIdrive Network
Device Interface
Drive Unit
Controller Supervisor
(DU)
1...n 1...n
1...n Communication
Drive Object
Object
(DO)
(CO)
Aggregation - consists out of
Generalisation - is sub-class of
Relationship - has a relation to
Figure 5 Hierarchical order in the Object Model

Content Start
Version 4.0
2.2.6 Layer Model
Separation of the objects in the Base Model according to the aspects of application and
communication leads to the Layer Model according to Figure 6. Here the Application Layer
only contains the functional aspects of the automation system, independent of the distribution
of the functional elements among physical stations and devices. The distribution aspect is
represented by the Communication Layer, which specifies the physical network components
and the allocation of the Functional Objects to them.
PROFIdrive Device
Application PROFIdrive
Layer Application
Drive
PROFIdrive Model
Object
Device
Communication Cyclic Acyclic Clock

Alarm
Data Data Synchronous
Services Mechanism
Exchange Exchange Operation
PROFIdrive
Communication Communication
Layer Network Interface Model
Network (physical)
Figure 6 PROFIdrive Base Model contains the Application Layer and

Communication Layer

Content Start
Version 4.0
2.2.7 Communication Services
2.2.7.1 General
The PROFIdrive Base Model defines the following Communication Services. The
Communication Services are provided from the Device and are used from the Functional
Object.
The representation of data shall be in big-endian format.
2.2.7.2 Cyclic Data Exchange
Cyclic communication means the simple transfer of process data of predefined size in a
reserved time slot. With cyclic communication, the process data that is critical with respect to
time is exchanged between the controller and device or between devices. Typical such data
contains setpoint values and actual values, control- and status information. The Cyclic Data
Exchange service is assigned to the Controller-Drive Unit and the Drive Unit Drive Unit
relationship. A Cyclic Data Exchange channel is related to a Communication Object at its end
points.
2.2.7.3 Acyclic Data Exchange
Compared to cyclic communication, data is exchanged acyclically only if necessary. Via

acyclic communication, not time critical data is transferred, for example the download of
firmware or parameter data. The Acyclic Data Exchange service is assigned to the
Controller-Drive Unit and the Supervisor-Drive Unit relationship. An Acyclic Data Exchange
channel is related to a Communication Object at its end points.
2.2.7.4 Alarm Mechanism
With the Alarm Mechanism service, alarm information and exception situations are signalled
to the controlling device in a real time manor. The service is working demand-oriented to keep
the exception status image of the Functional Object in the Controller up to date. With this
service the controller is able to respond on an occurring event in the drive as fast as possible
without polling the drive status information permanently by its own. The Alarm Mechanism
service is assigned to the Controller-Drive Unit relationship.

Content Start
Version 4.0
2.2.7.5 Clock Synchronous Operation
The Clock Synchronous Operation service guaranties the start of tasks on different
communication Devices or Functional Objects at the same time with minimum (specified) jitter
(e.g. the sampling and output processes). Also this service implies, that dedicated cyclic data
packages are definitely transmitted until a certain moment in the communication cycle.
For drive technology, clock cycle synchronous communication is the basis for drive
synchronization. Not only message interchange on the bus system is implemented in an
isochronous time base, but also the internal control algorithms - such as closed loop speed
and current controllers in the drive, or the controller in the higher level automation system -
are synchronized.
Controller Application Pos. Contr.

C1 C2 C3
R1 = drive closed loop control task
CX = controller task
Data flow
Actual Value Setpoint
Transfer Transfer
Communication Cyclic Acyclic Cyclic

spare Data Exchange Data Exchange spare Data Exchange
Cycle (timing)
Setpoint
Actual Value Transfer
Transfer
Data flow
Drive Unit
Application R1 R1 R1 R1 R1 R1 R1 R1

Acquisition Activation
Figure 7 Typical use case for Clock Synchronous Operation
The general model for the Clock Synchronous Operation service is defined according to
Figure 8. The model is based on local clocks which are related to every Device supporting the
Clock Synchronous Operation service. These local clocks are synchronized to one dedicated
Master Clock. After the Clock Synchronous Operation mechanism is started, all Slave Clocks
are synchronous to the Master Clock with a defined maximum Jitter of 1 microsecond. The
mechanism of start up and synchronization of the Slave Clocks to the Master Clock are
related to the Communication System (part of the Communication Layer).

Content Start
Version 4.0
The Device which comprises the Master Clock is defined as Clock Master. According to the
application, application tasks may be triggered by the Slave Clock of the Device. E.g.
concerning an axis controller, the sampling of input values and the output of motor current are
triggered out of the Master Clock (see also Figure 7).
Device = Clock Master
Master Clock
Slave Slave
Clock Clock
Synchronize Synchronize
(trigger) ... (trigger)
Task Task Task Task

1 ... n 1 ... n
Drive Unit (DU) Drive Unit (DU)
Figure 8 General Model for Clock Synchronous Operation

Content Start
Version 4.0
2.2.7.6 Base Model State Machine
For the Base Model the following states, related to the communication and application run up
process, are defined (see also Figure 9):
Offline: There is generally no Communication Service working

Preparation: In this state the Acyclic Data Exchange service and the Alarm Mechanism is
working. This means, that configuration information may be passed from the Controller to
the Drive Unit and Parameter Access is possible. Also alarms will be forwarded. There
may be no Cyclic Data Exchange service or the transmitted Data is not valid. The
Communication System tries to synchronize all Slave Clocks to the Clock Master.
Synchronisation: In this state the Acyclic Data Exchange, the Cyclic Data Exchange and
the Alarm Mechanism are working and the transmitted cyclic data is valid. The application
processes try to synchronize their Tasks to each other (synchronize to the local Slave
Clock and synchronize the data streams via the cyclic communication channels.
Operation: In this state also the application processes are synchronized and the whole
application is ready to operate (productive work).
If in this states exceptions occur which drive the system to lose one or more of the
characteristics related to the actual state, the related Devices will be forced to go back to a
corresponding predecessor state, in order to proceed to switch forward to the next higher
level again if possible and allowed.
System State Characteristics

Communication Layer
Offline - no communication
abort / error
Preparation - acyclic communication active
- PZD (Process Data) not valid
- Alarm Mechanism running
abort / error
Synchronisation - acyclic communication active
- PZD (Process Data) valid
abort / error
Operation - acyclic communication
- PZD (Process Data) valid
- Tasks synchronized
- Controller and DO (Drive Object)
Life sign synchronized
Application Layer
Figure 9 Base Model State Machine

Content Start
Version 4.0
2.3 Drive Model
Based on the Drive Unit device type, defined in the Base Model previously, this chapter
defines the architecture of the Drive Unit more detailed.
2.3.1 Drive Unit
This profile of drive engineering defines a PROFIdrive Device of Drive Unit type according to
Figure 10 as a Drive Unit (DU) containing exactly one or multiple Drive Objects (DO).
The unambiguous identification of a Drive Object within a Drive Unit is done by the Drive
Object ID (DO-ID) which is assigned to every DO of a DU.
Drive Unit
(DU)
Drive Object Drive Object Drive Object
(DO) (DO) . . . (DO)
DO-ID=a DO-ID=b DO-ID=x
Figure 10 General Drive Unit model
2.3.2 Drive Object
Figure 11 shows the general Drive Object (DO) architecture. Central element of the DO is the
Process Control Task which is responsible for the automation functionality of the DO.
Properties of the DO and the Process Control Task are represented and controlled by
parameters. The parameters are administered in the Parameter Data Base. To access DO
parameter, Acyclic Data Exchange service is used. For periodic transportation of setpoint
values to the DO and actual values from the DO, the Cyclic Data Exchange service is used. If
the DO is of Axis type (refer to 2.3.3), the DO comprises a General State Machine, which
controls and represents the states of the Drive Process Control Task. Exception situations out
of the Process Control Task and the General State Machine may be signalled by the Alarm
Mechanism to the controlling device.
The DO shall comprise as minimum mandatory functionality:
Parameters
The DO may comprise as optional functionality:
Process Control Task

Process Data (setpoint value, actual values)
General State Machine (for Axis type DO mandatory)
Support for Alarm Mechanism

Content Start
Version 4.0
Acyclic Clock
Cyclic
Alarm Queue Data Exchange Synchronous
Data Exchange
Operation
transmit transmit
setpoint actual write read Master Clock
signal exception values values parameter parameter sync information
cyclically cyclically
Alarm Process Data Parameter Master Clock

Mechanism (PZD) Access Regeneration
sync/trigger
Setpoint Values Actual Values
Parameter
Process Control Task Data Base
(e.g. closed loop control, inverter, ...)
sync/trigger
Drive Object
External Process
(e.g. motor and mechanics)
Figure 11 General Drive Object architecture

Content Start
Version 4.0
2.3.3 Axis type Drive Object
The DOs may be of different type. One dedicated type, which is of general importance in this
drive profile is the Axis type, which is typically related to a motor (Drive Axis) and is specified
in detail in 1.
Identification Parameter Communication

Interface
Axis Type
Drive Object
HMI, Communication
Ctrl. Word
Status Word
Open Loop Control Diagnostics Messages
Closed Loop Control Monitoring Alarms

Interferences
Setp/Act.Vals.
Encoder Control Set I/O
Encoder Interface Peripherals
Figure 12 Principle functional model of an Axis type Drive Object
Figure 12 shows the principle functionality of an Axis type DO. The Axis DO consists out of
numerous function modules that work together internally, and therefore portray the
intelligence of the Axis type DO.
The following logical objects are included in an Axis DO:
Objects for DO identification

Parameters for accessing information and settings of the individual function modules
Objects for setting the communication interface (for example, PROFIdrive Interface)
Objects for drive control (for example, control words and status words)
Objects for setpoint processing (for example, setpoint values and actual values)
Objects for diagnostics and monitoring (for example, messages, alarms, faults)
Objects for integrated sensor interface(s)
Objects for integrated peripheral functions (integrated I/O)

Content Start
Version 4.0
2.3.4 Drive Unit classification
Figure 13 shows the three principle classes of PROFIdrive Drive Units. While the Single-Axis
type is one physical device with only one Axis type DO, the Multi-Axis type consists of several
similar Axis type DOs. The modular type provides the greatest flexibility and comprises one or
more DOs, which may be of different type.
1 Device 1 Device 1 Device

1 Axis (DO) Multiple similar Axis (DOs) Multiple different DOs
DO DO DO DO DO
type A type A type A type A type A DO DO
(Drive (Drive (Drive (Drive type B type D
(Drive DO
Axis) Axis) Axis) Axis) Axis) (Drive
Axis) type C
M M M M M M M
Single-Axis Multi-Axis Modular

Drive Unit Drive Unit Drive Unit
Figure 13 Classes of PROFIdrive Drive Units
Drive Unit communication model
Figure 14 shows the different communication channels which are available between the Drive
Unit and the other Devices. The color shows the Communication Service related to this
communication channel.
The Clock Synchronous Operation as well as Process Data transfer is available between
Drive Unit and Controller and between Drive Units itself. Parameter Access to the Drive Unit
is available from all other Controller and Supervisor Devices.

Content Start
Version 4.0
Controller
(e.g. PLC/NC for
Drive Control)
Supervisor
(e.g. PC for Start-up,
Maintenance and
Diagnosis)
Clock cycle
synchronous
Parameter-Access
Process Data communication
ss
c ce
ta r-A
Da mete
s r a
es Pa
oc
Pr
Cyclic communication
Drive Unit
(Device) Acyclic communication
Figure 14 Overview about the available Communication Services between the

PROFIdrive Devices
2.4 Application Model and Application Classes
Today, drive applications are realized in a multiple of ways. The table below defines the
different Application Classes where the drives are used. The Application Classes are typical
examples from the entire spectrum of electrical drive engineering.
The Application Model is part of the Application Layer and therefore only related to functional
aspects (Functional Objects), independent of the distribution of Functional Objects among
devices. Therefore the type of Application Class predefines the contents of the Functional
Objects and the type of data (Information) to be transported between the Functional Objects
(Interface).
Table 1 Application Classes
b
No. Application Class Interface Functions
a
1 Standard Drive n-setpoint, Cyclic interface
torque-setpoint,
current-setpoint
2 Standard drive with distributed Technological Cyclic Interface
technology controller setpoint-actual values with
a
(command variables) Cyclic Data Exchange between DU
(continuous process)
a
3 Single Axis positioning drive, with pos-setpoint, Cyclic interface
local Motion Control
run requests
4 Motion Control with central n-setpoint Cyclic interface, Clock Synchronous
interpolation and speed setpoint Operation, DSC (refer to 4.5)
interface x-actual
Optional: additionally, for DSC:
DSC (Dynamic Servo Control) x (x err ), K V (k PC )

Content Start
Version 4.0
b
No. Application Class Interface Functions
5 Motion Control with central x-setpoint Cyclic interface, Clock Synchronous
c
interpolation and position setpoint Operation
interface
6 Motion control for clocked command variables, Cyclic interface, Clock Synchronous
processes, or distributed angular Operation,
synchronism motion instructions
Cyclic Data Exchange between DU
NOTE The Application Classes described here are assigned Profile functions in 4.13 which a drive
manufacturer shall implement if he wishes to be compliant with the particular Application Class.
a
The cyclic interface may also be operated clock-synchronously if, for example, it is a question of synchrony
of the actions in the case of several drives.
b
For all Application Classes: acyclic interface for parameters, diagnostics, identification
c
This Application Class is not described in this edition of the Profile. The dynamic characteristics of
Application Class 5 are reached with Application Class 4 with DSC.
2.4.1 AC 1: Standard Drive
In the simplest case, the drive is controlled via a primary setpoint (for example, speed
setpoint) (see Figure 15). The speed control is governed completely in the drive controller.
The PLC includes all technological functions for the automation process. The field bus is
merely the transmission medium between the automation system and the drive controller. The
Cyclic Data Exchange Communication Service is used. This type of application is used
primarily in the field of classical drive engineering (for example, conveyor systems). A PLC is
usually used as the automation system. Clock Synchronous Operation may be used but is
typically not necessary for this Application Class.
Application Class 1
Automation
Technology
Control Word + Speed Setpoint + ... Status Word + Speed Act. Val. + ...
Drive Drive Drive
Open Loop Speed Control/ Open Loop Speed Control/ Open Loop Speed Control/
/ losed Loop Speed Control
C / losed Loop Speed Control
C /
Closed Loop Speed Control
M Encoder
(optional)
M Encoder
(optional)
M Encoder
(optional)
Figure 15 Application Class 1

Content Start
Version 4.0
2.4.2 AC 2: Standard drive with distributed technology controller
Application Class 2 represents a very flexible version for implementing drive applications
(Figure 16). In this version, the automation process is broken down into many small sub-
processes.
The technology functions are no longer exclusively in the central PLC, but are also distributed
in the Drives. The communication interface serves as the technology interface. The data that
is exchanged via the bus system between the individual automation components and drive
controllers may be individually defined. This variant assumes, however, that communication is
guaranteed in all directions; that is, Process Data transfer should be possible also between
Drive Units. To realize applications like setpoint cascades, winders, and speed synchronism
Clock Synchronous Operation should be possible. The technology functions are realized in
the drive.
Application Class 2
Automation
Technology
Technological Requests, Setpoints... Technological Actual Values, Process States
Drive Drive Drive
Technology Technology Technology
Closed Loop Speed Ctrl. Closed Loop Speed Ctrl. Closed Loop Speed Ctrl.
Peripherals Peripherals Peripherals

(I/O) (I/O) (I/O)
M Encoder
M Encoder
M Encoder
(optional) (optional) (optional)

Content Start
Version 4.0
2.4.3 AC 3: Single Axis positioning drive with local Motion Control
In Application Class 3 (Figure 17), only the technology functions for the automation process
are still in the PLC. Positioning requests are stored in the Drive. A single positioning request
is started via command from the Controller (e.g. PLC). Interpolation and position control as
well as speed control are implemented directly in the drive. Since in this variant all time-
critical control algorithms are hidden in the drive controller, Clock Synchronous Operation is
only necessary if complex tracking for multiple axes shall be coordinated.
Application Class 3
Automation
Technology
Drive Request Drive Response

Positioning Ctrl.Word + ... Positioning Status Word + ...
Drive Drive
Interpolation Interpolation
Position Control Position Control
Closed Loop Speed Ctrl. Closed Loop Speed Ctrl.
M Encoder
M Encoder

Content Start
Version 4.0
2.4.4 AC 4: Motion Control with central interpolation and speed setpoint interface
Application Class 4 (Figure 18) shows the position closed loop control closed via the
Communication System. Drives for manipulator and robotic applications often require a
coordinated motion sequence of several drive systems. Motion control is primarily
implemented via a central automation unit (NC). For each drive, these controllers calculate
special setpoint profiles. By coordinating several drives (for example, for the XYZ axis),
certain trajectories may be implemented. In addition to the required technology functions for
the automation process, the automation system also includes the functions for interpolation
and position control of the drive. Speed setpoint values and actual values as well as the
position actual value are transferred via Cyclic Data Exchange. The drive controller
essentially only includes the algorithms for closed loop speed control and actual position
acquisition. Since the position is controlled via the bus system, Clock Synchronous Operation
is necessary and shall be very precise. Additionally, the DSC-functionality may be used to
increase the rigidity and dynamic response of the control loop.
Application Class 4
Automation
Technology
Interpolation
Position Control
Clock
Control Word + Speed Setpoint + ... Status Word + Actual Position...
Clock Synchronous
Operation Drive Drive Drive
M Encoder
M Encoder
M Encoder

Content Start
Version 4.0
2.4.5 AC 5: Motion Control with central interpolation and position setpoint interface
This Application Class is not dealt with in this PROFIdrive Profile Version. The dynamic
features of Application Class 5 may be achieved with Application Class 4 and DSC.
Application Class 5
Automation
Technology
Interpolation
Clock
Contr. Word + Position Setpoint + ... Status Word + Actual Position.....
Clock Synchronous
Operation
Drive Drive Drive
Position Control Position Control Position Control
M Encoder
M Encoder
M Encoder

Content Start
Version 4.0
2.4.6 AC 6: Motion Control for clocked processes, or distributed angular

synchronism
To realize applications like electric gearing, cam disc, angular synchronous operation, flying
saw, Cyclic Data Exchange and Clock Synchronous Operation between Devices is necessary.
These applications are normally realized with one master drive and several slave drives. The
term master drive means in this context that one drive axis provides process information (for
example position actual value) to the other drives. Thereupon, the slave drives coordinate
their own motion process with the process information of the master drive.
Application Class 6
Automation
Technology
Clock *
Technological Requests, Setpoints... Technological Actual Values, Process States
Clock Synchronous
Operation
Drive Drive Drive
Technology Technology Technology
Interpolation Interpolation Interpolation

Position Control Position Control Position Control
Peripherals Peripherals Peripherals

(I/O) (I/O) (I/O)
M Encoder
M Encoder
M Encoder

Content Start
Version 4.0
3 Parameter model
3.1 Parameter definition
A parameter represents an information memory that consists of the following elements:
Table 2 Parameter definition
Parameter value (PWE) Includes the information variable(s)

(refer to 3.1.1)
Parameter description (PBE) Specifies a parameter
(refer to 3.1.2)
Text Is used to support visualization and contains a general
description on the parameter function or on the parameter
(refer to 3.1.3) value
The total of all parameters of a drive uniquely describes its behaviour or characteristics.
A parameter number is assigned to each parameter. The number range of the parameters is
specified for decimal 1-65535. The parameter 0 is not permitted. Profile-specific parameters
are specified or reserved for the ranges decimal 900-999 and decimal 60000 65535 (refer to
5). The Profile-specific parameters have to be implemented exactly according to the definition
in 5, even if a parameter description is implemented in the drive.
Access to the parameters (parameter value, parameter description or text) is explained in 3.4
and [10].
3.1.1 Parameter value
The parameter value contains a single (simple variable) or several similar (array) information
variables.
An array consists of n elements of the same data type which may be individually addressed
with sub-indices from 0 to n-1.
3.1.2 Parameter description
The parameter description contains relevant information about the respective parameter.
Table 3 shows the structure of the parameter description which will be discussed in the
course of this chapter.
Table 3 Parameter description elements
Subindex Meaning Data type (refer to 3.2)
1 Identifier (ID) V2
2 Number of array elements or length of string Unsigned 16
3 Standardization factor Floating Point
4 Variable attribute OctetString 2
5 Reserved OctetString 4
6 Name VisibleString 16
7 Low limit OctetString 4

Content Start
Version 4.0
Subindex Meaning Data type (refer to 3.2)
8 High limit OctetString 4

9 Reserved OctetString 2
10 ID extension V2
11 PZD reference parameter Unsigned 16
12 PZD normalization V2
0 Complete description OctetString 46
Identifier (ID) (subindex 1)
Additional characteristics of the parameter are stored in the ID.
Bit value = 0 means: parameter does not possess this attribute.
Bit value = 1 means: parameter possesses this attribute ".
Table 4 Parameter description element "Identifier (ID)"
Bit Meaning Explanation
0-7 Data type of the parameter value (index from

Table 10)
8 Standardization factor and variable attribute This bit is set, if parameters have data types to which
not relevant physical values may not be calculated, for example the
data type string.
9 Parameter not writeable
10 Additional text array available
11 Reserved
12 Parameter was changed with respect to the This bit is set, if the parameter value is unequal to the
factory setting factory setting. It is reset, if the parameter value is
equal to the factory setting.
13 Parameter value may be reset only If this bit is set, the associated parameter value is
increased exclusively by internal processing while
externally it may only be set to 0 (for example, time
differences).
14 Array
15 Reserved
Number of array elements res. string length (subindex 2)
In the case of array parameters, the number of elements is entered here. In the case of
parameters of the data type String, the length of the string is entered here. The data types
OctetString or VisibleString correspond to an array of bytes. It is not possible to form an array
of the data type String.
Standardization factor (subindex 3)
Factor that converts the (internal) value into an (external) standardized variable which,
together with the unit, corresponds to the physical representation of the parameter. The
standardization factor is of the data type Floating Point.

Content Start
Version 4.0
Variable attribute (subindex 4)
A variable index and a conversion index are stored in the variable attribute (refer to [10]):
Table 5 Parameter description element "variable attribute
Octet 1 Octet 2
variable index Conversion index

(Factor A, Offset B)
The variable index represents the fixed coding of the physical variable (and therefore the
base unit) of the parameter value. The variable index is of the data type Unsigned 8.
The conversion index represents the fixed coding of the conversion factor (A) and the offset
(B) for a parameter value. With the conversion index, the unit may be converted into the base
unit. The conversion index is of the data type Integer 8.
EXAMPLE variable attribute = 13 / -3 (0x0DFD)
Variable index = 13 -> physical variable speed, basic unit meter/second

Conversion Index = -3 -> unit millimeter/second (factor A=0.001, offset B=0)
Examples: External representation (by means of standardization factor, Variable

attribute)
The following applies:
Physical value (in the unit) = transmitted value * standardization factor * unit
or
Physical value (in the base unit) = (transmitted value * standardization factor * A + B) * base unit
Coding for the variable index and the conversion index (Factor A, Offset B; refer to [10]):
EXAMPLE 1
Data Type: Integer 16

Transmission Value: 500
Standardization Factor: 1.0
Variable Index: 21 -> physical variable "Electrical Voltage", base unit Volt
Conversion Index: -3 -> unit "Millivolt" (Factor A=0.001, Offset B=0)
-> Physical Value (in the unit) = 500 * 1.0 mV = 500 mV

-> Physical Value (in the base unit) = (500 * 1.0 * 0.001 + 0) V = 0.5 V

Content Start
Version 4.0
EXAMPLE 2
Data Type: Unsigned16

Standardization Factor: 0.01
Variable Index: 13 -> physical variable "Speed, base unit Meter/Second
Conversion Index: 73 -> unit "Kilometer/Hour" (Factor A=1000/3600, Offset B=0)
-> Physical Value (in the unit) = 1234 * 0.01 km/h = 12.34 km/h
-> Physical Value (in the base unit) = (1234 * 0.01 * 1000/3600 + 0) m/s = 3.428 m/s
EXAMPLE 3
Data Type N2 -> 100 % corresponds to 214 (refer to [10]).

Standardization Factor: 0.0061 (100 / 214)
Variable Index: 24 -> physical variable "Ratio", base unit Percent
Conversion Index: 0 -> unit = base unit "Percent" (Factor A=1, Offset B=0)
-> Physical Value = 8043 * 0.0061 % = 49.1 %
NOTE In the case of the data types N2, N4 / X2, X4 / optional Integer16, Integer32, Floating Point (normalized
variables), the unit % may be converted to another physical unit by assigning a physical reference parameter (see
below, Description Element PZD Reference Parameter).
Name (subindex 6)
Name describes the symbolic name of the parameter. The name is of the data type
VisibleString with a length of 16.
Low/high limit (subindices 7 and 8)
Low/high limit defines the valid value range of the parameter value.
The drive rejects an attempt to assign a value outside of the parameters value range. The low
and the high limit are of the same data type as the parameter value, but the length of the
description elements is always 4 bytes (file format: right justified, big endian). For parameters
whose data types permit no value range (for example, VisibleString), the contents of these
description elements are of no importance.
ID extension (subindex 10)
The ID extension is reserved.

Content Start
Version 4.0
PZD reference parameter / PZD normalization (subindices 11 and 12)
Parameter values may also be transmitted as process data (refer to 4.4.3). If normalized
variables (data types N2, N4 / X2, X4 / optional Integer16, Integer32, Floating Point) are
transmitted, the following is necessary for calculating the physical value: the physical
reference value (process data reference value), and the bit (refer to Process Data
Normalization) to which the physical reference value refers. For a calculation example, refer
to 4.4.4.
For parameters of the data type X2, X4, the description elements PZD reference parameter
and PZD normalization shall be available.
For parameters of the data type N2, N4, the description elements PZD reference parameter
shall be available, and the description element PZD normalization is optional as it is defined
by the data type.
If parameters of data type Integer16, Integer32 or Floating Point are transmitted as

normalized process data (with unit "%") the description elements PZD reference parameter
and PZD normalization shall be available. If they are transmitted as non-normalized, these
description elements shall not be available.
In the case of all other data types these description elements are not relevant.
Table 6 Parameter Description Elements Process Data Reference Value/Process Data

Normalization
Description Element Content
PZD reference parameter 0 No reference value available

1-65535 Parameter number of the reference value
PZD normalization Bit 0-5 Normalization bit 0-31 (32-63 is reserved)
Bit 6-14 reserved
Bit 15 Normalization valid
NOTE 1 For the parameters with data type N2, N4, the coding of the normalization bit is fixed (14 and
30)
NOTE 2 For the normalized parameters with data type Floating Point, the coding of the normalization
bit is not relevant (=0).
NOTE 3 The combination no reference value exists/ normalization valid is permissible.
NOTE 4 Parameters that are used for reference values are not to be normalized.
NOTE 5 If the complete parameter description is read out with one access, the description elements
shall be included (see below).
Complete description (subindex 0)
The complete description includes a total field of 46 bytes (corresponding to the complete
parameter description structure). This length is the constant for each parameter (regardless of
the data type, etc.).

Content Start
Version 4.0
3.1.3 Text
Text from a text array may be assigned to a parameter as an additional explanation or

description. An indexed text line has a length of 16 bytes.
Table 7 Text array for parameter description
Subindex text array Text
0 Text 0 (16 bytes)

1 Text 1 (16 bytes)
2...n Text 2...n (16 bytes each)
The existence of a text array is marked within the parameter description (ID: additional text
array available). The text is stored in the object type array of the data type VisibleString 16
assigned to the parameter. Text arrays may be assigned to parameters of the object type
array (with any data type), or to parameters of the object type simple variable (with data
type Unsigned8/16/32, Boolean, or V2). The individual texts of a text array are assigned
to the array elements for parameters of the type array, and assigned to the values for
parameters of the type simple variable.
Array parameter text array
Subindex text array == Subindex array parameter
Unsigned8/16/32 text array
Subindex text array == parameter value
0 Parameter value 65535
Boolean text array
Number of texts = 2
Table 8 Text array for the data type Boolean
Subindex text array Parameter value
0 "false"
1 "true"
V2 text array
Number of texts = 32
To each bit of the bit sequence two texts are assigned, one each to the bit value 0 and 1.
Subindex Text Array == Bit Position * 2 + Bit Value
0 (LSB) Bit Position 15 (MSB), 0 Bit Value 1;

Content Start
Version 4.0
Table 9 Text array for data type V2 (bit sequence)
Subindex text array Parameter value
0 -------- -------0
1 -------- -------1
2 -------- ------0-
3 -------- ------1-
4 -------- -----0--
: :
30 0------- --------
31 1------- --------
3.2 Data types
3.2.1 Data types overview
Profile-specific data types are defined corresponding to the particular drive requirements. The
profile-specific data types are individually defined in [10]. The standard types are defined in
[10]. An overview of all of the permissible data types (standard data types and profile-specific
data types) and their coding is given in Table 10.
Table 10 Data types
Coding Data type Comment Implementation /

shall be supported
(decimal)
1 Boolean Standard data type optional

2 Integer8 Standard data type optional
5 Unsigned8 Standard data type mandatory
8 FloatingPoint Standard data type optional
9 VisibleString Standard data type optional
10 OctetString Standard data type optional
12 TimeOfDay (with date indication) Standard data type optional
13 TimeDifference Standard data type optional
...
50 Date Standard data type optional
52 TimeOfDay without date indication Standard data type optional
53 TimeDifference with date indication Standard data type optional
54 TimeDifference without date indication Standard data type optional
...
113 N2 Normalized value (16 bit) Profile-specific data type optional
114 N4 Normalized value (32 bit) Profile-specific data type optional
115 V2 Bit sequence Profile-specific data type optional
116 L2 Nibble Profile-specific data type optional
117 R2 Reciprocal time constant Profile-specific data type optional
Content Start
Version 4.0
Coding Data type Comment Implementation /

shall be supported
(decimal)
118 T2 Time constant (16 bit) Profile-specific data type optional

119 T4 Time constant (32 bit) Profile-specific data type optional
120 D2 Time constant Profile-specific data type optional
121 E2 Fixed point value (16 bit) Profile-specific data type optional
122 C4 Fixed point value (32 bit) Profile-specific data type optional
123 X2 Normalized value, variable (16 bit) Profile-specific data type optional
124 X4 Normalized value, variable (32 bit) Profile-specific data type optional
...
NOTE The standard data types specified in [10] and their coding are up-to-date according to this profile
edition. However, they will still be revised. The latest version of [2] should be consulted to get the most up-to-
date status.
3.2.2 Profile-specific data types
To allow drive applications with none of the profile-specific data types:
Instead of N2, N4 / X2, X4 use Integer16, Integer32 with optional normalization.
Normalized value: N2, N4

Meaning: Linear normalized value. 0% corresponds to 0 (0x0), 100% corresponds to 2 14
(0x4000) for N2 or 2 30 (0x4000 0000) for N4.
Range of values:
Coding Data type Range of values Resolution Length

-14 -14
113 N2 -200 % i (200-2 )% 2 = 0.0061 % 2 Octet
-30 -8
114 N4 -200 % i (200-2 -30 ) % 2 = 9.3 * 10 % 4 Octet
Coding: Representation in two's complement, the MSB (Most Significant Bit) is the bit
after the sign bit (SN) of the first octet.
SN = 0: positive numbers including zero

SN = 1: negative numbers
Bit 8 7 6 5 4 3 2 1
Octet 1 SN 20 2 -1 2 -2 2 -3 2 -4 2 -5 2 -6
:
:
-23 -24 -25
Octet 4 2 2 2 2 -26 2 -27 2 -28 2 -29 2 -30

Content Start
Version 4.0
Normalized value (variable normalization): X2, X4

Meaning: Linear normalized value. 0% corresponds to 0 (0x0), 100% corresponds to 2 X .
The structure is the same as for data types N2 and N4, but the normalization
(100 %) does not automatically refer to bit 14 or bit 30 respectively, but is
variable. The normalization bit is coded in the parameter description element
PZD normalization (refer to 3.1.2).
Range of values:

-12
123 X2 (e.g. with x = 12) -800 % i (800-2 -14 ) % 2 2 Octet
-30 -28
124 X4 (e.g. with x = 28) -800 % i (800-2 )% 2 4 Octet
Coding: Two's complement representation, the MSB (Most Significant Bit) is the bit

Bit 8 7 6 5 4 3 2 1
0 -1 -2 -3 -4 -5
Octet 1 SN 2 2 2 2 2 2 2 -6
:
:
-23 -24 -25
Octet 4 2 2 2 2 -26 2 -27 2 -28 2 -29 2 -30
Fixed point value: E2

Meaning: Linear fixed-point value with seven binary places after the decimal point. 0
corresponds to 0 (0x0), 128 corresponds to 2 14 (0x4000).
Range of values:

121 E2 -256+2 -7 i 256-2 -7 2 -7 = 0.0078125 2 Octet
Coding: Two's complement representation, the MSB (Most Significant Bit) is the bit

Bit 8 7 6 5 4 3 2 1
7 6 5 4 3 2
Octet 1 SN 2 2 2 2 2 2 21
Octet 2 20 2 -1 2 -2 2 -3 2 -4 2 -5 2 -6 2 -7

Content Start
Version 4.0
Fixed point value: C4

Meaning: Linear fixed point value with four decimal places. 0 corresponds to 0 (0x0),
0.0001 corresponds to 2 (0x0000 0001).
Range of values:

-4
122 C4 214748.3648 i 214748.3647 10 = 0.0001 4 Octet
Coding: As by Integer32, weighting of the bits has been reduced by a factor of 10000.
Bit sequence: V2
Meaning: Bit sequence to control and represent application functions. 16 Boolean
variables are combined in two octets. (Coding: 115)
Coding: Binary
Bit 8 7 6 5 4 3 2 1
Octet 1 15 14 13 12 11 10 9 8
Octet 2 7 6 5 4 3 2 1 0
Nibble: L2
Meaning: Four associated bits form a nibble. Four nibbles are represented in two octets.
The definition of the nibble is not specified. (Coding: 116)
Coding: Binary
Bit 8 7 6 5 4 3 2 1
Octet 1 Nibble 3 Nibble 2
Octet 2 Nibble 1 Nibble 0
Comment regarding time parameters

The value of time parameters of types D2, T2, T4, R2 always refer to the specified constant
sampling time T a . The associated sampling time (value of profile parameter 962) is required in
order to interpret the internal value.

Content Start
Version 4.0
Time constant: T2, T4

Meaning: Time data as a multiple of constant sampling time T a .
Range of values:
Coding Data type Range of values Resolutio Length

n
118 T2 0 i 32767 * Ta 2 Octet
Ta
119 T4 0i Ta 4 Octet
4294967295* T a
Interpreted value = Internal value * T a
Coding of internal value: T2: As by Unsigned16 with a restricted Range of values 0 x

32767.
When interpreted, internal values outside this range are set to 0.
T4: As by Unsigned 32.
Time constant: D2
Meaning: Time data as a fraction of the constant sampling time T a .
Range of values:

-14 -14
120 D2 0 i (2-2 ) * Ta 2 * Ta 2 Octet
Interpreted value = Internal value * T a /16384
Coding of internal value: As by Unsigned16 with a restricted Range of values 0 x

32767.
When interpreted, internal values outside this range are set to 0.
Reciprocal time constant: R2

Meaning: Time data as a reciprocal multiple of a constant sampling time T a .
Range of values:

117 R2 1 * T a i 16384 * T a Ta 2 Octet
Interpreted value = 16384 * T a /internal value
Coding of internal value: As by Unsigned16 with a limited Range of values 1 x 16384.

When interpreted, internal values outside this range are set to
16384.

Content Start
Version 4.0
3.3 Global and Local Parameters
As defined in 2.3 and 4.4.3, a Drive Unit consists out of the drive device itself and one or
several Drive Objects (DO). The drive axes are related to Axis type DOs.
For Multi-Axis and Modular Drive Units, each DO has a dedicated parameter number space.
Two types of parameters with different ranges of values are defined in the profile:
global parameter:
Global parameters are related to the complete device (for example communication
interface related parameters). If addressing different DOs of a Drive Unit, a global
parameter will always specify the same value.
DO/axis-specific parameters:
These parameters are related to the Drive Object. The DO/axis-specific parameters may
have different values in every Axis DO (for example parameter 967 "control word1").
The subdivision of the parameters into global and DO/axis-specific parameters is shown in 5.
Figure 21 shows an example with global parameter 918 "node address" and the axis-specific
parameter 944 "fault message counter" for a Multi-Axis or Modular Drive Unit. A Single-Axis
Drive Unit is similar to the Multi-Axis Drive Unit but only the DO1 is present.
Multi -Axis/Modular Drive Unit
DO 1 (e.g. Axis) DO 2 (e.g. Axis) DO 3 (e.g. Axis) DO n (e.g. Axis)
PNU Value PNU Value PNU Value PNU Value
1 ... 1 ... 1 ... 1 ...
2 ... 2 ... 2 ... 2 ...
918 3 918 3 918 3 918 3
944 12 944 3 944 7 944 4
... ... ... ... ... ...
... ... ... ... ... ...
Figure 21 Example overview of global and local parameters of a Multi-Axis/Modular

Drive Unit
The value range of the DO-ID numbers range from 0-254. With the DO-ID 0 the drive device
itself may be addressed (device representative, no axis) and the global parameters may be
read. The assignment of the drive axis numbers to the DOs is device-specific and may be
read out of parameter P978" list of module IDs" (refer to 4.4.3).
The addressing is described in 3.4.

Content Start
Version 4.0
3.4 Base Mode Parameter Access
In this chapter the access to parameters via the Base Mode is defined. A request language
will be defined for the access. The requests and the replies are transmitted acyclically by use
of the Acyclic Data Exchange mechanism of the Communication System.
The Base Mode Parameter Access exists because of compatibility reasons due to former
PROFIdrive profile and every drive shall be able to handle the Base Mode Parameter Access
(mandatory).
3.4.1 General characteristics

16-bit wide address each for parameter number and subindex.
Transmission of complete arrays or parts of them, or the entire parameter description.
Transmission of different parameters in one access (multi-parameter requests).
Always just one parameter request is being processed at a time (no pipelining).
A parameter request/parameter response has to fit in a data block (240 bytes max.) The
requests/replies are not split-up over several data blocks. The maximum length of the data
blocks may be less than 240 bytes depending on slave characteristics or bus
configuration.
No spontaneous messages will be transmitted.
For optimized simultaneous access to different parameters (for example, operator
interface screen contents), multi-parameter requests will be defined.
There are no cyclic parameter requests.
After run-up, the profile-specific parameters shall be at least readable in every state.
3.4.2 DO addressing modes
The Base Mode Parameter Access is defined with two different DO address modes according
to the following definition:
Base Mode Parameter Access Local: In this address mode only the local parameters of
the DO are accessable to which the CO, where the parameter access point is attached, is
related. The DO-ID in the parameter request is used for consistency check when
accessing local parameters of the DO. A successful access to the local parameters of the
DO is only possible, when the correct DO-ID, corresponding to the Slot number, is entered
in the parameter request header. Otherwise the DO parameter manager shall respond with
error code 0x19 Axis/DO nonexistent (see Table 15). For access of global parameters
the DO-ID in the parameter request header is dont care.
Base Mode Parameter Access Global: In this address mode all parameters of the Drive
Unit are accessable to which the CO, where the parameter access point is attached, is
related. The DO-ID in the parameter request is used for accessing of local parameters
inside the Drive Unit. For access of global parameters the DO-ID 0 should be used. This
address mode is for compatibility reasons (PROFIBUS) and should not be used by new
PROFINET IO Controller and Supervisor application processes.

Content Start
Version 4.0
3.4.3 Parameter requests and parameter responses
A parameter request consists of three segments:
Request header: ID for the request and number of parameters which are accessed. Multi-
Axis and Modular drives, Addressing of one DO.
Parameter address: Addressing of a parameter. If several parameters are accessed, there
are correspondingly many parameter addresses. The parameter address appears only in
the request, not in the response.
Parameter value: Per addressed parameter, there is a segment for the parameter values.
Depending on the request ID, parameter values appear only either in the request or in the
reply.
Words and double words:
The following telegram contents are displayed in words (a word or 2 bytes per line). Words or
double words will have the most significant byte being transmitted first (big endian).
Word: Byte 1 Byte 2
Double word: Byte 1 Byte 2

Byte 3 Byte 4
According to the Base Mode Parameter Access the structure of the parameter request and
parameter response is shown in Table 11 respectively Table 12.
Table 11 Base mode parameter request
Request Header Request Reference Request ID 0

Axis-No. / DO-ID No. of Parameters = n 2
st
1 Parameter Address Attribute No. of Elements 4
Parameter Number (PNU)
Subindex
th
n Parameter Address ... 4 + 6 * (n-1)
st
1 Parameter Value(s) Format No. of Values 4+6*n
(only for request Values
"Change parameter") ...
th
n Parameter Values ...
4 + 6 * n +...+ (Format_n *
Qty_n)

Content Start
Version 4.0
Table 12 Base mode parameter response
Response Header Request Ref. mirrored Response ID 0

Axis-No. / DO-ID mirrored No. of Parameters = n 2
st
1 Parameter Value(s) Format No. of Values 4
(only after request Values or Error Values
"Request") ...
th
n Parameter Values ...
4 + ... + (Format_n * Qty_n)
Meaning of the fields:
Request Header:
Request Reference
Unique identification of the request/response pair for the master. The master changes the
request reference with each new request (for example, modulo 255). The slave mirrors the
request reference in the response.
Request ID
two IDs are defined:
Request parameter
Change parameter
A parameter change may be stored either in volatile or non-volatile RAM according to the
device. A changed parameter that is stored in volatile RAM first may be stored in ROM
with parameter P971. The differentiation Value/Description/Text is added to the address
as attribute. The differentiation Word/Double Word is added to the parameter values as
format. For the differentiation Single/ Array Parameter, refer to No. Of Elements in the
parameter address.
Response ID:
Mirroring of the request ID with supplement information whether the request was executed
positively or negatively.
Request parameter positive
Request parameter negative (it was not possible to execute the request, entirely or
partially)
Change parameter positive
Change parameter negative (it was not possible to execute the request, entirely or
partially)
If the response is negative, error numbers are entered per partial response instead of
values.
Axis-No. / DO-ID:
For Base Mode Parameter Access Local: Used for consistency check. If the DO-ID in
this field does not match the DO-ID of the DO, this PAP is related to, the DO parameter
manager shall respond with error code 0x19 Axis/DO nonexistent (see Table 15). For
access of global parameters the DO-ID in the parameter request header is dont care.
For Base Mode Parameter Access Global: DO addressing information used for Multi-
Axis or Modular drives. This enables various axes / DOs to be able to be accessed each
with a dedicated parameter number space in the drive via the same PAP. See also 3.4.2.

Content Start
Version 4.0
No. of Parameters:
In the case of multi-parameter requests, specifying the number of the following Parameter
Address and/or Parameter Value areas. For single requests the No. of parameters = 1.
Value range 1 ... 39 (limitation because of PROFIBUS DPV1 telegram length).
Notice, that for a multi-parameter request the PROFIdrive Drive Unit shall arrange the
parameter value areas in the response message in the same order than in the
corresponding multi-parameter request message.
Parameter Address:
Attribute:
Type of object which is being accessed. Value range:
Value
Description
Text
Number of Elements:
Number of array elements that are accessed or length of string which is accessed.
Value range: 0, 1..234
Limitation because of PROFIBUS DPV1 telegram length.
Special Case Number of Elements = 0:
If values are accessed: recommended for non-indexed parameters.
Parameter Number:
Addresses the parameter that is being accessed. Value range: 1..65535.
Subindex:
Addresses the first array element of the parameter or the beginning of a string access or
the text array, or the description element that is being accessed. Value range: 0..65535.
Parameter Value:
Format:
Format and number specify the location in the telegram to which subsequent values are
assigned.
Value range:
Zero (without values as positive partial response to a change request)
Data type (refer to [10])
Error (as negative partial response)
Instead of a data type, the following are possible:
Byte (for description and texts)
Word
Double word
Number of Values:
Number of the following values or number of the following data type elements (number of
octets in case of OctetString). In case of write request of OctetString the correct length
shall be supplied otherwise the drive shall responds with error 0x18, number of values
are not consistent (see Table 15).

Content Start
Version 4.0
Values:
The values of the parameter
If the values consist of an odd number of bytes, a zero byte is appended in order to secure
the word structure of the telegrams.
In the case of a positive partial response, the parameter value contains the following:
Format = (Data Type or Byte, Word, Double Word)

Number of values
the values
In the case of a negative partial response, the parameter value contains the following:
Format = error
No. of values = 1
Value = error value = error number
In the case of a negative response, the parameter value may contain the following:
Format = error
No. of values = 2
Value 1 = Error Value 1: error number
Value 2 = Error Value 2: subindex of the first array element where the error occurs
(Purpose: after a faulty write access to an array, not all values shall be repeated).
In the case of a positive partial response without values, the parameter value contains the
following:
Format = zero
Number of values = 0
(no values)
Not all combinations consisting of attribute, number of elements, and subindex are permitted
(refer to Table 13).
A parameter which is not indexed in the profile may be realized with indices in the Drive Unit,
if the response to a Parameter Access is profile-specific.
Table 13 Permissible combinations consisting of attribute, number of elements and

subindex (see also [10])
Attribute No. of Subindex => Data

Elements
Value 0 0 The value

(single parameter)
1 0 The value
(Indexed parameter) 1 0...n One value, under subindex
a
2...n 0...n Several values, starting with Subindex

Content Start
Version 4.0
Attribute No. of Subindex => Data

Elements
Description 0 0 The entire description

(irrelevant)
1 1...n One description element
Text (from text array) 1 0...n One text (16bytes), under subindex
2...n 0...n Several texts, starting with subindex
a
If the number of elements available in the device does not match with the number of elements which
are requested or shall be changed, an error shall be output.
3.4.4 Coding
Table 14 Coding of the fields in parameter request/parameter response of Base Mode

Parameter Access
Field Data Type Values Comment
Request Reference Unsigned8 0x00 reserved

0x01..0xFF
Request ID Unsigned8 0x00 reserved
0x01 Request parameter
0x02 Change parameter
0x03..0x3F reserved
0x40..0x7F manufacturer-specific
0x80..0xFF reserved
Response ID Unsigned8 0x00 reserved
0x01 Request parameter(+)
0x02 Change parameter(+)
0x03..0x3F reserved
0x40..0x7F manufacturer-specific
0x80 reserved
0x81 Request parameter(-)
0x82 Change parameter(-)
0x83..0xBF reserved
0xC0..0xFF manufacturer-specific
Axis / DO-ID Unsigned8 0x00 Device-Representative Zero is not a DO but the access
to the device representative
0x01..0xFE DO-ID-Number 1..254 (PROFIBUS only)
0xFF reserved
No. of Parameters Unsigned8 0x00 reserved Limitation through DPV1
0x01..0x27 Quantity 1..39 telegram length
0x28..0xFF reserved
Attribute Unsigned8 0x00 reserved The four less significant bits are
0x10 Value reserved for (future) expansion
0x20 Description of No. of elements to 12bits
0x30 Text
0x40..0x70 reserved
0x80..0xF0 manufacturer-specific
No. of Elements Unsigned8 0x00 Special Function Limitation through compatibility
0x01..0xEA Quantity 1..234 with PROFIBUS DPV1 telegram
0xEB..0xFF reserved length
Parameter Number Unsigned16 0x0000 reserved
0x0001... Number 1.. 65535
0xFFFF

Content Start
Version 4.0
Field Data Type Values Comment
Subindex Unsigned16 0x0000... Number 0..65534

0xFFFE
Format Unsigned8 0x00 reserved Every slave shall at least
support the data types Byte,
0x01..0x36 Data types Word and Double Word
0x37..0x3F reserved (mandatory).
Write requests by the master
0x40 Zero preferably use the correct data
0x41 Byte types (refer to 3.2). As
0x42 Word substitute, Byte, Word or
0x43 Double word Double Word are also possible.
0x44 Error The master shall be able to
interpret all values/data types.
0x45.. 0xFF reserved
No. of Values Unsigned8 0x00..0xEA Quantity 0..234 Limitation because of 240 Bytes
0xEB..0xFF reserved Datablock size
(compatible with former
PROFIdrive version 3.1.2)
Error Number Unsigned16 0x0000... Error Numbers The more significant byte is
0x00FF (see Table 15) reserved
The device shall output an error, if reserved values are accessed.
Table 15 Error numbers in Base Mode parameter responses
Error No. Meaning Used at Supplem. Info
0x00 Impermissible parameter number Access to unavailable parameter 0

0x01 Parameter value cannot be changed Change access to a parameter value that Subindex
cannot be changed
0x02 Low or high limit exceeded Change access with value outside the Subindex
value limits
0x03 Faulty subindex Access to unavailable subindex of array Subindex
parameter. Shall not be used for non
array parameters
0x04 No array Access with subindex to non-indexed 0
parameter
0x05 Incorrect data type Change access with value that does not 0
match the data type of the parameter
0x06 Setting not permitted (may only be Change access with value unequal to 0 Subindex
reset) where this is not permitted
0x07 Description element cannot be Change access to a description element Subindex
changed that cannot be changed
0x08 reserved (PROFIdrive Profile V2: PPO-Write -
requested in IR not available)
0x09 No description data available Access to unavailable description 0
(parameter value is available)
0x0A reserved (PROFIdrive Profile V2: Access group -
wrong)
0x0B No operation priority Change access without rights to change 0
parameters
0x0C reserved (PROFIdrive Profile V2: wrong password) -
0x0D reserved (PROFIdrive Profile V2: Text cannot be -
read in cyclic data transfer)
0x0E reserved (PROFIdrive Profile V2: Name cannot be -
read in cyclic data transfer)
0x0F No text array available Access to text array that is not available 0
(parameter value is available)

Content Start
Version 4.0
Error No. Meaning Used at Supplem. Info
0x10 reserved (PROFIdrive Profile V2: No PPO-Write ) -

0x11 Request cannot be executed Access is temporarily not possible for 0
because of operating state reasons that are not specified in detail
0x12 reserved (PROFIdrive Profile V2: other error) -
0x13 reserved (PROFIdrive Profile V2: Data cannot be -
read in cyclic interchange)
0x14 Value impermissible Change access with a value that is within Subindex
the value limits but is not permissible for
other long-term reasons (parameter with
defined single values)
0x15 Response too long The length of the current response 0
exceeds the maximum transmittable
length
0x16 Parameter address impermissible Illegal value or value which is not 0
supported for the attribute, number of
elements, parameter number or subindex
or a combination
0x17 Illegal format Write request: Illegal format or format of 0
the parameter data which is not supported
0x18 Number of values are not consistent Write request: Number of the values of 0
the parameter data do not match the
number of elements in the parameter
address
0x19 Axis/DO nonexistent Access to an Axis/DO which does not 0
exist
0x20 Parameter text element cannot be Change access to a parameter text Subindex
changed element that cannot be changed
...
up to 0x64 reserved - -
0x65..0xFF Manufacturer-specific - -
In general, every PROFIdrive Drive Unit shall support Base Mode parameter read and write
requests with the data types, Byte, Word and Double Word (mandatory).
If the PROFIdrive Drive Unit supports also additional data types it shall behave in the
following manor:
In case of a parameter read request, it shall signal the corresponding data type in the read
response.
In case of a parameter write request it shall check the data type and signal an error if
parameter types dont match.
If the PROFIdrive Drive Unit doesnt support additional data types it shall behave in the
following manor:
It rejects the parameter write request with an error response if data types dont match.
The error numbers 0x00 ... 0x13 are taken from PROFIdrive Profile, Version 2. Values that
cannot be assigned are reserved for future use.

Content Start
Version 4.0
3.4.5 Telegram sequences for Parameter Access

Request parameter value, single
Parameter request:
Request header Request reference Request ID = 0

Request parameter
DO-ID = 0 No. of parameters = 1 2
Parameter address Attribute = Value No. of elements = 0 4

Parameter number
Subindex = 0 (irrelevant)
10
Parameter response positive with data of data type Word:
Response header Request ref. Mirrored Response ID = 0

Request parameter (+)
DO-ID mirrored No. of parameters = 1 2
Parameter value Format = Word No. of values = 1 4

Value 6
Parameter response positive with data of data type Double word:

Parameter value Format = Double word No. of values = 1 4

Value 6
10
Parameter response, negative:

Request parameter (-)
Parameter value Format = Error No. of values = 1 4

Error value 6

Content Start
Version 4.0
Change parameter value, single

Parameter request:

Change parameter

Parameter number
Subindex = 0 (irrelevant)

Value 12
14
Parameter response, positive:
Response header Request ref. mirrored Response ID = 0

Change parameter (+)

Change parameter (-)

Error value 6

Content Start
Version 4.0
Request parameter value, several array elements

Parameter request:

Request parameter

Parameter number
Subindex = 0
10


Value 1 6
Value 2
Value 3
Value 4
Value 5
16


Error value 6

Content Start
Version 4.0
Change parameter value, several array elements

Parameter request:

Change parameter

Parameter number
Subindex = 125

Value 1 12
Value 2
Value 3
Value 4
Value 5
22



Error value 6

Content Start
Version 4.0
Change parameter value, several array elements, Format Byte

Parameter request:

Change parameter

Parameter number
Subindex = 110
Parameter value Format = Byte No. of values = 7 10

Value 1 Value 2 12
Value 3 Value 4
Value 5 Value 6
Value 7 Dummy Byte 18



Error value 6

Content Start
Version 4.0
Request parameter value, multi-parameter

Parameter request:

Request parameter
1st parameter address Attribute = Value No. of elements = 1 4

Parameter number
Subindex = 7
2nd parameter address Attribute = Value No. of elements = 100 10

Parameter number
Subindex = 0
3rd parameter address Attribute = Value No. of elements = 2 16

Parameter number
Subindex = 13
22
Parameter response (+): all partial accesses OK

1st parameter value(s) Format = Word No. of values = 1 4

Value 6
2nd parameter value(s) Format = Word No. of values = 100 8
Value 1 10
Value 2
...
Value 100
3rd parameter value(s) Format = Double word No. of values = 2 210
Value 1 212
Value 2
220

Content Start
Version 4.0
Parameter response (-): first and third partial access OK, second partial access erroneous


Value 6
2nd parameter value(s) Format = Error No. of values = 1 8
Error value 10
Value 1 14
Value 2
22
Change parameter value, multi-parameter

Parameter request:

Change parameter

Parameter number
Subindex = 7
2nd parameter address Attribute = Value No. of elements = 100 10

Parameter number
Subindex = 0
3rd parameter address Attribute = Value No. of elements = 2 16

Parameter number
Subindex = 13

Value 24
2nd parameter value(s) Format = Word No. of values = 100 26
Value 1 28
Value 2
...
Value 100
Value 1 230
Value 2
238

Content Start
Version 4.0

Parameter response (-): first and third partial access OK, second partial access erroneous

1st parameter value(s) Format = Zero No. of values = 0 4

2nd parameter value(s) Format = Error No. of values = 2 6
Error value 8
Erroneous subindex 10
3rd parameter value(s) Format = Zero No. of values = 0 12
14
Request description, single

Parameter request:

Request parameter
Parameter address Attribute = Description No. of elements = 1 4

Parameter number
Subindex = n
10
Parameter response positive with data of the data type word (e.g. ID):


Value 6

Content Start
Version 4.0
Parameter response positive with text:


Byte 1 Byte 2 6
... ...
Byte 15 Byte 16
22


Error value 6
Request description, complete

Parameter request:

Request parameter
Parameter address Attribute = Description No. of elements = 0 4

(irrelevant)
Parameter number
Subindex = 0 (!)
10

Parameter value Format = Byte No. of values = (Bytes) 4

ID 6
(etc.)
...
... ...
6 + Description

Content Start
Version 4.0


Error value 6
Request text, single

Parameter request:

Request parameter
Parameter address Attribute = Text No. of elements = 1 4

Parameter number
Subindex = n
10


Byte 1 Byte 2 6
... ...
Byte 15 Byte 16
22

Request description (-)

Error value 6

Content Start
Version 4.0
Request parameter, multi-parameter, various attributes

Request of values, description and text in one request
Parameter request:

Request parameter

Parameter number
Subindex = 0
2nd parameter address Attribute = Description No. of elements = 0 10

Parameter number
Subindex = 0
3rd parameter address Attribute = Text No. of elements = 3 16

Parameter number
Subindex = 0
22

1st parameter values Format = Word No. of values = 3 4

(three values) Value 1
Value 2
Value 3
2nd parameter values Format = Byte No. of values = (Bytes) 12

(complete ID
description)
(etc.)
... ...
3rd parameter values Format = Byte No. of values = 48 12 + Description

(three texts) Byte 1 Byte 2
... ...
Byte 47 Byte 48
62 + Description

Content Start
Version 4.0
4 Drive control application process
4.1 General Axis type Drive Object architecture
Figure 22 shows the functional elements of the Axis type Drive Object (DO). Central element
of the Axis type DO is the Axis Control Task which is responsible for the control of the related
Axis. Properties of the DO and the Axis Control Task are represented and controlled by
parameters. The parameters are administered in the Parameter Data Base. To access DO
parameters, the Acyclic Data Exchange service is used by aid of the parameter manager. The
parameter manager receives parameter requests, does the access to the Parameter Data
Base and answers to the parameter request with a related parameter response. For periodic
transportation of setpoint values to the Axis and actual values from the Axis DO, the Cyclic
Data Exchange service is used. The Axis type DO comprises the General State Machine,
which controls and represents the states of the Axis Control Task. Exception situations out of
the Axis Control Task and the General State Machine may be signalled by the Alarm
Mechanism to the controlling device. For Clock Synchronous Operation of several DOs (Axis)
the Clock Synchronous Operation service shall be used to trigger the relevant control tasks.
The Axis type DO shall comprise the mandatory functionality:
Parameters
Axis Control Task
General State Machine
Process Data (setpoint values and actual values)
The Axis type DO may comprise as optional functionality:
Support of Alarm Mechanism

Clock Synchronous Operation of Axis Control Task

Content Start
Version 4.0
Acyclic Clock
Cyclic
Alarm Queue Data Exchange Synchronous
Data Exchange
Operation
transmit transmit
setpoint actual write read Master Clock
signal exception
values values parameter parameter sync information
cyclically cyclically
Alarm Process Data Parameter Master Clock

Mechanism (PZD) Access Regeneration
sync/trigger
Setpoint Values Actual Values
Parameter
General Axis Control Task Data Base
State Machine (closed loop control, motion control, ...)
sync/trigger
Axis type Drive Object
Actors and Sensors

(e.g. motor and measurement system)
Figure 22 General functional elements of the PROFIdrive Axis type DO
Figure 23 shows the more detailed functional architecture of the Axis type DO. The Axis
Control Task is subdivided in the following elements:
Fault buffer
Position feedback interface
Power stage
Current closed loop control
Life sign handling
Periphery control
Application Class and technology specific functionality
Depending on the level of the drive interface, the PROFIdrive Axis may operate in different
control modes. These general control modes are related to one or more of the PROFIdrive
Application Classes. For more details on the control modes refer to 4.3.

Content Start
Version 4.0
Clock Alarm Cyclic Acyclic

Sync. Queue Data Exchange Data Exchange
Op.
Parameter
Regeneration
Process Data (PZD)

Master Clock
Mechanism
Access
Alarm
Input PZD Output PZD request response

I/O STW2 STW1 setpoint actual
data ZSW2 ZSW1 values values
Parameter
Manager
Periphery Lifesign
internal clock
control handling
Parameter
Data Base
Fault State
Alarm event buffer machine
Current Application Class and

Power
M closed loop technology specific
stage
control functionality
internal clock V act

Position X act optional
E feedback
interface
Figure 23 Functional block diagram of the PROFIdrive Axis type DO
4.2 Control and Status words
To improve the exchange of devices of different manufacturers in a control application, we

strongly recommend to use the device-specific bits only for the control of manufacturer-
specific functions. The device-specific bits shall not be necessary for the operation of a device
in the speed control mode and in the positioning mode (default of the device-specific bits = 0).

Content Start
Version 4.0
4.2.1 Control word 1 (STW1)
Table 16 Overview on the assignment of the bits of control word 1
Bit Significance
Speed control mode Positioning mode
0 ON / OFF
1 No Coast Stop / Coast Stop (no OFF2 / OFF 2)
2 No Quick Stop / Quick Stop (no OFF3 / OFF 3)
3 Enable Operation / Disable Operation
4 Enable Ramp Generator / Do Not Reject Traversing Task /
Reset Ramp Generator Reject Traversing Task
5 Unfreeze Ramp Generator / No Intermediate Stop /
Freeze Ramp Generator Intermediate Stop
6 Enable Setpoint / Disable Setpoint Activate Traversing Task
(0 -> 1 and 1 -> 0))
7 Fault Acknowledge (0 -> 1)
a a
8 Jog 1 ON / Jog 1 OFF
a a
9 Jog 2 ON / Jog 2 OFF
10 Control By PLC / No Control By PLC
11 Device-specific Start Homing Procedure / Stop Homing Procedure
12-15 Device-specific
NOTE Using the closed-loop speed controlled mode in Application Class 4 with or without DSC (positioning
with central interpolation and positioning control) the STW1 bit 4 and 6 ("Enable/Reset Ramp Generator" and
"Enable/Disable Setpoint") keep their effectiveness, STW1 bit 5 ("Unfreeze/Freeze Ramp Generator") has no
relevance.
a
optional
Explanation: The significance for bit value = 1 is to the left of the slash; bit value = 0 to the
right.
Table 17 lists the common control bits, Table 18 and Table 19 the control bits where speed
control (AC 4) and positioning modes (AC 3) differ.
Table 17 Detailed assignment of the common control word 1 bits (STW1) for speed
control/positioning
Bit Value Significance Comments
0 1 ON Switched on condition; voltage at the power converter, i.e. the main

contact is closed (if present).
0 OFF Power-down (the drive returns to the "ready for switching on "
condition); the drive is ramped-down along the ramp (RFG) or along
(OFF 1) the current limit or along the voltage limit of the d.c. link; if standstill is
detected, the voltage is isolated; the main contact is opened (if
present).During deceleration bit 1 of ZSW1 is still set.
An OFF command is interruptible.
1 1 No Coast Stop All "Coast Stop (OFF2)" commands are withdrawn.
(no OFF 2)
0 Coast Stop Voltage is isolated.
The main contact is then opened (if present) and the drive goes into
(OFF 2) the Switching On Inhibited condition; the motor coasts down to a
standstill.

Content Start
Version 4.0
2 1 No Quick Stop All "Quick Stop (OFF3)" commands are withdrawn.

(no OFF 3)
0 Quick Stop Quick stop; if required, withdraw the operating enable, the drive is
decelerated as fast as possible, e.g. along the current limit or at the
(OFF 3) voltage limit of the d.c. link, at n / f = 0; if the rectifier pulses are
disabled, the voltage is isolated (the contact is opened) and the drive
goes into the "Switching On Inhibited" condition.
A Quick Stop command is not interruptible.
3 1 Enable Operation Enable electronics and pulses
The drive then runs-up to the setpoint.
0 Disable Operation The drive coasts down to a standstill (ramp-function generator to 0 or
tracking) and goes into the "Switched on" condition (refer to control
word 1, bit 0).
7 1 Fault Acknowledge The group signal is acknowledged with a positive edge; the drive
reaction to a fault depends on the type of fault (refer to [10] alarm
(0 -> 1) handling). If the fault reaction has isolated the voltage, the drive then
goes into the "Switching On Inhibited" condition
0 No significance
10 1 Control By PLC Control via interface, process data valid (refer to 4.11).
0 No Control By PLC Process data not valid; expect Sign-Of-Life. If loosing the control
priority bit the reaction is device-specific.
Possible reactions:
1) speed control: "old" process data is kept,
2) positioning: PZD are set to 0.
12 15 device-specific Definition not specified.
Table 18 Detailed assignment of the special control word 1 bits (STW1) for speed
control mode
4 1 Enable Ramp
Generator
0 Reset Ramp Output of the RFG is set to 0. The main contact remains closed, the
Generator converter is not isolated from the line, the drive decelerates along the
current limit or along the voltage limit of the d.c. link
5 1 Unfreeze Ramp
Generator
0 Freeze Ramp Freeze the actual setpoint entered by the ramp-function generator. If
Generator Application Class 4 is used Bit 5 is not relevant.
6 1 Enable Setpoint The value selected at the input of the RFG is switched-in.
0 Disable Setpoint The value selected at the input of the RFG is set to 0.
a
8 1 Jog 1 ON Prerequisite: Operation is enabled, drive is in standstill and STW1 bit
4, 5, 6 = 0. The drive runs up along the ramp of RFG to jogging
setpoint 1.
a
0 Jog 1 OFF Drive brakes along the ramp of RFG, if "Jog 1" was previously ON,
and goes into "Operation Enabled" when drive comes to a standstill.
a
9 1 Jog 2 ON Prerequisite: Operation is enabled, drive is in standstill and STW1 bit
4, 5, 6 = 0. The drive runs up along the ramp of RFG to jogging
setpoint 2.
a
0 Jog 2 OFF Drive brakes along the ramp of RFG, if "Jog 2" was previously ON,
and goes into "Operation Enabled" when drive comes to a standstill.
11 device-specific Significance not specified
a
optional

Content Start
Version 4.0
Table 19 Detailed assignment of the special control word 1 bits (STW1) for the
positioning mode
4 1 Do Not Reject A traversing task is activated using a signal edge at bit 6

Traversing Task
0 Reject Traversing Task The drive brakes from an active traversing task with maximum
acceleration to n=0 and remains stationary with the holding torque.
The current traversing task is rejected.
5 1 No Intermediate Stop This shall be continually set when executing a traversing task.
0 Intermediate Stop Drive brakes from an active traversing task to n = 0 along a ramp,
and remains stationary with the holding torque. The traversing task
is not rejected. The traversing task is continued when bit 5 of
control word 1 changes to 1.
6 Activate Traversing Task Each signal edge enables a traversing task or a new setpoint
(0 -> 1 or 1 -> 0) (toggle bit). An edge change may only be realized if it was
acknowledged with bit 12 of the status word 1 that the previous
traversing task was accepted and bit 11 of the status word 1
(home position) is set.
a
8 1 Jog 1 ON Prerequisite: Operation is enabled and no positioning procedure is
active. The drive is in variable-speed mode with jogging setpoint 1.
a
0 Jog 1 OFF
a
9 1 Jog 2 ON Like Bit 8 with jogging setpoint 2
a
0 Jog 2 OFF
11 1 Start Homing Procedure Homing Procedure is started with a change from 0 to 1. Bit 11 in
the status word is set to 0. Prerequisite: Operation is enabled.
0 Stop Homing Procedure Homing Procedure in progress is aborted, the drive stops along a
ramp.
a
optional
4.2.2 Control word 2 (STW2)
Table 20 Overview on the assignment of the bits of control word 2
Bit Significance
12-15 Controller Sign-Of-Life
NOTE If a clock-cycle synchronous application is not implemented, i.e. bits 12-15 of control word 2 are not
required to transfer the controller Sign-Of-Life, the complete control word 2 may be freely used.
4.2.3 Status word 1 (ZSW1)
Table 21 Overview on the assignment of the bits of status word 1
Bit Significance
0 Ready To Switch On /Not Ready To Switch On

1 Ready To Operate / Not Ready To Operate
2 Operation Enabled (drive follows setpoint) / Operation Disabled
3 Fault Present / No Fault
4 Coast Stop Not Activated / Coast Stop Activated (No OFF2 / OFF2)
5 Quick Stop Not Activated / Quick Stop Activated (No OFF3 / OFF3)

Content Start
Version 4.0
Bit Significance
6 Switching On Inhibited / Switching On Not Inhibited

7 Warning Present / No Warning
8 Speed Error Within Tolerance Range / Following Error Within Tolerance Range /
Speed Error Out Of Tolerance Range Following Error Out Of Tolerance Range
9 Control Requested / No Control Requested
10 f Or n Reached Or Exceeded / Target Position Reached /
f Or n Not Reached Not At Target Position
11 Device-specific Home Position Set / Home Position Not Yet Set
12 Device-specific Traversing Task Acknowledgement
(0 -> 1 and 1-> 0)
13 Device-specific Drive Stopped / Drive Moving
Explanation: The significance for bit value = 1 is left of the slash; bit value =0 to the right.
The common status bits are shown in Table 22 and the status bits which differ for the speed
control (AC 4) and positioning (AC 3) in Table 23 and Table 24.
Table 22 Detailed assignment of the common status word 1 bits (ZSW1) for the speed
control /positioning mode
Power supply is switched on, electronics initialized, main

0 1 Ready To Switch On
contact, if available, has dropped out, pulses are inhibited.
0 Not Ready To Switch On
1 1 Ready To Operate Refer to control word 1, bit 0.
0 Not Ready To Operate
Drive follows setpoint. This means, that the electronic and
pulses are enabled (Refer to control word 1, bit 3), the
2 1 Operation Enabled closed loop control is active and controls the motor and the
output of the setpoint channel is the input for the closed loop
control.
Either the pulses are disabled or the drive doesnt follow the
0 Operation Disabled
setpoint
Unacknowledged faults or currently not acknowledgeable
faults (fault messages) are present (in the fault buffer). The
fault reaction is fault-specific and device-specific. The
acknowledging of a fault may only be successful, if the fault
3 1 Fault Present cause has disappeared or has been removed before. If the
fault has isolated the voltage, the drive goes into the
Switching On Inhibited condition, otherwise the drive
returns to operation. The related fault numbers are in the
fault buffer.
0 No Fault
Coast Stop Not Activated
4 1
(No OFF 2)
Coast Stop Activated
0 "Coast Stop (OFF 2)" command is present.
(OFF 2)
Quick Stop Not Activated
5 1
(No OFF 3)

Content Start
Version 4.0
Quick Stop Activated

0 Quick Stop (OFF 3)" command is present.
(OFF 3)
The drive goes only again in the "Switched On" condition
with "No Coast Stop AND No Quick Stop" followed by "ON".
6 1 Switching On Inhibited This means that the "Switching On Inhibited" bit is only set
back to zero if the OFF command is set after "No Coast Stop
AND No Quick Stop".
0 Switching On Not Inhibit
Warning information present in the service/maintenance
7 1 Warning Present
parameter; no acknowledgement.
0 No Warning There is no warning or the warning has disappeared again.
The automation system is requested to assume control (refer
9 1 Control Requested
to 4.11.
Control by the automation system is not possible, only
0 No Control Requested
possible at the device or by another interface.
1415 - device-specific Significance not specified.
Table 23 Detailed assignment of the special status word 1 bits (ZSW1) for the speed
control mode
8 1 Speed Error Within Tolerance Actual value is within a tolerance band; dynamic violations
Range are permissible for t < t max , e.g.
n=n set ,
f=f set , etc.,
t m ax may be parameterized
0 Speed Error Out Of Tolerance

Range
10 1 f Or n Reached Or Exceeded Actual value comparison value (setpoint) which may be set
via the parameter number.
0 f Or n Not Reached
11-13 - device-specific Significance not specified.
Table 24 Detailed assignment of the special status word 1 bits (ZSW1) for the
positioning mode
8 1 Following Error Within The dynamic comparison of the setpoint position with the
Tolerance Range actual position value is located with the defined following
error window.
0 Following Error Out Of
Tolerance Range
10 1 Target Position Reached The position actual value is located at the end of a traversing
task in the positioning window.
0 Not At Target Position
11 1 Home Position Set Homing Procedure was executed and is valid.
0 Home Position Not Yet Set No valid Home Position available.
12 Edge Traversing Task Using an edge, it is acknowledged that a new traversing task
Acknowledgment (0 -> 1 and 1 or setpoint was accepted (the same signal level as for bit 6
-> 0) in the control word 1).

Content Start
Version 4.0
13 1 Drive Stopped Signals that a traversing task has been completed or

standstill for intermediate stop and stop.
0 Drive Moving Traversing task is executed n<>0.
4.2.4 Status word 2 (ZSW2)
Table 25 Overview on the assignment of the bits of status word 2
Bit Significance
12-15 DO Sign-Of-Life
NOTE If a clock cycle-synchronous application is not implemented, i.e. bits 12-15 of status word 2 are not
required to transfer the DO Sign-Of-Life, then the complete status word 2 may be freely used.
4.2.5 Status bit "Pulses Enabled/Disabled"
The controller may get the information, if the DO has disabled the pulses, out of the status bit
"Pulses Enabled".
This bit is optional. The manufacturer may use a device-specific bit of the status word 1 or 2
or, possibly, a bit in a manufacturer-specific status word.
In new developments, it is recommended to use bit 11 of status word 2 for "Pulses Enabled".
The evaluation of status word bit "Pulses enabled" is optional (refer to 5).
To identify the usage and the position of the bit "Pulses Enabled", a profile parameter P924
"status word bit Pulses Enabled" is defined with the following structure:
Subindex Meaning Comments
0 signal number status word 1, status word 2 or manufacturer-

specific status word
1 bit position 0..15
If the parameter P924 is implemented in the drive, the drive supports the evaluation of
"Pulses Enabled".
4.3 Operating Modes and State Machine
For applications with Drive Axis, a differentiation may be made according to the six
PROFIdrive Application Classes with the associated levels of drive interfaces (refer to 2.4).
According to the different interface levels the following Operation Modes are defined within
this profile:
a) Speed control mode

The Application Classes 1 and 4 may be combined in the speed control mode.
NOTE The operating mode speed control may be realized with different types of control modes, e.g., v/f
control, frequency control, voltage control and closed-loop speed control.
b) Positioning mode
The Application Class 3 is emulated under the positioning mode.
Content Start
Version 4.0
c) Operating mode for the process technology

The operating mode for the integration of drives in process technology applications
according to the VIK 1-NAMUR 2 recommendation is generally based on the Application
Class 1. For a detailed description of this mode refer to 8.
d) Manufacturer-specific modes
The Application Classes with distributed technology cannot be assigned to an operating
mode defined by the profile, as the interface of the higher-level open-loop control to the
technology is exclusively application-specific. The operating mode interface to the speed
control and the positioning feedback control is displaced inwards between the technology
and axis controller.
In addition to the operating modes defined by the profile and the associated state
diagrams, operating modes may be defined manufacturer-specific, whereby bits 0 3, 7
and 10 of control word 1 and bits 0 7 and 9 of status word 1 shall be used corresponding
to the specified operating modes in the profile.
e) Operating mode changeover
A steady-state operating mode setting may be realized via parameter 930.
A dynamic changeover is implemented manufacturer-specific using the device-specific
defined control word bits.
4.3.1 General state diagram
State diagram
State diagrams are defined for the operating modes.
In order to simplify the diagram, the states, common for all operating modes (also
manufacturer-specific), are combined in the general state diagram (see Figure 24) with only
the supplementary states of the individual modes being shown in dedicated diagrams. This
state diagram corresponds with the function block state machine in the general Drive Object
block diagram (see Figure 23).
Information on the general state diagram:
The green blocks represent states, the arrows represent transitions.

From several states, several transitions are possible. In order to achieve standard device
behaviour, the transitions are specified with assigned priorities in the particular state
diagrams in Section 4.3. Points are used to identify the priority level. The more points that
a transition has, the higher is its priority. Accordingly, a transition without points has the
lowest priority.
In the general state diagram, internal conditions of the drive are not shown (refer to [10];
Implementation example of the general state machine). Internal signals may have
influence on the transitions.
1 VIK = Association of the Industrial Customers and Industrial Power Producers
2 NAMUR = Standards Working Group for Instrumentation and Control in the Chemical Industry

Content Start
Version 4.0
General State Diagram

Power supply on
S1: Switching On Inhibited

a
ZSW1 bit 6=true; 0,1,2,"p.e." =false
Standstill detected
OFF Coast Stop Coast Stop OR
AND No Coast Stop b
OR Quick Stop STW1 bit1=false Disable Operation
AND No Quick Stop STW1 bit1=false STW1 bit3=false
STW1 bit0=false OR bit2=false
AND bit1=true AND bit2=true
S5:Switching Off quick stop

S2: Ready For Switching On ZSW1 bit 0,1, "p.e." =true
ZSW1 bit 0=true; 1,2,6,"p.e."=false bit 2,6=false
Standstill detected
OR Quick Stop
Coast Stop ON OFF Disable Operation STW1 bit 2=false
OR Quick Stop
STW1 bit0=true STW1 bit0=false STW1 bit3=false
STW1 bit1=false
OR bit2= false
S3: Switched On ramp stop

ZSW1 bit 0,1=true; 2,6,"p.e."=false
Coast Stop
STW1 bit1=false
Enable Disable b
ON OFF Quick Stop
Operation Operation
STW1 bit0=true STW1 bit0=false STW1 bit 2=false
STW1 bit3=true STW1 bit3=false
S4: Operation
ZSW1 bit 0,1,2,"p.e."=true; 6=false
NOTE 1 STW1 bit x,y =: These control word bits shall be set by the control.
NOTE 2 ZSW1 bit x,y = These status word bits indicate the actual state.
NOTE 3 Standstill detected is an internal result of a stop operation.
a
Abbr.:"p.e." = "Pulses enabled" optional (refer to 4.2.5)
b
The internal condition fault with ramp stop also activates this transition.
Figure 24 General state diagram for all operating modes
All transitions in this general state machine may only be initiated by a controller, if it has the
control priority. The following conditions shall be fulfilled to give the controller the control
priority (refer also to 4.11):
1) the PROFIBUS or PROFINET interface between this controller and the DO has the
control priority (P928)
2) ZSW1 Bit 9 is set by the DO
3) STW1 Bit 10 is set by the controller

Content Start
Version 4.0
Internal conditions of the drive or control priority of another interface may cause transitions
independent of this controller.
The bits defined for the positioning mode are only relevant, if the drive is in the state S4
"Operation".
Notice, that the priority of the Stop-Reactions is in the order of Ramp Stop, Quick Stop and
Coast Stop, where Coast Stop is the highest and Ramp Stop the lowest priority. The effect
and priority of the Stop-Reactions is independent from the origin (general state machine,
speed setpoint channel STW1 bits 4, 6 or Stop-Reactions caused by faults). This means, that
any higher priority Stop-Reaction overwrites all lower priority Stop-Reaction. For example if
the axis is switched off by STW1 bit 0 = 0 and remains in S5 Ramp Stop, a setting of STW1
bit 4 = 0 drives the axis to S5 Quick Stop.
Also all Stop-Reactions caused by faults (Fault with Ramp Stop, Fault with Quick Stop, Fault
with Coast Stop) force the general state machine to switch to state S1 (Switching On
Inhibited) or S2 (Ready for Switching On).
4.3.2 Speed control mode
The speed control mode comprises the speed setpoint interfaces used in the Application
Classes 1 and 4. Generally both interfaces use STW1/ZSW1 and the speed setpoint input to
control the drive. The differences between the speed setpoint interface in Application Class 1
and Application Class 4 are the different feedback values (Output Data) and the different
functionality of the speed setpoint channel.
Notice, that all Stop-Reactions out of the state machine (Coast Stop, Quick Stop and Ramp
Stop) are with higher priority than the control functions of the speed setpoint channel.
4.3.2.1 Speed control mode for Application Class 1
Speed control in Application Class 1 typically is represented by the lack of a position

feedback interface and the open loop control of the speed (or torque) via the PROFIdrive
Interface. Figure 25 shows the typical functionality of an Application Class 1 PROFIdrive Drive
Object. Clock Synchronous Operation is optional but mostly not necessary.

Content Start
Version 4.0
Clock Alarm Cyclic

Sync. Queue Data Exchange
Op.
Regeneration
Master Clock
Process Data (PZD)
Mechanism
Alarm Input PZD Output PZD
Periphery Lifesign NSOLL NIST

internal clock
control handling
Fault State
Power Current Frequency speed

M closed loop or vector setpoint
stage
control control channel
internal clock
optional

functionality
Figure 26 shows the typical functionality of the speed setpoint channel block in the
Application Class 1 and the effect of the STW1 control bits on the speed setpoint channel.
The jog mode functionality is optional.
If the drive supports parameter PNU930 (operating mode) than the drive shows the
functionality of the speed setpoint channel and the support of the bits 4, 5, 6 in STW1
according to Figure 26 by answering a parameter read request on PNU930 with a value == 1.
The Ramp Function Generator (RFG) is set to zero output if STW1 bit 4 is set to zero. If the
RFG is activated by STW1 bit 4 = 1, the RFG output starts with setpoint value zero or the
RFG output setpoint value may be synchronized to the actual value of the axis speed (vendor
specific).

Content Start
Version 4.0
setpoint a COMP
t max t ZSW1 bit 8

tolerance range r True = speed errror
within tolerance
actual value b range
False = speed error
out of tolerance
range
STW1 bit 4
True = enable RFG
False = reset RFG
STW1 bit 5
True = unfreeze RFG
False = freeze RFG
STW1 bit 6
True = enable setpoint
False = disable setpoint
1 = operate Change of mode between
0 = freeze
normal operation and jog
mode or vice versa
only when drive is
reset RFG in stand still
&
0 0 0 0
0
setpoint 1 1
RFG
(velocity) 1
to v/f control or
closed loop
speed controller
STW1 bit 8 (velocity)
True = Jog 1 ON
False = Jog 1 OFF
C1
Y
STW1 bit 9 C2 0= reset RFG
True = Jog 2 ON J1 J2 RFG (output=0)
False = Jog 2 OFF 1= operate RFG
Jogging Jogging
setpoint 1 setpoint 2 Jogging functionality (optional)
RFG = Ramp Function Generator

C1 C2 Y
0 0 0 setpoint a COMP
1 0 J1 actual value b
ZSW1 bit 10
0 1 J2 True = f or n reached
1 1 no change False = f or n not reached
Figure 26 Speed setpoint channel for use in Application Class 1 and 4

Content Start
Version 4.0
4.3.2.2 Speed control mode for Application Class 4
Speed control in Application Class 4 typically is used for positioning by use of servo drives
with central interpolation. Therefore the position closed loop control located on the control is
closed via the PROFIdrive Interface. For this Application Class the Position Feedback
Interface and the Clock Synchronous Operation is necessary. Optional a second Position
Feedback Interface and additional DSC functionality may be applied. Figure 27 shows the
typical functionality of an Application Class 4 PROFIdrive Axis DO.
Clock Alarm Cyclic

Sync. Queue Data Exchange
Op.
Regeneration
Master Clock
Process Data (PZD)

Mechanism
Alarm
Input PZD Output PZD

I/O STW2 STW1 setpoint actual actual
data ZSW2 ZSW1 values values 1 values 2
Periphery Lifesign
control handling
internal clock
Fault State
Current Speed Speed

Power
M closed loop closed loop setpoint
stage
control control channel

Position X act1
E1 feedback
interface
Position X act2
E2 feedback
interface
optional

functionality
In the Application Class 4 there is typically no need for a Ramp Function Generator (RFG) in
the speed setpoint channel. Therefore a more simple speed setpoint channel without RFG
functionality may be used (optional). Figure 28 shows the functionality of this reduced speed
Content Start
Version 4.0
setpoint channel block for use in the Application Class 4 and the effect of the STW1 control
bits on the speed setpoint channel. With this speed setpoint channel STW1 bit 5 is without
effectiveness. The jog mode functionality is optional.
If the drive supports parameter PNU930 (operating mode) than the drive shows the
functionality of the reduced speed setpoint channel and the only support of bits 4 and 6 in
STW1 according to Figure 28 by answering a parameter read request on PNU930 with a
value == 3.
setpoint a COMP
t max t ZSW1 bit 8

tolerance range r True = speed errror
within tolerance
actual value b range
False = speed error
out of tolerance
STW1 bit 4 range
True = enable RFG
False = reset RFG
STW1 bit 5
without effectivness
STW1 bit 6
False = disable setpoint
Change of mode between

mode or vice versa
only when drive is
Ramp down
& in standstill
0
0 0
0 to v/f control or
1 closed loop
setpoint 1 1 speed controller
(velocity) (velocity)
STW1 bit 8
True = Jog 1 ON
False = Jog 1 OFF
C1
Y
STW1 bit 9 C2
0= reset RFG
True = Jog 2 ON J1 J2 RFG
(output=0)
False = Jog 2 OFF
1= operate RFG
Jogging Jogging
RFG = Ramp Function Generator

C1 C2 Y
0 0 0 setpoint a COMP
1 0 J1 actual value b
ZSW1 bit 10
0 1 J2 True = f or n reached
1 1 no change False = f or n not reached
Figure 28 Reduced speed setpoint channel for use in Application Class 4 (optional)
4.3.2.3 Jogging functionality in speed control mode
The jogging functionality is optional. Prerequisite for the jog mode is that the drive is already
switched to state S4 operation. Switching of mode between normal operation and jog mode
(drive follows selected jogging setpoint) is only possible when the drive is in a standstill. To
enter the jog mode (drive shows effect on the jog bits (STW1, bits 8 and 9)) the standard
setpoint channel shall be completely deactivated (STW1, bits 4, 5, 6 ==0; bit 5 is dont care in
Content Start
Version 4.0
case of a Reduced Speed setpoint channel). Leaving the jog mode and switching back to
normal operation requires first that the drive comes to a standstill in the jog mode (STW1, Bits
8, 9 ==0). STW1 bits 4, 5, 6 need not force the drive to leave the jog mode if the drive is not
already in a standstill. If in jog mode the speed setpoint from jogging setpoint 1 is activated
(STW1 bit 8=1) and afterward also jogging setpoint 2 (STW1 bit 9=1) is activated, then the
drive still keeps the former setpoint value jogging setpoint 1. If both jog bits are activated at
the same time (from STW1 bit 8 = bit 9 == 0 to STW1 bit 8 = bit 9 == 1 with the next DP-
cycle), then the jogging setpoint value is zero.
4.3.3 Positioning mode
In positioning mode which refers to the Application Class 3, the speed setpoint channel
block is replaced by the motion control block (see Figure 29). The motion control block
comprises the functionality of a position closed loop control, an interpolator for point to point
movement, homing and jogging (optional). In positioning mode bits in the STW1/ZSW1, which
in speed control mode are dedicated to the speed setpoint channel, are used to control the
motion control operation (refer to 4.2). Also the general state machine/diagram according to
Figure 24 is expanded in the positioning mode according to Figure 30.
Clock Alarm Cyclic

Sync. Mechanism Data Exchange
cycle generation
Process Data (PZD)

Internal clock
Queue
Alarm
Input PZD Output PZD

Periphery Lifesign
internal clock
control handling
Fault State
Motion control
Power Current Speed Vsetp
M (interpolation)
stage closed loop closed loop
+ closed loop
control control
position control

Position X act optional
E feedback
interface

functionality

Content Start
Version 4.0
The general state machine is expanded as follows for the positioning mode:
State diagram of the Positioning Mode

in "Operation" (S4) state of the general state diagram (always ZSW1 bit 0,1,2,p.eb = true; 6 = false)
BASIC STATE: Operation

ZSW1 bit 10,13 = true
Jog 1 ON
OR Jog2 ON Start Homing Procedure
a
OR (Jog1 ON and Jog2 ON) STW1 bit 11 = true
STW1 bit 8 or 9 or 8&9 = true
Jog 1 OFF Stop Homing Procedure
AND Jog2 OFF STW1 bit 11 = false
STW1 bit 8, 9 = false
Jogging(optional) Homing Procedure

ZSW1 bit 10,13 = false
Do Not Reject Traversing Task Running
Speed equal to zero AND No Intermediate Stop ZSW1 bit10,11,13 = false
AND Activate Trav. Task (Edge)
STW 1 bit 4,5 = true Home
AND STW1 bit 6 edge Position Set
Braking with ramp Ready
ZSW1 bit10,13 = false
END Traversing Task ZSW1 bit 10,11,13 = true
Reject Traversing Task

STW1 bit 4 = false
Traversing task active Activate

ZSW1 bit10,13 = false Traversing Task
AND edge at ZSW1 bit 12 (Edge)
Intermediate Stop
STW1 bit 6 edge
STW1 bit 5 = false
Start Homing Procedure

Braking with ramp No Intermediate Stop STW1 bit 11 = true
ZSW1 bit10,13 = false STW1 bit 5 = true
Jog 1 ON
OR Jog2 ON Speed equal to zero
a
OR (Jog1 ON and Jog2 ON) optional
STW1 bit 8 or 9 or 8&9 = true Intermediate Stop
ZSW1 bit 13 = true
optional
a
if the device supports this combination (optional)
b
p.e. = status bit for pulses enabled/disabled
Figure 30 State diagram of the positioning mode

Content Start
Version 4.0
4.3.3.1 Homing Procedure
The drive executes autonomously the homing procedure. The strategy of the homing
procedure is defined manufacturer-specific by the parameterization of the drive.
Homing Procedure: Stop Homing Procedure by the master
STW1 Bit 11: Start/Stop

Homing Procedure 1
0
ZSW1 Bit 11: Home 1

Position Set/ Home 0
Position Not Yet Set
ZSW1 Bit 13:

Drive Stopped/
Drive Moving 1
0
Basic State Homing Procedure Basic State
Figure 31 Homing Procedure stopped by the controller
Homing Procedure: Home Position Set
STW1 Bit 11: Start/Stop

Homing Procedure 1
0
ZSW1 Bit 11: Home 1

Position Set/ Home 0
Position Not Yet Set
ZSW1 Bit 13:

Drive Stopped/ 1
Drive Moving 0
Basic State Homing Procedure Basic State
Figure 32 Homing Procedure: Home Position Set

Content Start
Version 4.0
4.3.3.2 Traversing Task Active
Traversing Task active positive and negative

edges are significant
STW1 Bit 6: Activate 1

Traversing Task 0
ZSW1 Bit 12: 1

Traversing Task 0
Acknowledgement
1
ZSW1 Bit 13: 0
Drive Stopped/
Drive Moving
1
ZSW1 Bit 10: Target 0
Position Reached /
Not At Target Position
Basic State Traversing Task active Basic State
Figure 33 Traversing Task Active
Traversing Task active: new traversing task or setpoint before

the end of the first traversing task
positive and negative
edges are significant
STW1 Bit 6: Activate 1
Traversing Task 0
ZSW1 Bit 12: 1

Traversing Task 0
Acknowledgement
1
ZSW1 Bit 13: 0
Drive Stopped/
Drive Moving
1
ZSW1 Bit 10: Target 0
Position Reached /
Not At Target Position
first traversing new traversing task
task or setpoint
Basic State Traversing Task active
Figure 34 Change of the traversing tasks immediately

Content Start
Version 4.0
4.4 Process Data (PZD)
The setpoints to the Axis and also the actual values from the Axis are transferred as PZD.
The process data is transferred using the Cyclic Data Exchange service. The representation
of data shall be in big-endian format.
The individual setpoints/actual values may be configured as Signals to be included in the

process data of the Axis. Furthermore, the controller may read-out the normalization for the
individual process data from the DO/Axis. There are four PZD descriptive elements in the
profile-specific parameter section for this process data configuration.
A detailed description is provided in 4.4.3 and 4.4.4.
The following advantages are obtained due to the telegram configuring and normalization:
Interoperability and interchangeability of PROFIdrive Controllers and Drive Units

Standard components may be simply commissioned
Automation mechanisms in the controller application. By reading-out parameters the
controller may adapt its cyclic interface to the Axis. This read-out procedure shall be taken
into account when running-up.
4.4.1 Signals
A series of signals with appropriate signal numbers are defined to configure the process data
(setpoints, actual values).
The following values are permissible for the signal numbers:
0 -> not assigned

1-99 -> standard signal numbers (profile-specific signal numbers)
100-65535 -> signal numbers (device-specific)
All of the defined signal numbers are listed in the following:
Table 26 Signal list assignment
Signal No. Significance Abbreviation Length Sign Description

16-/32 bit
1 Control word 1 STW1 16 Refer to 4.2.1

2 Status word 1 ZSW1 16 Refer to 4.2.3
3 Control word 2 STW2 16 Refer to 4.2.2
4 Status word 2 ZSW2 16 Refer to 4.2.4
5 Speed setpoint A NSOLL_A 16 with
6 Speed actual value A NIST_A 16 with
7 Speed setpoint B NSOLL_B 32 with
8 Speed actual value B NIST_B 32 with
9 Sensor 1 control word G1_STW 16 Refer to 4.6
10 Sensor 1 status word G1_ZSW 16 Refer to 4.6
11 Sensor 1 position actual value 1 G1_XIST1 32 Refer to 4.6

Content Start
Version 4.0
Signal No. Significance Abbreviation Length Sign Description

16-/32 bit

21 Input (digital) E_DIGITAL 16 Refer to 4.7
22 Output (digital) A_DIGITAL 16 Refer to 4.7
23 Input (analog) E_ANALOG 16 Refer to 4.7
24 Output (analog) A_ANALOG 16 Refer to 4.7
25 System deviation XERR 32 with Refer to 4.5
26 Position controller, gain factor KPC 32 with Refer to 4.5
27 Position setpoint value A XSOLL_A 32 with
28 Position actual value A XIST_A 32 with
29 Position actual value B XIST_B 32 with
30 Position actual value C XIST_C 32 with
31 Position actual value D XIST_D 32 with
32 Traversing block selection SATZANW 16
33 Actual traversing block AKTSATZ 16
34 target position TARPOS_A 32 with
35 velocity VELOCITY_A 32
36...50 Profile-specific Reserved
51 Output current IAIST_GLATT 16 Refer to 8
52 Active current ITIST_GLATT 16 Refer to 8
53 Torque actual value MIST_GLATT 16 Refer to 8
54 Active Power PIST_GLATT 16 Refer to 8
55 Frequency setpoint FSOLL 16 Refer to 8
56 Frequency actual value FIST_GLATT 16 Refer to 8
57 Speed actual value A NIST_A_GLATT 16 with Refer to 8
58 Drive status/fault word MELD_NAMUR 16 Refer to 8
59...99 Profile-specific Reserved
100..65535 Device-specific

Content Start
Version 4.0
4.4.2 Standard telegrams
Standard telegrams 1 to 4 are defined for speed setpoint interface operations (AC1 and AC4).
The standard telegrams are selected when configuring the process data (refer to 4.4.3).
The standard telegrams have the following structure:
Standard telegram 1: n set interface, 16 bit
PZD number 1 2
Setpoint STW1 NSOLL_A
PZD number 1 2
Actual value ZSW1 NIST_A
Standard telegram 2: n set interface, 32 bit, without sensor
PZD number 1 2 3 4
Setpoint STW1 NSOLL_B STW2
PZD number 1 2 3 4
Actual value ZSW1 NIST_B ZSW2
Standard telegram 3: n set interface, 32 bit, with one sensor
PZD number 1 2 3 4 5
Setpoint STW1 NSOLL_B STW2 G1_STW
PZD number 1 2 3 4 5 6 7 8 9
Actual value ZSW1 NIST_B ZSW2 G1_ZSW G1_XIST1 G1_XIST2
Standard telegram 4: n set interface, 32 bit, with two sensors
PZD number 1 2 3 4 5 6
Setpoint STW1 NSOLL_B STW2 G1_STW G2_STW
PZD number 1 2 3 4 5 6 7 8 9 ...
Actual value ZSW1 NIST_B ZSW2 G1_ZSW G1_XIST1 G1_XIST2 ...
... ... 10 11 12 13 14
... ... G2_ZSW G2_XIST1 G2_XIST2

Content Start
Version 4.0
The standard telegrams 5 and 6 are derived from standard telegrams 3 and 4 for additional
use of the Dynamic Servo Control (DSC / refer to 4.5).
Standard telegram 5: n set interface, 32 bit, with one sensor; additionally position
difference and position controller gain in the setpoint direction for DSC
PZD number 1 2 3 4 5 6 7 8 9
Setpoint STW1 NSOLL_B STW2 G1_STW XERR KPC
PZD number 1 2 3 4 5 6 7 8 9
Actual value ZSW1 NIST_B ZSW2 G1_ZSW G1_XIST1 G1_XIST2
Standard telegram 6: n set interface, 32 bit, with two sensors; additionally position
difference and position controller gain in the setpoint direction for DSC
PZD number 1 2 3 4 5 6 7 8 9 10
Setpoint STW1 NSOLL_B STW2 G1_STW G2_STW XERR KPC
PZD number 1 2 3 4 5 6 7 8 9 ...
Actual value ZSW1 NIST_B ZSW2 G1_ZSW G1_XIST1 G1_XIST2 ...
... ... 10 11 12 13 14
... ... G2_ZSW G2_XIST1 G2_XIST2
The following standard telegrams 7 and 9 are defined for positioning mode (AC 3).
Standard telegram 7: Positioning interface (transferring traversing blocks)
PZD number 1 2
Setpoint STW1 SATZANW
PZD number 1 2
Actual value ZSW1 AKTSATZ
Standard telegram 9: Positioning interface (with target position and velocity)
PZD-Number 1 2 3 4 5 6
Setpoint STW1 TARPOS_A STW2 VELOCITY_A
PZD-Number 1 2 3 4 5
Actual value ZSW1 XIST_A ZSW2 NIST_A
NOTE 1 The traversing block number is entered in standard telegram 7, in traversing block selection (SATZANW),
which the drive should then process. The actual traversing block (AKTSATZ), which is returned, indicates which
traversing block number the drive is currently processing.

Content Start
Version 4.0
NOTE 2 Standard telegram 9 transfers cyclically the target position (TARPOS_A) and the velocity (VELOCITY_A)
for decentral positioning, contrary to standard telegram 7 in which the target position and the velocity have to be
transferred by parameters.
The following standard telegram 8 is defined for the position setpoint interface (AC 5).
Standard telegram 8: x set -interface, 32 bit (position setpoint interface)
Setpoint STW1 XSOLL_A STW2 NSOLL_A
Actual value ZSW1 XIST_A ZSW2 NIST_A
The following standard telegram 20 is exclusively defined for the use of the speed setpoint
interface according to the VIK-NAMUR recommendations for process technology (AC 1).
Standard telegram 20: n set interface for the process technology, 16 bit
(refer to 8).
4.4.3 Configuring the Process Data
Process data in the data telegram may be assigned the individual setpoints/actual values
using the process data configuring (telegram configuration). The standard signals from 4.4.1
or also manufacturer-specific signals may be configured as setpoints/actual values.
There are four parameter numbers (PNU) in the profile-specific parameter section to configure
this process data.
Table 27 Parameters for configuring a telegram
PNU Significance Access Data type

authorization
915[x] PZD configuring (setpoint telegram) read / write Array[x]Unsigned16

916[x] PZD configuring (actual value telegram) read / write Array[x]Unsigned16
922 Telegram selection read / write Unsigned16
923[y] List of all of the parameters for signals (profile and device- read only Array[y]Unsigned16
specific)
P922: Telegram selection
P922 shall be readable in every Application Class.
If the telegram selection is set with the Communication System configuration or in a

manufacturer-specific way, the actual configuration shall be readable in parameter P922.

Content Start
Version 4.0
The following values are permissible:
P922 = 0 -> Telegram may be freely configured (P915[x], P916[x])
P922 = 1 -> Standard telegram 1: n set interface, 16 bit (PROFIdrive

profile, version 2)
P922 = 2 -> Standard telegram 2: n set interface, 32 bit, without sensor
P922 = 3 -> Standard telegram 3: n set interface, 32 bit, with one sensor
P922 = 4 -> Standard telegram 4: n set interface, 32 bit, with two sensors
P922 = 5 -> Standard telegram 5: n set interface, 32 bit, with one sensor;
additionally the position difference and the position controller
gain are transferred in the setpoint direction to implement DSC
P922 = 6 -> Standard telegram 6: n set interface, 32 bit, with two sensors;
additionally the position difference and the position controller
gain are transferred in the setpoint direction to implement
DSC
P922 = 7 -> Standard telegram 7: Positioning interface (transferring

traversing blocks)
P922 = 8 -> Standard telegram 8: x set-interface, 32 bit (target set

position)
P922 = 9 -> Standard telegram 9: positioning interface ( with target

position and velocity)
P922 = 10-19 -> Standard telegrams 10 -19 (reserved for PROFIdrive profile)
P922 = 20 -> n set interface for the process technology, 16 bit, see 8
P922 = 21-80 -> Standard telegrams 21 -80 (reserved for PROFIdrive profile)
P922 = 81-98 -> telegram 81-98 (reserved for encoder telegrams)
P922 = 99 -> Standard telegram 99 (reserved for PROFIdrive profile)
P922 = 100-60000 -> device-specific telegram
P922 = 60001-65535 -> Standard telegrams 60001-65535 (reserved for PROFIdrive

profile)
The following definitions are valid if selecting a telegram with P922:
The standard pre-assignment of P922 should be a value 1 - 99 for a standard telegram 1 -

99.
If P922 is changed to 0, the previous setting of P915[x], P916[x] is kept.
If P922 is changed to 1 - 65535, then P915[x], P916[x] are also changed if they have
been implemented.
To change P915 and P916, P922 has to be set to 0.

Content Start
Version 4.0
P915[x], P916[x]: Configuring PZD in the telegram (x = PZD number - 1)
Instead of selecting a telegram with parameter P922, a telegram may also be configured by
using P915[x] and P916[x].
The following definitions are valid when configuring the telegrams:
All of the signals which may be configured as process data are represented by a
manufacturer-specific defined parameter number.
The actual telegram is configured by entering the manufacturer-specific parameter number
into parameter P915[x] (setpoint telegram) and P916[x] (actual value telegram). The
process data (PZD 1...PZD n) is selected via the array index x (0 ... n-1).
It is permitted to fix the content of P 915 and P 916
A telegram configured with P915[x], P916[x] should fit to the actual telegram configuration
(i.e. the length), otherwise a device-specific alarm- or error response will be issued.
The array size depends on the way that the telegram was configured.
For PZD 1, only control word or status word 1 are permissible.
Process data which is not used is marked with zero (P915[x] = 0 or P916[x] = 0).
P923[y]: List of all the parameters for signals (y = signal number)
Using parameter P923[y], an assignment is made between the signal numbers and the
associated manufacturer-specific parameter numbers. The array index y is the number of the
signal. Array indices 1 to 99 consist of the standard signals defined in the profile (refer to
4.4.1), array indices 100 to 65535 contain the device-specific signals if they are defined.
The following is valid for parameter P923[y]:
There is an entry for all standard signals which the device supports and for the device-
specific signals.
Standard signals which are not supported are identified with the entry 0.
Gaps between device-specific signal numbers are filled with zeros.
Example for configuring a telegram
The following example specifies a standard telegram configuration (refer to P922) for the
setpoint with signal numbers 1 (STW1) and 5 (NSOLL_A), which are represented by the
manufacturer-specific parameters P833 and P711 (refer to P915[x], P923[y]).
The controller may determine the following assignments by reading-out parameters P915[x],
P923[y]:
P915[x] -> assignment: Parameter number / PZD number

P923[y] -> assignment: Parameter number/ signal number
The description elements of P711 contain information for the PZD normalization (refer to
4.4.4):
Refer to the manufacturer-specific normalization parameter P1401 (PZD reference

parameter)
Bit position for the normalization (PZD normalization)

Content Start
Version 4.0
P922 = 1 (Standard telegram 1) -> PZD 1 = STW1 / PZD 2 = NSOLL_A
PZD number 1 2 10
setpoint STW1 NSOLL_A . . . ---
P915[x] = 833 711 0

Parameter No. . . .
Descr.elements
(of P711)
P923[y] =
1
Parameter No.
PZD reference parameter
(P1401)
11 1401
0 0 12 0x000eH PZD standardization bit
1 833 P833 (STW1) (Bit14)
5 711 P711 (NSOLL_A)
99 0
x = PZD number
123 0 y = Signal number
150 345
Figure 35 Example for configuring a telegram
4.4.4 Process data normalization
Process data of the following data type is normalized:
Always: N2, N4, X2, X4

Optional: Integer16, Integer32, Floating Point
Non-normalized process data (e.g. data type Unsigned16)
The physical values may be calculated from the transferred value of a process data for non-
normalized variables (e.g. data type Unsigned16) using the parameter description elements
standardization factor (subindex 3, refer to 3.1.2) as well as variable attribute (subindex 4,
refer to 3.1.2).
Normalized process data (data types N2, N4 / X2, X4/ optional Integer16, Integer32,
Floating Point)
To calculate the physical value from the transferred value of a process data for normalized
variables (data types N2, N4 / X2, X4 / optional Integer16, Integer32, Floating Point)
additional description elements are required.
Setpoints and actual values are generally transferred as normalized process data which often
refer to various motor characteristic variables such as the maximum speed or the maximum
current. Often, these motor characteristic variables are saved in a manufacturer-specific
Content Start
Version 4.0
parameter (e.g. transferring the speed NSOLL_A = 0x4000H corresponds to 100% of P1401 =
3000 RPM).
Enabling the controller to be able to deliver setpoints to drives from various manufacturers,
this normalization information shall be able to be read out. To realize this, the already existing
parameter description elements are supplemented by the PZD reference parameter
(subindex 11, refer to 3.1.2) and PZD normalization (subindex 12, refer to 3.1.2)
components.
The PZD reference parameter component contains the parameter number of the reference
value and the PZD normalization component (the bit number of the bit) which refers to the
reference value.
Examples for normalizing process data
A controller will read out the normalization of speed setpoint NSOLL_A from the DO in order
to enter a speed setpoint of 1500 RPM:
Example A: data type = N2 100% = 0x4000H

Example B: data type = X2 100% = 0x1000H (for X = bit 12)
Example C: data type = Float 100% = 1.0 E+0
Example A and B apply to data type Integer16 as well.
To realize this, the following steps are required:
The controller shall first determine the manufacturer-specific parameter for NSOLL_A with
the standard signal number (in the example: 5) from P923[5] (in the example: 711).
The PZD reference parameter (in the example: 1401) and the PZD normalization bit (in the
example A: bit 14 corresponding to 0x4000H / in example B: bit 12 corresponding to
0x1000H) may be determined from the description element of this parameter.
The controller may calculate the setpoint to be entered by reading out the contents of
P1401 (in the example: 3000.0) and the variable attribute of P1401 (in the example: RPM).
(in the example A: 0x2000H corresponds to 1500 RPM / in the example B: 0x0800H
corresponds to 1500 RPM).
Parameter values:
P711 (example A) P711 (example B) P1401
Value e.g. 0x2000H e.g. 0x0800H 3000.0
Parameter description elements:
Identifier:
Bit 0-7 = data type 33 (N2) 43 (X2) 8 (float)
or 3 (Integer16) or 3 (Integer16)
No. of elements 1 1 1
14 12
Standardization factor 0.0061 (100 / 2 ) 0.0244 (100 / 2 ) 1.0
Variable attribute:
Variable/conversion index 24 / 0 (%) 24 / 0 (%) 11 / 67 (RPM)
Name nset nset nnorm

Content Start
Version 4.0
Lower limit value 8000H (-200%) 0x8000H (-800%) 1000.0

-14 -14
Upper limit value 0x7FFFH [(200%-2 )%] 0x7FFFH [(800%-2 )%] 10000.0
PZD reference parameter 1401 1401 0
PZD normalization:
Bit 0-5 = Normalization bit 0-31 14 (bit 14 -> 0x4000H) 12 (bit 12 -> 0x1000H) 0
Bit 15 = Normalization valid 1 (yes) 1 (yes) 0 (no)
Example C (Floating Point):
Parameter values:
P711 (example C) P1401
Value e.g. 0.5 3000.0
NOTE 0.5 corresponds to 1500 RPM
Parameter description elements:
P711 (example C) P1401
Identifier:
Bit 0-7 = data type 8 (float) 8 (float)
No. of elements 1 1
Standardization factor 100.0 (100 / 1.0) 1.0
Variable attribute:
Variable/conversion index 24 / 0 (%) 11 / 67 (RPM)
Name nset nnorm
Lower limit value -4.0 (-400%) 1000.0
Upper limit value 4.0 (400%) 10000.0
PZD reference parameter 1401 0
PZD normalization:
Bit 0-5 = Normalization bit 0-31 0 (always with float) 0
Bit 15 = Normalization valid 1 (yes) 0 (no)

Content Start
Version 4.0
4.5 Dynamic Servo Control (DSC)
4.5.1 Features
This function improves the dynamic performance of the position control loop by minimizing the
delays which normally occur with a velocity setpoint interface. In this case, only a relatively
simple expansion of the transferred setpoints and an additional feedback network are required
in the drive.
This function is upwards-compatible to the velocity setpoint interface. If required, it may be

switched over during operation to the velocity setpoint interface.
4.5.2 Structure
The control loop based on the velocity setpoint interface generally has the following structure:
Path
Interpolation n cm d NC Pos. Transmission Interpolation
Speed control
control delay (T P C ) Speed filter
x cm d x e rr n NC * n Dri ve
k pc
x ac t, NC
Speed
calculation
T pc
xact
Zero Offset and

Master Controller (NC) Compensation Drive Controller
Symbols: n cm d: : speed command T pc : position controller sampling time (= T MAP C )

x cm d : position command k pc : position controller gain
x err : position error command
x a c t : actual position
interface without DSC

Content Start
Version 4.0
The actual position calculated in the drive is also directly feed-back with DSC:
Path
Interpolation n cmd
Transmission Interpolation Position
Speed filter Speed control
delay (T PC ) control
xc m d x err n Drive
x act,NC
Speed
calculation
1 2 3 4
x act, Drive
X act,NC
T pc T pc T sc
x act
Zero Offset and

Master Controller (NC) Compensation Drive Controller
Symbols: n cm d: : speed command T sc : speed controller sampling time

x cm d : position command T pc : position controller sampling time (= T MAP C )
x err : position error command k pc : position controller gain
x a c t : actual position
interface with DSC
In order to realize this function, the system deviation calculated in the controller is transferred
in addition to the velocity setpoint. The additional feedback network (shaded) may use the
internal drive formats to represent the position, and is thereby independent of the position
representation in the controller. The diagram above assumes that the network is computed in
the velocity control clock cycle T SC , which is possible in many cases. This means that the
maximum possible dynamic performance improvement may be achieved. Higher clock cycle
times T are also possible if the calculating time is critical (T SC T T PC ).
4.5.3 Mode of operation
The structure contains a total of three feedback branches for position actual value (No. 1, 2
and 3). Feedback branch No. 2 completely compensates the effect of No. 1 regarding the
actual value x act sent from the drive. This means that the delay time in branch No. 1 no longer
has to be considered for the stability of the position control loop. Thereby, the position control
loop is initially open. Feedback branch No. 3 then re-closes the loop, however, with a lower
delay so that higher gains may be set.
The absolute reference of the position actual values is first established in the controller
(addition location Zero offset and compensation). The same absolute reference is contained
in the position set point x cmd . This means that the system deviation x err , computed in the
controller, has no zero point. The drive does not require any information about the zero points
and home positions.

Content Start
Version 4.0
4.5.4 Additional features
For a constant velocity, the transferred system deviation xerr is also constant. This makes it
extremely simply to generate an equivalent value if a telegram fails (the previous value is
reused).
The controller may select a different format for the position actual values and position setpoint
value than the drive (for example, in order to display a wider traversing range than the drive)
without loading the computational performance of the drive or having to increase telegram
formats or to modify the dynamic performance of the control loop. It is also possible to
compute feedback branch 1 referring to the load side and feedback branches 2 and 3
referring to the motor side, without changing the system behaviour.
It is permissible that the position actual value as supplied from the drive cyclically overflows,
as long as the controller is sampled often enough so that overflows such as these are
recognized. The feedback network (branches 2 and 3) shall not respond to such overflows
with transient reactions.
The cyclic overflow of the position actual values in the drive shall not be synchronized with a
mechanical overflow at the machine, but may be for example selected using the numerical
format.
4.5.5 Using multiple sensors
Feedback branch 4 for the velocity actual value always uses the motor sensor.
There are three operating situations for the feedback branches 1, 2 and 3:
1) Feedback branches 1, 2 and 3 use the motor-side sensor.

2) Feedback branches 2 and 3 use the motor sensor, feedback branch 1 the load-side
sensor.
3) Feedback branches 1, 2 and 3 use the load-side sensor.
If there is no load-side sensor case 1 always applies. In this case, feedback branch 1, 2 and 3
use the actual value from the motor sensor, whereby a different representation is possible in
branch 1 (numerical format, load reference). This case applies to for example linear or rotary
direct drives.
The feedback branches 2 and 3 may compute the motor-side actual value in a format which is
favourable for the drive; the physical weighting of a motor-side sensor increment on the load
side shall not be known.
If there is a load-side sensor which should be used for the position control loop, the two other
operating cases are practical:
In case 2, branch 1 is not completely compensated by branch 2, as the actual values of the
two sensors normally do not cover one another. However, the feedback network still acts
stable with respect to conventional control loops as not only is the load-side actual value fed
back but also the two actual values. The main advantage of this version is the fact that the
load-side actual value shall not be supplied from the drive, but may also come from a sensor
directly connected to the bus or to the controller.
Case 2 is handled in the drive as if there was no load-side sensor, i.e. the same as case 1
(not taking into account the fact, circumstances permitted, that an actual value of this sensor
is made available to the controller).

Content Start
Version 4.0
In case 3, feedback branches 2 and 3 may compute the load-side actual value in a format
which is favourable for the drive. The physical weighting of a load-side sensor increment shall
not be known. The controller shall ensure that also in this case the normalization of x err and
x act are the same at the interface so that a simple computation is possible in the drive. The
transition from the load to the motor side is made using the position controller gain factor k pc .
4.5.6 Interface
Two additional signals are transferred in the setpoint direction:
1) System deviation x err

2) Position controller gain factor k pc
These two signals have their own assigned index in signal list P923. They may be located at
any position of the telegram using parameter P915. In order to simplify the implementation in
the controller and drive, it is favourable if they are located at the end of the setpoint telegram.
The standard telegrams 5 and 6, defined for the Dynamic Servo Control (DSC) function, are
described in more detail in 4.4.2.
If the two signals x err and k pc have been configured, the feedback network in the drive is
activated. If only one of the two signals is configured, it is assumed that this is used for other
purposes and the feedback network remains inactive.
The normalization of XERR is identical to the normalization of G1_XIST1. Exception: If the

load-side actual value is transferred in G1_XIST1, and operating case 2 is present, then the
normalization of XERR corresponds to the motor-side actual value.
KPC has the unit 1/(1000s).
4.5.7 Operating states
From the drive perspective, there are two operating states, which differ as a result of k pc = 0
or k pc 0:
1) k pc = 0: The feedback network is ineffective. The position control loop in the drive is
opened. Generally, the controller uses this to completely open the position control
loop, e.g. for spindle operation or when errors occur. The controller may also select
a conventional closed-loop position control that way without having to re-configure
the drive. X err is invalid. It is recommended to send x err = 0. The velocity setpoint is
supplied via n cmd .
2) k pc 0: The feedback network is effective, the position control loop in the drive is
closed. A velocity pre-control value is entered via n cmd , which may also be zero.
The controller may change over between these two states at any time. Furthermore, the
controller may change the value of k pc at any time (for example to adapt the dynamic
performance when the gearbox ratio is changed or to compensate for non-linear gearboxes).

Content Start
Version 4.0
4.5.8 Implementation information
If the DSC functionality is used, the controller shall work with the optimized T DP cycle (T M >
T DX ) which is realized in the enhanced synchronized isochronous mode (refer to 6.7.2).
The feedback branch 2 shall precisely emulate the effect of feedback branch 1 between points
A and B. Both branches shall
1) operate with an actual value which comes from the same time instant and which is
sampled with the same frequency
2) have the same delay
3) contain the same fine interpolation
This is specified in the structure diagram (block diagram) using the dotted arrows.
The feedback network may also be re-configured by interchanging elements, as long as the
conditions are maintained, that branch 2 compensates branch 1 and branch 3 closes the
control loop. Such versions, which are structured differently, under certain circumstances, are
better emulated on existing hardware.
It is possible for example to compute branch 2 and process x err up to point B on a

communication CPU which is located in an intermediate position. However, this is assuming
that computational performance is still available and that only branch 3 and processing from
point B are calculated on the drive processor. Instead of a communication CPU, a slower time
level may be used on the drive processor.
However, when re-configuring the network, it should still be observed that actual values which
cyclically overflow cannot initiate transient reactions of the position control loop.
It is recommended that the feedback network is continuously calculated also during k pc = 0.

The memory, which is contained by the network, is always tracked in this way and the
transition to k pc 0, which may occur at any time, is easier to implement.
For a transition to k pc 0, the interpolation filters in the x err branch and in the n cmd branch
shall be bypassed for one clock cycle (T PC ).
For a transition to k pc = 0, the drive-internal controller output goes to zero as a jump function.
The controller simultaneously increases n cmd by the same absolute value also as a step
function so that the velocity sum at the speed controller input always runs continuously. In
order for this to also work during motion, the interpolation filter shall be bypassed in the n cmd
branch for one clock cycle (T PC ).
The velocity setpoint filter ("speed filter") specified in the block diagram is optional and has
nothing to do with the DSC function. It has only been drawn-in to make a clear differentiation
to conventional closed-loop position control structures.

Content Start
Version 4.0
4.6 Position feedback interface
4.6.1 Overview
The position feedback interface defined in this profile is an interface between the Axis and a
higher level control. The interface gives the possibility for the control to get position feedback
information over the PROFIdrive Interface taken from the sensors connected to the Drive. The
functionality described in the position feedback interface is implemented in the drive, not in
the sensor itself.
A position feedback interface consists of the following objects that may be used for telegram
configuring (refer to 4.4.3) through assignment (process data number/parameter number):
Gx_STW Control Word Control of the sensor functionality

Gx_ZSW Status Word Sensor states, sensor acknowledgements, sensor
error messages ...
Gx_XIST1 Actual Position-1 Actual position value
Gx_XIST2 Actual Position-2 Additional actual position value
These objects Gx_* are available for a max. of 3 sensors (Gx = Sensor 1 to 3), and may also
be used individually (for example, only G1_STW).
The sensors are parameterized via device-specific parameters.
The position feedback interface is defined for the application with a cyclic speed setpoint
interface.
G1_STW
G2_STW
communication system Drive Unit
Controller
DO
G1_ZSW G1_XIST1 G1_XIST2
G2_ZSW G2_XIST1
Figure 38 Example of the sensor interface (Sensor-1: two actual values / Sensor-2:
one actual value)
4.6.2 Actual positions
Because of possible user data failure actual positions (Gx_XISTx) cannot be transmitted as
partial actual values. For that reason, cyclically absolute actual position values are always
transmitted (i.e. after a certain number of revolutions there is an actual position overflow).
In Data_Exchange the drive always - independent of the controller's operating modes Clear
and Operate -sends the actual positions (Gx_XISTx).
The following applies to the evaluation of the actual positions (Gx_XISTx):
The receiver may evaluate an actual position incrementally, whereby the zero point is set
by approaching a home position and by setting it, or by the controller reading an absolute
value (refer to explanation below). This may be applied to all sensor types.
An actual position value may also be viewed as an absolute value (which may if
necessary, be charged up only against a zero shift in the controller), if limited to absolute
Content Start
Version 4.0
sensors on axes with a finite traversing range (which is less than the display range of the
sensor).
In the case of continuously rotating axes, incremental evaluation is preferable (no modulo
handling in the drive).
It should be possible for the controller to select the modulo range and the modulo strategy
(there should be none in the drive). If the drive permits modulo processing, this should be
able to be disabled via a parameter.
Explanation:
The actual position value transmitted in Gx_XISTx is an absolute actual value which the drive
may simply set to 0 when it is started and after the parking sensor has been disabled. For that
reason, a higher level control should only use the position differences between two position
controller cycles to calculate its internal actual position value.
A sensor shall deliver Gx_XIST1. If a sensor only uses a serial protocol and therefore has
only an absolute value, then this value will be delivered in Gx_XIST2 and also in
Gx_XIST1.
An increase in the Shift factor automatically results in an increase in resolution. This
should go for Gx_XIST1 and the absolute value in Gx_XIST2 as far as technically
possible.
(That means there will not only be padding with zeros inserted if the values are shifted
further to the left.)
The absolute value in Gx_XIST2 shall be valid at the same time as that from Gx_XIST1.
Only then is the absolute value usable to make corrections to the incremental value.
This means that the drive shall also make corrections to the absolute value via the
incremental value: several sampling periods may pass till the absolute value is available
from the sensor. This old absolute value shall be compensated with the incoming
incremental position to create the same valid instant in time for both values.
Assigning different functions to the Gx_XIST2 (as well as the normalization of Gx_XIST2
at the different functions) is governed by a prioritization of the functions (refer to Table
32).
The profile parameter P979 sensor format contains the important properties of the sensors.
It may be read out how Gx_XIST1 and Gx_XIST2 are normalized.
4.6.2.1 Structure of parameter 979 sensor format
Table 28 Structure of parameter 979 (sensor format)
Subindex Meaning Comments
0 Header information for the indices 1 to n

1 Sensor type 1. sensor (G1)
2 Sensor resolution 1. sensor (G1)
3 shift factor for G1_XIST1 1. sensor (G1)
4 shift factor for absolute value in G1_XIST2 1. sensor (G1)
5 Determinable resolutions 1. sensor (G1)
6 10 reserved for future use 1. sensor (G1)
11- 20 analog to Subindex 1 to 10 2. sensor (G2)
21 30 analog to Subindex 1 to 10 3. sensor (G3)
31 n reserved for the profile

Content Start
Version 4.0
Subindex 0: Header
Table 29 Subindex 0 (header) of parameter 979
Bits Meaning
03 Version of the parameter structure, least significant number (value range: 0..15)
This version field is incremented when additional data description information is added or when
assigning previously unassigned bits (compatible extension).
0: reserved
1: Identifier for the presented structure
>8: manufacturer-specific (the manufacturer has included additional indices, whereas those
defined in the profile remain unaltered.)
47 Version of the parameter structure, most significant number (value range: 0..15)
This version field is incremented when previously defined data description information is
modified. (incompatible modification)
0: reserved
1: Identifier for the presented structure
>8: manufacturer-specific
8 11 Number of described sensors (Gx) in the parameter. (value range: 0..15)
Its recommended to limit the number of described sensors to the number of active sensor
interfaces to reduce communication overhead between controller and DO.
12 15 Number of the assigned indices describing a sensor (sensor substructure). (value range: 5..10)
16 31 Reserved for future use
Subindex 1: Sensor type
Table 30 Subindex 1 (sensor type) of parameter 979
Bits Meaning
0 = 0 Rotary sensor
= 1 Linear sensor
1 = 0 A fine resolution in Gx_XIST1 is to be taken relative. This means the position of the sensor
signal within a sinus signal is not displayed in the switch-on instant.
= 1 A fine resolution in Gx_XIST1 displays the absolute position within a signal period. The
transferred value may be interpreted as absolute value, because the fine resolutions are
synchronous in every switch-on instant.
2 = 0 No 64 Bit absolute information available.
= 1 Reserved for future extensions: 64 Bit absolute information available.
3 30 Reserved for future use.
31 = 0 Data in parameter 979 substructure Gx is invalid
= 1 Data in parameter 979 substructure Gx is valid
Subindex 2: Sensor resolution
Table 31 Subindex 2 (sensor resolution) of parameter 979
Rotary sensor Number of pulses (=signal period) per revolution
Linear sensor Length of a signal period in Nanometers
The meaning results from Subindex 1 Bit 0.

This value is equally valid for Gx_XIST1 and the absolute value in Gx_XIST2. This implies that Gx_XIST1 and
the absolute value in Gx_XIST2 shall be able to be broken down to the same elementary unit when different
resolutions are present.
If the sensor delivers no signal period (=A and B-tracks) but instead a serial protocol, then the following is
valid: For a rotary sensor, the parameter contains the number of increments per revolution. For a linear
sensor, the parameter contains the increment length in Nanometers.

Content Start
Version 4.0
Subindex 3: Shift factor for Gx_XIST1
Specifies how many bits defining the sum of quadrant information and fine resolution are
displayed in Gx_XIST1. (value range: 0..32).
The fine resolution results from the signal period interpolation. An Impulse quadruplication
or arctangent interpolation evaluation is to be calculated to the fine resolution. Only values
of 2^n are possible for the Shift factor because the fine resolution should be interpretable
within a signal period (see Subindex 1 Bit 1). Thereby overflows in the fine resolution always
fall on a bit-boundary.
Sensors whose resolutions are less than 32 bits, may set their sensor information left
justified, so that the bit is known at which the modulo overflow takes place.
Subindex 4: Shift factor for absolute value in Gx_XIST2
Specifies how many bits defining the sum of quadrant information and fine resolution of the
transmitted absolute value in Gx_XIST2 are to be displayed. (value range: 0..32) (see also
Subindex 3).
Subindex 5: Determinable revolutions
Specifies which absolute position information may be delivered by the sensor. This is relevant
for rotary and also linear sensors.
Rotary sensors:
A value of 0 indicates that the sensor has no absolute information or may only display
values less than one absolute revolution. (For example a multipole resolver). Notice,
that with value = 0, the sensor interface will not support the absolute value reading
function via Gx_XIST2.
A value of 1 indicates that the sensor may display exactly one absolute revolution.(For
example a resolver with 1 pole pair). Notice, that with values of 1 or greater, the
encoder interface shall support the absolute value reading functionality via Gx_XIST2.
Values greater than 1 mark a multi-turn sensor (For example, 4096 is a commonly
used value).
Linear sensors:
A value of 0 indicates that the sensor has no absolute information. (For example
standard incremental linear scale).
A value of 1 or greater indicates that the sensor delivers absolute position information.

Content Start
Version 4.0
4.6.2.2 Examples of the actual value format
Meaning of the abbreviations:
F: fine resolution
P: pulses
Q: quadrant information (quadrants which are calculated of the signs of sinus and cosine)
R: revolutions
In these examples all Gx_XIST1 are specified with shift factor 11 (P979.3=11), except in
example 8. All Gx_XIST2 are specified with shift factor 9 (P979.4=9), except in examples 3, 5,
7 and 8.
The fine resolution information is optional and defined device-specific according to the quality
of the position feedback interface. The shift factor for Gx_XIST1 may be freely defined by the
application and may not match the internal resolution of the fine interpolation of the drive.
Unused bits of fine resolution in the actual value format shall be filled with zero bit value by
the drive. The maximum fine resolution the drive is capable to deliver need not be evaluated
out of P979.
EXAMPLE 1 multi-turn absolute value encoder with additional incremental tracks
12 Bit revolutions (multi-turn), 11 Bit increments (2048 pulses per revolution)
Gx_XIST1: integrated; initial value arbitrary
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
R R R R R R R R R R P P P P P P P P P P P Q Q F F F F F F F F F
absolute value in Gx_XIST2
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
R R R R R R R R R R R R P P P P P P P P P P P Q Q F F F F F F F
EXAMPLE 2 multi-turn absolute value encoder with additional incremental tracks
12 Bit revolutions (multi-turn), 9 Bit increments (512 pulses per revolution)
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
R R R R R R R R R R R R P P P P P P P P P Q Q F F F F F F F F F
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 R R R R R R R R R R R R P P P P P P P P P Q Q F F F F F F F

Content Start
Version 4.0
EXAMPLE 3 incremental encoder (with additional C/D tracks for commutation information)
11 Bit increments (2048 pulses per revolution), C/D tracks are with no effect on
the actual value format
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
R R R R R R R R R R P P P P P P P P P P P Q Q F F F F F F F F F
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
error code
EXAMPLE 4 linear absolute value encoder with additional incremental tracks
25 Bit, one period of the incremental track is divided in 160 values of the
protocol, 250000 pulses in 4 meters = 17.9 Bit
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
P P P P P P P P P P P P P P P P P P P P P Q Q F F F F F F F F F
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 0 0 0 P P P P P P P P P P P P P P P P P P Q Q F F F F F F F
EXAMPLE 5 "only" incremental encoder
5000 pulses = 12.28 Bits (decimal pulses)
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
P P P P P P P P P P P P P P P P P P P P P Q Q F F F F F F F F F
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
error code

Content Start
Version 4.0
EXAMPLE 6 2-pole resolver
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
R R R R R R R R R R R R R R R R R R R R R Q Q F F F F F F F F F
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Q Q F F F F F F F
EXAMPLE 7 8-pole resolver
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
R R R R R R R R R R R R R R R R R R R P P Q Q F F F F F F F F F
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
error code
EXAMPLE 8 "only" absolute value encoder (no additional incremental tracks)
25 Bit, thereof 8192 (13 bits) steps per revolution and 4096 (12 bits)
distinguishable revolutions
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
R R R R R R R R R R R R R R R R R R R P P P P P P P P P P P P P
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 0 0 0 0 0 R R R R R R R R R R R R P P P P P P P P P P P P P

Content Start
Version 4.0
4.6.3 Assigning the actual values in the telegram
Object Gx_XIST1 is used exclusively to transfer the cyclic position actual value.
The assignment of Gx_XIST2 with different functions (and the normalization of Gx_XIST2 for
the various functions) is controlled by the following priority assignment of the various
functions.
Table 32 Assigning Gx_XIST2 (sensor-x position actual value-2)
Prio Function Info from Info from Gx_XIST2 assignment Gx_XIST2

Gx_ZSW Gx_STW normalization
-- Communication in Preparation x Position actual value (cyclic) as in P979

1 Parking sensor x Not valid --
2 Sensor error x Device-specific error code --
3 Reference mark search x x Position actual value as Gx_XIST1 in
(reference mark or measured P979
or value)
measurement on the fly
4 Absolute value cyclically x Position actual value (cyclic) as in P979
If the Communication System is in the Clear state, it is recommended to transmit the

absolute position actual value in Gx_XIST2 automatically if already present in the drive. A
valid absolute position actual value in Gx_XIST2 is indicated by Gx_ZSW, bit 13. This helps
the controller to synchronize faster to the drive and therefore shortening the overall system
startup time.
4.6.4 Error codes in Gx_XIST2
Table 33 Error codes in Gx_XIST2
Gx_XIST2 Meaning Explanation
0x0001 Sensor group error Error in the processing of the sensor signal which causes
an invalid Gx_XIST (e.g. electronic malfunction, invalid
sensor signal input, )
0x0002 Zero mark monitoring Warning about inconsistence between correctly
processed Gx_XIST and sensor reference signal (e.g. lost
pulses, )
0x0003 Failure parking sensor Error because of not possible transition to SD12
(parking). This may be e.g. because the drive is currently
running (state S4) and the motor measurement system is
forced to parking.
0x0004 Abort reference value search Error occurred during the initialization or during the
search for reference mark.
0x0005 Abort reference value retrieval Error occurred during reading of the reference value.
There is no valid reference value or the command is not
allowed.
0x0006 Abort measurement on the fly Error occurred during the initialization or during the action
of the function measurement on the fly.
0x0007 Abort measured value retrieval Error occurred during reading the result of the function
measurement on the fly. There is no valid value or the
command is not allowed.
0x0008 Abort absolute value transmission Error because of not possible absolute value transmission
from encoder to the feedback interface. This may be e.g.
because of an absolute value encoder (with serial
interface) not present or not working.
0x0009 Abort absolute value transmission reserved

Content Start
Version 4.0
Gx_XIST2 Meaning Explanation
0x000A Abort absolute value transmission Absolute value track of encoder not readable
0x000B Abort absolute value transmission reserved
0x000C 0x0F00 reserved
0x0F01 Command not supported Error because of not supported optional function (e.g.
shift/preset home position)
0x0F02 0x1000 reserved
from 0x1001 manufacturer-specific
4.6.5 Position feedback control word
Table 34 Sensor control word
Bit Value Meaning Comments
0 1 Function requests a : Function 1-4:

1 1 Request reference mark search (Bit 7 = 0)
2 1 Reference mark Bit 0: Function 1 (Reference Mark 1)
search,
3 1 Bit 1: Function 2 (Reference Mark 2)
measurement on the
Bit 2: Function 3 (Reference Mark 3)
fly
Bit 3: Function 4 (Reference Mark 4)
Request measurement on the fly (Bit 7 = 1)

Bit 0: Function 1 (Probe 1 pos. edge)
Bit 1: Function 2 (Probe 1 neg. edge)
Bit 2: Function 3 (Probe 2 pos. edge)
Bit 3: Function 4 (Probe 2 neg. edge)
4-6 1-3 Command: 0: ----
1: activate Functions b x (specified by bits 0-3, 7)
2: read Value c x (specified by bits 0-3, 7)
3: cancel Functions d x
4-7: reserved (activation causes an error)
7 0/1 Mode:
Bit 7 = 0: Reference mark search (zero mark or BERO)
Bit 7 = 1: Measurement on the fly
8 Reserved (without effect)
11 0/1 Home position mode Modifier for home position mode:
Bit 11 = 0: set home position (absolute)
Bit 11 = 1: shift home position (relative)
12 1 Request set/shift Request for set/shift of home position.
of home position e Edge-triggered. Handshake with Gx_ZSW, bit 12.
Definition of preset / shift value is device-specific.
13 1 Request absolute Request of additional cyclic transmission of the absolute actual position in
value cyclically f Gx_XIST2.
Used for, for example: - additional measuring system monitoring
- synchronization at running-up
Content Start
Version 4.0
14 1 Activate parking Request to switch off monitoring of the measuring system and the actual
sensor value measurements in the drive. This makes it possible to remove a
sensor (or a motor with a sensor) on the machine without having to change
the drive configuration, or without causing a fault. Also when parking of the
sensor interface is instructed by this Gx_STW1, bit14, all actual errors of
the sensor interface are cleared. Typically the parking of the motor
measurement system while the drive is running (S4) is not allowed and will
result in a sensor interface error (Error code 0x3 in GxXIST2)
15 1 Acknowledging a Request to reset a sensor error (Gx_ZSW, bit15)
sensor error
a
Selection of Function (bit 0 to 3) and Command (bit 4 to 7) shall be set simultaneously. If a Command is
requested without having selected a valid Function (bit 0 to 3 are all zero), the function request will cause an
error (error code 0x04 0x07) and the position feedback interface changes to the SD3 state.
b
Activation of multiple functions with one command is possible (e.g. sensor control word = 0x0013). If only one
of this multiple function request causes an error, none function of this function request is performed and the
position feedback interface changes to the SD3 state
c
Only one function shall be selected. If more than one function is requested, the position feedback interface
changes to the SD3 with error code 0x05 or 0x07 in Gx_XIST2.
d
The cancel function command will cancel all functions (sensor control word bits 0 to 3 are with no effect) and
force the position feedback interface to change to the SD1 state (until it is not already parked or in error state).
e
Set-/Shift home position functionality is an optional functionality. If not implemented, requesting this function
will cause an error with error code 0xF01 in Gx_XIST2.
f
If the PROFIBUS is in the Clear state, it is recommended to transmit the absolute position actual value in
Gx_XIST2 automatically if already present in the drive. A valid absolute position actual value in Gx_XIST2 is
indicated by Gx_ZSW, bit 13 (refer to 4.6.3).
4.6.6 Position feedback status word
Table 35 Sensor status word
0 1 Function status: Status a : Function 1-4 active (reference mark search / measurement on the
fly)
1 1
2 1 Reference mark
search, Bit 0: Function 1 (Reference Mark 1 / Probe 1 pos. edge)
3 1
or Bit 1: Function 2 (Reference Mark 2 / Probe 1 neg. edge)
measurement on the Bit 2: Function 3 (Reference Mark 3 / Probe 2 pos. edge)
fly
Bit 3: Function 4 (Reference Mark 4 / Probe 2 neg. edge)
4 1 Status: Value 1 to 4 available (reference mark / probe )

5 1
6 1 Bit 4: Value 1 (Reference Mark 1 / Probe 1 pos. edge)
7 1 Bit 5: Value 2 (Reference Mark 2 / Probe 1 neg. edge)
Bit 6: Value 3 (Reference Mark 3 / Probe 2 pos. edge)
Bit 7: Value 4 (Reference Mark 4 / Probe 2 neg. edge)
Simultaneously to bit 0 to 3 (value available only if related function is

available).
8 1 Probe 1 Static mode Probe 1
deflected

Content Start
Version 4.0
9 1 Probe 2 Static mode Probe 2

deflected
10 Reserved, set to zero
11 requirement of error acknowledgement detected
12 1 set /shift of home Acknowledgement for Request for set/shift of home position.
position executed b
Edge triggered. Signals the setting/shifting of Gx_XIST1 and Gx_XIST2
value. Handshake with Gx_STW, bit 12.
13 1 Transmit absolute Indication of cyclic transmission of the absolute actual position in

value cyclically c Gx_XIST2.
Reaction on Gx_STW, bit 13 (request absolute value cyclically) or
PROFIBUS in state Clear
14 1 Parking sensor Acknowledgement for activate parking sensor (Gx_STW, bit 14) or
indication of invalid Gx_XIST1.
active d
15 1 Sensor error Signalizes a sensor error or an error in the actual value measurement. A
device-specific error code is provided in Gx_XIST2. If more errors occur
only the first will be shown.
a
If a function request causes an error, all functions are cancelled and the position feedback interface changes
to the SD3 state, which means that the sensor status bits 0 to 7 are set to zero and the sensor error bit 15 is
set ( the corresponding error code is provided in Gx_XIST2). Example: The function reference mark search for
reference mark 1 to 4 is activated (sensor control word = 0x001f) while the drive only supports two reference
marks. This will cause the sensor status word = 0x8000 and the 0x04 error code in Gx_XIST2.
b
Set-/Shift home position functionality is an optional functionality. If not implemented, bit 12 will be 0.
c
If the PROFIBUS is in the Clear state, it is recommended to transmit the absolute position actual value in
Gx_XIST2 automatically if already present in the drive. A valid absolute position actual value in Gx_XIST2 is
indicated by Gx_ZSW, bit 13 (refer to 4.6.3).
d
If the position feedback interface is in the state parking (SD12), bit 14 is set and only bits 8, 9, 14 of the
sensor status word are serviced, all other bits shall be set to zero.

Content Start
Version 4.0
4.6.7 State diagram of the position feedback interface
4.6.7.1 State diagram
TD30
BD2
optional add-on
SD14 TD26 SD13
parking parking & error

& error acknowledgement
TD27
TD23
TD28 TD 29 TD24 TD25
SD12 SD2 SD3

TD22
parking error acknowledgement error
TD21 (errorcode in Gx_XIST2)
TD16
TD20
BD1 TD17
SD11 SD4
measured value reference value in
in Gx_XIST2 Gx_XIST2
TD1
TD15 TD2
TD14 TD3
SD10 SD1 SD5

TD13 TD4
wait for wait for
normal operation
measured values reference marks
TD12 TD5
TD19 TD11 TD6 TD18
TD10 TD9 TD8 TD7
SD9 SD6
check measuring check reference task

task SD7
SD8
absolute value cyclically set / shift
in Gx_XIST2 home position
Figure 39 State diagram of the position feedback interface with designations of the
states and transitions

Content Start
Version 4.0
4.6.7.2 States
SD1 normal operation:
Action: None
Explanation: The position feedback interface operates normally.
Identification: Gx_ZSW bit 0-7 = 0000 0000b, Gx_ZSW bit 10-15 = 00 00x0b
SD2 error acknowledgement:

Action: Error is acknowledged.
Explanation: Error acknowledgment is being processed.
Identification: Gx_ZSW bit 11 = 1, bit 0-7 = 0000 0000b, Gx_ZSW bit 15 = 1 as long
as valid Errorcode is posted in Gx_XIST2 (as long as error is present).
SD3 error:
Action: Errorcode is posted in Gx_XIST2.
Explanation: There is an error present.
Identification: Gx_ZSW bit 15 = 1, Gx_ZSW bit 11 = 0, bit 0-7 = 0000 0000b
SD4 reference value in Gx_XIST2:

Action: Load reference value in Gx_XIST2.
Explanation: The reference value is loaded in Gx_XIST2.
Identification: Gx_ZSW bit 4-7 <> 0000b, bit 0-3 = 0000b
SD5 wait for reference marks:

Action: Wait for reference marks
Explanation: The reference mark is expected.
SD6 check reference task:

Action: Check reference task
Explanation: The referencing task is checked.
SD7 set / shift home position:

Action: set or shift value in Gx_XIST1 and Gx_XIST2
Explanation: Gx_XIST1 and Gx_XIST2 are set or shifted by a predefined preset
value. Set or shift is controlled by the mode bit Gx_STW, bit 11. See
also Note 1.
Identification: Gx_ZSW bit 12 = 1 (edge triggered), bit 0-7 = 0000 0000b
SD8 absolute value cyclically in XIST2:

Action: Load the absolute value cyclically in Gx_XIST2
Explanation: An absolute value is cyclically loaded in Gx_XIST2.
Identification: Gx_ZSW bit 13 = 1, bit 0-7 = 0000 0000b

Content Start
Version 4.0
SD9 check measuring task:

Action: Check measuring task
Explanation: The measuring task is checked.
SD10 wait for measured values:

Action: Wait for measured value
Explanation: The measured value is expected.
SD 11 measured value in XIST2:

Action: Load measured value in Gx_XIST2
Explanation: The measured value is loaded into Gx_XIST2.
SD 12 parking:
Action: All errors are cleared if Gx_STW bit 14 = 1.
Explanation: The position feedback interface is in a state where it is inactive and
does not deliver a valid Gx_XIST1 value. This is also the position
feedback interface initial state. See also Note 2.
Identification: Gx_ZSW bit 14 = 1
SD 13 parking & error (optional):

Action: Errorcode is posted in Gx_XIST2.
Explanation: There is an error present and Gx_XIST1 is signalled invalid.
Identification: Gx_ZSW bit 15 = 1, Gx_ZSW bit 14 = 1, Gx_ZSW bit 11 = 0,
bit 0-7 = 0000 0000b.
SD 14 parking & error acknowledgement (optional):

Action: Error is acknowledged.
Explanation: Error acknowledgement is being processed while Gx_XIST1 is
signalled invalid.
Identification: Gx_ZSW bit 14 = 1, Gx_ZSW bit 11 = 1, bit 0-7 = 0000 0000b,
Gx_ZSW bit 15 = 1. Errorcode is posted in Gx_XIST2 (as long as error
is present).
NOTE 1 Concerning set/shift home position:

The preset function supports the adaptation of the encoder zero point to the mechanical zero point of the system.
The set/shift home position function has an absolute and a relative operation mode selectable by bit 11 in the
Gx_STW1. The value to be taken for the set/shift function cannot be set dynamically by the process data. It is 0 by
default and may be set device-specific. The set/shift value is given in scaled measuring units. When set/shift of
home position is requested, the position feedback interface reads the current position value and calculates an
internal offset value from the preset value and the read position value. The position feedback interface
acknowledges the preset by setting bit 12 in the sensor status word. Bit 12 in the sensor control word may now be
set to zero by the controller. The position feedback interface will end the preset cycle by clearing bit 12 in the
sensor status word. The preset/shift home position functionality is optional.
NOTE 2 Concerning parking a sensor:

A parked sensor delivers no valid Gx_XIST1 values. The position feedback interface may be in the parked state
because of instructed parking which is initiated by Gx_STW bit 14 = 1 or because of autonomous parking which
is initiated internally by an invalid Gx_XIST1. If the position feedback interface is in instructed parking, the

Content Start
Version 4.0
interface is completely deactivated and therefore will not generate any error messages. Also all actual errors are
cleared. If allowed by the hardware, an instructed parked sensor may be separated from the drive. Data validity in
P979 for the respective sensor will be indicated by Bit 31 in Subindex 1 (see 0).
Reactivating the sensor: When a sensor becomes reactivated, a new initialization of the sensor is carried out.
4.6.7.3 Transitions
TD1 From: SD2 (error acknowledgment)
To: SD1 (normal operation)
Condition: Gx_STW bit 15 = 0 and error removed
TD2 From: SD4 (reference value in Gx_XIST2)
Condition: Gx_STW bit 4-6 = 000b
TD3 From: SD1 (normal operation)
To: SD4 (reference value in Gx_XIST2)
Condition: Gx_STW bit 7 = 0 and Gx_STW bit 4-6 = 010b and

Gx_STW bit 0-3 <> 0000b and Reference value is found
TD4 From: SD5 (wait for reference marks)
Condition: Gx_STW bit 4-6 = 000b and reference mark found
TD5 From: SD5 (wait for reference marks)
To: SD6 (check reference task)

Gx_STW bit 0-3 <> 0000b
To: SD7 (set / shift value in Gx_XIST1 and Gx_XIST2)
Condition: Gx_STW bit 12 = 1

Content Start
Version 4.0
TD8 From: SD7 (set / shift value in Gx_XIST1 and Gx_XIST2)
TD9 From: SD8 (absolute value cyclically in Gx_XIST2)
To: SD8 (absolute value cyclically in Gx_XIST2)
To: SD9 (check measuring task)

Gx_STW bit 0-3 <> 0000b
TD12 From: SD10 (wait for measuring task)
TD13 From: SD10 (wait for measuring task)
Condition: Gx_STW bit 4-6 = 000b and measured values found
To: SD11 (measured value in Gx_XIST2)

Gx_STW bit 0-3 <> 0000b and Measured value is found
TD15 From: SD11 (measured value in Gx_XIST2)

Content Start
Version 4.0
TD16 From: Every state in BD1
To: SD12 (parking)

additional condition, when SD13, SD14 are implemented:
or when (Gx_XIST1 is invalid and no error is occurred or present)
Notice: Condition changed related to profile Version 3
TD17 From: SD12 (parking)
Condition: Gx_STW bit 14 = 0 and Gx_ZSW bit 14 was set for at least 100 ms
additional condition, when SD13, SD14 are implemented:
and Gx_XIST1 is valid
TD18 From: SD6 (check reference task)
To: SD5 (wait for reference mark)
Condition: Task legal
TD19 From: SD9 (check measuring task)
To: SD10 (wait for measuring task)
Condition: Task legal
TD20 From: from every state in BD1
To: SD3 (error)
Condition: Error occurred or a command is illegal
TD21 From: SD3 (error)
To: SD2 (error acknowledgment)
Condition: Gx_STW bit 15 = 1 and Gx_XIST1 valid
To: SD3 (error)
Condition: Gx_STW bit 15 = 0 and an error still exists while Gx_XIST1 is valid

Content Start
Version 4.0
TD23 From: Every state in BD2
To: SD12 (parking)
Condition: Gx_STW bit 14 = 1 or

(Gx_STW bit 15 = 0 and error removed, while Gx_XIST1 is invalid)
Notice: Condition changed related to profile Version 3
TD24 From: SD3 (error)
To: SD13 (parking & error)
Condition: Gx_XIST1 invalid
TD25 From: SD13 (parking & error)
To: SD3 (error)
Condition: Gx_XIST1 valid and Gx_ZSW bit 14 = 1 for at least 100 ms
TD26 From: SD13 (parking & error)
To: SD14 (parking & error acknowledgement)
Condition: Gx_STW bit 15 = 1 while Gx_XIST1 invalid
TD27 From: SD14 (parking & error acknowledgement)
Condition: Gx_STW bit 15 = 0 and error still exists
To: SD14 (parking & error acknowledgement)
Condition: Gx_XIST1 invalid while Gx_STW bit 15 = 1
TD29 From: SD14 (parking & error acknowledgement)
To: SD2 (error acknowledgment)
Condition: Gx_XIST1 valid and Gx_ZSW bit 14 was set for at least 100 ms while
Gx_STW bit 15 = 1
TD30 From: SD12 (parking)
Condition: Gx_STW bit 14 = 0 and (Gx_XIST1 invalid and an error or an illegal

command is occurred)

Content Start
Version 4.0
The functions which may be executed are prioritized as follows (the function with the highest
priority is specified first):
Gx_STW bit 14
Gx_STW bit 15 (priority only if position feedback interface is in error state SD3)
Gx_STW bit 4-6
Gx_STW bit 12
Gx_STW bit 13
4.6.8 Device-specific expansions
A measurement on the fly/reference mark search may be optimized through the following
device-specific steps:
Using the additional actual positions XISTA,-B,-C,-D (the actual values requested by the
controller are then not multiplexed in Gx_XIST2, but are made available in XISTA,-B,-C,-
D).
Edge change (0 -> 1) of the status signal Value 1 - 4 available already with edge change
(1 -> 0) of the status signal Function 1 - 4 active (the controller may access the values
immediately).
Edge change (1 -> 0) of the status signal Value 1 - 4 available with recognition of the
next command for this function 1 - 4.
XISTA Actual Position A Additional actual position value
XISTB Actual Position B Additional actual position value
XISTC Actual Position C Additional actual position value
XISTD Actual Position D Additional actual position value
The objects XISTA,-B,-C,-D are independent of the sensor.
The following rules apply to the assignment of functions 1 - 4 to the additional actual values:
a) Function 1 -> XISTA

Function 2 -> XISTB
Function 3 -> XISTC
Function 4 -> XISTD
b) XISTA,-B,-C,-D not in the telegram -> Function 1 - 4 in Gx_XIST2 multiplexed

Content Start
Version 4.0
EXAMPLE 1 Measurement on the fly
Example for:
Probe 2 positive edge (function 3)
Position control with sensor 1

Bit7=1
In-process Measurement
o o
Mode
G1_STW, Bit 7
Bit2=1
Probe 2 Edge
o o
Function 3
G1_STW, Bit 2
Bit4-6=1 Bit4-6=2
Function 3 activate Read Value 3
Command
G1_STW, Bit 4-6
Bit2=1
Function 3 active
G1_ZSW, Bit 2
Bit6=1
Value 3 available
Value 3 available
G1_ZSW, Bit 6
Bit9=1 Bit9=1
Probe 2 deflected
G1_ZSW, Bit 9
Probe 2 Edge
(actual value-Latch)
Figure 40 Timing diagram: Measurement on the fly

Content Start
Version 4.0
EXAMPLE 2 Reference mark search
Example for:
Distance-coded referencing, two reference marks (Function1/Function 2)
Position Control with Sensor 1
Mode Bit7=0
G1_STW , Bit 7 referencelabel search
o o o
Bit0=1 Bit0=1
reference label reference label 1
o o
Function 1 1
G1_STW , Bit 0
Bit1=1 Bit1=1
reference label 2 referencelabel 2
Function 2 o o
G1_STW , Bit 1
Bit4-6=1 Bit4-6=2 Bit4-6=2

Function 1/2 activate read Value 1 read Value 2
Command
G1_STW , Bit 4-6
Bit0=1
Function 1 active
Function 1 active
G1_ZSW , Bit 0
Bit1=1
Function 2 active
Function 2 active
G1_ZSW , Bit 1
Bit4=1 Bit5=1
Value 1 available Value 2 available
Value 1/2 available
G1_ZSW , Bit 4/5
Reference label 1/2 1 2

(actual value-Latch)
Figure 41 Timing diagram: Reference mark search

Content Start
Version 4.0
4.7 Periphery
A drive hardware may also include I/O peripherals (onboard periphery) which is related to a
DO. These I/O peripherals may also be made accessible via PROFIdrive.
A signal number is assigned to each I/O type (refer to 4.4.1):
21 E_DIGITAL Input (digital) 16 bits

22 A_DIGITAL Output (digital) 16 bits
23 E_ANALOG Input (analog) 16 bits
24 A_ANALOG Output (analog) 16 bits
When configuring process data (refer to 4.4.3) an I/O signal number may be assigned to a
process data (PZD).
EXAMPLE
PZD number 1 2 3 4 5
Setpoint STW1 NSOLL_B A_DIGITAL A_DIGITAL
PZD number 1 2 3 4 5 6 7
Actual value ZSW1 NIST_B E_DIGITAL E_DIGITAL E_ANALOG E_ANALOG
Mapping the I/O area within the drive and parameter assignment of the I/O is defined to be
device-specific.

Content Start
Version 4.0
4.8 Warnings, messages, faults, diagnostics
4.8.1 Overview
A brief overview about the principle methods PROFIdrive provides for diagnostic functionality
is shown in Figure 42. Notice, that the fault buffer mechanism is the only mandatory
diagnostic functionality, and only the mechanism is specified.
drive exception Warnings are signaled and cleared

state autonomous by the drive optional
warning
mechanism
show
OK actual state actual state
provide specific
actual state
transitions
fault message
fault buffer
not mechanism show history of
OK
state transition
record state
mapping of actual fault situation
and
transitions
do fault acknowledge
(fault messages)
onto fault classes
Drive Fault entries must be acknowledged

mapping of warnings
onto fault classes
to disappear
fault classes standard diagnosis

mechanism mechanism
vendor independent PROFIdrive

PROFIdrive fault classes
fault classes standard alarm
mechanism
Figure 42 Overview about the diagnostic mechanisms of PROFIdrive
4.8.2 Warning mechanism
Parameters 953 to 960 (warning words) of data type V2 are reserved for the warning
mechanism. Other parameters may be used for this purpose in a manufacturer-specific way.
Every bit of a warning word is assigned a Drive Axis exception state. Bit value "0" signifies
"warning not present" (OK); bit value "1" signifies "warning present". The warning words are
only changed locally from the drive.
If at least one warning bit is set, then additionally the warning bit ZSW1, bit7 is set (see
Figure 43).
A warning word is assigned 32 warning texts (data type V2 with additional text array), which
include the contents of the warning or drive exception for visualization purposes.

Content Start
Version 4.0
ZSW1 bit 7 read

=1 if at least one PNU 953..960
Controller warning bit set
Drive
PNU 953 PNU 960

warning word warning word
definition of bits
is vendor / device specific 0 0 1 0 ... 0 .......... 0 0 ... 0
16 Bit
optional
set / reset
with every
change of the
to fault mechanism
corresponding
Drive Axis Exception Status
Drive Axis
Exception
Figure 43 Working of the warning mechanism
4.8.3 Fault buffer mechanism
A fault situation, which may be associated with one or several fault messages (drive
exceptions state changes), generates a device-specific fault reaction. E.g. it may cause the
power converter to be powered-down. An unacknowledged fault situation is also indicated by
ZSW1, bit3 (fault present). The fault buffer mechanism defines a fault tracking system in order
to save the fault messages. This fault tracking system consists of the fault buffer (which
consists at least out of the fault number list and the fault message counter, see also Figure
44). The fault buffer contains the fault messages which have been generated during the fault
situation; the fault number list contains explanations and assignments to the various fault
messages defined in the device. The mechanism, as to how the fault tracking system may be
operated, is described in the following paragraphs.
Fault buffer
Figure 47 illustrates the structure of a fault buffer. The fault buffer comprises rows and
columns. In the most detailed situation, the fault buffer has four columns which are
represented by the fault number (PNU 947), fault code (PNU 945), fault time (PNU 948) and
fault value (PNU 949) parameters. The parameters consist each of an array. The fault buffer
rows are represented by the parameter sub-indices which form the actual fault buffer.
The fault messages are entered into the fault buffer in the sequence in which they are
detected. This means, that each line in the fault buffer represents a fault message; the fault
number, fault code, fault value and fault time of a fault message may be addressed in the
particular parameter using the same subindex.
The fault buffer is subdivided into fault situations which are in turn further subdivided into fault
messages. The scaling of the fault buffer - how many fault situations and how many fault
messages per fault situation are contained in a fault buffer - may be set by parameter P950
Content Start
Version 4.0
"Scaling of the fault buffer" (refer also to 5). The implementation of the parameter is optional.
If a Drive Unit has not implemented parameter P950 the default configuration of eight fault
situations with eight fault messages per fault situation is assumed.
Drive internal fault number/code

User external fault code (optional)
Error No=22 Error: 22 Read write Error: 7020

read (mand.) (optional) read
Controller Local drive
operator
Drive panel
PNU944 PNU947 PNU946 PNU945

Fault message counter Fault number Fault code list Fault code
0 22 0 0 7020
33 1 136 . 1 7083
... ... .
7 0 . ... ...
. . 22 7020 7 0
. . . . .
ge
. . . . .
sa
. . . . .
es
. . 136 7083
. . . . .
lt m
. . . . .
u
63 63 . . .
Fa
. 63 63
optional
Drive Axis Defines size
if not
Exception
standard
Factory setting of code list is 1:1 (recommended)
PNU950 0 0
Scaling of the fault buffer 1 1
2 2
(read only) . .
. .
optional
Figure 44 Overview about the fault buffer mechanism
As example, the mechanism of the entering and saving of fault situations and fault messages
in the fault buffer is explained with the default configuration. If other quantities of the fault
situation and the fault message are chosen by parameter P950 the example has to be
transferred. The last fault situation which has still not been acknowledged starts with subindex
0, the first acknowledged fault situation with subindex 8. The maximum permissible subindex
is 63 (see Figure 47). This means that the oldest fault situation which is saved starts with
subindex 56. In a fault situation, a maximum of eight fault messages may be saved. If more
than eight fault messages occur during a fault situation, the eighth message is overwritten by
the most recent fault message (see Figure 46). If a fault situation comprises less than eight
fault messages, the fault number and the fault code zero are displayed in the subindex which
is not assigned a fault message. Conversely, if for a subindex the fault number and the fault
code are displayed as zero, the fault message with the next to last subindex was the last fault
message of the fault situation. If a previously unacknowledged fault situation is
acknowledged, this fault situation is shifted to the position of the first acknowledged fault
situation. The contents of the first acknowledged fault situation is previously shifted to the
position of the second acknowledged fault situation. The second acknowledged fault situation
is shifted to the position of the third acknowledged fault situation and so on (see Figure 45).
This implies as a result that the seventh acknowledged fault situation is also overwritten. The
fault messages (fault causes) which are still present after the acknowledgement form a new
fault situation (fault causes which are still present after acknowledgement generate a new
entry in the actual fault situation). A type of fault situation history is obtained for several fault
situations which have been acknowledged in succession.

Content Start
Version 4.0
If the same fault situation as the last acknowledged fault situation occurs it is allowed not to
shift this fault situation in order to keep the fault history.
Note, that the fault present bit (ZSW1, bit3) is set if there is at least one unacknowledged fault
message entry in the fault buffer, independent of the related fault reaction (see also Figure
45).
ZSW1 bit 3 STW1 bit 7

Fault Present Fault Acknowledge
read write =1 (positive edge)
for at least 20 ms Controller
reset bit 3 Drive
PNU 944 acknowledgement of
Fault message complete fault
write = 0
counter situation
PNU 947 (all unacknowledged
+1 xx faults)
Fault number
=0
0 oldest entry Actual fault
1 unacknowledged situation
2
.. faults
PNU 952 .
Fault situation 7 most recent entry Copy/acknowledge
reset
counter 8
.. fault situation
complete fault .. acknowledged (max. 3 s for
buffer (all zero) .. handling)
xx +1 faults
optional Last recently

.. acknowledged
..
. fault situation
reset
Fault Reaction
fault
acknowledgement
completed
fault reaction
or fault buffer reset
(device/fault specific)
Figure 45 Fault acknowledgement for the fault buffer mechanism

Content Start
Version 4.0
read ZSW1 bit 3 read

(evaluate) Fault Present
Controller
set bit 3 Drive
PNU 944 enter new fault PNU 947

message after
Fault message Fault number
last entry
counter
0 oldest entry
xx 1
unacknowledged Actual fault
+1 2
.. faults situation
.
7 most recent entry
8
..
..
.. acknowledged
faults
..
..
.
fault message
to warning
mechanism
fault reaction
(device/fault specific) Drive Axis
Exception
Figure 46 Processing of the fault messages in the fault buffer mechanism
Automatic fault buffer evaluation
The fault message counter (parameter 944) is incremented each time the fault buffer
changes. To evaluate the fault buffer automatically by a program, the program should read out
the fault message counter before and after evaluating the fault buffer. By checking that the
contents of the fault message counter are the same before and after evaluating the fault
buffer, it is guaranteed that the fault buffer was consistently evaluated, and had not changed
during the evaluation.
Time characteristics when acknowledging a fault
A fault is acknowledged by the controller with a positive edge at bit 7 of control word 1. The
fault acknowledgment bit shall be available for at least 20 ms so that it is guaranteed that a
DO recognizes the positive edge. DOs shall have successfully completed fault processing
within a max. of 3 s.
Erasing the fault buffer
The whole fault buffer (actual fault situation and all other fault situations) and the fault
message counter (parameter 944) is erased when the fault situation counter (parameter 952)
is reset to 0 (see Figure 45).

Content Start
Version 4.0
Mapping the internal fault number to the user's perspective (fault code)
The fault number (parameter 947) contains the internal fault number. The fault code is used to
systematically number fault messages from the user's perspective (see Figure 44). The
control or HMI system shall emulate the internal fault number to the fault code for the user.
This emulation may be optionally specified by the drive with the fault code list (parameter
946) which contains the fault code for each fault number.
Optionally, the user may directly read the fault code for each fault message (parameter 945)
from the drive.
Table 36 Fault buffer parameters
Para- Com-
Designation Explanation min.
meter plete
Fault message
944 Is incremented each time that the fault buffer changes m m
counter
945 Fault code Contains the fault code for each fault message for the user o o
Assignment of the internal fault number to the fault code for

946 Fault code list o o
the user
947 Fault number Contains the internal fault number for each fault message m m
948 Fault time Contains the fault instant for each fault message o o
949 Fault value Contains the fault value for each fault message o o
Scaling of the Contains the number of fault situations of the fault buffer and
950 o o
fault buffer the number of fault messages per fault situation
Contains the parameter of the fault value and the fault text
951 Fault number list -- m
for each internal fault number
Fault situation
952 Sum of all of the fault situations since the last reset o m
counter
NOTE 1 Character explanation:

m => shall be (mandatory) in this version
o => may be (optional)
--: not realized in this version
NOTE 2 Explanation:
min.: Minimum fault buffer version, which shall only include the fault message counter and the internal fault
number.
complete: Full fault buffer version, which shall contain in addition to the fault number, the optional fault time
and the fault value; a text and the fault value parameter for each internal fault number (fault
number list) and the fault situation counter. The full version of the fault buffer is specified for
evaluation at a numerical control.
NOTE 3 All parameters in Table 36 shall be only readable with the exception of parameter 952, which shall
also be writable (see also Figure 45) and parameter 946, which may also be writable.

Content Start
Version 4.0
Example with the default measures of the number of fault situations and fault message
(8x8)
PN947 PN945 PN948 PN949

Fault Fault Fault Fault
number code time value Sub-
index
5 72 Time 2 Value 2 0
11 50 Time 3 Value 3 1
Actual 0 0 xxxx xxxx 2
fault 3
situation 4
n 5
6
7
3 90 Time 1 xxx 8
0 0 xxx xxx 9
Fault x x xxx xxx 10
situation 11
n-1 12
13
14
15
56
57
Fault 58
situation 59
n-7 60
61
62
63
max. 8 x 8 entries, last unacknowledged fault situation = n
Figure 47 Fault buffer (subsequent system) with example
Various fault messages are defined in a device. It includes among others for example the
following fault codes:
50 Over-current (e.g.)
72 Over-voltage (e.g.)
90 Fuse failure (e.g.)
The current actual value is saved in parameter 15 and the voltage actual value in parameter
110. A fault number list is saved in the device like it is shown in Figure 48.
Two fault situations have occurred. For the first fault situation, the "fuse failure" fault message
has occurred, for the second, which has still not been acknowledged, first the fault messages
"overvoltage" and afterwards "overcurrent" has occurred.

Content Start
Version 4.0
This fault sequence is entered as an example in Figure 47.
951 946
Fault number list Fault code list
Subindex = PNU Text Subindex = Code No.

Fault number Fault number
0 0 No fault 0 0
1 XXX XXX 1 XXX
2 XXX XXX 2 XXX
3 0 Fuse failure 3 90
4 XXX XXX 4 XXX
5 110 Over -voltage 5 72
... ...
11 15 Over -current 11 50
... ...
Figure 48 Fault number list with example
4.8.4 Fault classes mechanism
Within the fault classes mechanism, the vendor independent PROFIdrive fault classes
according to Table 38 are defined. Out of every fault class a PROFIdrive diagnosis object
shall emerge if the fault classes attribute WARNING_PRESENT or FAULT_PRESENT is valid
(see Table 37). The diagnosis objects related to a fault class (maximum two per fault class)
emerge or disappear according to the settings or changes in the actual fault situation of the
fault buffer mechanism and the settings of warnings in the warning mechanism (see also
Figure 42). Thus the PROFIdrive diagnosis objects represent the actual fault and warning
situation of the DO.
It is recommended to compose a unique fault text for every diagnosis object for the signalling
to the user according to the following specification:
Signalling Text for Fault Class Attribute = WARNING_PRESENT:

PROFIdrive_Warning_<Fault Code>:<Fault Class Name>
Signalling Text for Fault Class Attribute = FAULT_PRESENT:

PROFIdrive_Fault_<Fault Code>:<Fault Class Name>
Table 37 Definition of the fault classes attribute
Fault class attribute Meaning
NO_FAULT There are no faults and no warnings present

WARNING_PRESENT There is at least one exception present, but the drive is still
working and follows the setpoint
FAULT_PRESENT There is at least one exception present, and one of this
exceptions caused a stop reaction (the drive does not follow the
setpoint any more)

Content Start
Version 4.0
Table 38 Definition of the PROFIdrive fault classes
Fault Code Fault Class Name Comments
Comprises exceptions in the main CPU of the drive,

01 Microcontroller Hardware or Software memory/checksum errors, over-/underrun in control
processes, controller self test failed,
Comprises exceptions out of the mains supply like
02 Mains Supply
phase error, mains over-/untervoltage,
Comprises exceptions out of the low voltage supply
03 Low Voltage Supply supplied to the drive system (e.g. external 24V
supply).
Exception because of overvoltage of the DC link,
which typically is a result of excessive energy
04 DC Link Overvoltage
feedback from the motor/process or a faulty dummy
load.
Comprises exceptions in the inverter stage of the
05 Power Electronics drive: phase current measurement errors, Uce
supervision error
Overtemperature because of overload or faulty
06 Overtemperature Electronic Device
cooling system
Exception because of over-current resulted from
07 Earth/Ground Fault shortage between phase and phase or phase and
ground.
Exception because of over-temperature of the motor.
08 Motor Overload This may be a result from motor overload or a faulty
cooling system.
Exception out of the Communication System between
the drive (DU) and the controller. E.g. this may be
09 Fieldbus System
temporary communication frame errors or exceptions
in the isochronous operation.
Exception because of a respond of the safety channel
10 Safety Channel
supervision.
Exception because of an exception in the feedback
11 Feedback interface or the feedback sensor (e.g. encoder,
position or velocity measurement system).
Exception out of the drive internal Communication
System if there is a separate physical entity related to
12 Internal Communication
the internal Communication System (e.g.
communication backplane, bus cable, ).
Comprises exceptions out of the infeed unit of the
13 Infeed
drive: e.g. missing DC link voltage,
Exception out of the dummy load circuit of the drive:
14 Brake Resistor Over-temperature brake resistor, brake resistor no
current,
Exception out of the main line filter in front of the
15 Line Filter infeed unit if the filter is a separate physical entity
(e.g. over-temperature , ).
Exception posted by additional input channels to the

drive. E.g. a separate custom specific temperature
16 External
sensor connected to the drive system by an digital
input.
Exception out of a drive internal process supervision
17 Technology
task/system. E.g. supervision of a torque limit.
Exception out of differences between real and
18 Engineering
expected configuration information.

Content Start
Version 4.0
Fault Code Fault Class Name Comments
Necessary because every entry in the actual fault

situation of the fault buffer and the warning
mechanism shall result in exception in one of the
19 Other PROFIdrive fault classes because of consistency. So
if an drive exception doesnt match with one of the
defined fault classes it shall be mapped this fault
class (Other).
4.9 Identification
4.9.1 Device identification
Within a complex Communication System, often many different devices are networked
together. In some cases, these devices are from different manufacturers. The following
elements for the Drive Unit identification are defined here in order to provide the plant
manufacturer and plant operator support during and after commissioning. It provides an
overview and diagnostics of the PROFIdrive Drive Units connected to the Communication
System.
The device manufacturer provides information for the device identification. The
manufacturers data is permanently anchored in the device and may only be read and not
changed.
Parameter 964 is the device identification parameter. The data type is "Array[n] of
Unsigned16. The assignment of the first subindices is defined and shown in Table 39.
Manufacturer-specific data may then follow. The minimum array length is 5 elements. See
also [8] for the PROFIdrive profile independent device identification by the I&M functionality.
Table 39 Structure of parameter 964 (Device identification)
Subindex Contents Comments
0 Manufacturer Coding, refer to [10]

1 Device type Manufacturer-specific
xxyy (decimal)
2 Version (Software)
Example: Version 2.1 results in 0201 decimal
3 Firmware date (year) yyyy (decimal)
4 Firmware date (day/month) ddmm (decimal)
If: the number of DO = 1, then: optional;
5 Number of Drive Objects (DO) If: the number of DO > 1 or subindex 6 available,
then: mandatory
6
Manufacturer-specific optional
...
4.9.2 Profile identification
Parameter 965 is the Profile identification number which identifies the profile and the profile
version. The PROFIdrive profile is assigned to the Profile Number 3 and the actual Version
Number of this profile is 40. The definition of byte 1 (Profile Number) and byte 2 (Version
Number) of PNU965 is shown in Table 40.

Content Start
Version 4.0
Table 40 Definition of the Profile identification number
Profile Number Version Number

Profile Version
(byte 1) (byte 2)
3 2 PROFIdrive Profile Version 2

3 3 PROFIdrive Profile Version 3.1.2
3 40 PROFIdrive Profile Version 4.0
3
4.9.3 Drive Object identification
Inside a Modular device the DOs may be of different type and based on different software.
The module manufacturer provides information for the DO identification. The manufacturers
data is permanently anchored in the DO and may only be read and not changed.
Local parameter 975 is the DO identification parameter. The data type is "Array[n] of
Unsigned16. The assignment of the first subindices is defined and shown in Table 41.
Manufacturer-specific data may then follow. The minimum array length is 7 elements.
Table 41 Structure of parameter 975 (DO identification)
Subindex Contents Comments
0 Manufacturer Coding, refer to [10]

1 DO type Manufacturer-specific
xxyy (decimal)
2 Version (Software)
Example: Version 2.1 results in 0201 decimal
3 Firmware date (year) yyyy (decimal)
4 Firmware date (day/month) ddmm (decimal)
5 PROFIdrive DO type class (Structure) see Table 42
6 PROFIdrive DO sub class 1 see Table 44
7 Drive Object ID (DO-ID) Optional for PROFIBUS Drive Units
8-9 reserved
10
Manufacturer-specific optional
...
Table 42 Structure of P975.5
Bit Value Meaning
07 0 - 255 PROFIdrive
DO-Type class
8 15 -- Reserved

Content Start
Version 4.0
Table 43 DO type class definition in P975.5
st
Decimal value of 1 Byte Type class
of P975.5 (Bit 0 7)
0 no type class information available

1 Axis
2 Infeed
3 General I/O
4 Controller
5 Encoder Interface
6 reserved

255
P975.5 shall be set to 1 if the DO is an Axis type DO according to the definition in 4.1. If the
functionality of the DO doesnt match the defined type classes in Table 42, P975.5 is set to 0.
In any case the vendor is free to enter his own DO type class according to his vendor specific
type class definition in P975.1.
Table 44 Assignment of the bits of DO sub class 1 identification in P975.6
Bit Significance (Bit = true) Significance (Bit = false)
0 Application Class 1 supported Application Class 1 not supported

6 reserved reserved
7 reserved reserved
8 reserved reserved
9 reserved reserved
10 reserved reserved
Notice, that P975 is recommended to implement for new drive system developments for all
DO and for every Drive Unit type. At least P975 is mandatory for all Drive Units who support
P978 and for all PROFINET IO devices.
4.9.4 I&M Parameter definition
For the Identification and Maintenance functionality (I&M) [8], I&M Records may be allocated
to the PROFIdrive components DU, DO and Submodules. For all PROFIdrive components the
I&M parameters are defined according to Table 45.

Content Start
Version 4.0
Table 45 PROFIdrive I&M parameter definition
I&M Parameter Value for PROFIdrive component
PROFILE_ID 0x3A00
PROFILE_SPECIFIC_TYPE 0x0000
REVISION_COUNTER 0x0000
4.10 Drive reset (power-on reset)
Summary
Especially for distributed applications, it makes sense to initiate a DO-specific reset which is
controlled by the controller application. This may either be initiated manually (by the user) or
automatically (by the application process). Applications are for example: reset for the first
start-up or reset after an error has been removed.
P972 drive reset
The reset is possible using the optional parameter P972 in the following manner:
Power-on reset (reset: closed-loop drive control + communication software)
The reset is initiated by write accessing P972 (value 1), or if required (refer below) firstly
prepared (value 2) and then initiated:
P972=0: initial status (or status after a reset)

P972=1: power-on reset (initiation)
P972=2: power-on reset (preparation)
The implementation of the parameter and the realization of the various versions are optional.
The interlocking and checks for the drive when initiating a reset are device-specific.
When write accessing P972, a negative acknowledgement is possible.
Error 0: illegal parameter number (P972 not implemented)

Error 2: lower or upper value limit exceeded (e.g. value=3, but only values 1 and 2 are
implemented)
Error 17: task cannot be executed due to operating status (e.g. the drive is moving)
Error 20: illegal value (e.g. value=2, but only value 1 implemented)
Drive reset: Direct initiation (P972=1)
The write access to P972 (with value 1) results in a drive reset and therefore from the
perspective of the Controller in a Drive Unit failure. It cannot be guaranteed that the positive
acknowledgment is still sent in time from the Drive Unit or received from the Controller.

Content Start
Version 4.0
Master Slave
Task
Sequence 1: negative acknowledgment
Task
Sequence 2: positive acknowledgment
Slave failure
t
Task
Sequence 3: Slave failure
Figure 49 Drive reset: Direct initiation (P972 = 1)
Drive reset: Preparation/initiation (e.g. P972 = 2 / P972 = 1)
For the sequence described above (direct resolution), after a DO fails and becomes
operational again the value of P972 = 0 cannot clearly indicate whether the reset was
executed or not.
The security may be required if the reset was not manually initiated (by the user), but was
automatically initiated (by the application process). This may be guaranteed if the reset is first
prepared with write access (with value 2) and is then initiated by a write access (with the
value 1). After this, by reading back the contents of P972 it may be clearly identified if the
reset was executed (P972 = 0).
EXAMPLE
1) Controller writes P972 = 2 and expects a positive acknowledgement to the write

request.
2) Controller writes P972 = 1, drive executes a power-on reset.
3) After the connection has been re-established, the controller reads P972 from the
drive. If P972 = 0, the power-on reset was successfully executed; if P972 = 2, the
write request P972 = 1 has been lost, and the controller shall repeat the action.

Content Start
Version 4.0
4.11 Operation priority of parameters and control priority
P927: Operation priority of parameters
If there are several interfaces which may have the operation priority of parameters, parameter
P927 specifies manufacturer-specific which interface has the operation priority to set
parameters.
If the controller attempts to write values without rights to change parameters, an error
message is issued.
P928: Control priority
Is to be set locally; specifies on a manufacturer-specific way which interface has the control
priority to set process data. Value = 1 means PROFIBUS Interface 1; other values are
manufacturer-specific.
Change of the control priority between Supervisor and controller (in case of P928 = 1)
After drive reset the Controller has the control priority as default.
It should be possible that a supervisor may fetch the Control priority from the controller so
that supervisor may issue setpoints for the drive.
The Control priority should be withdrawn from the operational controller and should also be
able to be returned.
The changeover should be exclusively made by the Supervisor. The mechanism to change the
control priority is manufacturer-specific. Parameter P928, e.g., may be set to device-specific
values in order to change the control priority.
The access to the process data of the supervisor is also manufacturer-specific. The
supervisor may access the process data, e.g., by the parameters P900 "Setpoint telegram
(PZD)"and P907 "Actual value telegram (PZD)".
The requirements for changing the Control priority should be:
Drive is not in the "ready state

ZSW1, bit 1 = 0: "Not Ready To Switch On"
and ZSW1, bit 2 = 0: "Operation Disabled"
Controller and supervisors control an "OFF" command in the control word.
STW1, bit 0 = 0: "OFF (OFF1)"
or STW1, bit 1 = 0: "Coast Stop (OFF2)"
or STW1, bit 2 = 0: "Quick Stop (OFF3)"
If the control priority is changed to the supervisor the controller which had the control priority
before looses the control priority. Because of this reason, the non-controlling controller
receives a status word ZSW1 of the DO in which bit 9 is set to zero ("No Control Requested").
The controlling supervisor receives acyclically a status word ZSW1 of the DO in which bit 9 is
set to one ("Control Requested").

Content Start
Version 4.0
Control requested by the DO / Control by PLC
Status word 1 Bit 9: Control Requested

This bit is set by the DO, if it is prepared to be controlled by the controller and ready to
accept the controller's control word and setpoints.
The DO shall not wait for STW1 Bit 10 of the controller to set the "Control Requested" bit.
Precondition:
The control priority has to be set to the PROFIBUS interface.
Control word 1 Bit 10: Control By PLC
This bit is set by the controller, if it sends valid control words and setpoints.
PZD exception for Sign-Of-Life:
In the case of clock cycle synchronous application the sign-of-lives which are part of the
process data are evaluated by the DO independent of the setting of STW1 Bit 10.
The DO sends always its status words and actual values, independent of ZSW1 Bit 9 and
STW1 Bit 10.
The DO accepts the controller's control words and setpoints if STW1 Bit 10 is set.
4.12 User data reliability
For both transmission directions (Controller <-> DO), user data reliability is achieved using a
Sign-Of-Life (4-bit counter).
The value range of the Sign-Of-Life is only 1 to 15 respectively (0 = invalid) since:
A DO that does not support the fail-safe mode receives a data telegram in the clear mode with
the Output Data set to 0 (thus, failure of the Sign-Of-Life may be recognized only if LS = 0 is
not permissible).
Through the DOs Sign-Of-Life, a maximum ratio of T MAPC /T DP of 14/1 is possible. Regardless
of the ratio T MAPC /T DP, the counter is always incremented to the maximum value (15).
In Multi-Axis Drive Units, the reaction to Sign-Of-Life failures is axial. Device-specific the
reaction to one Drive Axis may affect more Drive Axis.
4.12.1 Controller's Sign-Of-Life (C-LS)
Transmission (C-LS)
A 4-bit counter is used in Control Word 2 (refer to 4.2.2) as the Sign-Of-Life for the controller.
This counter is incremented by the controller in each controller application cycle, and thus
also identifies the computation of the position controller (first DP cycle in the T MAPC ). The DO
receives the new Sign-Of-Life of the controller together with the new setpoint at the time T O in
the following DP-cycle.
Synchronization (C-LS)
The Controller application starts the Controller-LS with an arbitrary value between 1 and 15,
at the earliest when changing from Preparation -> Synchronization (refer to 2.2.7.6).

Content Start
Version 4.0
Monitoring (C-LS)
If in a Controller application cycle the DO application does not recognize a correct count (i.e.
a positive or a negative deviation is recognized), it initially processes with the old telegram
data from the last valid controller telegram. For setpoint generation, a device-specific failure
strategy may be used.
If the DO application does not recognize the expected numerical value after a parameterized
number of controller application cycles (T MLS = n * T MAPC ; n may be selected via profile
parameter 925; also refer to 4.12.3), the affected Drive Axis messages a fault. After fault
acknowledgement, the DO application then attempts to automatically re-synchronize itself to
the Sign-Of-Life of the controller application. Depending on the particular application, a new
start may be required.
If the Sign-Of-Life fails, it may be for the following reasons:
Failure of the controller application level (with DP transmission still operational)

-> Sign-Of-Life failure
The DP cycle T DP has been exceeded (through telegram repetition)
-> PLL failure
Example: Permanent LS failure, T MLS = 5 * T MAPC : the strategy of the Sign-Of-Life failure
counter is explained in 4.12.3:
TMAPC : | | | | | | | | | |
Controller LS (reference): 1 2 3 4 5 6 7 8 9 10
Controller LS (actual): 1 2 2 2 2 2 2 2 2 2
Failure counter: 0 0 10 20 30 40 50 50 50 50
Response: | -> Failure | -> Switch-off
Figure 50 Example: Long term Sign-Of-Life failure of the controller
Example: Temporary LS failure, T MLS = 5 * T MAPC : The strategy of the Sign-Of-Life failure
counter is explained in 4.12.3:
TMAPC : | | | | | | | | | |
Failure counter: 0 0 10 20 19 18 17 16 15 14
Response: | -> Failure |
Figure 51 Example: Temporary failure of the controller LS (negative deviation)

Content Start
Version 4.0
TMAPC : | | | | | | | | | |
Failure counter: 0 0 10 20 19 18 17 16 15 14
Response: | -> Failure |
Figure 52 Example: Temporary failure of the controller LS (positive deviation; double

step)
NOTE 1 A permanent skew of the controllers Sign-Of-Life (failure of sampling time) causes an error (see above)
unless the controller application may correct the Sign-Of-Life.
NOTE 2 If the cause of the Sign-Of-Life failure is a failure when processing the cyclic telegrams (DX) in the
controller application, generating a diagnostics message by the DO application may be more suitable than
transmitting a drive fault because the drive fault may no longer be processed.
NOTE 3 If the controller Sign-Of-Life fails within one cycle of the controller application for T MAPC T DP , this should
only signify one failure (i.e. the Sign-Of-Life failure counter may only be incremented once).
4.12.2 DOs Sign-Of-Life (DO-LS)
Transmission (DO-LS)
A 4-bit counter in status word 2 (refer to 4.2.4) is used as a Sign-Of-Life for the DO. The DO
increments this counter with each DP cycle.
Synchronization (DO-LS)
The DO application starts the DOs Sign-Of-Life with an arbitrary value between 1 and 15:
after successful PLL synchronization and at the change (n -> n + 1) of the controllers Sign-
Of-Life.
Monitoring (DO-LS)
If the controller application does not recognize a correct count in a controller application cycle
(i.e. a positive or negative deviation has been recognized), it initially uses the old telegram
data from the last valid DO telegram. To generate the actual value, a device-specific failure
strategy may be implemented.
If the controller application does not recognize the expected numerical value after a
parameterized time (T SLS = n * T DP ; n may be parameterized or defined depending on the
manufacturer of the controller application), the affected Drive Axis is shut down by the
controller application (possibly also involved drives), and an appropriate fault is signalled to
the user. The controller application then attempts to automatically re-synchronize itself to the
Sign-Of-Life of the DO application. Depending on the particular application, a re-start may be
required or it may be sufficient to acknowledge the fault.
Example reasons for the Sign-Of-Life to fail may be:
Failure of the DO application level (while DP transmission is still functioning)

-> Sign-Of-Life failure
DO failure in the sense of DP (DO does not respond although telegram was repeated)
-> PLL failure

Content Start
Version 4.0
Example: Permanent LS failure, T SLS = 5 * T DP : the strategy of the Sign-Of-Life failure is

explained in 4.12.3:
DP cycle: | | | | | | | | | |
DO LS (reference): 1 2 3 4 5 6 7 8 9 10
DO LS (actual): 1 2 2 2 2 2 2 2 2 2
Failure counter: 0 0 10 20 30 40 50 50 50 50
Response: | -> Failure | -> Switch-off
Figure 53 Example: Permanent failure of the DO LS
Example: Temporary LS failure, T SLS = 5 * T DP : the strategy of the Sign-Of-Life failure is

explained in 4.12.3:
DP cycle: | | | | | | | | | |
DO LS (reference): 1 2 3 4 5 6 7 8 9 10
DO LS (actual): 1 2 2 2 5 6 7 8 9 10
Failure counter: 0 0 10 20 19 18 17 16 15 14
Response: | -> failure |
Figure 54 Example: Temporary failure of the DO LS (negative deviation)
DP cycle: | | | | | | | | | |
DO LS (reference): 1 2 3 4 5 6 7 8 9 10
DO LS (actual): 1 2 4 5 5 6 7 8 9 10
Failure counter: 0 0 10 20 19 18 17 16 15 14
Response: | -> failure |
Figure 55 Example: Temporary failure of the DO LS (positive deviation; double step)
NOTE A permanent skew of the Sign-Of-Life of the DO (failure of a sampling time) causes an error (see above)
unless the DO application may correct the Sign-Of-Life.
4.12.3 Counting strategy for the Sign-Of-Life failure counter
The strategy which is applied in order to prevent fast shutdown for a sporadically faulted
controller or DO application is described in the following text. This strategy guarantees that at
least a specific percentage of the telegrams shall be valid before a Drive Axis is powered-
down.
A counter is defined on the DO side in which for each deviation (independent as to whether it
is a positive or negative deviation) between the expected and actually transferred value for
the controller Sign-Of-Life, it is incremented by ten. For each additional deviation, the counter
is again incremented by ten. If a deviation between the expected and received controller Sign-
Of-Life is not recognized, the counter is decreased by one. The minimum value which may
then be counted down to is zero. This is simultaneously the value from which counting is
Content Start
Version 4.0
started. This method ensures that more than 90% of the telegrams transferred in continuous
operation originate from an undisturbed controller application.
Profile parameter 925 (axis-specific, data type Unsigned16) may be used to set a maximum
on how many consecutive controller Sign-Of-Life failures may occur (for an initial counter
value of zero and without any intermediate valid sequences) without failure of a Drive Axis.
Depending on the previous history, it is possible that just a few controller Sign-Of-Life failures
are sufficient to cause a failure of a Drive Axis. If the Drive Axis is powered-down, the Sign-
Of-Life failure counter maintains its value up to the start of the re-synchronization operation.
In the following example, the Sign-Of-Life failure counter in the Drive Axis is viewed over time
with respect to the transferred controller Sign-Of-Life. The maximum number of controller
Sign-Of-Life failures which may be tolerated was set to three in parameter 925.
Value of the sign-of-life failure counter in the slave
Failure and shutdown

40
Failure Failure OK
Failure OK OK
Failure OK OK OK OK OK
30 OK
OK OK OK OK OK
20
10
Transferred sign-of-life
Figure 56 Value of the DO Sign-Of-Life failure counter (axis-specific) with respect to

the transferred controller Sign-Of-Life
The same strategy is recommended when monitoring the DO Sign-Of-Life in the controller.
However, with which parameter the maximum number of tolerable DO Sign-Of-Life character
failures may be parameterized, has not been defined.

Content Start
Version 4.0
4.13 Specified DO functions for the Application Classes
According to the definition of the Application Classes in 2.4, Table 46 specifies the DO
functionality the drive shall comprise to match a specific Application Class.
Application Class 1: Standard Drive

Application Class 2: Standard drive with distributed technology controller
Application Class 3: Single axis positioning drive, with local Motion Control
Application Class 4: Motion Control with central interpolation and speed setpoint interface
Application Class 5: Motion Control with central interpolation and position setpoint
interface
Application Class 6: Motion Control for clocked processes, or distributed angular
synchronism
Table 46 Specified DO functions for the Application Classes
Cross-
Application classes
Functionality reference
1 2 3 4 5 6
Parameter model m m m m m refer to 3.1
Base Mode Parameter Access m m m m m refer to 3.4
speed control mode m m refer to 4.3.2
positioning mode m refer to 4.3.3
Manufacturer-specific mode m m refer to 4.3
Control word 2 m m m refer to 4.2.2
Status word 2 m m m refer to 4.2.4

a
Position feedback interface m refer to 4.6
Standard telegram 1 m refer to 4.4.2
Standard telegram 2 refer to 4.4.2
Standard telegram 4 o refer to 4.4.2

b
Standard telegram 5 (for DSC) m refer to 4.4.2
Standard telegram 6 (for DSC) o refer to 4.4.2
Standard telegram 9 o refer to 4.4.2

c
Standard telegram 20 m refer to 8.5
d
Telegram configuring m m m m m refer to 4.4.3
e
Process data normalization m o m m refer to 4.4.4
Warnings refer to 4.8.2
f f f g f
Fault buffer m m M m m refer to 4.8.3
DSC o refer to 4.5
Periphery refer to 4.7
Identification m m m m m refer to 4.9
Drive reset refer to 4.10
Clock Synchronous Operation m m refer to

2.2.7.5

Content Start
Version 4.0
Cross-
Application classes
Functionality reference
1 2 3 4 5 6
h h
DU-to-DU communication m o m refer to
relationship 2.2.7.2
NOTE Explanation of characters:

m => shall be (mandatory)
a
For this Application Class, the position feedback interface with one sensor is mandatory.
Additional sensors are optional.
b
Only mandatory if optional functionality DSC is implemented
c
Only for applications in the process technology operating mode
d
Parameter 922 shall be implemented, at least readable.
e
For standard telegram 8 the process data normalization is recommended
f
For this Application Class, the minimum fault buffer is mandatory
g
For this Application Class, the complete fault buffer is mandatory
h
PROFIBUS DP: The publisher and subscriber functionality shall be supported
PROFINET IO: M CR shall be supported
Information regarding Table 46:
The requirements regarding Application Class 5 are not defined in this profile. This is the
reason, that no profile functions are specified for this Application Class in Table 46.

Content Start
Version 4.0
5 Parameter Definition
5.1 PROFIdrive Parameter listed by function
5.1.1 Life sign monitoring
Parameter P925 is used for optional parameterization of life sign monitoring.
Table 47 Parameter for Life sign monitoring
PNU Significance Implementation Validity range
925 Number of life sign failures that may be tolerated. optional DO-specific
5.1.2 PZD-Telegram Selection and Configuration
Parameter P922 is used to display the actual setting of the PROFIdrive telegram configuration
in the DO. Optional the telegram configuration may also be set by use of P922. By use of the
P915, P916 the free telegram configuration is possible (P922 set to 0).
Table 48 Parameter for PZD-Telegram selection and configuration
915 PZD configuring (setpoint telegram) optional DO-specific

916 PZD configuring (actual value telegram) optional DO-specific
922 Telegram number; 0=free configuration mandatory DO-specific
923 List of all parameters for signals optional DO-specific
5.1.3 Sensor Interface
P979 is the only parameter for the identification of the DO sensor interface and the related
sensor. The sensor interface of a DO comprises a maximum of three channels which are all
together handled in P979.
Table 49 Parameter for Sensor interface
979 Structure for description of a maximum of three mandatory if DO-specific

channels sensor interface
is present

Content Start
Version 4.0
5.1.4 Fault buffer handling
For the read out and management of the DO specific error management the parameters from
P944 up to P952 are used and together referred as Fault Buffer.
Table 50 Parameter for Fault buffer handling
944 Fault buffer handling Refer to Table DO-specific

up to 36
952
5.1.5 Warning signals
The parameters from P953 up to 960 are used to signal the actual present warning situations
of the DO.
Table 51 Parameter for Warning mechanism
953 Read out of warning signals optional DO-specific

up to
960
5.1.6 Spontaneous messages
The spontaneous message mechanism will no longer be supported by the Profile Version 4
Table 52 Parameter for Spontaneous message mechanism
973 Reserved / not supported any more - -
5.1.7 Closed loop control operating mode
P930 shows the actual interface mode configuration of the DO. The interface mode defines
the impact of the bits in STW1 and ZSW1.
Table 53 Parameter for Closed loop control operating mode
930 Read out of configured interface mode mandatory, if DO DO-specific

supports more
than one mode

Content Start
Version 4.0
5.1.8 Set and store local parameter set
P970 and P971 are used to set the default values of the local parameter set or to store the
actual local parameter set in non volatile way.
Table 54 Parameter for Set and store of the local parameter set
970 Set the local parameter set to default values optional DO-specific
971 Store the local parameter set to a non volatile optional DO-specific
memory.
5.1.9 Set and store complete parameter set
P976 and P977 are used to set the default values of the complete Drive Unit parameter set
(global and all local) or to store the complete Drive Unit parameter set in a non volatile way.
This functionality typically is used only while the drive commissioning work is done. It is
recommended to use this functionality not by the controller (controlling application process).
Table 55 Parameter for Set and store complete parameter set
976 Set the whole DU parameter set to default values optional global
977 Store the whole DU parameter set to a non volatile optional global
memory.
5.1.10 Drive Reset
P972 is used to reset the whole Drive Unit. This functionality typically is used only while the
drive commissioning work is done. It is recommended to use this functionality not by the
controller (controlling application process).
Table 56 Parameter for Drive reset
972 Reset of whole Drive Unit optional global

Content Start
Version 4.0
5.1.11 Operation priority for write parameters
Control information about the actual authorization for the write access on parameters.
Table 57 Parameter for Operation priority for write parameters
927 Vendor-specific coding of authorization for the optional DO-specific

write access on parameters.
5.1.12 DO-identification and setup
Identification of DO specific type information. P975 is used for the identification of the DO
type. P962 und P969 define time scale factors used by the DO.
Table 58 Parameter for DO identification and setup
975 Identification data block for the DO (e.g. type mandatory DO-specific
information)
962 Sampling time to convert the time parameters. mandatory if DO-specific
parameters of
the data types D,
T or R are used
in this DO
969 Actual time difference (operation time since last optional DO-specific
start-up)
965 Profile Identification Number mandatory DO-specific
5.1.13 Parameter Database Handling and Identification
The parameters P980 to P999 contain two lists for the identification of all parameters the DO
supports and the changed parameters compared to the factory default setting.
Table 59 Parameter for Parameter set identification
980 Number list of defined parameter mandatory DO-specific

up to
989
990 Number list of changed parameters (compared to optional DO-specific
up to the factory/default setting)
999

Content Start
Version 4.0
5.1.14 Device Identification
The parameters P919 and P964 provide Drive Unit specific identification and configuration
information (e.g. vendor, type, version, number of DOs, ...).
Parameter P978 shows the complete Drive Unit DO configuration (for PROFIBUS DP devices)
and also shows the association between the Slotnumber (Axis Number for PROFIBUS DP
devices) and the corresponding DO-ID of the DO.
Table 60 Parameter for Device identification
964 Device identification data block (read only) mandatory global

919 Vendor specific system ID (read only) optional global
978 List of all DO-Ids (read only) mandatory if DO- global
ID is not equal to
Slotnumber (Axis
number for
PROFIBUS DP
devices).
5.1.15 Alternative Supervisor PZD Control Channel
The optional parameters P900, P907and P928 are used for alternative control (PZD) of an
axis by the Supervisor.
Table 61 Parameter for Alternative supervisor PZD control channel
900 Axis specific setpoint telegram (PZD) optional DO-specific

907 Axis specific Actual value telegram (PZD) optional DO-specific
928 Management of PZD control priority optional DO-specific

Content Start
Version 4.0
5.2 PROFIdrive Parameter listed by number
Parameter numbers 900 to 999 (decimal) and 60000 to 65335 (decimal) are defined and
reserved in accordance with the profile. All non-defined parameter numbers in the range from
900 to 999 and from 60000 to 65335 are reserved in accordance with the profile.
Communication system related parameters are defined in the chapters 6.8.2 and 7.8.2.
PNU: 900
Significance: Setpoint telegram (PZD)
Data type: OctetString
Implementation: Optional
Validity range: Global
Explanation: Object to transfer control words and setpoints (Controller DO) in
the acyclic communication.
The length of the OctetString differs from manufacturer to
manufacturer and corresponds to the maximum possible length of
the setpoint telegram in bytes.
Reference: ---
PNU: 901 to 905

Significance: reserved
Data type: ---
Implementation: ---
Validity range: ---
Explanation: These parameter numbers were defined in the PROFIdrive Profile
Versions 1 and 2 and may no longer be used.
Reference: ---
PNU: 906
Data type: ---
Implementation: ---
Validity range: ---
Explanation: ---
Reference: ---

Content Start
Version 4.0
PNU 907
Significance: Actual value telegram (PZD)
Data type: OctetString
Explanation: Object to transfer status words and actual values (DO Controller)
in the acyclic communication.
The length of the OctetString differs from manufacturer to
manufacturer and corresponds to the maximum possible length of
the actual value telegrams in bytes
Reference: ---
PNU: 908 to 914

Data type: ---
Implementation: ---
Validity range: ---
Explanation: These parameter numbers were defined in the PROFIdrive profile
Reference: ---
PNU: 915
Significance: Selection switch for PZD in the setpoint telegram
Data type: Array[n] Unsigned16
Implementation: optional; P915, P916 and P923 shall be implemented together
Validity range: DO-specific
Explanation: The number n of array elements corresponds to the number of
process data in the setpoint telegram.
Reference: Refer to 4.4.3
PNU: 916
Significance: Selection switch for PZD in the actual value telegram
Implementation: optional; P915, P916 and P923 shall be implemented together
Explanation: The number n of the array elements corresponds to the number of
process data in the actual value telegram.

Content Start
Version 4.0
PNU: 917
Data type: ---
Implementation: ---
Validity range: ---
Explanation: This parameter number was defined in the PROFIdrive Profile
Reference: ---
PNU: 918
Significance: reserved for PROFIBUS communication interface
Data type: ---
Implementation: ---
Validity range: ---
Explanation: ---
PNU: 919
Significance: Device system number
Data type: VisibleString16
Explanation: The device system number is a manufacturer-specific system ID.
Reference: ---
PNU: 920, 921

Data type: ---
Implementation: ---
Validity range: ---
Explanation: These parameter numbers were defined in the PROFIdrive Profile
Reference: ---

Content Start
Version 4.0
PNU: 922
Significance: Telegram selection
Data type: Unsigned16
Implementation: Mandatory, readable
Explanation: Using this parameter, as a minimum, the currently selected standard
telegram may be read-out. In an expanded implementation, this
parameter may be used to select a standard telegram.
PNU: 923
Significance: List of all parameters for signals
Implementation: Mandatory, if the process data normalization is used and/or P915
and P916 are implemented.
Explanation: This parameter may be used to assign the internal parameter
numbers to the signals (standard signals defined in the profile and
device-specific signals).
PNU: 924
Significance: Status word bit Pulses Enabled
Data type: Array[2] Unsigned16
Implementation: optional
Explanation: Read only; This parameter may be used to define the position of the
bit "Pulses Enabled/Disabled" in a status word. If the parameter is
implemented the functionality is supported by the drive.

Content Start
Version 4.0
PNU: 925
Significance: Number of Controller Sign-Of-Life failures which may be tolerated
Implementation: Optional, if this parameter is not implemented, then precisely one
Controller Sign-Of-Life failure is tolerated. Optionally with value
0xFFFF the life sign monitoring may be switched off (for test
purpose).
Explanation: This parameter may be used to define user-specific the number of
Controller Sign-Of-Life failures which may be tolerated.
PNU: 926
Data type: ---
Implementation: ---
Validity range: ---
Explanation: ---
Reference: ---
PNU: 927
Significance: operation priority of parameters
Data type: Manufacturer-specific
Validity range: Global (PROFIBUS DP) / DO-specific (PROFINET IO)
Explanation: This defines manufacturer-specific which interfaces have the
operation priority to set parameters. An error message is output if
the Controller tries to write parameter values without operation
priority.
Reference: Refer to 4.11
PNU: 928
Significance: Control priority PZD
Explanation: This defines manufacturer-specific, which interface has the control
authority. A value = 1 signifies PROFIBUS interface 1; other values
are manufacturer-specific. The Controller only takes control, if it is
ready to do this.

Content Start
Version 4.0
PNU: 929
Data type: ---
Implementation: ---
Validity range: ---
Explanation: ---
Reference: ---
PNU: 930
Significance: Operating mode
Implementation: Mandatory, if other modes than exclusively the speed control mode
(PNU 930 =1) have been implemented (also manufacturer-specific
modes)
Explanation: This is used to designate the operating mode. Depending on the
type of device this parameter is preset by the manufacturer. A
presetting of 1 means that the device supports the speed control
mode and the speed setpoint channel comprises RFG functionality.
A pre-assignment of 2 indicates that the device supports the
positioning mode. A presetting of 3 means that the device supports
the speed control mode and the speed setpoint channel doesnt
support RFG functionality.
All numerical values with bit 15 (MSB) = 1 designate manufacturer-
specific modes. If parameter 930 may be written (device-specific),
then the operating modes may be toggled between (Caution:
Different assignment of the control/status words). If a device does
not have parameter 930, then it supports the speed control mode
with RFG functionality (Operating mode = 1) by default.
PNU: 931 to 943

Data type: ---
Implementation: ---
Validity range: ---
Explanation: These parameters were defined in PROFIdrive Profile Versions 1
and 2, and may no longer be used.
Reference: ---

Content Start
Version 4.0
PNU: 944
Significance: Fault message counter
Implementation: mandatory
Explanation: The fault message counter is incremented each time that the fault
buffer changes. This means, that it may be guaranteed that the fault
buffer may be consistently read-out. Without this parameter, it is not
guaranteed that the fault buffer had not changed while reading-out.
PNU: 945
Significance: Fault code
Explanation: The fault code allows the manufacturer to systematically number the
faults which may occur, from the user's perspective.
PNU: 946
Significance: Fault code list
Explanation: Every fault number, defined in the device, is assigned a fault code
by the fault code list. The fault number is the subindex of the fault
code list. The number n of the array elements is manufacturer-
specific. If implemented the parameter shall be at least readable.
Setting of the Fault code list may be done by writing of PNU946.

Content Start
Version 4.0
PNU: 947
Significance: Fault number
Implementation: mandatory
Explanation: The fault number contains the subindex to access the fault number
list PNU 951. The fault number may be identical to the fault code.
The fault number simultaneously contains the subindex to access
the fault code list PNU 946. This means that it establishes the link
between the fault number list and fault code list.
PNU: 948
Significance: Fault time
Data type: Array[n] TimeDifference
Explanation: The fault time is the instant in time that the fault message occurred.
PNU: 949
Significance: Fault value
Data type: Array[n] (manufacturer-specific)
Explanation: The individual parameters of a drive may be assigned different data
types. This means that the data type of Parameter 949 cannot be
specified in detail. After the parameter definition (refer to 3.1) an
array consists of elements with the same data type, which means
that it shall be defined manufacturer-specific, of which data type
parameter 949 is. For instance, if 16-bit variables are processed,
then the data type Word shall be selected for parameter 949. When
processing 32 bit values, the data types Double Word shall be
selected. The quantitative significance of the fault value is not
described in more detail in the profile, this has to be also defined
and specified by the manufacturer.

Content Start
Version 4.0
PNU: 950
Significance: Scaling of the fault buffer
Data type: Array [2] Unsigned16
Implementation: optional, if the parameter is not implemented, a fault buffer with
eight fault situation each with eight fault message is assumed
Explanation: This parameter defines the number of fault situation (Subindex 0)
and the number of fault message in a fault situation (Subindex 1) of
the fault buffer. The Parameter is only readable.
PNU: 951
Significance: Fault number list with text
Implementation: Dependent on the fault buffer version
Explanation: The fault number list includes, for each fault message, defined in the
device, a reference to the parameter number to which the fault value
is assigned. An explanatory text is specified for each of the fault
messages, defined in the device, in the additional text field of the
fault number list (i.e. in IDENTIFIER, bit 10 is set). If a parameter
cannot be assigned to a fault message for the particular fault value,
then the fault number list has a value of zero under the appropriate
entry. Generally, the fault number list for a device is permanent and
does not change. The fault number list is consecutively assigned
without any gap. The number n of the array elements is
manufacturer-specific.
PNU: 952
Significance: Fault situation counter
Implementation: Dependent on the fault buffer version
Explanation: The parameter specifies the number of fault situations since the last
reset. If this parameter is set to 0 (write), the complete fault buffer is
deleted.

Content Start
Version 4.0
PNU: 953 to 960

Significance: Warning parameters
Data type: V2
Explanation: ---
PNU: 961
Data type: ---
Implementation: ---
Validity range: ---
Explanation: The parameter number was defined in PROFIdrive Profile Versions 1
Reference: ---
PNU: 962
Significance: Sampling time to convert the time parameters
Data type: TimeDifference
Implementation: Mandatory, if parameters of the data types D, T or R are used
Explanation: Shortest sampling time of the device to calculate time parameters T,
D, R.
Reference: ---
PNU: 963
Significance: reserved for PROFIBUS communication interface
Data type: ---
Implementation: ---
Validity range: ---
Explanation: ---

Content Start
Version 4.0
PNU: 964
Significance: Device identification
Implementation: Indices 0-4 are mandatory; if the drive has several axes or
manufacturer-specific data is implemented, then subindex 5 is also
mandatory; the manufacturer-specific data starts with subindex 6
Explanation: All data for device identification is included under this parameter,
and is made available to the identify service.
PNU: 965
Significance: Profile identification number
Data type: OctetString 2
Implementation: Mandatory
Explanation: The profile identification is saved here. Byte 1 includes the PNO
Profile Number 3 (for PROFIdrive). Byte 2 identifies the version .
The Version Number of this profile is 40.
PNU: 966
Data type: ---
Implementation: ---
Validity range: ---
Explanation: The parameter number was defined in PROFIdrive Profile Versions 1
Reference: ---
PNU: 967
Significance: Control word 1
Data type: V2
Explanation: ---

Content Start
Version 4.0
PNU: 968
Significance: Status word 1
Data type: V2
Explanation: ---
PNU: 969
Significance: Actual time difference
Data type: TimeDifference
Explanation: The actual time difference refers to the last time that this time
counter was preset or reset. The identification of parameter
description of bit 13 is equal to 1 for this parameter.
Reference: ---
PNU: 970
Significance: Load parameter set
Explanation: P0970 is used to reset the DO-specific parameters to the factory
setting.
Value = 0: default;
Value = 1: load complete factory setting;
Value > 1: manufacturer-specific data set
After execution of loading a parameter set, parameter 970 is reset to
0.The definition of parameter P970 in PROFIdrive Version 2 is also
permitted:
Load data set: 0 is the factory setting.
Value > 0: Manufacturer-specific data set.
In new developments, it is recommended to use the new definition of
P970
Reference: Refer to 3.1.2; Table 4 Bit 12

Content Start
Version 4.0
PNU: 971
Significance: Transfer into a non-volatile memory
Explanation: Parameters belonging to one axis and the global parameters are
saved with this parameter.
Value = 0: default;
Value = 1: actual DO-specific parameter set is saved in a
non-volatile way;
Value > 1: Manufacturer-specific data set;
After saving a data set parameter 971 is reset to 0.
Reference: ---
PNU: 972
Significance: Drive reset
Explanation: ---
PNU: 973
Data type: ---
Implementation: ---
Validity range: ---
Explanation: This parameter number was defined in the PROFIdrive Profile
Version 3 and may no longer be used.
Reference: ---
PNU: 974
Data type: ---
Implementation: ---
Validity range: ---
Explanation: ---
Reference: ---

Content Start
Version 4.0
PNU: 975
Significance: DO identification
Implementation: This parameter is recommended for all classes of Drive Units. P975
is mandatory for a Drive Unit which supports P978 and for all
PROFINET IO Devices.
Explanation: All data for DO identification is included under this parameter, and is
made available to the identify service.
PNU: 976
Significance: load device parameter set
Explanation: P0976 is used to reset all parameters to the factory setting.
Value = 0: default;
Value = 1: load complete factory setting
Value > 1: manufacturer-specific data set
After execution of loading a parameter set parameter 976 is reset to
0.
Reference: ---
PNU: 977
Significance: transfer in non-volatile memory (global)
Data type: Unsigned 16
Explanation: All parameters, i.e. parameters of all axes and the global parameters
are saved with this parameter.
Value = 0: default;
Value = 1: actual parameters of the device are saved in a non-
volatile way;
Value > 1: Manufacturer-specific data set;
After saving a data set parameter 977 is reset to 0.
Reference: ---

Content Start
Version 4.0
PNU: 978
Significance: list of all DO-IDs
Data type: Array[n] Unsigned8; n = 0,.., (maximum number of DOs + 1)
Implementation: mandatory if the DO-ID numbers of the Drive Unit are not equal to
the corresponding Slotnumber (for PROFIBUS DP the corresponding
Axis number). Mandatory, for modular PROFIBUS DP Drive Units if
here are DOs which are not related to a slot/axis.
Explanation: P978 consists out of the DO-IDs for all DOs in the PROFIdrive
Device. The DO-IDs of the DOs may be independent from the
Slotnumber (axis number for PROFIBUS DP device). The DO-ID
may be a number from 1 to 254. Value 255 means that there is no
DO assigned, the zero value is a delimiter. Entries which exist after
the first Zero-Value indicate DO-IDs of DOs without PZD (only used
for PROFIBUS DP devices). The second zero value indicates the
end of the list. A valid DO-ID list comprises at minimum two zero
values. P978 is only writeable during commissioning. The
configuration telegram is dismissed if it is not compatible to P978.
The controller has to check if the parameter is implemented, and if it
is so, it has to read out the parameter values (DO-IDs to be used for
the Base Mode Parameter Access to the DOs inside the Drive Unit).
Reference: Refer to 4.4.3.
PNU: 979
Significance: Sensor format
Implementation: mandatory, if the position feedback interface is realized
Explanation: The number n of array elements is in this profile version 31. The
parameter is only readable.

Content Start
Version 4.0
PNU: 980 to 989

Significance: Number list of defined parameter
Implementation: Mandatory
Explanation: The number n of array elements is manufacturer-specific. All
parameter numbers defined in a device are saved in parameters
under the sub-indices (manufacturer-specific and profile
parameters). The arrays shall be assigned in increasing sequence
and consecutively. If a subindex contains zero, the end of the list of
defined parameters has been reached. If a subindex contains the
parameter number of the next list parameter, then the list is
continued there. Therefore the PNU980 to 989 are omitted from the
Number list of defined parameter. The number list of defined
parameter shall be implemented for every DO. Parameters of the
number list which are empty may not be implemented.
Reference: ---
PNU: 990 to 999

Significance: Number list of changed parameters
Explanation: The number n of array elements is manufacturer-specific. All
parameter numbers of the parameters (manufacturer-specific and
profile parameters), which may be written and which are changed in
respect to the factory setting, are saved under the sub-indices of
these parameters. The arrays shall be assigned in increasing
sequence and consecutively. If a subindex contains zero, the end of
the list of changed parameters has been reached. If a subindex
contains the parameter number of the next list parameter, the list is
continued there. Parameters of the number list which are empty may
not be implemented.
Reference: ---
PNU: 60000 to 60999

Significance: reserved for PROFINET IO communication interface
Data type: ---
Implementation: ---
Validity range: ---
Explanation: ---

Content Start
Version 4.0
PNU: 61000 to 65535

Data type: ---
Implementation: ---
Validity range: ---
Explanation: ---
Reference: ---

Content Start
Version 4.0
6 PROFIBUS DP Communication Layer
This chapter defines the mapping of the PROFIdrive Base Model on the PROFIBUS DP
Communication System (refer to [2]).
6.1 Base Model at PROFIBUS DP
When using PROFIBUS DP as Communication Network, the PROFIdrive Devices are mapped
to the following PROFIBUS DP objects:
Controller: The PROFIdrive Controller is represented by the PROFIBUS DP Master Class

1 (DPM1). E.g. this may be a PLC, NC or PC.
Drive Unit: The PROFIdrive Drive Unit is represented by the PROFIBUS DP Slave. The
Drive Unit is related to one or more Axis of the automation system.
Supervisor: The PROFIdrive Supervisor is represented by the PROFIBUS DP Master
Class 2 (DPM2). E.g. this may be a PG or OP.
Figure 57 shows the topology of a typical PROFIdrive drive system using PROFIBUS DP as
Communication Network.
DPM1 DPM1 DPM2
PLC, NC, PC PLC, NC, PC PG, OP
PROFIBUS DP
I/O I/O
D D
Slave R R Slave
I I
other V V other
peripherals E E peripherals
Slave Slave
M M
E E
PROFIdrive
Application Application
Class 1 Class 3
Figure 57 PROFIBUS DP Devices in a PROFIdrive drive system

Content Start
Version 4.0
The PROFIdrive Communication Relationships between the Devices are mapped to

PROFIBUS DP in the following way:
Controller - Drive Unit Relationship is represented by C0 plus C1 Channel

Supervisor - Drive Unit Relationship is represented by C2 Channel
Drive Unit - Drive Unit Relationship is represented by slave-to-slave Communication
(DXB)
Figure 58 shows the PROFIdrive Devices and there relationships on PROFIBUS DP.
Device -Device PROFIBUS-DP

Communication Relationship
DP-Master
Class 2
Device PROFIBUS-DP Device (Supervisor)
C2-Channel
el
nn
ha
C
C2
DP-Master
Class 1
(Controller)
C0
l
an
e
nn
ha
dC
1C
1C
d C
an
ha
C0
nn
el
DP-Slave DxB Channel DP-Slave

(Drive Unit) (Drive Unit)
Figure 58 PROFIdrive Devices and there Relationship for PROFIBUS DP

Content Start
Version 4.0
For PROFIBUS DP as Communication System for PROFIdrive, the PROFIdrive General

Communication Model is shown in Figure 59. With PROFIBUS DP, having different Network
Interfaces (Master- or Slave-Interface) means also to have different Stations. Therefore the
Station and Device Objects in the General Communication Model are the same.
With PROFIBUS, a maximum of 126 devices - that is, masters or slaves - may be connected
to one bus in single- or multi-master operation. Thus, PROFIdrive Drive Units with different
operating modes (speed control and positioning) as well as other peripherals (such as I/O)
may be operated on one bus.
Therefore the PROFIdrive Device at PROFIBUS DP is precisely defined by the following

address information:
Network (PROFIBUS bus/domain)

Device (PROFIBUS node address)
DP-Slave DP-Master
(Station and (Station and
Drive Unit) Controller/Supervisor)
Drive Unit Controller/
Supervisor
PROFIBUS
DP-Slave Device DP-Master
Interface Interface
NetworkInterface Connector Network Interface Connector
PROFIBUS
(Network)
Figure 59 General Communication Model for PROFIdrive at PROFIBUS DP

Content Start
Version 4.0
The PROFIdrive Base Model Communication Services are provided by the following
PROFIBUS DP mechanisms:
The Cyclic Data Exchange service for PROFIBUS DP is realized by two different PROFIBUS
DP communication mechanisms depending on the communication relationship.
For the Master/Slave (Controller/Drive Unit) relationship the Cyclic Data Exchange is
realized by use of simple transfer of user data via the Data_Exchange telegram (DX).
For the Slave/Slave (Drive Unit/Drive Unit) relationship the Cyclic Data Exchange is
realized by use of the Slave-to-slave communication mechanism. The so-called Publisher-
Subscriber-Model is based on a publisher (passive station) which provides its actual
values not only to the DP master but also to all other stations (subscribers), so that the
other slaves may access and process this data. Therefore, by the configuration of the
PROFIBUS DP system, the Slave-to-slave relationships between the DP slaves are
configured and contains the information which subscriber accesses to which publisher
data. The Slave-to-slave communication is coupled to the cyclic user data exchange of
DP. Figure 60 shows the mechanism of the Slave-to-slave communication.
DP Master (Cl. 1)
Parameterization Master
,
Active Station
Output Data Input Data
Response
DP Slave (Drive) DP Slave (Drive) DP Slave (Drive)
Publisher Subscriber Subscriber
Slave-to-Slave-Communications (Links)
Figure 60 PROFIBUS DP slave-to-slave communication designations
The Acyclic Data Exchange service is realized by the DPV1-Parameter-Channel mechanism

of PROFIBUS DP.
Acyclic communication uses the DPV1 mechanisms READ and WRITE of data block (DPV1-
Parameter-Channel).
This allows start-up tools to be connected as Class 2 Master on PROFIBUS DP and a series
of functions, e.g. reading out the process data normalization through the control.

Content Start
Version 4.0
With PROFIdrive on PROFIBUS DP the Alarm Mechanism is not used. Diagnosis and Fault
management is done by use of PROFIdrive mechanism based on standard Parameter Access
and the cyclic PROFIdrive control and status words.
Clock Synchronous Operation at PROFIBUS DP is done by using the PROFIBUS DP-V2

Isochron Mode. Clock cycle synchronous operation in the PROFIBUS DP Isochron Mode is
implemented by using an isochronous clock signal. This cyclic, isochronous clock signal is
transmitted as Global Control telegram from the Class 1 Master to all PROFIBUS slaves.
Thus, the slaves supporting DP-V2 isochronous operation may synchronize their applications
(internal/Slave Clock) with the Master Clock (refer to [2]).
Special error mechanisms in each station make stable communication possible, even if there
is a sporadic failure of the Master Clock.
For PROFIdrive, the PROFIBUS DP-V2 Isochron Mode is the basis for drive synchronization.
Not only message interchange on the bus system is implemented in an isochronous time
frame, but also the internal control algorithms - such as closed loop speed and current
controllers in the drive, or the controller in the higher level automation system - are
synchronized (see Figure 61).
Controller Application Pos. Contr.

R1 R2 R3
DX = Data Exchange Telegram
Rx = Controller Task of Axis x
Master /Controller
Transfer Transfer
DX DX DX DX DX DX
DP Cycle Acycl. Communic.
Clock Slave Slave Slave Clock Slave Slave Slave
1 2 3 + Reserve 1 2 3
Setpoint
Actual Value Transfer
Transfer
Slave/Drive Unit
Drive Unit
Application R1 R1 R1 R1 R1 R1 R1 R1

Acquisition Activation
Figure 61 Clock cycle synchronous communication for PROFIdrive at PROFIBUS DP

Content Start
Version 4.0
6.1.5 Drive Unit Communication Model
Figure 62 shows the Drive Unit Communication Model when PROFIBUS DP is used as
DP-Master Class 1
(Controller)
DP-Master Class 2
(Supervisor)
DPV1-Parameter-Channel
Clock cycle
synchronous
communication
Process Data
(DX)
el
nn
ha
ve r -C
la n et e
- S t io m
t- o nica ara
e ) -P
av u B V1 Cyclic communication
Sl omm (Dx DP
C
Acyclic communication
DP-Slave
(Drive Unit)
Figure 62 Overview about the Drive Unit Communication Model on PROFIBUS
The type of PROFIBUS DP clock pulse generation (refer to 6.7.5) permits only one
synchronous DP-Master Class 1 (DPM1) on the bus. Additional masters on this bus may only
be non synchronous DP-Masters (DPM1, DPM2). DP-Masters Class 2 (DPM2) are
subordinated to the DPM1 with respect to the distribution of the cycle time, and thus increase
the minimal DP cycle time T DP (refer to 6.7).
The following restrictions to bus topology are recommended when using the synchronous
operation:
A DPM1 may use without restrictions all the available services; other communication
partners on the bus should be limited to maximum 2 acyclic Class 2 channels (Services:
Initiate, Read, Write, Data transport).
A DPM2 has to be certified for the cycle synchronous applications (Token Hold Time).
6.1.6 Base Model State Machine
For PROFIdrive at PROFIBUS the States of the PROFIdrive Base Model State Machine are
mapped to the PROFIBUS states according to Figure 63. The actions to be carried out in the
different phases and the corresponding PROFIBUS states are described in the following list:
Offline: In the Offline state no Communication Service is available. No data passes

between the Devices.

Content Start
Version 4.0
Phase1: This state is the PROFIBUS Clear state and part 1 of the PROFIdrive
Preparation state. In Phase 1 the acyclic data transfer is working. Therefore Controller and
Supervisor may perform a Parameter Access to the Drive Unit. Also the Drive Unit may
signal exceptions via the Alarm Mechanism to the Controller.
Typically in this mode the Controller tries to parameterize the Drive Units (Slaves)
assigned to it, to configure them, and to prepare for start of process data exchange. In this
state Input and Output Data (PZD) are not valid.
Phase2: This state is part 2 of the PROFIdrive Preparation state, where the PROFIBUS
is already in the operate state and the Drive Units (Slaves) try to synchronize their local
clocks to the Master Clock according to the specification of the DPV2 Isochronous Mode.
In this Phase the Cyclic Data Exchange is active and the Global Control Telegram is send
by the Class 1 Master. Also the other Communication System services (Acyclic Data
Exchange, Alarm Mechanism) are active and running.
Phase3: This state is part 1 of the PROFIdrive Synchronization state, where the
PROFIBUS is already in the operate state (Input and Output PZD are valid), all Slave
Clocks are synchronized to the Master Clock and the PROFIdrive Application Layer tries
to synchronize its tasks by use of the Life Sign mechanism. In this first part the Master
Life Sign (M-LS) is synchronized (see also 4.12).
PROFIBUS is already in the operate state (Input and Output PZD are valid), all Slave
Clocks are synchronized to the Master Clock and the PROFIdrive Application Layer tries
to synchronize there Tasks by use of the Life Sign mechanism. In this second part the
Slave Life Sign (S-LS) is synchronized while the Master Life Sign is already synchronized
(see also 4.12).
Operation: In the Operation state all Communication Services are available and active,
also the Functional Objects on the Application Layer are synchronized and the whole
PROFIdrive application is ready to operate.
PROFIdrive
Parameter Access, PZD valid,

Parameter Access, PZD not valid Slave Clocks synchronized
to Master Clock
Communication Layer Application Layer
Offline Preparation Synchronization Operation
Phase 1 Phase 2 Phase 3 Phase 4
PROFIBUS
offline clear operate operate operate operate
Parameter access, PLL-synchronisation*), M-LS-synchr. S-LS-synchr.

configuration (DX, Send GC)
(Set_Prm, IsoM
Parameter, Chk_Cfg)
*) if clock synchronous operation is required
Figure 63 Mapping of the Base Model State Machine at PROFIBUS DP
6.1.7 Definition of the CO
For PROFIdrive the PROFIBUS Slot is defined as common CO. The CO/Slot should be used
as Communication Object for Process Data, Parameter Access.

Content Start
Version 4.0
6.2 Drive Model at PROFIBUS DP
6.2.1 Drive Unit
Figure 64 shows the PROFIdrive Drive Unit mapped on a PROFIBUS slave device. The
logical address elements for the Drive Object in the PROFIBUS system are:
PROFIBUS domain
Node-Address
DO-ID
PROFIBUS
Domain
PROFIBUS
Node-Adress
DP-Slave
Interface
Drive Unit (DU)
Drive Object Drive Object ... Drive Object

(DO) (DO) (DO)
PROFIdrive
DO-ID
Figure 64 PROFIBUS DP specific Logical Drive Unit model (multi axis drive)

Content Start
Version 4.0
6.3 Process Data
6.3.1 COs for Process Data configuration
Within PROFIBUS the Slot consists out of Input and/or Output Data. With PROFIdrive the
Input and Output Data of one or more PROFIBUS Slots is mapped to setpoint values and
actual values of the DO.
The mapping for a typical DO in a Multi-Axis or Modular Drive Unit is shown in Figure 65. A
single axis DU consists at least out of one Slot/CO (Input/Output PZD). In a Multi-Axis or
Modular Drive Unit the slots related to one DO are separated to the slots of the next DO by a
special Axis Separator slot. The Axis Separator slot is empty and therefore doesnt comprise
any PZD.
Axis-Number = x-1 Axis-Number = x Axis-Number = x+1
Slot Slot
Slot n-1 Slot n Slot n+1 Slot n+m
n+m+1 n+m+2
.... Axis PZD .... Axis PZD

Separator and PZD PZD Separator and
(AT) PAP (AT)
PAP
CO CO ... CO
Parameter
Output PZD In/Output PZD Input PZD Manager
DO Setpoint Values Actual Values

DO
not Alarm Process Control Task Parameter
used (e.g. closed loop control, inverter, ...) Data Base
DO
DO_ID
External Process
(e.g. motor and mechanics)
Relationship
Data flow
Figure 65 Mapping of PROFIBUS Slot to the PROFIdrive DO
For PROFIdrive at PROFIBUS the following Slot types are defined:
Standard DP-Slot (standard configuration identifier/DP ID):

Used for Input PZD or Output PZD
Profile-specific Slots (special configuration identifier/PROFIdrive ID):
Axis Separator (empty/ no PZD)
PROFIdrive Standard telegram (Input plus Output PZD)
DXB (Slave-to-slave Output PZD)
Content Start
Version 4.0
A group of Slots belonging to one DO are identified by the Axis-Number. The Axis-Number
starts with the number 1 and comprises at least one Slot. Note, that the Drive Unit may
consist out of more DOs than the highest Axis-Number because of additional DOs without
PZD.
6.3.2 Standard telegram configuration
Every telegram type supported by the Drive Unit shall be described by associated IDs.
Telegrams which the master sends to the slave are interpreted as Output Data, and those
telegrams which the master receives from the slave are interpreted as Input Data.
Recommendations for the DP IDs and the PROFIdrive IDs to transfer the PROFIdrive
standard telegrams (defined in 4.4.2) are shown in Table 62. The recommendations of the DP
ID are given for data transfer with consistency over the complete length.
Table 62 DP IDs and PROFIdrive IDs of the standard telegrams (refer to 4.4.2)
DP IDs PROFIdrive IDs

Standard
telegram
brief description of
the standard
telegrams We recommend to use the
Actual value
Setpoint direction special configuration
direction
identifiers.
PZD component PZD component

speed setpoint (16 bit), Output module Input module
1 no sensor, no Sign-Of- 2 words output, 2 word input
Life 2 words 2 words
0xC3 0xC1 0xC1 0xFD 0x00 0x01
1110 0001 = 0xE1 1101 0001 = 0xD1
speed setpoint (32 bit), Output module Input module 4 words output, 4 words input
2 no sensor, additional
control word 4 words 4 words 0xC3 0xC3 0xC3 0xFD 0x00 0x02
1110 0011 = 0xE3 1101 0011 = 0xD3
3 additional control word
,with one sensor 5 words 9 words 0xC3 0xC4 0xC8 0xFD 0x00 0x03
1110 0100 = 0xE4 1101 1000 = 0xD8
speed setpoint (32 bit), Output module 6 word output, 14 word input
Input module
4 additional control word, 0xC3 0xC5 0xCD 0xFD 0x00
with two sensors 6 words 14 words
0x04
1110 0101 = 0xE5 1101 1101 = 0xDD
5 additional control word
,with one sensor, DSC 9 words 9 words 0xC3 0xC8 0xC8 0xFD 0x00 0x05
1110 1000 = 0xE8 1101 1000 = 0xD8
speed setpoint (32 bit), Output module 10 words output, 14 word input
Input module
6 additional control word, 0xC3 0xC9 0xCD 0xFD 0x00
with two sensors, DSC 10 words 14 words
0x06
1110 1001 = 0xE9 1101 1101 = 0xDD

Content Start
Version 4.0
DP IDs PROFIdrive IDs

Standard
telegram
brief description of
the standard
telegrams We recommend to use the
Actual value
Setpoint direction special configuration
direction
identifiers.

Positioning interface Output module Input module 2 words output, 2 words input
7 (transferring traversing
blocks) 2 words 2 words 0xC3 0xC1 0xC1 0xFD 0x00 0x07
1110 0001 = 0xE1 1101 0001 = 0xD1
position setpoint, Output module Input module 5 words output, 5 words input
8 speed setpoint,
additional control word 5 words 5 words 0xC3 0xC4 0xC4 0xFD 0x00 0x08
1110 0100 = 0xE4 1101 0100 = 0xD4
Positioning interface ( Output module Input module 6 words output, 5 words input
9 with target position and
velocity) 6 words 5 words 0xC3 0xC5 0xC4 0xFD 0x00 0x09
1110 0101 = 0xE5 1101 0100 = 0xD4
Speed setpoint (16bit)
Output module Input module 2 words output, 6 words input
20 n set interface for the
process technology, 2 words 6 words 0xC3 0xC1 0xC5 0xFD 0x00 0x14
see also 8.5
1110 0001 = 0xE1 1101 0101 = 0xD5
NOTE 1 The formation of the PROFIdrive IDs is explained in [10], the formation of the DP IDs is described in [2]
(Part 6 Chapter 6.2.5 "Coding section related to configuration PDUs").
NOTE 2 The PZD data may be distributed over several modules in the master configuration for the PZD
component.
NOTE 3 PROFIdrive IDs: The telegrams which are actually configured may be looked up in parameter P922
"telegram selection".
Examples of configuration telegrams using DP IDs or PROFIdrive IDs for standard telegram 3
with one axis, two axis, and slave-to-slave communication are given below.
Drive Unit 1 Drive Axis, standard telegram 3
Slot 1 2
DP ID 0xE4 (output) 0xD8 (input)

PROFIdrive ID 0xC3 0xC4 0xC8 0xFD 0x00 0x03
Drive Unit 2 drive axes, standard telegram 3

Drive Axis 1 2
Slot 1 2 3 4 5 6
0x01 0xFE 0x01 0xFE

DP ID 0xE4 (output) 0xD8 (input) (axis 0xE4 (output) 0xD8 (input) (axis
separator) separator)
Slot 1 2 3 4
0xC3 0xC4 0xC8 0xFD 0x01 0xFE 0xC3 0xC4 0xC8 0xFD 0x01 0xFE
PROFIdrive ID
0x00 0x03 (axis separator) 0x00 0x03 (axis separator)

Content Start
Version 4.0
Drive Unit 2 drive axes, standard telegram 3, per axis one DXB link each with 2 words
Drive Axis 1 2
Slot 1 2 3 4 5 6 7 8
0x81 0x01 0x81 0x01

0xC1 0xFE 0xC1 0xFE
0xE4 0xD8 0xF9 0xE4 0xD8 0xF9
DP ID (axis (axis
(output) (input) (output) (input)
(1 DXB separa- (1 DXB separa-
Link) tor) Link) tor)
Slot 1 2 3 4 5 6
0xC3 0xC4 0x81 0xC1 0x01 0xFE 0xC3 0xC4 0x81 0xC1 0x01 0xFE
PROFIdrive ID 0xC8 0xFD 0xF9 0xC8 0xFD 0xF9
(axis (axis
0x00 0x03 (1 DXB Link) separator) 0x00 0x03 (1 DXB Link) separator)
Example of the configuration telegram using DP IDs or PROFIdrive IDs for standard telegram
20 with one axis is given below.
Drive 1 Drive Axis, standard telegram 20

Unit
Slot 1 2
DP ID 0xE1 (output) 0xD5 (input)

PROFIdrive 0xC3 0xC1 0xC5 0xFD 0x00 0x14
ID
6.3.3 Slave-to-slave Communication (DXB)

NOTE In the subsequent text only slave-to-slave communication will be referred to. Slave-to-slave
communication and Data-eXchange Broadcast (DXB) are synonymous. The service used for slave-to-slave
communication of PROFIBUS DP is Data-eXchange Broadcast.
6.3.3.1 Overview
Slave-to-slave communication allows DP nodes to also read the Input Data (actual values) of
DP slaves either completely or in part, and use them as Output Data (setpoint values). Thus,
the possible uses of PROFIBUS are expanded, particularly in the area of distributed
applications in drive engineering.
Via slave-to-slave communication, signals may be transmitted from drive to drive; for
example:
Speed setpoint values for setting up a setpoint cascade in paper, foil, wire-drawing
machines and as well as fiber stretching plants.
Torque setpoint values for load distribution controllers of drives that are coupled
mechanically or via the material, such as longitudinal line-shaft drives for a printing
machine, or S-drum drives.
Acceleration setpoint values (dv/dt) for acceleration pre-control of multiple motor
drives.
Position setpoint values, e.g. for an electronic shaft.

Content Start
Version 4.0
The essential features of slave-to-slave communication are:
General
All nodes which transfer data via slave-to-slave communications are located in one
PROFIBUS network.
All data which is transferred using slave-to-slave communication is exchanged in one
DP cycle.
Data is transferred via slave-to-slave communication cyclically in every DP cycle.
The slave-to-slave communication relationships (links) are steady-state. This means
that they cannot be re-configured during runtime without having to re-parameterize the
master and the slaves.
Every slave-to-slave communication link shall be configured using the bus
configuration tool.
The slave-to-slave communication links are target-oriented configured for each slave
which receives data via slave-to-slave communication (Subscriber).
The descriptive data of the configured slave-to-slave communication links (subscriber
table) is distributed to the subscribers at start-up (parameterization).
Master
A DP master which may initiate slave-to-slave communication (Data-eXchange
Broadcast) is required so that the slaves may communicate with each another.
The DP master receives all of the data sent from publishers as Input Data without
requiring any special configuring.
Data in the subscriber, which is controlled from the publishers, is not sent as Output
Data from the associated DP master.
Slave
A DP slave may publicize data via slave-to-slave communication (publisher function)
as well as receive data (subscriber function). A drive with slave-to-slave
communication which is in conformance with PROFIdrive should be able to receive
data from at least one node and publish all of its Input Data.
The slave shall also be able to operate with a standard master without slave-to-slave
communication. The slave-to-slave communication may be switched-on/off by an
appropriately parameterized bus.
Publisher
A publisher shall support the "DXB request" and "DXB response" PROFIBUS functions.
A publisher shall support the "Publisher_supp key word in the GSD file.
Subscriber
A subscriber shall support the key word "Subscriber_supp in the GSD file.
A subscriber shall support the block structure of parameterization data in order to load
the subscriber table.
The Subscriber shall support a supervision mechanism (DXB-Timer) for each DXB-
Link.

Content Start
Version 4.0
6.3.3.2 Application example
Segment of a foil coating plant
Machine velocity Stretch ratio Stretch ratio

Pull setpoint V-set V2/V1 V3/V2
value
PLC Operator
V1, dV1/dt V1, dV1/dt V2, dV2/dt V3, dV3/dt

Pull actual
10 11 12 13
Winder X X
techn.
9
A.I.
V1 V2 V3
Drying
Unwinder Pull measurement Control Coating Pull group
drive
Figure 66 Application example of slave-to-slave communication
The PLC is the PROFIBUS DP Master Class 1. All drives and distributed I/O are networked
with the PLC as passive nodes (slaves). The control drive receives the machine setpoint V-set
from the master system. The other drives receive their individual stretching ratios or the
tension setpoint from the master. These values are almost steady-state or changed extremely
slowly.
The drives, coupled by the slave-to-slave communication of PROFIBUS form an autonomous

setpoint cascade, automatically follow the speed setpoint of the central ramp-function
generator computed in the control drive. The winder senses the tension actual value (also via
slave-to-slave communication) from the distributed analog input of the tension measuring
device. The command variables are quickly and automatically transferred from drive to drive
without any computation required from the master system.
This means that the master system is relieved of time-critical (fast) setpoint calculations
during acceleration and deceleration. All of the dynamic command variables are computed
decentralized and distributed to the following drives via the bus.

Content Start
Version 4.0
6.3.3.3 User model and configuration
Publisher and Subscribers are modelled just like conventional DP slaves.
Subscribers receive additional descriptive objects for the slave-to-slave communication

relationships.
The bus is configured in two steps:
First step all of the slaves are configured with their Input and Output Data.
Second step the slave-to-slave communication relationships are configured for each
subscriber.
Configuration identifier for slave-to-slave communication in the configuration telegram:
An ID using the special configuration identifier format shall be set in the configuration string
for every slave-to-slave communication link.
ID for slave-to-slave communication: 0x81; 0xCy-1; 0xF9 (y = length of link data in words)
The configuration for slave-to-slave communication is described using the example from
6.3.3.2.
Control drive configuration:
Slave #11 (Publisher)
Module ID I/O offset Technological significance
1 2 words- 0 Control word 1

output 1
data 2 V-set
3 (machine velocity)
2 3 words- 0 Status word 1
input 1
data 2 V1
3 (velocity of the control drive)
4 dV1/dt
5 (material web acceleration)

Content Start
Version 4.0
Configuration of the sequential drive (coating):
Slave #12 (Publisher and Subscriber)
1 2 words- 0 Control word 1

Output 1
Data 2 V2/V1
3
2 3 words- 0 Status word 1
Input 1
Data 2 V2
3
4 dV2/dt
5
The sequential drive (coating) provides for the subsequent drive of the setpoint cascade V2
and dV2/dt as publisher data.
Configuration of the slave-to-slave communication link of the coating drive:
Link Publisher # I offset 1) Length O offset 2) Technological significance

Publisher Subscriber
1 11 2 4 4 V1
6 dV1/dt
7 (material web acceleration)
Unwinder configuration:
Slave #10 (Subscriber)
1 2 word 0 Control word 1

output 1
data 2 Tension setpoint
3
2 2 word 0 Status word 1
Input Data 1
2 Tension actual value
3
1) Offset (starts with 0 in byte) in the publisher Input Data, from which point on the subscriber should access data.
2) Offset (starts with 0 in byte) in the Output Data of the subscriber, in which the publisher data are mapped.

Content Start
Version 4.0
Configuration of the slave-to-slave communication links of the unwinder:
Link Publisher # I offset 1) Length O offset 2) Technological significance

Publisher Subscriber
1 11 2 4 4 V1
6 DV1/dt
7 (material web application)
2 9 0 2 8 Tension actual values
9
6.3.3.4 Device internal data mapping
With the definition of Links from the Publisher to a Subscriber the subscriber device is
capable of filtering the link data out of the relevant broadcast telegrams. Because of the axis
modular structure of a PROFIdrive Device, a mapping of the link data to the axis PZD Input
Data is necessary (see Figure 67). The information for the DXB filtering and the related
mapping of the filtered data to the PZD Input Data field of the PROFIdrive Axis is combined in
the DXB-Subscribertable. The structure and handling of the Subscriber table is described in
6.3.3.5.
DP Slave
interface
download via Prm mechanism broadcast
telegram subscriber filter
PZD from Master mechanism
Axis 1 Axis 2 ... Axis n
data data data
publisher A publisher B ... publisher n
PZD
subscriber mapping
table
slave output data slave output data slave output data
Slot Slot Slot Slot Slot Slot
PZD-setpoint PZD-setpoint PZD-setpoint

value value value
D0 / Axis 1 D0 / Axis 2 D0 / Axis n

. . .
Multi-Axis / Modular Drive Unit
Figure 67 Dataflow inside a Multi-Axis or Modular Device with DXB relations
1) Offset (starts with 0 in byte) in the publisher Input Data, from which point on the subscriber should access data.
2) Offset (starts with 0 in byte) in the Output Data of the subscriber, in which the publisher data are mapped.

Content Start
Version 4.0
6.3.3.5 Subscriber table
In order that a DP slave may operate as subscriber on the bus at run-up, the subscriber table
shall be loaded into the slave in a User_Prm_Data block or an Ext_User_Prm_Data block (if
supported). Together with the Cfg-data, the DP slave may undertake the required checks and
settings and therefore map the data from the master and from the publishers to its own output
ranges (axis).
6.3.3.5.1 Structure of the Subscriber table
The Subscriber table consists of one or more link blocks. The following information is saved in
the link block of the subscriber table:
Which publisher is to be accessed

How long is the Publisher Input Data (for test purposes)
From which position in the Publisher Input Data is the link data to be accessed (byte
offset)
To which axis (DO) the filtered link data is to be merged
To which position of the axis Input PZD data stream the filtered link data is to be added
How many data (bytes) are to be accessed
Element Description Value Explanation
Block header Block-Length 8 - 234 Including length byte

Command 0x07 Identifier DXB-Subscribertable
Slot 0 Device
Specifier 0x00 reserved
Version Version ID 0x01 Version 1

Link1 Publisher_Addr 0 125 Source DP-Slave address
Input_Data_Length_Publisher 1 - 244 Length of publisher input telegram
Source_Offset_Publisher 0 - 243 Offset for input data access
Dest_Slot_Number 1 - 255 Slotnumber for link data mapping
Offset_Data_Area 0 - 244 Offset for link data mapping
Length_Data_Area 0 - 244 Length of accessed link data
Link2 Publisher_Addr 0 125 Source DP-Slave address
Input_Data_Length_Publisher 1 - 244 Length of publisher input telegram
Source_Offset_Publisher 0 - 243 Offset for input data access
Dest_Slot_Number 1 - 255 Slotnumber for link data mapping
Offset_Data_Area 0 - 244 Offset for link data mapping
Length_Data_Area 0 - 244 Length of accessed link data
Link 3

Figure 68 Structure of a subscriber table (inside a Prm-Block)

NOTE 1 In order to ensure that the system may be expanded, a version ID is provided in the subscriber table.
NOTE 2 The table length may be determined via the length specification in the block header.

Content Start
Version 4.0
NOTE 3 If data from one publisher has to be distributed to several axis on one subscriber this may be done by
placing of multiple link entries in the subscriber table.
6.3.3.5.2 Data transfer routes of the Subscriber table
The Subscriber table may be transferred to the slave via two different transfer routes:
Using the Check User Prm service (where the maximum length of the filter table including
header is limited to 234 bytes). This way is recommended because of general support by
masters.
or using the Check Ext User Prm service (where the maximum length of the filter table
including header is limited to 244 bytes).
The particular route that is used depends on the parameterization master, the bus
configuration tool and the supported services on the slave (see also 6.3.3.8).
6.3.3.6 Timing characteristics
6.3.3.6.1 Bus cycle
The DP cycle is extended by the delay times between the publisher broadcast telegrams and
the next master telegram respectively (in comparison to a DP cycle without slave-to-slave
communication).
Figure 69 shows telegram timing with slave-to-slave communication:
minTSDR
(Publisher) TID2
PROFIBUS
DXB request DXB response REQUEST
TSYN maxTSDR
Ready to receive
Figure 69 Timing diagram of PROFIBUS with slave-to-slave communication
The timing may be optimized, using controllers which guarantee short response times. In this
case the max. T SDR shall be specified in the GSD of all of the devices. A bus configuration tool
may then use this value when calculating T ID2 .
6.3.3.6.2 Delay time of the publisher data
At the instant that the master Output Data is received, the data of the publishers, which are in
the cycle before the subscriber, are from the actual cycle; the data of the publishers, which
are in the cycle after the subscriber, are from the last previous cycle. This concurrence may
be optimized by using clock-cycle synchronism.
6.3.3.7 Monitoring and diagnostics
The subscriber monitors a slave-to-slave communication link and may identify various errors
in operation. The subscriber keeps a status report for each slave-to-slave communication link
and signals every status change to its parameterization master. This means that this master
has essential information about the status of all of the slave-to-slave communication links.
By the subscriber the time and data are monitored for every publisher. The time monitoring
interval corresponds to the response monitoring of the PROFIBUS-DP. Since the data is

Content Start
Version 4.0
checked against the configured lengths, steady-state configuring errors and dynamic errors
may be sensed during data transfer. When an error occurs, data cannot be re-sent as the
publishers send their data as a broadcast. If the subscriber identifies a failure, it shall respond
in an application-specific way and transfer a diagnostics message to the master.
The master may always interrogate the subscribers for the status of all slave-to-slave
communication links. When interrogated by the master, the slave signals the statuses of the
slave-to-slave communication links with the DXB link status object. In this object, the address
of the publishers and the link status of every slave-to-slave communication link are
transferred (refer to [2]).
6.3.3.7.1 Monitoring the accessed data in the subscriber
In order to avoid dynamic as well as steady-state errors for the links, the subscriber shall
recognize the publisher data length (this corresponds to the input data length).
Dynamic errors may occur due to errors in the publisher (this sends data which are either
too short or too long)
Steady-state errors may occur if there are links outside the publisher data
If a subscriber recognizes a length error, the link for this publisher is not executed. The
application in the subscriber may then respond appropriately.
6.3.3.7.2 Response in the subscriber for user data failure in the publisher
The response is manufacturer-specific. To recognize this failure, a sign-of-life may be used as

by the master-slave relationship for clock-cycle synchronism. The publisher generates and the
subscriber monitors the sign-of-life.
6.3.3.8 Configuring, GSD extensions
The GSD file (device data file) is the basis and input for the configuring tool. This GSD file
shall be supplied by the device manufacturer of a DP slave which is to operate as a
Subscriber/Publisher on PROFIBUS DP.
The following parameters are required in order to implement slave-to-slave communication:
Table 63 Parameters (Set_Prm, GSD) for slave-to-slave communication (Data-

eXchange Broadcast)
Parameter Designation Set_ GSD Data type Units min. required values Typical value
Prm
(in- Publisher Sub- (internal) (absolute)
ternal) scriber
DPV1_ Support of the x Boolean - -- True 1 True

DPV1
Slave functionality (1: True) --
Publisher_ Support of the x Boolean - True True 1 True

Publisher
supp functionality (1: True)
Subscriber Support of the x Boolean - False True 1 True

_supp Subscriber
functionality (1: True)

Content Start
Version 4.0
Parameter Designation Set_ GSD Data type Units min. required values Typical value
Prm
(in- Publisher Sub- (internal) (absolute)
ternal) scriber
DXB_Max_ Number of max. x Unsigned8 - -- 1 8 8

possible links to
Link_Count different
publishers
DXB_Max_ Maximum x Unsigned8 Byte -- 2 32 32
possible data
Data_ length of a link
Length to one publisher
a
MaxTsdr_ Maximum slave x Unsigned1 t BIT <= 800 <= 800 400 33,2 s
processing time 6
xx
at xx Mbaud
DXB_Subs Supported x Unsigned8 - -- 0 1 1
cribertable SAPs
_ for DXB-
Block_ Subscribertable
Location
Publisher_ Publisher x Unsigned8 -
address of the
Addr link
Publisher_ Total input data x Unsigned8 Byte
length of the
Length Publisher
Sample_ Start of the link x Unsigned8 Byte
Offset
Sample_ Length of the x Unsigned8 Byte
link
Length
a
Value at 12 Mbaud
If the extended parameterization is used, then additional GSD parameters are necessary
(refer to [4]).
A more detailed description of the parameters listed in Table 63 is provided in [10].

Content Start
Version 4.0
6.4 Parameter Access
6.4.1 PAP for Parameter Access
For PROFIdrive at PROFIBUS the Data Block (DS) 47 is defined as the PAP to provide the
PROFIdrive Base Mode Parameter Access. For PROFIBUS only the Base Mode Parameter
Access - Global service is defined. The access for the Base Mode Parameter Access is done
by a read/write on Data Block 47 (DS47) of the specific CO (Slot).
Every PROFIdrive Device on PROFIBUS shall support the Base Mode Parameter Access -
Global via Slot 0, DS47. All PROFIdrive parameter of the complete Drive Unit (all DOs, global
and local parameter) are accessible via this PAP. Figure 70 shows the Parameter Access
mechanism of a Drive Unit.
Please note, that the addressing of the DO local parameter is only done by the DO-ID send to
the device in the parameter request data structure (see 3.4).
Optional additional PAPs may be located on every CO (Slot) of the Drive Unit which is related
to a DO (see also Figure 70).
PROFIBUS
Node-address
Slotnumber
DP-Slave Interface
0 1 2 3 4 5
Device PZD AT PZD PZD AT

Representa
tive
Input/
Output
(axis
separator)
Input/
Output
Input/
Output
(axis
separator) ...
PAP PAP PAP PAP PAP PAP
DS47 DS47 DS47 DS47 DS47 DS47 DU
PZD PZD
DO DO ...
local local
parameter parameter
set set
Adress for access of

DO local parameters is
the DO_ID
Parameter
manager
global
parameter set
DO_ID
Relationship
optional
Figure 70 PAP and Parameter Access mechanism for PROFIdrive at PROFIBUS

Content Start
Version 4.0
Please note the following conventions:
The Parameter Access to all DO of a Drive Unit shall be possible via the Slot 0-PAP.
Addressing of the DO is done by the DO-ID passed inside the request header data
structure (Base Mode Parameter Access Global).
The Parameter Access to a specific DO shall be possible via the PAPs of all COs (Slots)
related to that DO.
Access to DOs which are not related to a CO (Slot) shall be done via the Slot 0-PAP.
It is recommended to perform the Parameter Access to a specific DO via the PAP of the
first (lowest Slotnumber) of the related Slots of the DO.
6.4.2 DPV1 parameter channel for Parameter Access
6.4.2.1 General
In this chapter the mechanism for transportation of the Parameter Access request/response
data structure by use of the DPV1 parameter channel is specified. Table 64 gives an overview
about the PROFIBUS DP services used for the parameter channel.
Table 64 Services used for Parameter Access on PROFIBUS DP
DP DPV1
Master type Class 1 (PLC) Class 2 (PG, OP)

Connection type MSCY MSAC_C1 MSAC_C2
cyclic acyclic acyclic
DP(V1) service Data_Exchange Read/Write (data block) Data_Transport
PROFIdrive application Process data Parameter requests -
NOTE The fields with grey background indicate the scope of this section.
Addressing of the PAP is done by CO/Slot and index/DS (data block). The definitions refer to
the Read and Write services via the C1 and C2 channel. The Data_Transport service is not
used since it is only accessible for a Class 2 Master.
The PROFIdrive Profile for drives defines the following PAPs for the Parameter Access on
PROFIBUS DP:
Table 65 Defined PAPs for Parameter Access
PAP Contents Index (Data Block)
Access Point for

47
Base Mode PAP Base Mode Parameter Access Global
6.4.2.2 DPV1 telegram sequences for Base Mode Parameter Access
The data in the write request corresponds to the parameter request. The data in the read
response corresponds to the parameter response.
A write request is first sent with the parameter request. The master has to send a read
request so that the slave answers with a read response containing the parameter response.

Content Start
Version 4.0
Master DPV1 Slave
Parameter Write.req DB47 Parameter

Request with data (parameter request) Request
Write.res
without data
Read.req DB47
without data
Parameter Processing
Read.res(-)
without data
Read.req DB47
without data
Parameter Read.res Parameter

Response with data (parameter response) Response
Figure 71 Telegram sequence via DPV1
Table 66 State machine for slave processing
State Connection Idle Request being processed Response

disconnected available
Event
Connection Action Reset processing

being
established
Subsequent Idle Idle
state
Connection Action (ignore) Reset processing

being
disconnected
Subsequent - Connection disconnected
state
Write.req Action (protocol error) Start processing Write.res(-) Reject response

Write.res(-) Start processing
Write.res(+) "state conflict" Write.res(+)
Subsequent - Request being - Request being
state processed processed
Read.req Action (protocol error) Read.res(-) Read.res(+)

Read.res(-)
"state conflict"
Subsequent - - Idle
state
Processing Action Reject Reject (internal error)

completed
reject
Subsequent - - Response available -
state
NOTE 1 Significance: The columns specify the state. The rows explain an event. Every row is subdivided
into two fields. One describes the action and the other the subsequent state.
NOTE 2 This state machine is valid for a DPV1 connection. If several connections have been set-up, then the
appropriate number of state machines shall be available. The order of a DPV1 telegram sequence is always: first
write request, then read request.

Content Start
Version 4.0
6.4.2.3 DPV1 telegram frame

a) Standard case
The following four DPV1 telegrams are used for transmitting a parameter
request/parameter response pair via the PAP (Slot 0, DS47):
1) Transmission of the parameter request in a DPV1 Write request:
DPV1 Write Function_Num Slot_Number = ...

Header = 0x5F (Write)
Index = 47 Length = (Data)
DPV1 Data Parameter request ...

(Length)

2) Short acknowledgement of the parameter request with DPV1 Write response (without
data):
DPV1 Write Function_Num Slot_Number

Header = 0x5F (Write) = (mirrored)
Index = (mirrored) Length = (mirrored)
3) Request of the parameter response in a DPV1 Read request (without data):
DPV1 Read Function_Num Slot_Number = ...

Header = 0x5E (Read)
Index = 47 Length = MAX
4) Transmission of the parameter response in the DPV1 Read Response:
DPV1 Read Function_Num Slot_Number

Header = 0x5E (Read) = (mirrored)
Index = (mirrored) Length = (Data)
DPV1 Data Parameter response ...

(Length)
...
Meaning and utilization of the elements in the DPV1 Header:

Function_Num:
ID for DPV1 service (Read, Write, Error)
Slot_Number:
DPV1: In the request: addressing of a real or virtual module of the slave, in the
response: mirrored.
PROFIdrive: no evaluation.
Index (Data Block):
DPV1: In the request: addressing of a data block at the slave, in the response:
mirrored.
PROFIdrive: data block number 47 defined for parameter requests and for parameter
response.

Content Start
Version 4.0
Length:
DPV1: In the Write request and Read response, the length of the transmitted data in
bytes.
PROFIdrive: Length of parameter request/parameter response.
DPV1: In the Read request, the requested length of a data block.
PROFIdrive: Maximum length possible
DPV1: In the Write response, the data length accepted by the slave.
PROFIdrive: Mirroring of the length from the Write request.
b) Error case
If there is an error, the reply to a DPV1 Read or Write request is an error response.
5) DPV1 Error Response:
DPV1 Error Function_Num Error_Decode

= 0xDF (Error Write) = 128 (DPV1)
= 0xDE (Error Read)
Error_Code_1 Error_Code_2
= (don't care always = 0)
Error_Decode:
DPV1: ID as to how Error_Code_1/2 are to be interpreted.
PROFIdrive: always 128 (DPV1 codes)
Error_Code_1:
DPV1: Breakdown into error class (4 bits) and error code (4 bits); refer to Table 67.
PROFIdrive: Utilizing certain numbers
Error_Code_2:
DPV1: Application-specific
PROFIdrive: not used (always = 0)
Table 67 DPV1 Error class and code for PROFIdrive
Error_Class Error_Code Application PROFIdrive

(from DPV1 Spec) (from DPV1 Spec)
0x0..0x9 = reserved
0xA = application 0x0 = read error -
0x1 = write error
0x2 = module failure
0x3 to 7 = reserved
0x8 = version conflict
0x9 = feature not supported
0xA to 0xF = user specific
0xB = access 0x0 = invalid index 0xB0 = No data block DB47: parameter requests are not
supported
0x1 = write length error
0x2 = invalid slot
0x3 = type conflict
0x4 = invalid area

Content Start
Version 4.0
Error_Class Error_Code Application PROFIdrive

(from DPV1 Spec) (from DPV1 Spec)
0x5 = state conflict 0xB5 = Access to DB47 temporarily not possible due to
internal processing status
0x6 = access denied
0x7 = invalid range 0xB7 = Write DB47 with error in the DB47 header
0x8 = invalid parameter
0x9 = invalid type
0xA to 0xF = user specific
0xC = resource 0x0 = read constraint conflict -
0x1 = write constraint conflict
0x2 = resource busy
0x3 = resource unavailable
0x4..0x7 = reserved
0x8..0xF = user specific
0xD...0xF = user specific
6.4.2.4 Data block lengths
If the data block length limitation of DPV1 (also refer to [1]) is used, then the following
settings of the transferred data quantity are recommended which help to optimize the DP
cycle.
Data quantities which may be transferred as a function of the maximum data block length.
Numerical data used as basis:
(Length in bytes) Complete Half Quarter
Max. Profibus length 255 127 63

FDL user data 244 116 52
DPV1 user data 240 112 48
Parameter address and value 236 108 44
FDL header 11
DPV1 header 4
Parameter header 4
Parameter address 6
Parameter value header 2
Formulas:
1) DPV1 user data length required as a function of the number of parameters and
number of values
DPV1 user data length =
Parameter header (=4) +
Number of parameters * ( Parameter address (=6) + Parameter value header (=2) +
Format(=1,2,4) * number of values)

Content Start
Version 4.0
2) Max. number of parameters for a specified DPV1 user data length (number of
values = 1)
Number of parameters =
= ( DPV1 user data length - Parameter header (=4) )
/ (Parameter address(=6) + Parameter value header(=2) + Format(=1,2,4) )
3) Maximum number of values for a specified DPV1 user data length (number of
parameters = 1)
Number of elements =
= ( DPV1 user data length - Parameter header(=4)
- Parameter address(=6) - Parameter value header(=2) )
/ Format(=1,2,4)
Table 68 Limits due to the DPV1 data block length
Object Task Limited by Data block length Data block length Data block length
240 byte 112 byte 48 byte
Word D Word Word D Word Word D Word

One parameter, Request Number of 117 58 53 26 21 10
several elements Change elements 114 57 50 25 18 9
Multi-parameters, Request Number of 39 39 18 18 7 7
each one element Change parameters 23 19 10 9 4 3
Description complete Request Lengths in bytes 234 106 42

or string
Change 228 100 36
Text (length=16) Request Number of 14 6 2
requests
Change 14 6 2
6.4.2.5 Scalability of the functionality

Multi-Parameter Accesses: yes/no
Parameter description available: yes/no
If no parameter description is available, the parameter description shall be added as a file
to the drive.
DPV1 data block length: limitation of the data block length for the purpose of shorter bus
cycles in the isochronous mode.

Content Start
Version 4.0
6.4.2.6 GSD parameters for DPV1
The following GSD parameters are relevant for the DPV1 Parameter Access:
Table 69 GSD parameters for the DPV1 Parameter Access
Parameter Designation
DPV1_Slave DPV1 support

C1_Max_Data_Len Max. DPV1 data block length for the
communication channel with the Class 1 Master
C2_Max_Data_Len Max. DPV1 data block length for the
communication channel with the Class 2 Master
C1_Read_Write_supp Supports the read and write services of the
Class 1 Master
C2_Read_Write_supp Supports the read and write services of the
Class 2 Master
C2_Max_Count_Channels Maximum account of active C2 channels of the
DPV1 slave
NOTE A summarization of all relevant GSD entries for isochronous mode, Data
eXchange Broadcast and DPV1 Parameter Access is given in [10]. For further information
see [4].
6.5 Drive Unit Configuration
6.5.1 Drive Unit Configuration on PROFIBUS DP
The general Drive Unit (DU) configuration on PROFIBUS is shown in Figure 72. Figure 72
also shows the related data objects for PZD data, local and global parameter data and device
or DO related configuration data. For the general classification of DU types see 2.3.4.
A DU consists logically out of the drive device itself and one or several Drive Objects (DO).
The drive device is represented by slot 0 / DO-ID=0.
The DO consists at least out of its specific parameters.
A DO of type Axis consists also out of its process data (PZD), the axis specific parameters,
and its axis-specific configuration data.
The process data is composed out of several slots containing the I/O data of the telegrams
used for this DO and the axis separator. There may be more slots for additional I/O data or
slave-to-slave communication (DXB).
The context includes the configuration data of the DO. The configuration data itself consists of
the configuration identifiers for each slot and the parameter data. All configuration identifiers
are combined into one configuration string for this device which is transferred to the device by
the configuration telegram.
The parameter data is put together by the Isochronous Parameter Block, the DXB Block, and
the DO specific parameters.

Content Start
Version 4.0
st nd th
Drive Device 1 Drive Object 2 Drive Object ... m Drive Object
Slot 0 slot 1..n slot n+1..o ... slot x+1..y
Process Data PZD Process Data PZD Process Data PZD

(I/O Data) (I/O Data) (I/O Data)
Standard telegram Standard telegram Standard telegram
Control Control Control
Feedback Feedback Feedback
Additional I/O (DXB) Additional I/O (DXB) Additional I/O (DXB)

DPV1 parameter access
to device via
DO-ID = 0 Axis separator Axis separator Axis separator
Drive Parameters
(Process Data) DO-ID DO-ID DO-ID
(P978 Subindex 0) (P978 Subindex 1) (P978 Subindex m-1)
Device
Identification Fault Buffer Fault Buffer Fault Buffer
Communication
Interface
Local Local Local
Drive Reset Parameters Parameters Parameters
Context
Configuration Configuration Configuration
IsoM Data Data Data
Parameters
Parameter Data Parameter Data Parameter Data
DXB Table
DPV1 parameter access via:

- Single/Multi-Axis type: DO-ID = Axis-Number
- Modular type: DO-ID out of P978
NOTE The expressions in parentheses are used in the PROFIBUS specification (refer to [2]).
Figure 72 Drive Unit Structure
Explanations:
1) The device itself has no process data, they are assigned to a DO.
2) The Axis Separator at the end of the last DO is optional.
3) If a Drive Unit consists only of one DO, the Axis Separator of this DO is optional.
4) Shorter configuration are allowed: If only a part of the DOs exchanges process data,
and this part is set in the "list of DO-IDs" (refer to Drive Object - ID) in front of the
DOs which do not exchange process data, then it is allowed to configure no axis
separators for the non-used Dos.
5) longer configuration are not allowed
If the standard configuration is used, the ID required in the configuration telegram contains
information about the direction (I/O), the format (word), the data length, and the data
consistency (consistency over the complete length).

Content Start
Version 4.0
The information about the slots and DOs in the slave, and their IDs are also known as the
slave configuration. The configuration, configured using the GSD data in the DP master, is
sent when establishing cyclic communication between the DP master and the DP slave with
the DP function Chk_Cfg. The slave checks whether the received configuration and the saved
configuration coincide. The configuration may be read back using the Get_Config DP service.
6.5.2 Getting the Drive Object ID (DO-ID)
To select a dedicated DO via the DPV1 Parameter Access the DO-ID is used for addressing.
For Single-Axis and Multi-Axis Drive Units, the DO-ID is set equal to the Axis-Number.
Because with the Modular Drive Unit type theres the possibility to have DO types which have
no cyclic process data but Parameter Access via the acyclic communication channel, the DO-
ID may be different from the Axis-Number. Figure 73 shows the principle configuration and the
communication channels inside a Modular Drive Unit. To correlate the axis-number of the
cyclic communication channel and the DO-ID for the acyclic Parameter Access, the list of
DO-ID in P978 is used.
DP
cyclic communication channel acyclic communication / DPV1 parameter channel
DP Slave
Interface
DO-ID = 0 DO-ID Axis-No DO-ID DO-ID Axis-No DO-ID Axis-No

(device access) = 12 =1 = 13 = 14 =2 = 15 =3
Parameter
manager
DO DO DO DO
Global
parameter set
Drive Device
Modular Drive Unit
at PROFIBUS DP
Parameter P978 is a list of all DO-IDs (see Figure 74). In the PROFIdrive context, a DO-ID is
assigned to every DO. The DO-ID is an identifier for a DO typically used for Modular Drive
Units. For the Base Mode Parameter Access via PROFIBUS DPV1 (refer to 3.4) this identifier
is used to address a certain DO (see Figure 73). In the cyclic communication in which process
data is exchanged the order of the process data is fixed by the process data configuration and
referred as Axis-Number (see Figure 75). The identifier of the DOs is entered in parameter
P978 in the sequence in which the drive DOs receive their process data (see also Figure 73
and Figure 74).

Content Start
Version 4.0
cyclic transfer of acyclic transfer of

process data P978 list of all Module IDs parameters
Subindex DO-ID
PZD Parameter
1. axis 0 12 access via
DPV1:
DO-ID for
PZD 1 14 addressing
2. axis a certain
DO
2 15
PZD
3. axis
3 0
4 13
5 0
List 1
List 2
Figure 74 Meaning of parameter P978 "list of all DO-IDs" for the DU at PROFIBUS DP
The subindices of P978 correspond to the process data view of the drive axes in ascending
order. P978 consists out of two lists (see Figure 74). First (starting with subindex 0) the list of
DOs with Cyclic Data Exchange starts and is terminated with a zero DO-ID. The second list
starts directly behind the first list and contains the DO-ID of DOs without cyclic data channel.
This list terminates also with a zero DO-ID. Therefore all DO-IDs of the device are listed if a
second zero is detected as DO-ID.
During Data_Exchange these rules always have to be fulfilled:
no gap in the list

the end of every list is signalled by 0, all DOs are listed if a second 0 is detected
every number exists only once
DO-ID = 255 signals not a valid DO-ID but a PZD cyclic communication channel which is
not assigned a DO
Notice that parameter P978 is mandatory for a Modular Drive Unit at PROFIBUS DP. If P978
is present, the DO-ID for the DO Parameter Access shall be taken out of P978. P978
optionally may also be used for Single-Axis and Multi-Axis Drive Units, if for any reason its
necessary to have the DO-ID not equal to the Axis-Number. If the Drive Unit doesnt possess
P978 the DO-ID for the DO Parameter Access is equal to the process data Axis-Number.
Further details to parameter P978 are defined in the 5.2.
Identification of DO type in a Modular DU is done by evaluation of P975 (refer to 4.9.3).

Content Start
Version 4.0
Profibus configuration (PZD) Modular Unit (DO)

point of view point of view
Number.
DO
DO-ID
Axis-
PNU 975.5
DO-Type
Identification
Index DO-ID
Device
Device Representative Device
Slot 0
=0
0 9
Slot 1
1 10
....... PZD Parameter 1
Drive
9 1
Axis
2 20
Slot n: Axis seperator
Slot n +1
3 0
....... Drive
PZD Parameter 2 10 1 Axis
4 11
Slot m Axis seperator
5 21
Parameter - 11 2 other
6 0
DO
Slot m +1 7 x
....... 3 Drive
PZD Parameter 20 1
8 x Axis
9 x
Parameter - 21 other
3
DO PNU 978
Figure 75 Example of P978 for a complex Modular Drive Unit at PROFIBUS DP
6.6 Alarm Mechanism
6.6.1 General
Within PROFIdrive at PROFIBUS the usage of the Alarm Mechanism is not specified.
Therefore for the PROFIBUS master only the ZSW1 and the Fault Buffer Mechanism via
Parameter Access are available.

Content Start
Version 4.0
6.7 Clock Synchronous Operation
6.7.1 Sequence of an isochronous DP cycle
Figure 76 shows the sequence of an isochronous DP Cycle.
TJ
DP-cyclic DP-acyclic
GC GC
DX DX DX MSG GAP (Clock
(Clock (Slave 1) (Slave 2) ... (Slave n) etc.
TOK RES
Cycle ) (Acyclic services Slave x) cycle)
TDX
TDP
Figure 76 Sequence of an isochronous DP cycle
T J (Jitter time)
T J mirrors the time in which the clock jitter lasts. The clock jitter is the shifting of the GC
telegram with respect to time (refer also to 6.7.5.2).
T DX (Data_Exchange-Time)
This time is the sum of the transmission times of all Data_Exchange telegrams for all slaves.
T DP (DP-Cycle-Time)
T DP is the time a DP cycle lasts.
Content of a DP cycle
GC: Global_Control
The end of the Global_Control telegram marks the beginning of a new DP cycle.
DX: Data_Exchange
With the service Data_Exchange, user data exchange between master and slave 1-n is
executed sequentially.
MSG: acyclic services

After cyclic transmission the master may transmit an acyclic service, e.g. parameter channel
via DPV1.
GAP: Attempt to include new active stations

An attempt to include new active stations is made after each xth cycle.

Content Start
Version 4.0
TOK: Token Passing

The token is passed to the own station or to other masters.
RES: Reserve
The reserve consists of the "active spare time" which is used as an active rest (master
transmits to itself) and the "passive spare time".
6.7.2 Time settings
Master -Application -Cycle TMAPC

TDP
TM Rx: controller x
Master R1 R2 R3
T: GlobalControl
TDX (clock generator)
Sx.: Slavex
DP- Cycle T S1 S2 S3 MSG Reserve T
MSG:acyclic services
T O_MIN
TBASE_IO TBASE_DP
Slave -Appl .-Cycle TSAPC
R1 R1 R1 R1
Slave1..3 R1 R1 R1
R1 R1 R1 R1
Act. Val.acquisit.
TI TO Setpoint transfer
Figure 77 Time settings
T DP (DP-Cycle-Time))
The DP cycle time consists of the following parts:
Duration of the cyclic services T DX : depends on the number of slaves, DX telegram

lengths
Duration of an acyclic services: depends on the maximum length of the DPV1
telegrams
Duration until a new clock pulse is generated: GAP, token passing, reserve,
Global_Control
In addition, there is the following general condition for the DP cycle time:
T DP >= maxT DP_MIN highest value of T DP_MIN of all slaves
Time settings in GSD file:
T BASE_DP Time base of T DP (Unit: [1/12 s], e.g.: 3000 = 250 s)

T DP_MIN Minimum DP cycle time (Unit: [T BASE_DP ], e.g.: 2 = 500 s)
The specified value shall fulfill the following condition:
T BASE_DP = 1 ms/2 n with n = 0 5 (integer number)
This means that one of the following values may be selected:
T BASE_DP : 375/750/1500/3000/6000/12000 =
31.25 s/62.5 s/125 s/250 s/500 s/1000 s.
The drive shall also handle the permissible multiple of the selected value.
Content Start
Version 4.0
The DP cycle time resulting from this should be offered as a default when configuring (refer to
6.7.4). However, it should still be possible to enter other (higher) values.
T I (Input time: Time for actual value acquisition))

The detailed parameter description is provided in [2].
Time settings in the GSD file:
T BASE_IO Time base of T I, T O (Unit: [1/12 s], e.g.: 3000 = 250 s)

T I_MIN Minimum T I (Unit: [T BASE_IO ], e.g.: 1 = 250 s)
The specified value shall fulfill the following conditions:
T BASE_IO = 1 ms/2 n with n = 0 5 (integer number)
This means, that one of the following values may be selected:
T BASE_ IO: 375/750/1500/3000/6000/12000 =
31.25 s/62.5 s/125 s/250 s/500 s/1000 s.
The drive shall also be able to handle the permissible multiples of the selected
value.
T O (Output time: Time for setpoint transfer))

The detailed description of the parameter is provided in [2].
Time settings in the GSD file:
T BASE_IO Time base of T I, T O (Unit: [1/12 s], e.g.: 3000 = 250 s)

T O_MIN Minimum (T O -T DX ) (Unit: [T BASE_IO ], e.g.: 1 = 250 s)
The specified value shall fulfill the following condition:
T BASE_IO = 1 ms/2n with n = 0 5 (integer multiple)
This means that one of the following values may be selected:
T BASE_IO : 375/750/1500/3000/6000/12000 =
31.25 s/62.5 s/125 s/250 s/500 s/1000 s.
The drive shall also be able to handle the permissible multiples of the selected
value.
T M (Master time: Start of master control))

T MAPC, SAPC (Master_Application_Cycle-, Slave_Application_Cycle-Time: Controller clock

cycles)
Different values for T MAPC , T DP , T SAPC

In the case of a joint DP cycle, different slave-specific settings for master application cycle
and slave application cycle are possible:

Content Start
Version 4.0
T MAPC >= T DP >= T SAPC
T MAPC = n * T DP (n = 1 - 14, to limit using Sign-Of-Life for slave refer to 6.7.3)
Transmission times
Depending on the model used, the following transmission times are relevant:
Master -> Slave: 1-2 T DP , depending on T O

Slave -> Master: 1-3 T DP , depending on T I and T M
Master <-> Slave additional delay through HW and SW interfaces (for example,
communication RAM)
In the case of technological functions such as axis interpolation, pre-control, the same
transmission times (delays) are required for the participating slaves.
Scalability of the model

The following parameters allow a separate scalability of master, slave, and bus:
Master (application) -> T MAPC , T M

Slave (application) -> T SAPC , T I , T O
Bus -> T DP
In the master system, the clock cycle synchronization may be realized in the buffered
synchronized mode or in the enhanced synchronized mode (refer to [2] part 5).
6.7.2.1 Example (simplest DP cycle)
clock cycle (TMAPC)

(Closed-loop position controller) TM=0
Master R1 R2 R3 R1 R2 R3 R1 R2 R3 R1 R2 R3
DP-cycle T S1 S2 S3 MSG Reserve T S1 S2 S3 MSG Reserve T S1 S2 S3 MSG Reserve T S1 S2 S3 MSG Reserve T
clock cycle (TSAPC)

(Closed-loop
speed controller/current controller) R1
R1 R1 R1 R1 R1
R1 R1 R1 R1 R1 R1 R1 R1
Slave1..3 R1 R1 R1
TI=0 TO=0
Figure 78 Example: Simplest DP cycle

Content Start
Version 4.0
In this example, four DP cycles are needed for a response in the position control loop.
1) Actual value acquisition (in slave)

2) Actual value transmission (slave -> master)
3) Position controller (slave -> master)
4) Setpoint transmission (master -> slave)
In the simplest DP cycle the buffered synchronized isochronous mode is used. This model
places the lowest demands on the computational performance of the master. However, it
increases the control delay:
Delay = 4 * T DP
6.7.2.2 Example (optimized DP cycle)
clock cycle (T MAPC)

(Closed-loop position controller)
Master
TM
R1 R2 R3 R1 R2 R3 R1 R2 R3
DP-cycle T S1 S2
S2 S3 MSG Reserve T S1 S2 S3 MSG Reserve T S2 S3 MSG Reserve T
S1
clock cycle (TSAPC)

(Closed-loop
speed controller/current controller)
R1 R1 R1 R1
R1 R1 R1 R1
Slave1..3 R1 R1 R1 R1 R1
TI TO
Figure 79 Example: Optimized DP cycle
In the optimized DP cycle the enhanced synchronized isochronous mode is used. The
sequence actual value acquisition, actual value transmission, position control, setpoint
transmission is optimized with respect to time so that the control delay is minimized.
The clock cycle synchronization in Application Class 4 "Positioning with central interpolation
and position control" requires this mode.
For time setting refer to 6.7.2.
a) Slave optimization (T I )
This time for synchronizing the actual value acquisition should be located as close as
possible to the end of the DP cycle.
b) Slave optimization (T O )
This time for synchronizing setpoint acquisition in all slaves should be located as close as
possible to the end of cyclic data transmission.
c) Master optimization (T M )
For this, a position controller shift of time T M is added so that the transmitted values are
available to the position controller in the same DP cycle. The calculation of new setpoint
values in the position controller shall be completed prior to the next data transmission to
the slave.

Content Start
Version 4.0
The shift may be realized in two ways:

1) The sequence of the slaves in the DP cycle is not known. The position controllers are
shifted to a time at which Data_Exchange with all slaves has been completed.
2) The sequence of the slaves in the DP cycle is known. Position control may be
executed in the sequence of data transmission. The shift of the position controller of
an axis only has to take into account the end of the Data_Exchange of the assigned
slave.
This model makes greater demands on the computational performance as well as the
sequential control of the master and of the slaves, but minimizes the control-related delay.
The control-related delay is calculated as follows:
Delay = T DP + T I + T O
6.7.2.3 Example (optimized DP cycle, T MAPC = 2 * T DP )
TMAPC=2 * TDP
clock cycle (TMAPC)
(Closed-loop position controller)
TM
Master R1 R2 R3 R1 R2 R3
DP-cycle MSG Reserve T S1 S2 S3 MSG Reserve T S1 S2 S3 MSG Reserve T S1

S1 S2 S3 MSG
clock cycle (TSAPC)

(Closed-loop
speed controller/current controller)
R1 R1
R1 R1 R1 R1 R1 R1 R1 R1
R1
Slave1..3
TI TO
Figure 80 Example: Optimized DP cycle (T MAPC = 2 * T DP )
In this example, the master is relieved of computation time. This results from the fact that the
position controller cycle is a multiple of the DP cycle. Such a setting may be necessary if the
runtime of the control in the master is only a low proportion of the entire runtime in the
master. For setting the timing refer to 6.7.2.

Content Start
Version 4.0
6.7.3 Running-up, cyclic operation
Execution (in general)
When running-up and cyclic operation, the following DP services are required:
Function DP Service
Slave parameterization/configuration Set_Prm, Chk_Cfg

Clock cycle transmission Global_Control
User data transmission Data_Exchange
Sign-Of-Life transmission (slave, master)
Running-up consists of the following phases:
Phase 1: Slave parameterization, slave configuration

Phase 2: Synchronizing of the PLL to the cycle Global_Control
Phase 3: Synchronizing of the slave application to the masters Sign-Of-Life
Phase 4: Synchronizing of the master application to the slaves Sign-Of-Life
The following starting points in time are possible after an error in cyclic operation:
A: Running-up again; for example after faulty parameter assignment,

Initiated by the master application (write access to the profile parameter P972)
B: Re-synchronization of the PLL; for example after clock failure,
Initiated by the master application (mode Operate and Data_Exchange)
C: Re-synchronization to the masters Sign-Of-Life (LS) after it failed,
Initiated by the slave application (autonomous)
D: Re-synchronization to the slaves Sign-Of-Life after it failed,
Initiated by the master application (independently)
Figure 81 shows the sequence when running-up with respect to time:

Content Start
Version 4.0
Master Application Slave Application
Phase 1:
A Parameterization
Configuration
Phase 2:
B PLL Synchronization
C
Phase 3: Synchronization
to master`s sign-of-life
Running-Up Monitoring
D
Phase 4: Synchronization
to slave`s sign-of-life
Figure 81 Running-up (sequence with respect to time)
For information, the State Machine Descriptions for the Isochronous Mode of [2] may be read
in [10].
If the system runs-up again (totally or partially, refer to A to D) this is treated the same as a
new Running-up (like after Power-On).
The Sign-Of-Lives are used to monitor the synchronism of the master and the slave
applications. In Multi-Axis Drive Units, it is recommended to realize the handling of the slave's
Sign-Of-Life and of the master's Sign-Of-Life axis-specific.
The power-up synchronization diagrams do not take into account the transmission time of the
Sign-Of-Life. Depending on the model used (refer to 6.7.2.1 up to 6.7.2.3) the following
transmission times are however relevant:
Master -> Slave: 1 - 2 T DP , depending on T O

Slave -> Master: 1 - 3 T DP , depending on T I and T M
Master <-> Slave additional delay because of HW/SW interfaces (such as
communication RAM)
However, for the synchronization functionality a constant transmission time poses no problem,
as it is not required that different slave signs-of-life take up the same or certain phase relation
with respect to the masters Sign-Of-Life.
The following sequences are specified for a ratio T MAPC /T DP = 1/1. A concluding example
specifies the sequence for a ratio T MAPC /T DP = 2/1.

Content Start
Version 4.0
Phase 1: Slave parameterization, configuration
Master application DP Master DP Slave Slave application

....
Set_Prm DP Parameterization
( Drive Parameterization
IsoM Parameter PLL Parameterization
)
....
Chk_Cfg DP configuration
....
GC
(
Clear,
Sync/Freeze,
Group 0/8
)
DX (Nil)
DX (S -LS = 0)
Figure 82 Phase 1: Slave parameterization, configuration
The values transferred with Set_Prm (refer to [10]) are first required in the slave application
for DP, drive and PLL parameterization, all before the master application goes into the state
Operate.
The Chk_Cfg service (refer to 4.4.3) includes the DP configuration.
The communication shall be reset (re-parameterization with Set_Prm, refer to A in Figure 81),
in order to allow a new parameterization, for example the PLL after faults due to incorrect
parameterization (drive reset by writing a certain value into the profile parameter P972).
Phase 2: Synchronization of the PLL with the Clock Global_Control

....
GC
(
Clear,
Sync/Freeze,
Group 0/8
)
DX (Nil)
DX (S -LS = 0)
Figure 83 Phase 2: Synchronization of the PLL to the Clock Global_Control

Content Start
Version 4.0

Status Operate GC Start: PLL
+ ( Synchronization
Data_Exchange Operate,
Sync/Freeze,
Group 8
)
DX (M -LS = Nil)
DX (S -LS = 0)
....
GC (Operate ...)
Start: M -LS = 1 DX (M -LS = 1)
Start: Running -up DX (S -LS = 0)
monitoring
....
GC (Operate ...)
M-LS + 1 DX (M -LS = n)
DX (S -LS = 0) End: PLL -
Synchronization
Start: Clock monitoring

....
GC (Operate ...)
M-LS + 1 DX (M -LS = n)
DX (S -LS = m) S-LS + 1
Change: Operate -> Clear GC (Clear ...)
DX (Nil)
DX (S -LS = m + S-LS = 0
1)
GC (Clear ...)
DX (Nil)
DX (S -LS = 0) S-LS = 0
Figure 83 Phase 2: Synchronization of the PLL to the Clock Global_Control

(continued)
PLL parameterization shall be concluded prior to PLL synchronization (refer to 6.7.5.3).
If the slave application recognizes Operate in the Global_Control status and it receives valid
Data_Exchange telegrams, then it starts the PLL synchronization. Any further change from
clear to operate of the master results in a new run-up starting with the PLL synchronization
(refer to B in Figure 81) up to the slave Sign-Of-Life discontinuation.
To start a new synchronization, the PLL synchronization does necessarily need the change
from clear to operate. The PLL synchronization should also be possible as soon as a GC with
group 8 is sent.
After PLL synchronization has been completed, cyclic operation starts if the internal
conditions of the slave for cyclic operation are fulfilled, and the slave application starts with
clock monitoring (refer to 6.7.6).
The status of the masters Sign-Of-Life is unimportant for PLL synchronization. The start of
the masters Sign-Of-Life and the start of the running-up monitoring may begin at a later time.
Content Start
Version 4.0
This may be utilized by the master application to delay slave synchronization. If for example,
parameters are read from the slave by the master application for adapting the cyclic interface,
the masters Sign-Of-Life and running-up monitoring will only be started after this process.
After the running-up monitoring time expires, the master application sends out a
corresponding alarm.
If the master application executes a change from Operate->Clear, the following applies:
In Data_Exchange, the master switches the Output Data into the safe mode (without
FailSafe -> Output Data = 0, with FailSafe -> length of Output Data = 0). The result is a
failure of the masters Sign-Of-Life. The slaves Sign-Of-Life is set to 0 in order to have
the same conditions for the transition from clear to operate as in phase 2.
The Global_Control for the clock cycle continues to be transmitted (-> the events
from/to secondary layers (FDL) are saved).
The PLL synchrony may be retained specific to the application.
Phase 3: Synchronization of the slave application to the master's Sign-Of-Life

....
GC
(
Operate,
Sync/Freeze,
Group 8
)
M-LS + 1 DX (M -LS = n)
DX (S -LS = 0)
GC (Operate ...)
M-LS + 1 DX (M -LS = n + 1) Start: M -LS-
Synchronization
DX (S -LS = 0)
GC (Operate ...)
M-LS + 1 DX (M -LS = n + 2) Test: M -LS (1. OK)
DX (S -LS = 0)
....
GC (Operate ...)
M-LS + 1 DX (M -LS = n) Test: M -LS (x. OK)
End: M -LS
Synchronization
DX (S -LS = 0)
Figure 84 Phase 3: Synchronizing the slave application with the master's Sign-Of-Life

Content Start
Version 4.0
GC ( Operate ...)
M-LS + 1 DX (M -LS = n + 1)
DX (S -LS = 0) Start: S -LS (for the
master)
Start: M -LS monitoring
GC (Operate ...)
M-LS + 1 DX (M -LS = n + 2)
DX (S -LS = m) S-LS = m + 1
Figure 84 Phase 3: Synchronizing the slave application with the master's Sign-Of-Life
(continued)
After successful PLL synchronization, the slave application starts the slaves Sign-Of-Life
(counter in the DP cycle) with an arbitrary value between 1 and 15 when the masters Sign-Of-
Life changes (n -> n + 1). The slaves Sign-Of-Life is first communicated to the master at the
end of its own Sign-Of-Life synchronization which results in the master application being
synchronized with the slaves Sign-Of-Life only after slave synchronization.
The slave starts Sign-Of-Life synchronization at a change of the masters Sign-Of-Life (n -> n
+ 1). The slave application tests the masters Sign-Of-Life in each DP cycle. The expectation
value of the masters Sign-Of-Life in the slave application in the next master application cycle
is as follows:
Master-LS = n + 1 (max. 15)
If a tested masters Sign-Of-Life does not correspond to the expected value, synchronization
restarts. The synchronization phase is considered completed only if, in the slave application,
the complete value range of different masters signs-of-life corresponded to the expected
values in the master application cycle. The slaves Sign-Of-Life is then transmitted to the
master for the first time (see above).
After the signs-of-life synchronization has been completed, the slave application starts with its
cyclic monitoring of the masters Sign-Of-Life (refer to 6.7.6).

Content Start
Version 4.0
isolate the internal clock cycle

source from the PLL output; Drive unit is not synchronized
stop PLL
Drive Unit
PLL Synchronization Synchronize PLL to Global Control

PHASE 2
Synchronization O.K.
PLL Fault
(clock failure) Synchronize internal clock cycle
source to PLL output
Recognize the DP cycle start from

Global Control
Global Control recognized
Drive
Drive Axis
Drive Axis
Unit
synchronized Drive Axis Control Loop is
activated
Sign-Of-Life
Master LS change recognized Fault
PLL Fault Sign-Of-Life

(clock failure) Synchronization
Check Master LS and Global
PHASE 3
Control
16 changes of Master LS are O.K.
Synchronize internal clock

cycle to TMAPC
Drive Axis synchronized to

Master LS
Figure 85 State diagram of phases 2 and 3 of the run-up
Phase 4: Synchronization of the master application to the slaves Sign-Of-Life

....
GC
(
Operate,
Sync/Freeze,
Group 8
)
DX (M -LS = n)

Life

Content Start
Version 4.0

DX (S -LS = 0) Start: S -LS (for the
master)
Start: M -LS
monitoring
GC (Operate ...)
M-LS + 1 DX (M -LS = n + 1) S-LS + 1
Start: S -LS- DX (S -LS = m)
Synchronization
GC (Operate ...)
M-LS + 1 DX (M -LS = n + 2)
Test: S -LS (1. OK) DX (S -LS = m + 1) S-LS + 1
....
GC (Operate ...)
M-LS + 1 DX (M -LS = n)
Test: S -LS (x . OK) DX (S -LS = m) S-LS + 1
End: S -LS
synchronization
GC (Operate ...)
M-LS + 1 DX (M -LS = n + 1)
End: Running -up DX (S -LS = m + 1) S-LS + 1
monitoring
Start: S -LS monitoring
GC (Operate ...)
M-LS + 1 DX (M -LS = n + 2) Monitoring M -LS
Monitoring S -LS DX (S -LS = m + 2) S-LS + 1

Life (continued)
The master application starts the masters Sign-Of-Life (counter in the master application
cycle) with an arbitrary value between 1 and 15 at the earliest when changing from Clear ->
Operate.
The master application starts the Sign-Of-Life synchronization at a slaves Sign-Of-Life (m

unequal to 0). The master application tests the slaves Sign-Of-Life during each master
application cycle. The expected value of the slaves Sign-Of-Life in the next master
application cycle is as follows:
SlaveLS = m + MasterApplication Cycle/DP Cycle = m + T MAPC /T DP (max. 15)
If a tested slaves Sign-Of-Life does not correspond to the expected value, synchronization of
Phase 4 restarts. The synchronization phase is considered to be completed only if, in the
master application, the complete value range of the different slaves signs-of-life
corresponded to the expected values in the master application cycle.
After running-up synchronization has been completed, the master application concludes
running-up monitoring and starts with the cyclic monitoring of the slaves Sign-Of-Life (refer to
6.7.6).
The applications (master, slave) monitor the Sign-Of-Life of the other (refer to 6.7.6). If the
Sign-Of-Life fails (master or slave application), the other will try automatically to re-
synchronize itself to the failed application.

Content Start
Version 4.0
If the slave application detects that the masters Sign-Of-Life failed, the slave application
immediately attempts a re-synchronization to the masters Sign-Of-Life (refer to C in Figure
81), so that synchronous operation may continue after the users acknowledgement. This re-
synchronization also causes the slaves Sign-Of-Life to discontinue.
If the master application detects a failure of the slaves Sign-Of-Life, the master application
immediately attempts a re-synchronization to the slaves Sign-Of-Life (refer to D in Figure 81),
so that cyclic operation may continue after the user acknowledged this fault.
Example: Run-up into cyclic operation (T MAPC /T DP = 2/1)
Phase Master application DP Master DP Slave Slave application

1 Set_Prm PLL parameterization
....
2 GC (Clear)
DX (Nil)
DX (S -LS = 0)
2 Change: Clear -> GC (Operate) Start: PLL Synchronization
Operate
DX (M-LS = 0)
DX (S -LS = 0)
....
2 GC (Operate)
Start: M -LS = 1 DX (M -LS = 1)
Start: Running -up DX (S -LS = 0)
monitoring
....
2 GC (Operate)
DX (M -LS = n)
DX (S -LS = 0) End: PLL Synchronizatio n
Start: Clock monitoring
Start: cyclic operation
...
3 GC (Operate)
DX (M -LS = n + Start: LS -Synchronization
1) Start: S -LS = 1 (only
internal)
DX (S -LS = 0)
3 GC (Operate)
DX (M -LS = n + Test: M -LS
1)
DX (S -LS = 0)
3 GC (Operate)
DX (M -LS = n + Test: M -LS (1. OK)
2)
DX (S -LS = 0)
Figure 87 Example: Running-up to cyclic operation (TMAPC /T DP = 2/1)

Content Start
Version 4.0
Phase Master application DP Master DP Slave Slave application

3 GC (Operate)
DX (M -LS = n + Test: M -LS
2)
DX (S -LS = 0)
....
3 GC (Operate)
DX (M -LS = n) Test: M -LS (x. OK)
End: LS -Synchronization
DX (S -LS = 0)
4 GC (Operate)
DX (M -LS = n)
DX (S -LS = m) Start: S -LS (for the master)
Start: M -LS monitoring
4 GC (Operate)
DX (M -LS = n +
1)
Start: LS DX (S -LS = m + 1)
Synchronization
4 GC (Operate)
DX (M -LS = n +
1)
DX (S -LS = m + 2)
4 GC (Operate)
DX (M -LS = n +
2)
Test: S -LS (1 . OK) DX (S -LS = m + 3)
4 GC (Operate)
DX (M -LS = n +
2)
DX (S -LS = m + 4)
....
4 GC (Operate)
DX (M -LS = n)
Test: S -LS (x. OK) DX (S -LS = m)
End: LS
synchronization
5 GC (Operate)
DX (M -LS = n)
DX (S -LS = m + 1)
5 GC (Operate)
DX (M -LS = n +
1)
End: Running -up DX (S -LS = m + 2)
monitoring
Start: S -LS monitoring
Figure 87 Example: Running-up to cyclic operation (TMAPC /T DP = 2/1) (continued)

Content Start
Version 4.0
6.7.4 Parameterization, configuring (Set_Prm, GSD)
The following parameters are needed for a clock-cycle synchronous drive interface:
Table 70 Parameters (Set_Prm, GSD) for "Clock-Cycle Synchronous Drive Interface
Parameter Name Set_ GSD Data Type Unit typical values

Prm (Internal)
(internal) (absolute)
DPV1_ Support of the DPV1- x Boolean - 1 True

functionality
Slave (1: True)
Isochron_ Support of the x Boolean - 1 True
isochronous mode
Mode_ (1: True)
supp
Isochron_ Request of the x Boolean - 1 True
isochronous mode
Mode_ (1: True)
required
T BASE_DP Time Base for T DP x x Unsigned32 1/12 s 1500 125 s
T DP_MIN Minimum T DP x Unsigned16 T BASE_DP 8 1000 s
T DP_MAX Maximum T DP x Unsigned16 T BASE_DP 256 32ms
T DP DP Cycle Time x Unsigned16 T BASE_DP 16 2000 s
T MAPC Master Application x Unsigned8 T DP 1 2000 s
Cycle Time
T BASE_IO Time Base of T I , T O x x Unsigned32 1/12 s 1500 125 s
T I_MIN Minimum T I x Unsigned16 T BASE_IO 1 125 s
TI Point in time for actual x Unsigned16 T BASE_IO 2 250 s
value acquisition
T O_MIN Minimum (T O -T DX ) x Unsigned16 T BASE_IO 1 125 s
TO Point in time for x Unsigned16 T BASE_IO 9 1125 s
setpoint transfer
T DX Data_Exchange time x Unsigned32 1/12 s 12000 1000 s
T PLL_W PLL Window (1/2) x Unsigned16 1/12 s 12 1 s
T PLL_W _MAX Maximum of PLL x Unsigned16 1/12 s 12 1 s
Window
T PLL_D PLL Delay x Unsigned16 1/12 s 0 0 s
A detailed description of the parameters which have been introduced in Table 70 is provided
in [10].
If the parameter Isochron_Mode_Supported = 0, the remaining isochronous parameters (in

the parameterization telegram or in the GSD file) are unimportant.
The unit [1/12s] of the basic times T BASE_DP , T BASE_IO and the times T DX , T PLL_W , and T PLL_D
has the following advantages:
1/12 s corresponds to the time t BIT at 12 Mbaud (83 ns) and may also be used for
other baud rates
1/12 s also permits the representation of 31.25s, for example, without using the data
type Float
1/12 s as unit for the two parameters T PLL_W and T PLL_D allows these to be more finely
set for a lower baud rate than with the unit t BIT
Content Start
Version 4.0
1/12 s as unit for the two parameters T PLL_W and T PLL_D permits implementation
independent of the baud rate (for example by a soft PLL)
The times T PLL_W (PLL window) and T PLL_D (PLL delay time) are used to parameterize the PLL
(refer to 6.7.5.3).
6.7.5 Clock cycle generation (Global_Control) and clock cycle save
6.7.5.1 Definition of the Global_Control service (current functionality)
With a Global_Control telegram, a master may send commands (SYNC, UNSYNC, FREEZE,
UNFREEZE, CLEAR_DATA) to a group of slaves or to all slaves.
The allocation of a slave to a specific group is specified during run-up in the parameterization
telegram.
The data part of the global control telegram consists of 2 bytes:
1 st octet: commands SYNC (bit coded)
2 nd octet: Group 1 to 8 (bit coded)
A destructed global control telegram is not repeated.
Types of synchronization (expansion for "clock cyclic synchronous drive interface)
Of the possible groups 1 to 8 (see above), the following group is permanently reserved in the
Global_Control telegram for the application clock cyclic synchronous drive interface:
Group 8: Clock synchronization
In the case of the application clock cyclic synchronous drive interface, the DP master sends a
Global_Control telegram with the ID for Group 8 at the start of a cycle.
A drive which supports the isochronous mode may not be assigned to a group in the
parameterization, but still responds to the Global Control of Group 8. A drive, which does not
support the isochronous mode, may be operated with Group 8 at the clock cycle limits with
SYNC/FREEZE.

Content Start
Version 4.0
Table 71 Possible synchronization type combinations
Synchronization Supported synchronization Parameterization

mechanism mechanism
parameter Global
Control
Isochronous Basic Sync, Group (Group
Mode synchronization Freeze Ident Select)
(Sync, Freeze)
No synchronization -- -- -- -- --
User synchronization -- x x 1-7 1-7

Cyclic synchronization -- x x 8 8
(combined synchronization
telegram with Sync and/or
Freeze Command)
Cyclic synchronization X -- -- -- 8
(Isochronous Mode)
NOTE -- not used at this synchronization mechanism
NOTE The Global_Control telegram to indicate the master operating mode is sent as an additional
Global_Control to Group 0 (no group) so that mixed operation with slaves without synchronization (without Group
8) is possible.
6.7.5.2 Clock jitter
The clock cycle transmitted with Global_Control has the following attributes:
Clock Jitter see below

Clock Failure a faulty global control telegram is not repeated
Phase Shift between different slaves through runtimes of the Global_Control
time delay telegram repetitions in the previous cycle
Clock jitter is the stochastic deviation of the nominal clock instant, because the deviation may
change in every clock cycle. The jitter is specified in 0..x ns, this means it is always an
additional value to the nominal clock instant. The slave controls the nominal clock instant plus
x/2 in average.
Following components form the clock jitter:
Master-ASIC
Profibus physics
Repeater
Slave-ASIC
The quartz drift leads to non exact periods of the Global control telegram and changes with
the time (effect of temperature, aging).
An individual clock jitter evaluated in the slave as too large is considered a jitter failure. The
slave then generates a substitute clock cycle (refer to 6.7.6).

Content Start
Version 4.0
The maximum jitter value maxT J shall not exceed 1 s. An individual clock jitter evaluated in
the slave as too large is considered a clock failure.
Table 72 shows the allowable conditions in isochronous mode for baud rate, min and max DP
clock cycle, and jitter.
Table 72 Conditions for Isochronous Mode
DP clock cycle
a
Baud rate MAXIMUM Minimum Clock generation output Clock regeneration input
12 Mbit/s 32ms 0,5ms < 200ns max 1s
6 Mbit/s 32ms 0,5ms < 300ns max 1s

3 Mbit/s 32ms 1ms < 450ns max 1s
1,5 Mbit/s 32ms 2ms < 790ns max 1s
Allowable Failures 3 in a row 5 in a row

a
All PROFIdrive-conform Master and Slaves shall support 12Mbit/s for clock cycle synchronous applications.
The following limits for bit clock generation output in the Master and Slave shall not exceed:
Bit clock cycle accuracy < 0,03%

Drift/Time +/- 1 ppm/min
6.7.5.3 PLL for clock regeneration in the slave
By using a PLL, the clock jitter may be smoothed in the slave, and clock failure as well as
runtime effects may be compensated. In this chapter a principal description of the PLL
functions is given.
PLL Reset
Global_Control Clock cycle SYNC
(DP Clock DP Slave (TDP) (TDP / n)
cycle) ASIC PLL Clock cycle
Generation
- Jitter <=1s - Smoothing - Jitter <=100ns
at the DP plug Clock Jitter - without failure
of the slave - with delay
- with failure PLL Start - Compensation
Clock Failure
SYNC Mode
SYNC Enable - Compensation
SYNC clock cycle Period Duration Runtime Effects
No. of SYNC pulses per TDP
PLL-Window Hit Display
PLL-Delay Clock0 Display
DP Cycle (TDP)
Global_Control
Window Failure (no GC; destroyed

Failure (delayed) during transport via bus)
Figure 88 PLL for clock save in the slave

Content Start
Version 4.0
The PLL has the following input signals (parameter or pin):
Table 73 Input signals of the PLL
Input signal Description Input
Par. Pin
PLL reset Hardware reset of the PLL. x

CLOCK CYCLE When the Global_Control telegram for the clock cycle is received, the x
DP slave ASIC indicates this.
PLL start This may be used to stop or start the PLL. x
SYNC mode Synchronous/not synchronous: x
This is used to set whether or not the PLL attempts to synchronize the
SYNC signal to the Global_Control telegram.
SYNC enable This may be used to set whether or not the SYNC signal is to be put x
out.
SYNC clock cycle period This may be used to set the SYNC clock cycle period as multiple x
duration integer component of the Global_Control clock cycle period.
Number of SYNC cycles This may be used to set the number of SYNC clock cycles per x
per T DP Global_Control clock cycle period duration.
PLL window The selected value is half the width of the tolerance window. x
PLL delay time The selected value is the delay time of the generated SYNC clock x
cycle.
NOTE 1 The PLL window and PLL delay time parameters are also part of the parameterization telegram Set_Prm
(refer to 6.7.4)
NOTE 2 To set several input parameters the DP cycle time (T DP ) as well as the baud rate shall be known.
The PLL has the following output signals (register or pin):
Table 74 Output signals of the PLL
Output Signal Description Output

Reg. Pin
SYNC The clock cycle output of the PLL is a clock that is jitter-free and x
stable to the greatest extent possible.
This clock cycle deviates from the DP clock cycle by a constant
delay time that may be set (compensates phase shifts between
slaves due to the runtimes of the Global_Control telegram).
The period of the SYNC clock pulse is an integer component of the
actual T DP .
Hit Display Indicates whether a Global_Control telegram arrived within the x
tolerance window.
Clock0 Display Indicates whether the SYNC clock cycle that was just read out x
coincides with the (expected) Global_Control telegram (shifted by
st
the delay time) (1 clock cycle or Clock0).
NOTE In the non-synchronized mode (see above, input parameter SYNC mode), the SYNC signal is a fixed
clock cycle with the desired period duration.
The PLL runs up as follows (if SYNC mode = synchronous)
HW reset of the PLL

Parameterization of the PLL (see above which parameters are set)
Synchronization of the SYNC clock with the DP clock (transient)
Enable of the SYNC signal after successful synchronization
Content Start
Version 4.0
The PLL should behave as follows during stationary operation (if SYNC mode = synchronous)
Generation of the SYNC clock cycle (with the above requirements)

When recognizing the DP clock cycle (within the tolerance window), the PLL should
start to compensate and display the detection of the DP clock cycle (hit-display still in
the same DP cycle)
If the DP clock cycle fails (outside the tolerance window), the PLL should not start to
compensate but continue with unchanged SYNC clock cycle
Display whether the SYNC clock cycle that was just read out coincides with the
expected DP clock cycle (Clock0)
Note regarding runtime compensation (PLL delay time)
The Global_Control telegram received by a slave is read out from the PLL delayed by a
parameterized delay time (see above). This shift has to be taken into account at
implementation. For example, the actual value (time T I ) is measured as shortly as possible
prior to the SYNC clock pulse which the PLL reads out. In the case of a longer delay time, it
may be possible that the actual value may no longer be transmitted because Data_Exchange
has already started on the bus (-> T I_MIN has to be larger than the delay).
Data_Exchange
Global_Control
delay
SYNC
TI
Figure 89 Run time compensation
6.7.6 Monitoring mechanisms
Standard DP monitoring
Monitoring the slave response in the DP master: max-T SDR / Checksum
If the slave does not respond during the response time max-T SDR, or if the master detects a
checksum error, the master repeats the telegram for a configured number of times. If all
telegram repetitions are unsuccessful, there will be a complete communication failure with this
slave.
It should be possible to configure in the master what the response is for the other drives if one
drive fails.
Setting: 60 - 800 t Bit (depends on baud rate)

NOTE Reduction is useful specific to the profile because the response time and therefore the DP cycle (T DP ) may
be optimized.
Monitoring time in the DP slave: TWD
In a slave, watchdog monitoring with T WD ensures that if the master fails, the slaves outputs
go into a safe condition after this time expires; this implies that the drives are stopped. For

Content Start
Version 4.0
clock-synchronous drive coupling, it makes sense if the setting is as far as possible the same
for all slaves (simultaneous stopping is possible).
Setting: TWD > T TR (Target_Rotation_Time)
Monitoring time in the DP-Master Class 1: Data_Control_Time
User data operation between the DPM1 and the slaves assigned to it is monitored by the
master with the Data_Control_Time. Within the Data_Control_Time, at least one user data
transfer shall have been exchanged correctly with the respective slave. If this is not the case,
this is signalled to the user of the DP master.
Setting: Data_Control_Time >=6* TWD (see above)
Violation of the DP cycle T DP
Violating the DP cycle T DP (for example because telegrams have been repeated) does not
necessarily have to cause communication failure considering the following reasons:
Clock pulse failure may be intercepted in the slave through a failure strategy (own
clock pulse generation) (see below, Clock Failure)
A possibly resulting user data failure may be intercepted in the slave using a failure
strategy (substitute value) (see below, user data failure)
As shown below, a DP cycle violation may not lead to permanent clock pulse shifts:
DP Clock (setp.) z / az z / az z / az z / az z / az Z / az
DP Clock (actual) z / az z / az z z / az z / az Z / az
z / az = cyclic / acyclic
NOTE 1 The master has to ensure that no permanent clock pulse shifts take place if the DP cycle is violated. The
cycle may be snapped into place by the following cycle suppressing the acyclic part of the cycle after the violation
(refer to 7.7.1).
NOTE 2 Several successive DP cycle violations may cause a permanent clock pulse shift (for example through
timer overflow in the master ASIC).
Clock failure
The slave monitors the clock failure of the master. Monitoring starts after the slave has been
successfully synchronized with the clock cycle; i.e. when the slaves Sign-Of-Life counter
starts.
For responding to clock pulse failure, a manufacturer-specific monitoring threshold shall be

defined.
When the alarm threshold is exceeded, a fault is put out (PROFIdrive: status word group bit,
fault parameter, operating mode fault): The monitoring ensures that the PLL does not lose
unrecognized clock cycle synchronization when more sequent telegrams get lost.
Possible causes of clock pulse failure:
Fault (Failure) of Global_Control

Telegram repetition
Clock jitter too large
Incorrect parameterization of the cycle time parameters
Incorrect parameterization of the PLL
Content Start
Version 4.0
After a number of defined manufacturer-specific consecutive clock cycle failures, a fault is

generated and the system shall be re-synchronized.
Example: (fault after 4 DP cycles):
Pos. Ctrl. clock: | | | | | |
DP clock: | | | | |
Counter failure: 0 0 0 0 0 1 2 3 4 4 4
Slave: |-> a |-> b |-> c
a) Slave is synchronous (start of monitoring)

b) 1st clock failure
c) Fault (after 4 DP cycles)
Figure 90 Example: Clock failure
User data failure
User data transfer is secured (refer to 4.12) in both directions (master <-> slave) using a 4 bit
counter (Sign-Of-Life) that is transmitted by using the DP service Data_Exchange.
6.8 PROFIBUS DP specific Parameter
6.8.1 Overview of the communication interface related parameters
These parameters are related to the Network Communication Interface of the Drive Unit or
Station.
Table 75 Overview of the specific PROFIBUS DP parameters for Communication

system interfaces
918 PROFIBUS DP node address mandatory if global

PROFIBUS DP
slave interface is
present
963 PROFIBUS DP actual baud rate mandatory if global
PROFIBUS DP
slave interface is
present

Content Start
Version 4.0
6.8.2 Definition of the specific parameters

PNU: 918
Significance: Node address
Implementation: Mandatory (at least readable), if PROFIBUS DP slave interface is
present
Explanation: The node addresses 0, 1 and 2 are mostly occupied by masters and
the configuration tool. Therefore they should not be used by slaves
on PROFIBUS. The first reasonable node address for a slave on
PROFIBUS is 3. The node address 126 should be the default setting
of parameter 918 because the address 126 is not requested by the
DPM1 master.
Reference: ---
PNU: 963
Significance: Actual baud rate
Explanation: For automatic baud rate recognition, this parameter indicates the
actual baud rate. The parameter is only set by the interface. For
interfaces without automatic function, the baud rate is set via this
parameter. Only relevant, if PROFIBUS DP slave interface is
present. The baud rate is designated and coded in Table 76.
Reference: ---
Table 76 Coding of the baud rate in Parameter 963
Value in Parameter 963 Significance
0 9.6 kbit/s
1 19.2 kbit/s
2 93.75 kbit/s
3 187.5 kbit/s
4 500 kbit/s
6 1500 kbit/s
7 3000 kbit/s
8 6000 kbit/s
9 12000 kbit/s
10 31.25 kbit/s
11 45.45 kbit/s
NOTE For value 5 in Parameter 963 explicitly no

baud rate is defined.

Content Start
Version 4.0
6.9 Specified communication functions for the Application Classes
According to the definition of the Application Classes in 2.4, Table 77 specifies the
communication functionality the drive shall comprise to match a specific Application Class for
PROFIdrive at PROFIBUS DP.

interface
synchronism
Table 77 Specified communication functions for the Application Classes
Relevant Application Classes Cross-reference

Functionality
for
1 2 3 4 5 6
Acyclic Services C1 m
Acyclic Services C2 m m m m m
Isochron Mode o o m m
Slave Publisher Functionality m m
Subscriber Functionality m m
Extended Parameterization o o o o o
Alarm Handling
C1-Master
Isochron Mode o o m m
Data-eXchange-Broadcast m m
C2-Master Acyclic Services C2 m m m m m

Information regardingTable 77:

Content Start
Version 4.0
7 PROFINET IO Communication Layer
This chapter defines the mapping of the PROFIdrive Base Model on the PROFINET IO
Communication System (refer to [9]).
7.1 Base Model at PROFINET IO
When using PROFINET IO as Communication Network, the PROFIdrive Devices are mapped
to the following PROFINET IO objects:
Controller: The PROFIdrive Controller is represented by the IO-Controller. E.g. this may
be a PLC, NC or PC.
Drive Unit: The PROFIdrive Drive Unit is represented by the IO-Device. The Drive Unit is
related to one or more Axis of the automation system.
Supervisor: The PROFIdrive Supervisor is represented by the IO-Supervisor. E.g. this
may be a PG or OP.
Figure 91 shows the topology of a typical PROFIdrive drive system using PROFINET IO as
Communication Network.
IO-Controller 1 IO-Controller 2 IO-Supervisor
PLC, NC, PC PLC, NC, PC PG, OP
PROFINET IO
IO- I/O IO- I/O

Device D D Device
IO- R IO- R
Device I Device I
other V V other
peripherals E E peripherals
M M
E E
PROFIdrive
Application Application
Class 1 Class 3
Figure 91 PROFINET IO Devices in a PROFIdrive drive system

Content Start
Version 4.0
The PROFIdrive Communication Relationships between the Devices are mapped to

PROFINET IO in the following way:
Controller - Drive Unit Relationship is represented by IO AR

Supervisor - Drive Unit Relationship is represented by Supervisor AR
Drive Unit - Drive Unit There is no dedicated Application Relationship for data
exchange between Drive Units. The data exchange between Drive Units is realized by use
of a Multicast-CR (M CR) which is initiated and supervised by the IO Controllers.
Figure 92 shows the PROFIdrive Devices and their relationships on PROFINET IO.
Device -Device PROFINET IO

Communication Relationship
IO
Device PROFINET Device Supervisor
Supervisor AR
R
rA
so
vi
p er
IO
Su
Controller
IO
AR
IO
AR
IO Device M CR IO Device
(Drive Unit) (Drive Unit)
Figure 92 PROFIdrive Devices and there Relationship for PROFINET IO

Content Start
Version 4.0
For PROFINET IO as Communication System for PROFIdrive, the PROFIdrive General

Communication Model is shown in Figure 93.
Within the PROFINET Context the PROFIdrive Device at PROFINET IO is precisely defined
by the following address information:
Network (PROFINET IO Bus/Domain)

Station (PROFINET IO Name of Station/IP-address). The Name of Station identifies the
Station unambiguously. The IP-address is assigned to the Network Interface and
corresponds to the Name of Station but may vary with a new start-up of the
Communication System. The Name of Station is assigned when setting up the network
configuration.
Interface (PROFINET IO Interface UUID). The Interface UUID defines the type of the
PROFINET IO Interface which are e.g. Device, Controller, Supervisor, according to [9].
Object (PROFINET IO Object UUID). The Object UUID comprises the sub address
elements Vendor, Device Type and Instance. For the PROFINET devices the Vendor-ID is
allocated by the PNO, the Device Type is allocated by the vendor and the Instance is
allocated when setting up the Network configuration.
API. The API to be used for PROFIdrive is 0x3A00. Inside a PROFIdrive application all
application processes are of PROFIdrive Application Process type (API=0x3A00).
PROFINET IO
Station
PROFIdrive
Drive Unit
... PROFIdrive
Controller
(IO Device) (IO Controller)
IO Device IO Supervisor IO Controller

Interface Interface Interface
Station Station
...
PROFINET IO Network Interface
Network Interface Connector
Network
Figure 93 General Communication Model for PROFIdrive at PROFINET IO

Content Start
Version 4.0
The PROFIdrive Base Model Communication Services are provided by the following
PROFINET IO Application Service Elements (ASE):
The PROFIdrive Cyclic Data Exchange service is provided on PROFINET IO by the IO Data
ASE.
For the Cyclic Data Exchange between Controller and Drive Unit this is done by the IO CR
which is part of the IO AR. The IO AR is established by the Context ASE.
For the Cyclic Data Exchange between Drive Unit and another Drive Unit, this is done by
the M CR. Initiation and supervision of the M CR should be done by the related
controller(s) (refer to [9]).
The PROFIdrive Acyclic Data Exchange service is provided on PROFINET IO by the Record
Data ASE.
The Acyclic Data Exchange between Controller and Drive Unit is done by the Record Data
CR which is part of the IO AR or Supervisor AR.
Also theres an additional possibility for an acyclic (read only) data exchange by the
implicit read mechanism, which is part of an Implicit AR.
The PROFIdrive Alarm Mechanism is provided on PROFINET IO by the Alarm ASE. The
Alarm ASE is realized by the Alarm CR which is part of the IO AR.

Content Start
Version 4.0
The PROFIdrive Clock Synchronous Operation Mechanism is provided on PROFINET IO by

the Isochronous Mode Application ASE. Clock Synchronous Operation is only possible
when using PROFINET IO with IRT. With PROFINET IO with IRT theres the possibility to
have different cycle time for the DOs. Figure 94 shows an example with a Reduction Ratio of
4, which means, that PROFINET IO Data Cycle T DC is divided into four phases. The Does
cyclic data objects may be actualized in every phase of the Data Cycle or less often. This
gives the possibility to operate drive axes with different performance requirements within one
PROFINET IO domain without excessive communication overhead (refer to [9]).
Reduction Ratio = 4

Sequence
1 2 3 1 1 2 1
Send Clock Send Clock Send Clock Send Clock
Figure 94 Clock cycle synchronous communication for PROFIdrive at PROFINET IO

Content Start
Version 4.0
7.1.5 Drive Unit Communication Model
Figure 95 shows the Drive Unit Communication Model for the PROFINET IO Communication
System.
IO Controller
(Controller)
IO Supervisor
(Supervisor)
IO AR (Record Data CR)
IO AR (Input/Output CR)
Isochronous Operation
(PROFINET IO
with IRT)
d
t r ea
p lic i
Im
or
R
CR rA
M r v is o Cyclic communication
pe
Su
Acyclic communication
IO Device
(Drive Unit)
Figure 95 Overview about the Drive Unit Communication Model on PROFINET IO
PROFINET IO allows multiple Controllers within one domain. Also theres the possibility to
establish and control DOs of one Drive Unit from different Controllers even to share one DO
by more than one Controller. Within one IRT Domain there is one dedicated Clock Master for
the Isochronous Operation Mode.

Content Start
Version 4.0
IO AR
Input CR (mandatory)
Output CR (mandatory)
Alarm CR mandatory)
Alarm CR (optional)
Record Data CR (mandatory)
IO Controller
(Controller)
IO-Device
(Drive Unit)
IO Supervisor
(Supervisor) Supervisor AR
IO X CR (optional)
Figure 96 Contents of IO AR and Supervisor AR
Figure 96 shows the principle content of an IO AR and a Supervisor AR according to [9].

Mandatory for both AR is the Record Data CR which is necessary for the context management
and the PROFIdrive Parameter Access. The IO AR also comprises the Input and Output CR
which is used for the Cyclic Data Exchange and the Alarm CR which is used for the Alarm
Mechanism.
Figure 97 shows the use of an M CR for Cyclic Data Exchange between two Drive Units
according to [9]. The initiation and supervision of the M CR is done by the IO-Controller or the
IO-Controllers if the AR endpoints of the M CR are parts of different IO AR to different IO-
Controllers.

Content Start
Version 4.0
IO-Controller IO-Controller
(Controller) (Controller)
Connection establishment

and monitoring
Alarm CR (optional)
Alarm CR (optional)
Alarm CR (mandatory)
Alarm CR (mandatory)
IO AR
IO AR
unidirectional
IO-connection
M CR
IO-Device IO-Device
Drive Unit Drive Unit
(Publisher) (Subscriber)
Figure 97 M CR used for Cyclic Data Exchange between Drive Units
7.1.6 Base Model State Machine
For PROFIdrive at PROFINET IO the States of the PROFIdrive Base Model State Machine are
mapped to the PROFINET IO states according to Figure 98. The actions to be carried out in
the different phases and the corresponding PROFINET IO states are described in the
following list:
Offline: In the Offline state no Communication Service is available. In this phase the
Communication System prepares for setup of basic communication functions to start the
Context Management process. Here this means the evaluation of the local configuration
and the address assignment to the stations.
Phase1: The PROFIdrive Phase 1 comprises the PROFINET IO Context Management
substep 1. Here first standard IO ARs are established to transmit standard and isochron
configuration information to the devices. Then the alarm handler is started and the local
synchronization between Slave Clock and Slave Clocks is established.
Phase2: The PROFIdrive Phase 2 comprises the PROFINET IO Context Management
substep 2. Here, with the IRT-configuration information present, the standard IO ARs are
broken down and new IRT-IO ARs are established if the PROFINET IO domain is
configured to operate in IRT mode. Phase 2 is finished with a consistency check and the
activation of provider and consumer.

Content Start
Version 4.0
PROFINET IO applications/application processes are already started (Input and Output
PZD are valid), and operating in isochronous mode. Now the PROFIdrive Application
Layer tries to synchronize its tasks by use of the Life Sign mechanism. In this first part the
Controller Life Sign (C-LS) is synchronized (see also 4.12).
PROFINET IO applications/application processes are already started (Input and Output
PZD are valid), and operating in isochronous mode. Now the PROFIdrive Application
Layer tries to synchronize its Tasks by use of the Life Sign mechanism. In this second part
the DO Life Sign (DO-LS) is synchronized (see also 4.12).
Operation: In the Operation state all Communication Services are available and active,
also the Functional Objects on the Application Layer are synchronized and the whole
PROFIdrive application is ready to operate.
PROFIdrive
Parameter Access,
PZD valid, Slave Clocks
Parameter Access, PZD not valid
synchronized
to Master Clock
Communication Layer Application Layer
Offline Preparation Synchronization Operation
PROFINET IO
Step1: Evaluate Step3: - establish IRT/IOAR *) C-LS-synchr. DO-LS-synchr. production

local configuration - establish IO AR - consistency check
- transmit isochron data *) and activation of
Step2: address- - Start Alarm Handler Provider and
assignment - establish local Consumer
synchronization *) - start of local
application
*) if clock synchronous operation is required
Figure 98 Mapping of the Base Model State Machine at PROFINET IO
7.1.7 Definition of the CO
For PROFIdrive the PROFINET IO Subslot is defined as common CO. The CO/Subslot should
be used as Communication Object for Process Data, Parameter Access and the Alarm
Mechanism.

Content Start
Version 4.0
7.2 Drive Model at PROFINET IO
7.2.1 Drive Unit
Figure 99 shows the PROFIdrive Drive Unit mapped on a PROFINET IO device. The logical
address elements for a Drive Unit in the PROFINET IO Communication System are:
domain
Name of Station/IP-address
Interface UUID
Object UUID
API (here for PROFIdrive only 0x3A00 is valid)
PROFINET IO
Domain
PROFINET IO
Name of Station
Network Interface
Interface
UUID
IO Device Interface
Object
UUID
Drive Unit (DU)
Drive Object Drive Object Drive Object

(DO) (DO) ... (DO)
Station
PROFIdrive PROFINET
DO-ID Slot-Number
Figure 99 PROFINET IO specific Logical Drive Unit model (multi axis drive)
7.2.2 Drive Unit Architecture
Figure 100 shows the general architecture and the mapping of the architectural elements to
COs for the Drive Unit for PROFINET IO. General with PROFINET IO the DO is mapped
exactly to one Module/Slot. This means that every Module within a PROFIdrive Drive Unit is a
DO. Slot 0 is exclusively reserved for Device representative purpose and therefore shall not
used for any PROFIdrive module. Valid Slotnumbers for PROFIdrive DOs are from 1 to
0x7FFF.
Content Start
Version 4.0
Every DO contains at least the mandatory Module Access Point (MAP) which is mapped to a
dedicated DO Representative Submodule. This MAP Submodule contains at least the
mandatory Parameter Access Point (PAP) which is mapped to a dedicated Record Data
Object (see 7.4). Via the DO representative Submodule (MAP/PAP) and the specified Record
Data Object the access to the DO parameter manager is possible. The DO parameter
manager has access to the DO local Parameter Data Base and also to the Device global
Parameter Data Base because with PROFIdrive, access to global Parameters is possible by
every present PAP (DO).
In addition to the mandatory MAP submodule, the DO may contain additional (optional)
submodules which may be used to:
Represent communication end points for PZD (cyclic data channel) and also to structure
the PZD in data blocks (telegrams, signals).
Represent physical or logical Subobjects of the DO. E.g. the motor of the axis or a special
module (pluggable) may be represented by a dedicated Submodule.
IO AR
SLOT 0 SLOT 1 SLOT m

Subslot 0 Subslot 1 Subslot 0 Subslot 1 Subslot 2 Subslot 3 ..... Subslot m
Module Standard- Signal

.....
Access Point Telegr. 4
Mist
(MAP)
Data Record 0xB02E
(PAP)
DO
acyclic cyclic
data data
channel channel
Parameter
Manager
Device/Global DO
DO Function
Parameter Parameter
Database Database
Device / Drive Unit

DO x ..... DO y
IO-Device
Figure 100 Representation of the PROFIdrive DO by PROFINET IO Submodules (CO)
The Submodules of a DO may be part of an AR. Also the Submodules of one DO may be
assigned to different ARs, but one Submodule may only be part of exactly one AR. The only
exception to this is the Implicit AR, which may have access to every submodule, but only
readable.
The hierarchical Structure of the related objects of a Drive Unit is shown in Figure 101.

Content Start
Version 4.0
Drive Unit
(DU)
1..n
Drive Object
(DO)
Drive
Sub-Object
(Submodule)
Cyclic Component
Data-Object Representative
1
DO/Parameter
Telegram Signal ...... Motor ...... access point
(MAP/PAP)
Aggregation - is part of Generalisation - is subclass from
Figure 101 Hierarchical model of the Drive Unit on PROFINET IO
7.2.3 Definition of the Module Ident Number and API
A PROFIdrive DO is represented by a Module with PROFIdrive AP (API=0x3A00). The related

Module Ident Number is vendor specific [9].
7.2.4 Definition of the Submodule Ident Numbers
Within the PROFIdrive AP (API=0x3A00) context the Subobjects/Submodules of a DO are

identified by the PROFINET IO Submodule Ident Number. Therefore every vendor shall use
the Submodule Ident Numbers according to Table 78 for the Drive Sub-Objects.
The identification and function of a Submodule is only dependent on the Submodule Ident
Number but not on the Slotnumber related to the Submodule.

Content Start
Version 4.0
Table 78 Definition of Submodul-IDs
Submodule Shortform Significance PZD length (Word)

Ident Number
Input Output
0 - not used - -
1 ST1 PZD Data Object Standard telegram 1 2 2
10 - 19 Reserved for PROFIdrive Profile - -
(according to VIK-NAMUR)
81 - 98 Reserved for PROFIdrive Profile (Encoder - -
telegram)
99 Reserved for PROFIdrive Profile - -
100 - 60000 Reserved for manufacturer-specific telegram - -
PZD Data Objects
60001 - 62000 Reserved for PROFIdrive Profile Signal data - -
objects
64001 - 65531 Reserved for PROFIdrive Profile representative - -
Data Objects
65532 I-REP Interface-Module Representative 0 0
65533 IF-REP Infeed/Rectifier/Line-Module Representative 0 0
65534 C-REP Controller-Module-Representative 0 0
65535 M-REP Motor-Representative 0 0
65536 DO-REP, DO-Module Representative (MAP) with PAP, 0 0
(=0xFFFF) MAP/PAP implementation mandatory
65537 - Reserved for PROFIdrive Profile - -
0xFFFFFFFF

Content Start
Version 4.0
7.3 Process Data
7.3.1 COs for Process Data configuration
Within PROFINET IO the cyclic data channel is composed out of all Submodules belonging to
the DO/Slot which are of PZD Data Object type. Modularity of the whole PZD data block is
possible by configuration of multiple Submodules as shown in Figure 102. The PZD data block
is put together according to the ascending Slotnumbers of the PZD Data Object Submodules.
It is strongly recommended to start the PZD data block by a PROFIdrive standard telegram
Submodule.
Slot Slot X = DO Y
Subslot 0 1 2 ... 14 ... 18
Submodule
- 0xFFFF 3 empty 60054 empty 121
Ident Number
PZD
Submodule DO-REP
PZD
Vendor
Type reserved ST3 ... P_IST_ ...
MAP/PAP monitor
GLATT
block
Output/Input
- - 5/9 ... 1 ... 0/8
data size (Word)
Vendor specific
Modular PZD-data block Standard telegram Signal
data block
ascending address
Figure 102 - Modularity of the PZD data block (example)
7.3.2 Process Data Producer and Consumer Status
The Producer Status (IOPS) and the Consumer Status (IOCS) are described in detail in [9].
7.4 Parameter Access
7.4.1 PAPs for Parameter Access
For PROFIdrive at PROFINET IO, Record Data Objects are used as PAP to transfer requests
to the parameter manager and to transfer responses from the parameter manager to the
Controller or the Supervisor. For Parameter Access the Record Data write access is defined
as request to the parameter manager, the Record Data read access is defined as response
from the parameter manager.
According also to Figure 100, the PAP Record Data Objects are related to the Submodules of
MAP type (Submodule Ident Number = 0xFFFF). The list of defined Parameter Access Modes
and there related Record Data Object is shown in Table 79.

Content Start
Version 4.0
Table 79 Definition of Parameter Access Modes
MAP Index Parameter Access Service Implementation Comment

(Record
Data Object)
0x0000 User specific Record Data, may be used optional Record Data 47 is
- 0x7FFF for user specific PAP. recommended to be used for
Base Mode Parameter Access
Global (0xB02F) for
compatibility reasons.
0xB000 Not defined - Reserved for further definition
- 0xB02E
0xB02E Base Mode Parameter Access - Local mandatory Parameter request compatible
(refer to 3.4.2) to PROFIBUS DP Parameter
Access defined in PROFIdrive
Profile Version 3 but
addressing of the DO is done
by the slot number.
0xB02F Base Mode Parameter Access - Global optional Parameter request compatible
(refer to 3.4.2) to Base Mode Parameter
Access (0xB02E), but
addressing of the DO is done
by the DO-ID in the request
header.
0xB030 Not defined - Reserved for further definition
- 0xBFFF
7.4.2 Base Mode Parameter Access
7.4.2.1 General
Every PROFIdrive Device on PROFINET IO shall support the Base Mode Parameter Access -
Local.
The Base Mode Parameter Access at PROFINET IO shall support at least 255 byte
request/response data block size (mandatory). Support of greater block sizes is optional.
7.4.2.2 Properties Base Mode Parameter Access - Local
A successful access to the local parameters of a DO is only possible, when the correct DO-ID
corresponding to the Slotnumber is entered in the parameter request header. Otherwise the
DO parameter manager will respond with error code 0x19 Axis/DO nonexistent.
For access of global parameters every valid PAP may be used. When accessing a global
parameter, the DO-ID in the parameter request header is of no importance (dont care) and
will not be checked by the DO parameter manager.
7.4.2.3 Properties Base Mode Parameter Access - Global
A successful access to the local parameters of a DO is possible, when a valid DO-ID is

entered in the parameter request header. Otherwise the DO parameter manager will respond
with error code 0x19 Axis/DO nonexistent.
For access of global parameters every valid PAP may be used. When accessing a global
parameter, the DO-ID in the parameter request header shall be a valid DO-ID (also 0 is a
valid DO-ID).

Content Start
Version 4.0
7.4.2.4 Data flow for the Base Mode Parameter Access
The data flow for the request and response data structure between the controller or
supervisor and the DO parameter manager is shown in Figure 103.
Parameter Parameter
response request
Base Mode Base Mode
Parameter Request Reference Response ID Request Reference Request ID Parameter
response DO-ID No of Parameters DO-ID No of Parameters request
DO not ready
readout of for (new) error:
ParameterResponse parameter parameter ErrorCode=0xDF ParameterRequest
ok ErrorDecode=0x80
response request ErrorCode1=0xB5 or 0xB5 1)
ErrorCode2=0
no response request
available accepted ok
error: 2)
ErrorCode=0xDE
ErrorDecode=0x80
ErrorCode1=0xB5 read write
ErrorCode2=0
Data Record Data Record
0xB02F 0xB02F
Controller/Supervisor
Data Record Data Record
0xB02E (READ) 0xB02E (WRITE)
transfer
BlockHeader; transfer BlockHeader;
request to
ParameterResponse response to ParameterRequest
Parameter
Data Record
Manager
Request Reference Response ID Parameter Request Reference Request ID

DO-ID No of Parameters Manager 3) DO-ID No of Parameters
Base Mode Parameter Base Mode Parameter
response request
Parameter
Data Base
Drive / DO
1) ErrorCode=0xA7 if blocked because Parameter Manager is busy

ErrorCode=0xB5 if response wasn't read out
2) Readout of response only once; second attempt to readout the same response causes an error
3) Processing of the parameter requests only one by one (sequence)
Figure 103 Data flow for request and response for the Base Mode Parameter Access

Content Start
Version 4.0
7.5 Drive Unit Configuration
7.5.1 Drive Unit Configuration on PROFINET IO
The general Drive Unit configuration on PROFINET IO is shown in Figure 104. From the
logical point of view there are two classes of Objects:
The DOs which are named and identified by the DO-ID. They represent the application
functionality and application processes.
The Slots which are named and identified by the Slotnumber. They represent the global
communication end point for a DO.
These two classes of objects are configured by association of the DO-ID to the corresponding
Slotnumber.
IO Device
Interface
Slotnumber
Slot 0 Slot 1 Slot 2 Slot 3 Slot 4 Slot 5 ...

PZD PZD PZD
MAP
PAP
PAP
PAP
PAP
PNU 978
DO DO DO DO
DO-ID DO-ID DO-ID DO-ID

= 10 = 11 = 51 = 55
DO-ID
Drive Unit
at PROFINET IO
7.5.2 Getting the Drive Object ID (DO-ID)
The assignment of Slotnumbers to DO-IDs may be posted by the optional global parameter
P978 List of all DO-ID according to Figure 104 and Figure 105. If the Drive Unit does not
possess the parameter P978, the DO-ID is equal to the Slotnumber (the DO-ID is necessary
for the Base Mode Parameter Access).

Content Start
Version 4.0
Rules for P978 List of all DO-ID:
The subindex = Slotnumber 1

If there is a Slot with a PROFIdrive Module plugged in, but no DO associated (Slot 3 in
Figure 104), the DO-ID value in P978 is 255.
If there is an empty Slot (no PROFIdrive Module plugged in), the DO-ID value in P978
shall be 255 or a valid DO-ID (this indicates no DO or a DO which exists but is not
connected to a PROFIdrive Module).
If all configured Slots (all DO-IDs) are listed, the list in P978 is terminated by two list
elements with DO-ID value = 0.
P978 List of all Module IDs

Subindex = Subindex DO-ID
Slotnumber-1
0 10
1 11
2 255
PROFINET IO PROFIdrive
Slotnumber DO-ID
3 51
4 55
5 0
6 0
Figure 105 Meaning of parameter P978 "list of all DO-IDs" for the DU at PROFINET IO
7.6 Alarm Mechanism
7.6.1 Use of the Diagnosis Objects
Within the PROFIdrive Drive Unit the PROFIdrive diagnosis objects defined in chapter 4.8.4
should be mapped to a PROFINET IO diagnosis object. These diagnosis objects shall be
represented by the Channel Diagnosis diagnosis type [9].
7.6.2 Use of the Alarm Mechanism
For the Alarm Mechanism the PROFINET IO Alarm ASE [9] shall be used. Within this Alarm
Mechanism the diagnosis objects according to the Definition in chapter 7.6.1 are transmitted
by the Channel Diagnosis mechanism. If the controller doesnt support the alarm the
acknowledge will be not supported. The DO is not committed to react on this negative

Content Start
Version 4.0
acknowledge and may ignore it (dont care). The definition of the AlarmNotification-PDU for
the PROFINET IO Alarm Mechanism is according to Table 80.
Table 80 Use of the AlarmNotification-PDU
Attribute Meaning
BlockHeader see [10]
AlarmType Diagnosis Appears if diagnosis object attribute changes to new

state WARNING_PRESENT or FAULT_PRESENT.
Diagnosis Disappears if diagnosis object attribute changes from
old state WARNING_PRESENT or FAULT_PRESENT.
API 0x3A00 (PROFIdrive profile)
SlotNumber Slotnumber of the DO (Module), the diagnosis object is related to
SubslotNumber Subslotnumber of the MAP/PAP of the DO (Module), the
diagnosis object is related to
ModuleIdentNumber ModuleIdentNumber of the DO (Module), the diagnosis object is
related to
SubmoduleIdentNumber 65536 (SubmoduleIdentNumber of the MAP)
AlarmSpecifier See [10] (Alarm type Diagnosis)
UserStructureIdentifier 0x8000 (ChannelDiagnosisData)
Mult. ChannelDiagnosisData List of structure ChannelDiagnosisData (see Table 81)
7.6.3 Use of the ChannelDiagnosisData Structure
The Definition of the ChannelDiagnosisData structure is according to Table 81.
Table 81 Use of ChannelDiagnosisData
Attribute Meaning
ChannelNumber 0x8000 (whole submodule)
ChannelProperties.Type 0
ChannelProperties.Reserved 0
0 = no maintenance required
ChannelProperties.MaintenanceRequired
1 = maintenance required
ChannelProperties.MaintenanceDemanded 0 = no warning; 1 = warning present
ChannelProperties.Specifier 0 = no error; 1 = error present
ChannelProperties.Direction 0
ChannelErrorType see Table 82
7.6.4 Use of the ChannelErrorType
The Definition of the ChannelErrorType is according to Table 82.
Table 82 Use of ChannelErrorType
ChannelErrorType Meaning / Diagnosis Object
0x9000 Microcontroller Hardware or Software
0x9001 Mains Supply

Content Start
Version 4.0
ChannelErrorType Meaning / Diagnosis Object
0x9002 Low Voltage Supply

0x9003 DC Link Overvoltage
0x9004 Power Electronics
0x9005 Overtemperature Electronic Device
0x9006 Earth/Ground Fault
0x9007 Motor Overload
0x9008 Fieldbus System
0x9009 Safety Channel
0x900A Feedback
0x900B Internal Communication
0x900C Infeed
0x900D Brake Resistor
0x900E Line Filter
0x9010 External
0x9011 Technology
0x9012 Engineering
0x9013 Other
0x9014 0x908F reserved
7.6.5 On demand access of Diagnosis Information
Readout of the actual diagnosis information out of the DO by the controller shall be possible
by using the standard PROFINET IO Diagnosis ASE. Within this diagnosis mechanism the
diagnosis objects according to the Definition in chapter 7.6.1 are transmitted by the Channel
Diagnosis mechanism. The definition of the DiagnosisData for the PROFINET IO Diagnosis
mechanism is according to Table 83.
Table 83 Use of the DiagnosisData
Attribute Meaning
BlockHeader see [10]

API 0x3A00 (PROFIdrive profile) depending on BlockVersionLow
SlotNumber Slotnumber of the DO (Module), the diagnosis object is related to
SubslotNumber Subslotnumber of the MAP/PAP of the DO (Module), the
diagnosis object is related to
ChannelNumber 0x8000 (whole submodule)

ChannelProperties Type=0; Direction= 0
UserStructureIdentifier 0x8000 (ChannelDiagnosisData)
Mult. ChannelDiagnosisData List of structure ChannelDiagnosisData (see Table 81)

Content Start
Version 4.0
7.7 Clock Synchronous Operation
7.7.1 Sequence of an isochronous Data Cycle
Figure 106 shows the sequence of an isochronous PROFINET IO with IRT Data Cycle.
Applicationcycle T CAPC =1 x T DC
T ApplEnd Controller
T ApplStart
application background
Bus
T input_valid = 0 T output_valid
T I_min T O_min
TI TO DO
Phase 2 Phase 3 Phase 4 Phase 1 Phase 2 Phase 3 Phase 4 Phase 1 Phase 2
T DC DataCycle T DC T DC
Figure 106 Sequence of isochronous Data Cycle
T DC (Data cycle time)

Data Cycle time for periodicity of the IRT communication.
T CAPC (Controller application cycle time)

Cycle time for the periodicity of the Controller application process.
T I (Time for actual value acquisition)

Time, related to the beginning of a T DC cycle, for the acquisition of the actual values.
T I_min (Lack time for the acquisition process)

Time needed for acquisition and processing of the input values before ready to be send by the
T input_valid (Time for Input Data available)

Time, when the new Input Data (actual values) are ready to be send to the controller.

Content Start
Version 4.0
T O (Time for setpoint transfer)

Time, related to the end of a T DC cycle, when the new setpoint values get valid to the axis
application process.
T O_min (Lack time for the setpoint transfer process)

Time needed for the processing of the new setpoint values before they are able to get valid to
the application process.
T output_valid (Time for Output Data available)

Time where the new Output Data (setpoint values) from the controller are available at the DO.
7.8 PROFINET IO specific Parameter
7.8.1 Overview of the communication interface related Parameters
These parameters are related to the Network Communication Interface of the Drive Unit or
Station.
Table 84 Overview of the specific PROFINET IO parameters for Communication

system interfaces
61000 NameOfStation (read only) mandatory if global

PROFINET IO
Network
Interface is
present
61001 IPOfStation (read only) mandatory if global
PROFINET IO
Network
Interface is
present
61002 MacOfStation (read only) mandatory if global
PROFINET IO
Network
Interface is
present

Content Start
Version 4.0
7.8.2 Definition of the specific parameters

PNU: 61000
Significance: NameOfStation
Data type: VisibleString 241
Implementation: Mandatory if PROFINET Network Interface is present
Explanation: This parameter contains the Name of Station for the PROFINET IO
Network Interface, which is related to this Drive Unit. This is an
additional service parallel to the standard PROFINET IO
mechanism, which makes the Name of Station also accessible via
PROFIdrive Parameter Access.
Reference: ---
PNU: 61001
Significance: IPOfStation
Explanation: This parameter contains the IP Address of the Station for the
PROFINET IO Network Interface, which is related to this Drive Unit.
This is an additional service parallel to the standard PROFINET IO
mechanism, which makes the IP Address of Station also accessible
via PROFIdrive Parameter Access.
Reference: ---
PNU: 61002
Significance: MacOfStation
Explanation: This parameter contains the MAC Address of the Station for the
PROFINET IO Network Interface, which is related to this Drive Unit.
This is an additional service parallel to the standard PROFINET IO
mechanism, which makes the MAC Address of Station also
accessible via PROFIdrive Parameter Access.
Reference: ---

Content Start
Version 4.0
7.9 Specified communication functions for the Application Classes
According to the definition of the Application Classes in 2.4, Table 85 specifies the
communication functionality the drive shall comprise to match a specific Application Class for
PROFIdrive at PROFINET IO.

interface
synchronism
Table 85 Specified communication functions for the Application Classes
Application Classes
Functionality
1 2 3 4 5 6
RT m m m o m
IRT m m
M CR (Broadcast) m m

Information regarding Table 85:

Content Start
Version 4.0
8 Integration of drives in process technology (VIK 1) -NAMUR 2) )
8.1 General
This chapter shows the integration of drives in process technology according to the VIK-
NAMUR guideline [7]. The drive applications are realized only in open-loop (e.g. v/f control) or
closed-loop speed control mode, therefore they belong to the PROFIdrive Application Class 1
(see Figure 107).
Application Class 1
N-Setpoint value interface
Drive
Nsoll closed
Process ramp
loop
control function
speed
M E
system generator
control
Nist
Application Class 1
F-Setpoint value interface
Drive
Fsoll
Process ramp
v/f
control function
control
M
system generator
Fist
Figure 107 Functionality and Interfaces for drive integration according to VIK-NAMUR
Purpose of the VIK-NAMUR guideline for the integration of drives in the process technology
industry is to specify a standard interface between drive and the process control system which
offers the possibility to exchange the drive or drive system by another drive (even another
vendor) without need of any change to the process control system. Therefore a special
application-specific GSD is used and the drive shall be set up to act as a VIK-NAMUR drive
with application-specific Ident_Number = 0x3AA0. The VIK-NAMUR guideline specifies the
drive interface in hardware (VIK-NAMUR terminal block) and Software (PROFIdrive Interface
VIK-NAMUR mode). The principle structure of the interface is shown in Figure 108.
1) VIK = Association of the Industrial Customers and Industrial Power Producers
2) NAMUR = Standards Working Group for Instrumentation and Control in the Chemical Industry

Content Start
Version 4.0
Drive ( in cabinet)
PROFIdrive
Profile
VIK-NAMUR
Profibus VIK-NAMUR Terminal Block

Process
control
M E
system
hardware
stop
inevitable line
line interrupt
Specified by
VIK-NAMUR Guideline
Figure 108 Principle structure of the drive interface according to VIK-NAMUR

guideline
8.2 Commands and Checkback signals
The device-specific bits of the control word1 (STW1), status word1 (ZSW1) and drive
status/fault word (MELD_NAMUR) in the PROFIdrive Profile Drive Technology are fix defined
for the VIK-NAMUR process technology operating mode.
8.2.1 Control word1
Table 86 Overview on the assignment of the bits of control word1 for the process
technology operating mode
Process technology operating mode (VIK-NAMUR standard)
0 ON OFF
1 No Coast Stop (No OFF2) Coast Stop (OFF2)
2 No Quick Stop (No OFF3) Quick Stop (OFF3)
3 Enable Operation Disable Operation
4 Enable Ramp Generator Reset Ramp Generator
5 Unfreeze Ramp Generator Freeze Ramp Generator
6 Enable Setpoint Disable Setpoint
7 Fault Acknowledge (0 1)
8 a a
Jog 1 ON Jog 1 OFF
9 a a
Jog 2 ON Jog 2 OFF
10 Control By PLC No Control By PLC

b
11 Setpoint Inversion No Setpoint Inversion

Content Start
Version 4.0
12 b b
Reserved Reserved
13 b b
Reserved Reserved
14 b b
Reserved Reserved
b b
15 Parameter Set 2 Parameter Set 1
NOTE 1 It shall be possible to parameterize the converter / inverter with manufacturer-specific parameters in
order to disable a certain direction of rotation.
NOTE 2 Bit 0 to Bit 10 of the control word 1 are the same as in the control word 1 of the speed control
operating mode.
NOTE 3 Further details to the control word bits may be found in 4.2.1.
a
optional
b
deviations of the VIK-NAMUR Control Word 1 (STW1) from the standard PROFIdrive STW1.
8.2.2 Status word1
Table 87 Overview on the assignment of the bits of status word1 for the process
technology operating mode

0 Ready To Switch On Not Ready To Switch On

1 Ready To Operate Not Ready To Operate
2 Operation Enabled (drive follows setpoint) Operation Disabled
3 Fault Present No Fault
4 No OFF2 OFF2
Coast Stop Not Activated or Coast Stop Activated or
Inevitable Line Interruption Not Activated Inevitable Line Interruption Activated
5 No OFF3 OFF3
Quick Stop Not Activated or Quick Stop Activated or
External Interlock Not Activated External Interlock Activated
6 Switching On Inhibited Switching On Not Inhibited
7 Warning Present No Warning
8 Speed Error Within Tolerance Range Speed Error Out Of Tolerance Range
9 Control Requested No Control Requested
10 f Or n Reached Or Exceeded f Or n Not Reached
a
11 Adjustable Current Limit Or Torque Limit Not Adjustable Current Limit Or Torque Limit Reached
a
Reached
a a
12 Reserved Reserved
a a
13 Motor Overload Not Activated Motor Overload Activated
a a
14 Positive Speed Direction No Positive Speed Direction
a a
15 Parameter Set 2 active Parameter Set 1 active
NOTE 1 Bit 0 to Bit 3 and Bit 6 to Bit 10 of the status word 1 are the same as in the status word 1 of the
speed control operating mode.
NOTE 2 Further details to the status word bits may be found in 4.2.3.
a
deviations of the VIK-NAMUR Status Word 1 (ZSW1) from the standard PROFIdrive ZSW1

Content Start
Version 4.0
8.2.3 Drive status/fault word
Table 88 Overview on the assignment of the bits of drive status/fault word for the
process technology operating mode
0 Fault Control Electronic/Software No Fault Control Electronic/Software

1 Fault Supply Net No Fault Supply Net
2 DC Link Overvoltage No DC Link Overvoltage
3 Fault Power Section No Fault Power Section
4 Overtemperature Converter No Overtemperature Converter
5 Earth Fault No Earth Fault
6 Overload Motor No Overload Motor
7 Error Communication Bus No Error Communication Bus
8 External Safety Trip No External Safety Trip
9 Fault Speed Sensor No Fault Speed Sensor
10 Fault Internal Communication No Fault Internal Communication
11 Fault Infeed System (DC Link) No Fault Infeed System (DC Link)
15 Miscellaneous Faults No Miscellaneous Faults

Content Start
Version 4.0
8.3 State diagrams
8.3.1 General state diagram
The general state diagram (refer to 4.12.1) is also valid for applications in the process
technology operating mode.
8.3.2 Setpoint channel for VIK-NAMUR operating mode
STW1 bit 11
True = setpoint inversion
False = no setpoint inversion
STW1 bit 4
True = enable RFG
False = reset RFG Change of mode between
STW1 bit 5 mode or vice versa
True = unfreeze RFG only when drive is
False = freeze RFG
in stand still
STW1 bit 6
False = disable setpoint 1= operate
0= freeze
reset RFG
&
0 0 0
0 0
0
setpoint 1 1
-1 1 RFG
(velocity) 1
to v/f control or
closed loop
speed controller
STW1 bit 8 (velocity)
True = Jog 1 ON
False = Jog 1 OFF
C1
Y
STW1 bit 9 C2
True = Jog 2 ON RFG
0 = reset RFG
J1 J2
False = Jog 2 OFF (output=0)
1 = operate RFG
Jogging Jogging
C1 C2 Y
0 0 0
1 0 J1
0 1 J2
1 1 no change
Figure 109 Speed setpoint channel for VIK-NAMUR process technology operating
mode
In addition to the standard PROFIdrive setpoint channel (see 4.12.2), the setpoint inversion
functionality controlled by STW1 bit 11 is defined for VIK-NAMUR according to Figure 109.
Also additional monitoring functionality according to Figure 110 is specified.

Content Start
Version 4.0
VIK-NAMUR process technology operating mode

ZSW1 bit 10
true = f Or n
COMP Reached Or
STW1 bit 15 Comparison
true = Parameter Set2 Value a Exceeded
false = Parameter Set1 false = f Or n Not
Actual value b Reached
Parameter 0 ZSW1 bit 11
Set 1 true = Adjustable
Current Limit
Parameter 1
Set 2 Or Torque
Limit Not
Reached
STW1 Parameter Set false = Adjustable
Drive & Motor
bit15
monitoring
Current Limit
0 1 Or Torque
1 2 Limit Reached
ZSW1 bit 13
true = Motor Overload
Not Activated
false = Motor Overload
Activated
ZSW1 bit 14
Y true = Positive
1
Speed
Speed
X Y Direction
0 false = No Positive
X
Speed
Direction
Figure 110 Process technology operating mode, control word 1 bit 15

and status word 1 bit 10,11,13,14
STW1 bit15: Parameter Set
Parameter set1 may be switched over to parameter set2 and vice versa.
8.4 Inevitable line interruption and external interlock
This chapter describes the inevitable line interruption and the external interlock. The
inevitable line interruption is connected to the NAMUR standard terminal block (Input 17 / 18).
With contact open between terminal 17 and 18, an inevitable line interrupt shall be performed
in that way, that the inverter and the motor shall be secure separated from the line. Also the
inevitable line interrupt may be activated by an over temperature signal on the terminals 90 /
91 (see Figure 111). The signal for the inevitable line interrupt is also connected to a digital
input of the drive. The input of the drive shall be parameterized in that way, that it causes a
Coast Stop on the drive. Also one digital output of the drive shall be parameterized with the
status Coast Stop Activated / Inevitable Line Interruption Activated and this output shall also
force the switch device to separate the drive secure from the line.
The application program in the PLC (Programmable Logic Controller) recognizes an inevitable
line interruption, if in the control word1 (STW1) sent by the PLC the bit1 is TRUE that means
No Coast Stop and in the status word1 (ZSW1) the bit4 is FALSE that means Coast Stop
Activated / Inevitable Line Interruption Activated. The inevitable line interruption has to be
realized with applicable switch devices according to the VIK-NAMUR Guidelines.

Content Start
Version 4.0
VIK-NAMUR-Interface
STW 1
Profibus / PROFIdrive Bit 1
>
Bit 2 = Control
Profibus
Bit 5 Infeed
All other terminals X2 N24 X2 +

Bit 4
are without 1 >
function!
P24
2
ZSW 1 =
External Interlock
(Contact open P24 15
Output
-> interruption) Quick Stop Line
17
Inevitable Off >1
Inevitable line interruption
18 interrupt =
(Contact open -> interruption)
Off Inevitable line
X3
interruption path
90 Temperature separates
91 monitor inverter from line
PTC
M
X1
Area Line
Inverter-(Cabinet-)Side
Figure 111 Process technology operating mode, inevitable line interruption and
external interlock
The external interlock is connected to the NAMUR standard terminal block (Input 15). The
signal from this terminal is connected to a digital input of the drive. This digital input shall be
parameterized with the function Quick Stop. In case of external interlock the drive gets the
information for a quick stop via the digital input. The converter / inverter stops the motor along
the programmable current limit and then the output pulses are disabled and the inverter is
separated from the line.
The application program in the PLC (Programmable Logic Controller) recognizes an external
interlock, if in the control word1 (STW1) sent by the PLC the bit2 is TRUE that means No
Quick Stop and in the status word1 (ZSW1) the bit5 is FALSE that means Quick Stop
Activated / External Interlock Activated.

Content Start
Version 4.0
8.5 Standard telegram
Standard telegram 20 is defined for the process technology.
Further information to standard telegrams, signal numbers (see Table 26) and telegram
selection may be found in 4.4. Information to standard telegram configuration for PROFIBUS
DP may be found in 6.3.2.
Standard telegram-20: n set interface for the process technology, 16 bit
PZD number 1 2
Setpoint STW1 NSOLL_A 1) /
FSOLL 1)
PZD 1 2 3 4 5 6
number
Actual ZSW1 NIST_A_GLATT 1) / IAIST_GLATT ITIST_GLATT 2) PIST_GLATT 3) MELD_NAMUR
value
FIST_GLATT 1) or
MIST_GLATT 2)
The signal numbers defined for the process technology are included in Table 26.
Process Data Normalization:
The data type for process data in setpoint-direction and actual value-direction is Integer16 (a
signed 16 bit-value), except control word1 (STW1) and status word1 (ZSW1).
The scaling factor for all process data is defined as follows: 100% corresponds to 4000 hex .
The value for this data ranges from 200% to + 200%. The PZD normalization shall be
configured in the following way: normalization bit 0-5 shall be set to 14 (bit 14 -> 0x4000 hex )
and normalization valid bit 15 shall be set to 1 (YES) (refer to 3.1.2 and 4.4.4).
The process data in actual value-direction shall be filtered with a first order filter element and
a constant filter time of approximately 100 milliseconds, except control word1 (STW1) and
status word1 (ZSW1). This is achieved by use of the special signals xxx_GLATT.
There has to be a manufacturer-specific parameter, where it is defined which physical value

represented by 100%. The manufacturer-specific parameter shall not be a fixed value in the
converter / inverter.
1) The setpoint NSOLL_A and the actual value NIST_A in process data 2 are only for applications in the closed-
loop speed control mode and the setpoint FSOLL and the actual value FIST in process data 2 are only for
applications in v/f control mode.
2) The actual value in process data 4 has to be configured with the process variable active current (ITIST) or
torque actual value (MIST). If both process variables are not available, the process data 4 shall be zero.
3) The actual value in process data 5 has to be configured with the process variable active power (PIST). If the
process variable is not available, the process data 5 shall be zero.

Content Start
Version 4.0
Annex A
(informative)
Bibliography (Normative references)
[1] Technical Guideline: PROFIBUS-DP Extension to EN 50170 (DPV1); Version 2.0; April
1998
[2] IEC 61158 Digital data communication for measurement and control Fieldbus for use
in industrial control systems, 3. Edition
[3] not used
[4] PROFIBUS Guideline; Specification for PROFIBUS Device Description and Device
Integration, Volume 1, GSD V 5.0; Draft, Order No. 2.122
[5] PROFIBUS Profile for variable-speed drives, PROFIdrive, Version 2, Edition September
1997, Order No. 3.071
[6] not used
[7] NAMUR-Guideline: Ausfhrung von Frequenzumrichtern Standard Klemmleiste fr
drehzahlvernderliche Antriebe; NE 37 ; April 1996
[8] PROFIBUS Profile Guideline; Part 1; Identification & Maintenance Functions; Version
1.1; May 2003; Order No. 3.502
[9] PROFINET IO Application Layer Service Definition & Protocol Specification,
Version 2.0, PNO, Order No. 2.332
[10] Application Guide, planned

Content Start
Version 4.0
Annex B
(informative)
Definitions and abbreviations
B.1 Abbreviated terms
B.1.1 General
AK PROFIdrive Application Class
AP Application Process
API Application Process Identifier
AR Application Relationship
ASE Application Service Element
BERO Proximity Switch
C-LS Controllers Sign-Of-Life
CM Context Management
CO Communication Object
CR Communication Relationship
DAP Device Access Point
DO Drive Object
DO-LS Drive Object Sign-Of-Life
DP Decentralized (distributed) Periphery
DPM1 DP-Master Class1 (central automation device)
DPM2 DP-Master Class2 (programming, configuring device, or operator interface)
DPV1 DP Version 1
(optional addition to PROFIBUS-DP, expanded communication functionality)
DSC Dynamic Servo Control
DU Drive Unit
DX Data_Exchange
DXB Data-eXchange-Broadcast
EN European Standard
f frequency
FDL Fieldbus Data Link (Layer 2)
GAP Area between own station address and the next one (attempt to include new
active stations)
GC Global_Control
GSD Device Data File (device description, input for a bus configuring tool)
HMI Human Machine Interface
HW Hardware
IEC International Electro-technical Commission
I/O Input/Output
IOAR IO Application Relationship

Content Start
Version 4.0
IOCS IO Consumer Status

IOPS IO Producer Status
ID Identifier
IP Internet Protocol
IR Information Report
IRT Isochronous Realtime Ethernet
IsoM Isochronous Mode
LSB Least Significant Bit
LS Sign-Of-Life
MAP Module Access Point
M CR Multicast CR
MSB Most Significant Bit
MSG Acyclic services (Message)
NAMUR Standards Working Group for Instrumentation and Control in the Chemical
Industry
NC Numerical control system with a numeric control command set
NDEF not defined
OP Operator Panel
PAP Parameter Access Point
PBE Parameter description
PC Personal Computer
PDU Protocol Data Unit
PG Programming device
PKW Parameter ID/Parameter Value
PLC Programmable Logic Controller without a Motion Control command set
PLL Phase Locked Loop (phase control loop)
PNO PROFIBUS User Organization
PNU Parameter Number
PPO Parameter process data object
Prm Parameter
PROFIBUS Process Field Bus
PWE Parameter value
PZD Process Data; is transmitted cyclically
RES Reserve
RFG Ramp Function Generator
SAP Service Access Point
SN Sign
STW Control Word
SW Software
SYN Synchronization

Content Start
Version 4.0
UUID Universal Unique Identifier

TOK Token passing
URL Universal Resource Locator
VDI Association of German Engineers
VIK Association of the Industrial Customers and Industrial Power Producers
ZSW Status Word
B.1.2 Timing Parameters

T BASE_DP Time base of T DP
T BASE_IO Time base of T I , T O
t BIT Bit-Time
T CAPC Application-Cycle-Time
T DC Data-Cycle-Time
T DP DP-Cycle-Time
T DP_MIN Minimum of T DP
T DX Data_Exchange-Time
TJ Jitter-Time
TI Input-Time
T I_MIN Minimum of T I
T ID1 Idle-Time 1
T ID2 Idle-Time 2
T input_valid Lack time for the acquisition process
TM Master-Time
T MAPC Master_Application_Cycle-Time
T MLS Master_Life_Sign-Time
TO Output-Time
T O_MIN Minimum of (T O -T DX )
T output_valid Lack time for the setpoint transfer process
T PC Position Controller Sampling Time
T PLL_D PLL-Delay
T PLL_W PLL-Window
T SAPC Slave_Application_Cycle-Time
T SC Speed Controller Sampling Time
T SDR Station_Delay_Responder- Time
T SET Setup-Time
T SLS Slave_Life_Sign-Time
T SYN Synchronization-Time
T SM Safety-Margin
T TH Token_Hold-Time
T TR Target_Rotation-Time

Content Start
Version 4.0
TWD Watchdog-Time

Content Start
Version 4.0
Index
Actual baud rate ..................................228, 229 being established .............................195
Actual value acquisition .................17, 207, 251 Consumer Status ........................................ 244
Actual values Control
PNU 907 ..........................................156 by PLC .............................................143
Process data (PZD) ............................91 priority..............................................142
Acyclic communication ..................18, 155, 156 requested .........................................143
Acyclic Data Exchange......................25, 29, 71 Control and Status words ........... 73, 74, 76, 79
PROFIBUS DP .................................175 Control word 1........................... 74, 75, 76, 256
DPV1 mechanisms ........................175 Control word 2............................................... 76
PROFINET IO...................................234 Controller application cycle time ................. 251
Acyclic services .............................................18 Controller clock cycles
Duration ...........................................206 Different values ................................206
MSG.................................................205 Controller's Sign-Of-Life.............................. 143
Alarm Mechanism..........................................25 Conversion index .......................................... 42
PROFIBUS DP .................................176 Counting strategy
PROFINET IO...................................234 Sign-Of-Life failure counter ...............146
API ...............................................................233 Cyclic Data Exchange................................... 25
Application Classes .......................................33 PROFIBUS DP .................................175
Specified functions ........... 148, 230, 254 PROFINET IO...................................234
Application Model ..........................................33 Data block length ........................................ 198
Application Service Elements ......................234 Data cycle time ........................................... 251
ASE..............................................................234 Data types
Axis addressing .......................................54, 57 Overview ........................................... 46
Axis DO..........................................................31 Profile specific data types .................. 47
Base Mode Parameter access ......................52 Data_Exchange (DX) .................................. 205
PROFIBUS DP ......................... 193, 194 Data_Exchange-Time ................................. 205
PROFINET IO...................................245 Data-eXchange Broadcast (DXB)............... 183
Base Mode Parameter Access Diagnostics ......................................190
General characteristics .......................52 GSD entries......................................191
Base Model....................................................20 Monitoring ........................................190
Communication Devices......................20 Publisher ..........................................184
Communication Network .....................21 Subscriber ........................................184
Communication Relationship ...............20 Subscriber table ...............................189
Communication Services.....................25 Timing ..............................................190
Functional Object ...............................22 Deadtime..................................................... 101
Layer Model .......................................24 Definitions ..................................................... 19
Object Model ......................................23 Clock cycle synchronization ............... 19
Checkback signals.......................................256 Clock cycle synchronous application .. 19
Chk_Cfg.......................................................202 Drive-to-Drive communication ............ 19
Clock Equidistance...................................... 19
Failure..............................................227 Input data .......................................... 19
Jitter ................................................223 Isochronous mode ............................. 19
Clock cycle Output data ....................................... 19
Generation .......................................222 Process data (PZD) ........................... 19
Save ................................................222 Technological functions ..................... 19
Synchronism.......................................17 Delay................................................... 208, 209
Clock Synchronous Operation.......................26 Device
PROFIBUS DP .................................176 General architecture .......................... 22
PROFINET IO...................................235 Identification.....................................137
Coding Diagnosis .................................................... 128
Base Mode Parameter Access ............57 DO's Sign-Of-Life........................................ 145
Data types ..........................................46 DP cycle
Commands ............................................73, 256 Content ............................................205
Complete description (subindex 0)................44 Optimized cycle (T MAPC = 2 * T DP .......210
Configuring a telegram Optimized DP cycle ..........................209
Example .............................................97 Simplest DP cycle.............................208
Configuring the process data ........................95 Time setting .....................................206
Connection Violation ...........................................227
being disconnected...........................195 DP IDs......................................................... 181
Content Start
Version 4.0
DP-Cycle-Time ....................................205, 206 Fault buffer....................................129

DPM1...........................................................172 Mapping internal fault number........133
DPM2...........................................................172 Parameters ...................................133
DPV1 telegram frame ..................................196 FREEZE...................................................... 222
DPV1 telegram sequences..........................194 Functionality
Drive Application Classes .......... 148, 230, 254
Architecture ........................................29 GAP ............................................................ 205
Drive Object .......................................29 GC............................................................... 205
Axis type .........................................31 Get_Config.................................................. 202
ID.......................................... 202, 247 Global_Control (GC) ................................... 205
Identification..................................138 Global_Control telegram............................. 222
Parameter P978 ............................202 Group .................................................. 222, 223
Structure .........................................29 GSD parameter
I&M Functionality ..............................139 DPV1 ...............................................200
Model .................................................29 Slave-to-slave communication...........191
Profile Homing procedure ........................................ 89
Identification..................................137 I/O peripherals ............................................ 127
Drive reset ...................................................140 ID extension (subindex 10) ........................... 43
Direct initiation .................................140 Identification................................................ 137
Preparation ......................................141 Device ..............................................137
Drive status/fault word .................................258 Drive Object .....................................138
Drive Unit .......................................................32 I&M Parameter .................................139
Architecture ......................................240 Profile Version ..................................137
Classification ......................................32 Identifier (ID) (subindex 1) ............................ 41
Configuration ............................ 200, 247 Include new active stations (GAP).............. 205
Modular ..............................................32 Input data ...................................................... 19
Multi-Axis ...........................................32 Interface
Single-Axis .........................................32 according to VIK-NAMUR..................256
Drive-to-Drive communication .......................17 DSC .................................................104
DSC .............................................................101 Position feedback .............................106
Additional features............................103 related parameters ................... 228, 252
Features...........................................101 Sensor .............................................150
Implementation information ...............105 UUID ................................................233
Mode of operation.............................102 IO AR .......................................................... 237
Operating states ...............................104 IOCS ........................................................... 244
Structure ..........................................101 IOPS ........................................................... 244
Using multiple sensors......................103 IP-address................................................... 233
DX................................................................205 Jitter ............................................................ 223
Dynamic Servo Control................................101 Jitter time .................................................... 205
Error numbers................................................58 Jogging
Error value ...................................................197 Positioning mode ............................... 88
Error_Class..................................................197 speed control mode ........................... 86
Error_Code ..................................................197 Lack time for the acquisition process.......... 251
Failure strategy Lack time for the setpoint transfer process. 252
Clock pulse failure ............................227 Limit
Master..............................................226 High .................................................. 43
Slave................................................226 Low ................................................... 43
User data failure ...............................227 Low/high limit (subindices 7 and 8)............... 43
Fault M CR........................................................... 237
Messages .........................................129 MAP ............................................................ 241
Parameters.......................................133 Master control ............................................. 207
Situation...........................................129 Master optimization..................................... 209
Situation history................................130 Master_Application_Cycle_Time ................ 207
Tracking ...........................................129 Measurement on the fly .............................. 125
Tracking system ...............................129 Module Access Point .................................. 241
Fault classes mechnism ..............................135 Monitoring
Faults ...........................................................128 Controller's Sign-Of-Life ...................144
Fault buffer mechanism ....................129 DOs Sign-Of-Life .............................145
Acknowledgment ...........................132 Monitoring mechanisms.............................. 226
Automatic evaluation .....................132 MSG ............................................................ 205
Erasing the fault buffer ..................132 Multi-axis Drive Units .................................... 51

Content Start
Version 4.0
Name (subindex 6) ........................................43 Process Data (PZD)...................................... 91

Name of Station...........................................233 Signals .............................................. 91
New functions ................................................18 Process data normalization .......................... 98
Number of array elements (subindex 2) ........41 Example ............................................ 99
Object UUID ................................................233 Non-normalize ................................... 98
Operating mode Normalize .......................................... 98
Process technology ..........................255 Process technology..................................... 255
Operating Modes ...........................................79 Producer Status .......................................... 244
Operation priority of parameters..................142 PROFIBUS DP Communication Layer
Output data....................................................19 Acyclic Data Exchange .....................175
P978 Alarm Mechanism .............................176
List of all DO-IDs ..............................248 Clock cycle synchronism ...................205
Rules for ..........................................248 Clock Synchronous Operation ...........176
PAP..............................................................241 Cyclic Data Exchange .......................175
Parameter Telegram sequences ........................194
Definition............................................40 Profile parameters............................... 150, 155
Description .........................................40 listed by function ..............................150
Complete description (subindex 0) ...44 listed by number ...............................155
ID extension (subindex 10) ..............43 PROFINET IO Communication Layer
Identifier (ID) (subindex 1) ...............41 Acyclic Data Exchange .....................234
Low/high limit (subindices 7 and 8) ..43 Alarm Mechanism .............................234
Name (subindex 6) ..........................43 Clock cycle synchronism ...................251
No. of array elements (subindex 2) ..41 Clock Synchronous Operation ...........235
PZD normalization (subindex 12) .....44 Cyclic Data Exchange .......................234
PZD ref. parameter (subindex 11) ....44 PAP .................................................244
Standardization factor (subindex 3) ..41 Parameter Access Point....................244
String length (subindex 2) ................41 Submodule IDs .................................243
Variable attribute (subindex 4) .........42 PROFINET IO Communication LayerSubslot
Model .................................................40 ................................................................. 239
Value .................................................40 Publisher ..................................................... 184
Parameter Access PZD
DPV1 parameter channel ..................194 Normalization .................................... 99
PAP .................................................193 Normalization (subindex 12)............... 44
Parameter Access Modes ...........................245 Reference parameter ......................... 99
Parameter Access Point ..............................241 Reference parameter (subindex 11) ... 44
Parameter request global ..............................52 Reference mark search .............................. 126
Parameter request local ................................52 Reserve (RES)............................................ 206
Parameter requests .......................................53 Running-up ................................................. 211
Parameter responses ....................................53 Slave configuration ...........................213
PLL ..............................................................224 Slave parameterization .....................213
Position feedback control word ...................114 Synchronization
Position feedback interface .........................106 Master application to the slaves Sign-
Actual positions ................................106 Of-Life .......................................217
Assignm. in the actual value telegr. ...113 PLL to the clock cycle ....................213
Device-specific expansions ...............124 Slave application to the master's Sign-
Error codes ......................................113 Of-Life .......................................215
Parameter P979 structure .................107 Scalability
Sensor format...................................107 DPV1 functionality ............................199
State diagram ...................................117 Model of the clock cycle synchronization
States ..............................................118 .....................................................208
Transitions .......................................120 Setpoint transfer.......................................... 207
Position feedback status word.....................115 Setpoints
Positioning mode Process data (PZD) ........................... 91
Functionality .......................................87 Signals
State diagram .....................................88 Process Data (PZD)........................... 91
Power-On-Reset..........................................140 Sign-Of-Life................................................. 143
P972 ................................................140 Sign-Of-Life failure
Prm parameter Controllers Sign-Of-Life ...................144
Clock-Cycle Synchronism .................221 Counter ............................................146
Slave-to-slave communication...........191 DOs Sign-Of-Life .............................145
Process data (PZD) .......................................19 Slave optimization....................................... 209

Content Start
Version 4.0
Slave_Application_Cycle_Time...................207 Telegram sequences .................................... 60

Slave-to-slave communication ....................183 Text ............................................................... 45
Configuring (GSD) ............................191 Text array
Speed control mode ......................................82 Array parameter ................................ 45
for Application Class 1 ........................82 Boolean............................................. 45
for Application Class 4 ........................85 Unsigned8/16/32 ............................... 45
Standard DP monitoring ..............................226 V2 ..................................................... 45
Standard telegrams .......................................93 TI min ............................................................. 251
Standardization factor (subindex 3)...............41 TI.. ....................................................... 207, 251
State ..............................................................79 Time for input data available....................... 251
State diagram Time for output data available .................... 252
General ..............................................80 Time for setpoint transfer............................ 252
Position feedback interface ...............117 Time setting ................................................ 206
Positioning mode ................................88 Tinput valid ....................................................... 251
State machine................................................79 TJ................................................................. 205
General ..............................................80 TM ................................................................ 207
Positioning mode ................................88 TMAPC ........................................................... 207
Status word 1............................ 76, 77, 78, 257 TO ................................................................ 207
Status word 2.................................................79 TO min ............................................................ 252
String length (subindex 2)..............................41 TO.. .............................................................. 252
Subscriber ...................................................184 TOK............................................................. 206
Subscriber table...........................................189 Token Passing (TOK) ................................. 206
Supervisor AR .............................................237 Toutput valid ...................................................... 252
SYNC...........................................................222 Transmission
Synchronization .............................................19 Controller's Sign-Of-Life ...................143
Controller's Sign-Of-Life ...................143 DO's Sign-Of-Life .............................145
DO's Sign-Of-Life .............................145 Transmission times ..................................... 208
Synchronous communication ........................26 Traversing Task ............................................ 90
Synchronous operation TSAPC............................................................ 207
restrictions to bus topology ...............177 Types of synchronization ............................ 222
TCAPC ............................................................251 User data failure.......................................... 228
TDC.. .............................................................251 User data reliability ..................................... 143
TDP ...............................................................205 Valid Slotnumbers....................................... 240
TDX ...............................................................205 Variable attribute (subindex 4)...................... 42
Technological functions .................................19 Variable index ............................................... 42
Telegram configuration..................................95 Warnings..................................................... 128

PROFIdrive Profile V4 0

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PROFIdrive Profile V4 0

Uploaded by

Copyright:

Available Formats

Start

Profile Drive Technology

Order No: 3.172

Copyright PNO 2005 - All Rights Reserved Page 1 of 271

Document Identification: TC3-05-0005

Prepared by the PROFIBUS Working Group 6 PROFIdrive in the Technical Committee 3

may: indicates flexibility of choice with no implied preference.

should: indicates flexibility of choice with a strongly preferred implementation.

shall: indicates a mandatory requirement. Designers shall implement such

Copyright PNO 2005 - All Rights Reserved Page 2 of 271

Copyright PNO 2005 - All Rights Reserved Page 3 of 271

3.3 Global and Local Parameters ...............................................................................51

4.6.7.2 States...................................................................................... 118

Copyright PNO 2005 - All Rights Reserved Page 5 of 271

6.1.4.4 Clock Synchronous Operation .................................................. 176

6.8.2 Definition of the specific parameters ....................................................... 229

Copyright PNO 2005 - All Rights Reserved Page 7 of 271

8.2.1 Control word1 ........................................................................................ 256

Copyright PNO 2005 - All Rights Reserved Page 8 of 271

Copyright PNO 2005 - All Rights Reserved Page 9 of 271

Copyright PNO 2005 - All Rights Reserved Page 11 of 271

Copyright PNO 2005 - All Rights Reserved Page 12 of 271

Copyright PNO 2005 - All Rights Reserved Page 13 of 271

Table 36 Fault buffer parameters.................................................................................... 133

Copyright PNO 2005 - All Rights Reserved Page 14 of 271

Copyright PNO 2005 - All Rights Reserved Page 15 of 271

Identification Version Originator Date Change Note / History / Reason

Copyright PNO 2005 - All Rights Reserved Page 16 of 271

Today, variable-speed electric drives from basic AC drive converters up to high-dynamic

Drive-to-Drive communication: State-of-the-art automation solutions with digital Drive Units

1.1.2 Goals of the PROFIdrive Profile

1.1.3 New Functions of Version 4

1.1.4 Structure of the Document

Copyright PNO 2005 - All Rights Reserved Page 18 of 271

Figure 1 Basic structure of the document

Output data: Data, which a device cyclically receives from the

Drive-to-Drive communication: Drive-to-Drive communication refers to the

Clock synchronous Operation

Synchronization: Establish synchronism

Copyright PNO 2005 - All Rights Reserved Page 19 of 271

2 Integration of drives in automation systems

2.2 Base Model

2.2.1 Communication Devices

2.2.2 Communication Relationship

Device -Device Communication

Drive Unit - Drive Unit

Figure 2 PROFIdrive Devices and there relationship

Copyright PNO 2005 - All Rights Reserved Page 20 of 271

2.2.3 Communication Network

Network Interface Connector

Figure 3 General Communication Model of a PROFIdrive Automation System

Copyright PNO 2005 - All Rights Reserved Page 21 of 271

2.2.4 Functional Object

Functional Functional Functional

Copyright PNO 2005 - All Rights Reserved Page 22 of 271

2.2.5 Object Model

Aggregation - consists out of

Relationship - has a relation to

Figure 5 Hierarchical order in the Object Model

Copyright PNO 2005 - All Rights Reserved Page 23 of 271

2.2.6 Layer Model

Communication Cyclic Acyclic Clock

Figure 6 PROFIdrive Base Model contains the Application Layer and

Copyright PNO 2005 - All Rights Reserved Page 24 of 271