DP Comm Doku v10 e

Application for Communication
Direct Data Exchange between separate

DP Systems via DP-Communication
Direct Data Exchange between separate DP Systems via DP-Communication
Preamble
Requirement
Communication between separate stations or station parts on field bus
level is a key requirement in today’s industrial sector which every
manufacturer of automation systems must fulfill.
Possible solutions
Apart from the proprietary SIMATIC specific protocols S7 Standard
Communication and S7-Communication, the standardized DP
Communication can also be used for transferring average data volumes
(up to 240 bytes) via Profibus, the worldwide leading representative in the
field level.
Standardization of this protocol also enables to simply link the SIMATIC to
any foreign systems via the same route.
Copyright © Siemens AG 2005 All rights reserved
Example application
20987807_DP_Comm_DOKU_v10_e
A solution option is presented here as an example which links two stations

or station components via Profibus DP communication. This enables
exchanging data quickly between two separate DP systems.
Benefits for the user

The completely prepared and executable application software as well as
this documentation provide the following benefit:
• Acquiring background knowledge on the topics of Profibus, Configuring
the CP 342-5, user interface for the DP communication
• Using modules which can be used as base element in other applications
independently of the general application, e.g. failure analysis and
treatment
• Time saving at own development by means of simple expansion of the
sample application, for example, setting up further modular units on the
basis of the example application.
Rev A. Final 02.12.2003 2/83

Basic solution principle of this application

The application requires various hardware and software components.
Some of them are included in the delivery of the application, others are
provided by you.
Fig. 0-1
This documentation informs you about the individual components involved

and how they correlate with each other.
Notes on further communication examples

In this application the “DP communication“ task has been embedded in
practice relevant data amounts, control structures and user modules.
Additionally, there is a startup example on the same topic on the SIMATIC
NET Quick Start CD, which is, however, restricted to the basic supply of the
viewed user interface, in order to reduce the program scope to a minimum.
The functionality in this quick start example consists only of bi-directional
sending of on single byte between Master (CPU 315-2DP) and Slave
(CP342-5).
Rev A. Final 02.12.2003 3/83

Foreword
Structure of the document

The documentation of this application is divided into the following main
parts.
Part Description Note
A1 Part A1 gives you a general overview of the
contents. You learn about the components
used (standard hardware and software
components and the additionally developed
software).
The basic function data illustrate the powerful
performance of this application.
A2 Part A2 gives a detailed description of the You can skip this part if
function processes of the hardware and you just want to test the
software components involved. Read this part if application first using the
you want to know what the functions do and step–by-step instructions.
how the solution components interact.
B Part B leads you step by step through setup
and commissioning of the application on the
basis of the delivered software and introduces
the core configuration steps where necessary.
C Part C is of interest if you want to take the
software and expand or adapt it to your set-up.
Table 0-1
Rev A. Final 02.12.2003 4/83

Warranty, Liability and Support
We do not accept any liability for the information contained in this

document.
Any claims against us - based on whatever legal reason - resulting from
the use of the examples, information, programs, engineering and
performance data etc., described in this document shall be excluded. Such
an exclusion shall not apply in the case of mandatory liability, e.g. under
the German Product Liability Act (“Produkthaftungsgesetz”), in case of
intent, gross negligence, or injury of life, body or health, guarantee for the
quality of a product, fraudulent concealment of a deficiency or breach of a
condition which goes to the root of the contract (“wesentliche
Vertragspflichten”). However, claims arising from a breach of a condition
which goes to the root of the contract shall be limited to the foreseeable
damage which is intrinsic to the contract, unless caused by intent or gross
negligence or based on mandatory liability for injury of life, body or health.
The above provisions does not imply a change in the burden of proof to
your detriment.
The Application Examples are not binding and do not claim to be complete
regarding the circuits shown, equipping and any eventuality. They do not
represent customer-specific solutions. They are only intended to provide
support for typical applications. You are responsible in ensuring that the
described products are correctly used.
These Application Examples do not relieve you of the responsibility in
safely and professionally using, installing, operating and servicing
equipment. When using these Application Examples, you recognize that
Siemens cannot be made liable for any damage/claims beyond the liability
clause described above. We reserve the right to make changes to these
Application Examples at any time without prior notice. If there are any
deviations between the recommendations provided in these Application
Examples and other Siemens publications - e.g. Catalogs - then the
contents of the other documents have priority.
Copyright© 2004 Siemens A&D. It is not permissible to transfer or

copy these Application Examples or excerpts of them without first
having prior authorization from Siemens A&D in writing.
For questions about this document please use the following

e-mail-address:
csweb@ad.siemens.de
Rev A. Final 02.12.2003 5/83

Table of Contents
Part A1: Application Description................................................................................. 8

1 The Automation Task................................................................................. 9
2 Automation Solution................................................................................ 11
2.1 Overview of complete solution ................................................................... 12
2.2 Description of functionality of the application ............................................. 13
2.3 Alternative solutions ................................................................................... 15
2.4 Required components ................................................................................ 17
2.4.1 Hardware components ............................................................................... 17
2.4.2 Software components ................................................................................ 17
2.4.3 Application software ................................................................................... 18
3 Basic performance data .......................................................................... 30
3.1 Basic performance data of the hardware without application

components................................................................................................ 30
3.2 Basic performance data of the S7 protocol ................................................ 31

3.3 Basic performance data of the overall application (STEP7 project).......... 31
Part A2: Function Mechanisms ................................................................................. 32
4 Function Mechanisms ............................................................................. 32
4.1 Data flow model in this HW constellation ................................................... 34
4.2 Structural components of the communication task .................................... 35
4.3 Physical bus medium ................................................................................. 37
4.4 Protocol specific mechanisms.................................................................... 37
4.5 Application structure in this example.......................................................... 45
4.5.1 Data flow model DP Master -> Slave communication ................................ 45
4.5.2 Data flow model DP Slave -> Master communication ................................ 48
4.6 Function elements of the application software ........................................... 50
4.6.1 Block hierarchy........................................................................................... 51
4.6.2 Data flow between Master and Slave......................................................... 53
4.6.3 Function element “Data source”................................................................. 53
4.6.4 Function element “Telegram generation” ................................................... 54
4.6.5 Function element “Sending routine” ........................................................... 55
4.6.6 Function element “Receiving routine” ........................................................ 56
4.6.7 Function element “Error evaluation”........................................................... 58
4.6.8 Function element “Acknowledgement routine”........................................... 58
Part B: Installation of the Example Application....................................................... 60
5 Installation of Hardware and Software................................................... 60
5.1 Hardware configuration .............................................................................. 61
Rev A. Final 02.12.2003 6/83

5.2 Installation of the software ......................................................................... 62

5.3 Configurations of the application................................................................ 63
5.3.1 Configuration of the Profibus CP................................................................ 63
5.3.2 Configuring a clock synchronization........................................................... 65
6 Operator Control and Monitoring of the Application ............................ 67
6.1 Functions of the user interface................................................................... 68
6.2 Modification of data transfer....................................................................... 72
Part C: Program Description ..................................................................................... 74
7 Explanations on the STEP7 Program..................................................... 75
7.1 Block FC100 “DP_KOMM“ ......................................................................... 75
7.2 Block FC10 “WRITE_TO_SLAVE“ of the Master station ........................... 76
7.3 Block FC20 ”READ_FROM_SLAVE“ of the Master station ....................... 77
7.4 Block FC10 “SEND“ of the Slave station.................................................... 78
7.5 Block FC20 “RECEIVE“ of the Slave station.............................................. 79

8 Changes in the STEP7 Program ............................................................. 79

8.1 Using other Slave modules ........................................................................ 79
9 Glossary.................................................................................................... 82
10 Bibliography ............................................................................................. 83
Rev A. Final 02.12.2003 7/83

Part A1: Application Description
Objectives of Part A1
Part A1 of this document provides the reader with information on the
following topics:
• The automation task
• Illustrate a possible solution for it
• Illustrate the performance of the entire application
Content of Part A1
1 The Automation Task................................................................................. 9

2 Automation Solution................................................................................ 11
2.1 Overview of complete solution ................................................................... 12

2.2 Description of functionality of the application ............................................. 13

2.3 Alternative solutions ................................................................................... 15
2.4 Required components ................................................................................ 17
2.4.1 Hardware components ............................................................................... 17
2.4.2 Software components ................................................................................ 17
2.4.3 Application software ................................................................................... 18
3 Basic performance data .......................................................................... 30
components................................................................................................ 30
3.2 Basic performance data of the S7 protocol ................................................ 31
3.3 Basic performance data of the overall application (STEP7 project).......... 31
Rev A. Final 02.12.2003 8/83

1 The Automation Task
Category
This chapter describes the automation task. It is the basis for the
automation solution described in chapter 2.
Technical task
The application is to illustrate a method where two stations or station parts,
consisting of respectively one DP Master system with DP slaves, can be
linked quickly and efficiently in order to exchange smaller data amounts.
Thereby, the load on the Profibus via which the link is established is to be
kept at a minimum.
The following figure illustrates the task.
Fig. 1-1
Station 1 consists of a CPU 315-2 with DP master system. Station 2 is set

up in the same way. Both systems are now to be connected without as little
workload as possible. A Profibus CP is to be integrated in station 2 which
operates as DP Slave of station 1.
With as little programming workload as possible, up to 240 bytes are to be
transmitted between the stations in either direction, using the standard DP
mechanism.
Rev A. Final 02.12.2003 9/83

Specific requirements on the application
• Bi-directional data transfer between Master and Slave via Profibus DP,
implemented as Client-to-Client connection
• High-performance transfer of data record with little load on the bus
connection
• Secure and consistent transfer of data records with acknowledgement of
complete reception without errors
• Variable data volume of 1 to 240 bytes
• Cost-efficient solution
• Principally it can also be employed for connecting to any DP Master
system
Rev A. Final 02.12.2003 10/83

2 Automation Solution
Introduction
This chapter provides you with detailed information on how this application
solves the automation task described in chapter 1. It demonstrates what the
application can do, which function elements it contains and how it works. Its
functions are deliberately described in universally applicable terms. Part A2
of this documentation includes in-depth information which you will only
need if you are interested in background knowledge, the detailed processes
and the interactions between the individual solution components.
Content of automation solution chapter

Table 2-1
Chapter Chapter heading You are informed on…

2.1 Overview of complete solution ...which components are involved, and where is
the focus of the application

2.2 Integrated functionalities of the ... which actions are performed by the program,
application and what are the function elements/ learning
units
2.3 Alternative solutions ...which further possibilities of fulfilling the
functionality, required in the task, are there
2.4 Required components ...which standard hardware and software
elements are necessary in order to be able to
use this application, and which blocks are
contained in the application software
Rev A. Final 02.12.2003 11/83

2.1 Overview of complete solution
Display of involved components

The following overview displays the HW setup of the example application
(without DP Master systems) including the connection to the PG/PC and
the function elements which have been realized here.
Master 1 Slave
Master 2
Fig. 2-1
Focus of the application
The DP Master system of both stations with further Slaves is not displayed
here, neither will it be taken into account in the following. This application
focuses on linking both CPUs via the Profibus CP 342-5.
Rev A. Final 02.12.2003 12/83

2.2 Description of functionality of the application
What is the main functionality of the application?

The application transfers smaller data records via Profibus (variable from 1
to 240 bytes, of which a maximum of 202 bytes are user data) in both
directions between a DP Master CPU and a second CPU, whereby a CP
342-5 has been configured as DP Slave.
Description of the actions performed by the program

The following table describes which actions are performed by the
application in order to solve the task.
Table 2-2
No. Action Explanation
1 As soon as new data are to be sent to the The trigger for a new requirement is a bit
communication partner, a new data record which can be set via the variable table.
of required size is generated.

2 The data record is split into send units, the The Slave modules are configured in the
size of which corresponds to the Slave sizes 3x64 bytes, 1x32 bytes and 1x16
modules configured in the CP342-5. bytes, respectively as input and output
modules.
3 The send units are provided with header This enables checking the complete transfer
information or frames. of all send units.
4 The data is sent to the communication Using the DPWR_DAT system function, the
partner. master writes data to the output module of
the Slave, vice versa, the Slave station uses
the DP_SEND standard function for
transferring the data to the CP.
5 An error evaluation routine checks In case of an error, the error status is saved
whether writing data to the DP slave or including the time stamp.
transferal to the CP was completed
without errors.
6 The data is read from the communication The Master station reads the data
partner. successively from the input modules of the
Slave, using the system function
DPRD_DAT, vice versa, the Slave station
uses the DP_RECV standard function to
collect data from the CP.
7 An error evaluation routine checks In case of an error, the error status is saved
whether reading data from the DP slave or in return including the time stamp.
receiving data from the CP was completed
without errors.
8 The received data are checked for This happens using a data record at the
completeness. beginning and end of each data unit.
Rev A. Final 02.12.2003 13/83

No. Action Explanation

9 The receiver sends an acknowledgement The acknowledgement informs the sender of
to the sender. whether the send data has arrived complete
and without errors at the receiver.
Description of the function elements/ learning units

The application on hand is divided into the function elements which can be
used as learning units. They show how a certain partial task has been
solved and are to be used as basic units for your own applications.
Table 2-3
No. Function element/ Explanation
Learning unit
1 Data source A data simulator provides simulated data to the application. The
number of generated bytes is given when calling the function
block. The block is called individually if triggered accordingly.
2 Telegram A data record splitter divides the data to be sent according to the
generator size of the I/O module of the Slave. Furthermore, it generates a

header for the first send unit, which contains an ID, the total
length of the data record and a time stamp. Further send units
contain an ID each at the beginning and end of the unit. This ID is
the same for each send unit within a data record.
3 Sending routine The sending routine writes the data provided in a DB, including
header, to the output module of the Slave, or respectively, sends
it to the CP.
4 Receiving routine The receiving routine reads the data from the receive module of
the slave, or from the CP and stores it in a special DB.
5 Error evaluation The error evaluation is activated in case of an error, by storing the
error status of a communication function (DP_SEND, DP_RECV,
DPWR_DAT, DPRD_DAT) in a protocol DB together with a time
stamp, canceling the send function and providing a respective
returned value at the user interface.
6 Acknowledgement One input and output module of the DP slave each has been
routine reserved for acknowledgement information: user data is not
transferred via this module. If new data has arrived, the receiver
sends an acknowledgement back to the sender. This
acknowledgement contains an acknowledgement ID and the ID
and length of the received data record, as well as a receive status
which indicates whether the receiver has received the data
completely.
Rev A. Final 02.12.2003 14/83

Advantages of this solution

• Very quick communication
• Cost-effective, as only one CP is used for the connection type
introduced here.
• The DP-Slave-CPU communicates with the Master via CP342-5
irrespective of the communication via its DP line.
• For the DP-Master-CPU the reaction time of its DP line is only marginally
higher.
• The configuration effort is low.
2.3 Alternative solutions
Application on hand
The application on hand illustrates a solution which only requires one CP

for a communication between two S7 stations via Profibus in order to send

up to 240 bytes of data consistently from one station to the other.
What are the alternatives?

The following alternatives will yield the same functionalities:
• Different communication service
○ For larger data volumes, a communication service of the
S7-Communication can also be used. This requires installing the
optional package NCM S7 for Profibus which is delivered free of
charge along with the STEP7 basic package. Communication blocks
(PUT/GET, BSEND/BRECV, USEND/URECV) and a connection
configuration are required for the S7-300 to be the Client (possible
with CP 342-5).
○ The SDA service of the FDL protocol on the Profibus is also suitable
for similar data volumes and transfer speeds. However, this requires
the use of two suitable Profibus-CPs.
• HW alternatives
○ A S7-CPU 342-5 can be used for both communication partners. The
resulting hardware costs are of course higher. (a must for FDL
communication)
Rev A. Final 02.12.2003 15/83

○ Application of a DP/DP coupler. It is used for interconnecting two

PROFIBUS-DP networks in order to transfer data from the Master of
one network to the Master of the other network.
The maximum amount of the data to be transferred in total is 256
bytes. Thereby, a maximum of 240 bytes can be transferred in one
direction. The DP/DP coupler is configured as modular Slave. The
output data of one Slave is used as input data of the respective other
Slave and vice versa.
Rev A. Final 02.12.2003 16/83

2.4 Required components
2.4.1 Hardware components
The following hardware components are required for using the application.
Table 2-4
Component MLFB / Order number Note
SIMATIC S7-300, mounting 6ES7 390-1AE80-0AA0
rail, length: 480mm
Current Supply PS 307 2A 6ES7307-1BA00-0AA0 Or similar power

supply
CPU 315-2 DP (2 ea.) 6ES7 315-2AG10-0AB0 A CPU without DP
interface can be used
for the Slave station
e.g. a CPU 314.

Micro Memory Card 6ES7953-8LM00-0AA0

NFLASH, 4MB (2 ea.)
CP 342-5 6GK7 342-5DA02-0XE0
Standard bus line SIMATIC 6XV1 830-3DH15 Length approx. 1.5m,
NET for PROFIBUS-DP with two M12
connectors (or other
Profibus line)
Power PG 6ES7750-2CA52-4FB4 See PG-
configurator in A&D
Mall
MPI cable 6ES7 901-0BF00-0AA0 Or PROFIBUS cable
2.4.2 Software components
The following software components are required to use the application.
Table 2-5
Component MLFB / Order number Note
STEP7 V5.2 SP1 6ES7810-4CC06-0YX0 Incl. NCM S7
Windows 2000 SP1 Or operating system

supported by STEP
V5.2 SP1
Rev A. Final 02.12.2003 17/83

2.4.3 Application software
The application software of the STEP7 project “Appl10“ contains both

S7-300 stations.
• “Station1_Master“
• “Station2_Slave“
Fig. 2-2
For each of both stations you find two tables on the following pages, which,
with the exception of the used standard function blocks and system
functions, lists all blocks contained in the project:
• Standard user blocks (OBs)
• Application user blocks
The application blocks are respectively assigned to one of the function
elements, and their function is described in key words.
Part A2 discusses these function element in detail.
Rev A. Final 02.12.2003 18/83

Standard user blocks Station1_Master

Table 2-6
Funktion element Name Function description Technical specifications System
Environment
Startup OB100 Generates startup conditions for the application • Language: STL S7 CPU
• Load memory: 114 bytes
• RAM: 46 bytes
Cyclic operation OB1 • Call FC100 “DP_KOMM“ • Language: STL S7 CPU
• reset if necessary • Load memory: 186 bytes
• RAM: 92 bytes
Diagnostic alarm OB82 • Included as a standard • Language: STL S7 CPU
• RAM: 38 bytes
Priority class error OB85 • Included as a standard • Language: STL S7 CPU
• RAM: 38 bytes
Module rack failure OB86 • Included as a standard • Language: STL S7 CPU
• RAM: 38 bytes
Rev A. Final 02.12.2003 19/83

Application user blocks Station1_Master

Table 2-7
Function element Name Function description Technical specifications System
Environment
Central block of the Call FC100 • Call FB28 “DATA_GENERATOR“ • Language: STL OB1
application “DP_KOMM“
• Call FC30 “SPLIT_RAW_DATA“ • Load memory: 292 bytes
• Call FC10 “WRITE_TO_SLAVE” • RAM: 228 bytes
• Call FC40 “EVAL_ACKNOWLEDGE”
• Call FC20 “READ_FROM_SLAVE”
Sending routine FC10 • Write data to the outputs (Slave module) • Language: STL FC100
”WRITE_TO_SLAVE“
• In case of an error call FB33 • Load memory: 842 bytes
“ERROR_C“
• RAM: 746 bytes
DB1 Storage for the data to be sent Filled by the • Language: DB
“RAW_DATA“ function FB28 “DATA_GENERATOR“.
• RAM: 238 bytes
DB10 “Send mailbox“: Storage for data ready to be • Language: DB
”SEND_DATA” sent, which have been provided with header
information. • Load memory: 412 bytes
• RAM: 276 bytes
Receiving routine FC20 • Read data from inputs (Slave module) • Language: STL FC100
“READ_FROM_SLAVE“ •
• In case of an error call FB33 “ERROR_C“ Load memory: 1524 bytes
• Generate acknowledgement • RAM: 1402 bytes
• Measure performance data
Rev A. Final 02.12.2003 20/83


Environment
DB11 “Receive mailbox“: Storage for received data, • Language: DB
”RECV_DATA” including header information • Load memory: 412 bytes
• RAM: 276 bytes
DB12 Storage for received net data • Language: DB
“DATA_COMPLETE“ • Load memory: 294 bytes
• RAM: 238 bytes
Data source FB28 Generate data • Language: STL FC100
“DATA GENERATOR“ • Load memory: 290 bytes
• RAM: 208 bytes
DB28 Instance DB for FB28 • Language: DB
• RAM: 54 bytes
Telegram generator FC30 • Dividing the raw data of the DB1 into smaller • Language: STL FC100
“SPLIT_RAW_DATA“ units depending on the size of the Slave
module.
• RAM: 484 bytes
• Add header information
UDT1 Contains header information such as ID, data
”Header“ record length, time stamp.
UDT2 Contains 60 bytes of data and an ID at the
“Telegram64“ beginning and end of the unit.
”Telegram32“ beginning and end of the unit.
UDT5 Contains a header, 54 bytes of data and an ID
“FirstTelegram64” at the end of the unit.
Rev A. Final 02.12.2003 21/83


Environment
Error evaluation FB33 Error routine • Language: STL FC10, FC20
“ERROR_C“
• RAM: 460 bytes
• RAM: 58 bytes
DB90 Defines which actions are to be performed, if • Language: DB
”ERROR_DB_WRITE“ certain errors occur during writing.
• RAM: 76 bytes
”ERROR_DB_READ“ certain errors occur during reading.
• RAM: 76 bytes
DB95 Protocols occurred errors with time stamp. • Language: DB
“PROTOCOL_DB“
• RAM: 236 bytes
UDT 105 Contains error/ execution status and assigned
action.
UDT 110 Error protocol entry
Acknowledgement routine FC40 Evaluation whether the last send job has been • Language: STL FC100
“EVAL_ACKNOWLEDGE“ acknowledged successfully.
• RAM: 104 bytes
Rev A. Final 02.12.2003 22/83


Environment
DB2 Contains the received acknowledgement. • Language: DB
“GET_ACK“
• RAM: 52 bytes
DB3 Contains the acknowledgement to be sent. • Language: DB
”GIVE_ACK”
• RAM: 52 bytes
UDT4 ”Acknowledge” Acknowledgement information
Rev A. Final 02.12.2003 23/83

Standard user blocks Station2_Slave

Table 2-8
Environment
Startup OB100 Generates startup conditions for the application • Language: STL S7 CPU
• RAM: 46 bytes
Cyclic operation: OB1 • Call FC100 “DP_KOMM“ • Language: STL S7 CPU
• reset if necessary • Load memory: 178 bytes
• RAM: 84 bytes
Diagnostic alarm OB82 • Language: STL S7 CPU
• RAM: 38 bytes
Rev A. Final 02.12.2003 24/83

Application user blocks Station2_Slave

Table 2-9
Environment
Central block of the Call FC100 • Call FB28 “DATA_GENERATOR“ • Language: STL OB1
application “DP_KOMM“
• Call FC30 “SPLIT_RAW_DATA“ • Load memory: 294 bytes
• Call FC40 “EVAL_ACKNOWLEDGE“ • RAM: 232 bytes
• Call FC10 “SEND“
• Call FC20 “RECEIVE“
Sending routine FC10 • Data to be transferred to the CP • Language: STL FC100
“SEND“
• In case of an error call FB33 • Load memory: 476 bytes
“ERROR_C“
• RAM: 408 bytes
DB1 Storage for the data to be sent. Filled by the • Language: DB
“RAW_DATA“ function FB28 “DATA_GENERATOR“.
• RAM: 238 bytes
DB10 “Send mailbox“: Storage for data ready to be • Language: DB
”SEND_DATA” sent, which have been provided with header
information. • Load memory: 412 bytes
• RAM: 276 bytes
Receiving routine FC20 • Read data from the CP • Language: STL FC100
“RECEIVE“
• In case of an error call FB33 “ERROR_C“ • Load memory: 1554 bytes
• Generate acknowledgement • RAM: 1338 bytes
• Measure performance data
Rev A. Final 02.12.2003 25/83


Environment
DB11 “Receive mailbox“: Storage for received data, • Language: DB
”RECV_DATA” including header information
• RAM: 276 bytes
DB12 Storage for received net data • Language: DB
“DATA_COMPLETE“
• RAM: 238 bytes
Data source FB28 Generate data • Language: STL FC100
“DATA GENERATOR“
• RAM: 208 bytes
• RAM: 54 bytes
Telegram generator FC30 • Dividing the raw data of the DB1 into smaller • Language: STL FC100
“SPLIT_RAW_DATA“ units depending on the size of the Slave
module. • Load memory: 550 bytes
• Add header information • RAM: 486 bytes
UDT1 Contains header information such as ID, data

”Header“ record length, time stamp.
“Telegram64“ beginning and end of the unit.
”Telegram32“ beginning and end of the unit.
Rev A. Final 02.12.2003 26/83


Environment
UDT5 Contains a header, 54 bytes of data and an ID
“FirstTelegram64” at the end of the unit.
Error evaluation FB33 Error routine • Language: STL FC10, FC20
“ERROR_C“
• RAM: 460 bytes
• RAM: 58 bytes
”ERROR_DB_SEND“ certain errors occur during sending.
• RAM: 76 bytes
“ERROR_DB_RECV“ certain errors occur during receiving of data. • Load memory: 192 bytes
• RAM: 76 bytes
DB95 Protocols occurred errors with time stamp. • Language: DB
“PROTOCOL_DB“ • Load memory: 502 bytes
• RAM: 236 bytes
UDT 105 Contains error/ execution status and assigned
action.
UDT 110 Error protocol entry
Acknowledgement routine FC40 Evaluation whether the last send job has been • Language: STL FC100
“EVAL_ACKNOWLEDGE“ acknowledged successfully. • Load memory: 162 bytes
• RAM: 104 bytes
Rev A. Final 02.12.2003 27/83


Environment
DB2 Contains the received acknowledgement. • Language: DB
“GET_ACK“ • Load memory: 118 bytes
• RAM: 52 bytes
DB3 Contains the acknowledgement to be sent. • Language: DB
”GIVE_ACK” • Load memory: 118 bytes
• RAM: 52 bytes
UDT4 Acknowledgement information
”Acknowledge”
Configuration elements
On top of the general hardware configuration, the application contains the following configuration elements:
Table 2-10
Element Function Description Engineering-Tool
CP342-5 Configuring the 240 input and output bytes each, divided between 5 input and 5 HW-Config of the Master station
Slave modules output modules.
MPI Clock For clock synchronization between Master and Slave. NetPro
synchronization
The configuration of both elements is described in chapter 5.3 “Configurations of the application“.
Rev A. Final 02.12.2003 28/83

Workload for programming / configuration
• Good basic knowledge in STEP7 programming is sufficient for

implementing the functionality contained in this application.
• With average programming knowledge, the expected programming
workload is approx. 3-6 days.
• The configuration effort is low.
Rev A. Final 02.12.2003 29/83

3 Basic performance data
Content
This chapter gives you a summary of the performance of this application
and the components used.

components
Specifications of the CP342-5 DP

Table 3-1
Criterion Basic performance data Additional note
Transmission speed 9.6 kbits/sec The transfer speed is set using
the STEP 7 configuration
19.2 kbits/sec
software.
45.45 kbits/sec
93.75 kbits/sec
187.5 kbits/sec
500 kbits/sec
1.5 Mbit/s (default)
3 Mbit/s
6 Mbit/s
12 Mbit/s
Size of the DP data areas (per
DP Slave):
– DP input area
max. 240 bytes
– DP output area max. 240 bytes
Reaction times DP Slave: Note

- per data block call DP_SEND - 5.7 ms at 240 bytes The given reaction times at DP
- per data block call DP_RECV - 6.4 ms at 240 bytes Slave operation can only be
(runtime of the CPU 314) considered as guide values and
only apply for the case where no
other services (e.g. PG
functions) are processed in the
CP.
Rev A. Final 02.12.2003 30/83

3.2 Basic performance data of the S7 protocol
Table 3-2
Transmission speed 9.6kBaud...12Mbaud
Standardization Standardized DP communication
possible, as well as with non-
SIMATIC systems complying with
this standard.
Acknowledgement The protocol acknowledges the data Level 7 of the
on user level in the source and ISO/OSI-reference
target CPU. model
3.3 Basic performance data of the overall application

(STEP7 project)
Table 3-3
Program size Master 5758 bytes In RAM:
Program size Slave 7114 bytes In RAM:
Maximum cycle time of the Master 20 ms
CPU
Minimum cycle time of the Slave 17 ms
CPU
Max. data record length (user 202 bytes A total of 240 bytes can be
data) transferred
Transmission time Master -> Slave (202 bytes raw data)
Average 79 ms
Maximal 438 ms
Minimal 7 ms For 100 measurements
Transmission time Slave -> Master (202 bytes raw data)
Average 33 ms
Maximal 51 ms
Minimal 19 ms
Error buffer size 20 protocol entries each for Expandable
Master and Slave
Specific error reactions On the Master as well as the Expandable
Slave side, one specific
reaction can be defined for
every 10 errors during writing
and reading.
Rev A. Final 02.12.2003 31/83

Part A2: Function Mechanisms
Objectives of Part A2
Part A2 of this document provides the reader with information on the
following:
• Explanation of all integrated function elements
• Description of components which can be easily integrated in your
specific applications
• Respective background knowledge
Content Part A2
4 Function Mechanisms ............................................................................. 32

4.1 Data flow model in this HW constellation ................................................... 34
4.2 Structural components of the communication task .................................... 35

4.3 Physical bus medium ................................................................................. 37

4.4 Protocol specific mechanisms.................................................................... 37
4.5 Application structure in this example.......................................................... 45
4.5.1 Data flow model DP Master -> Slave communication ................................ 45
4.5.2 Data flow model DP Slave -> Master communication ................................ 48
4.6 Function elements of the application software ........................................... 50
4.6.1 Block hierarchy........................................................................................... 51
4.6.2 Data flow between Master and Slave......................................................... 53
4.6.3 Function element “Data source”................................................................. 53
4.6.4 Function element “Telegram generation” ................................................... 54
4.6.5 Function element “Sending routine” ........................................................... 55
4.6.6 Function element “Receiving routine” ........................................................ 56
4.6.7 Function element “Error evaluation”........................................................... 58
4.6.8 Function element “Acknowledgement routine”........................................... 58
Rev A. Final 02.12.2003 32/83

4 Function Mechanisms
What will you find here?

Provides information on
• Solution structure of the overall application
• User bus/protocol
• Used function elements and their functioning
What can you do with it?

In principle this application can immediately be used. The installation
instructions tell you how to start the application, even if you have not read
this chapter. If however, you wish to vary certain modules of the application
for your requirements, more detailed information is necessary.
Rev A. Final 02.12.2003 33/83

4.1 Data flow model in this HW constellation
Illustration of the data flow model

The following diagram displays the data flow model of the application from
a SIMATIC component view.
For a better overview, only the data flow from Master to Slave is considered
here. The data flow in reverse direction is principally along the same path,
only that different communication functions are called in the user program.
Fig. 4-1
Rev A. Final 02.12.2003 34/83


Table 4-1
No. Description
1 In the user program of the Master station, the data range to be sent is
transferred to the user interface (system function SFC15 “DPWR_DAT“,
loaded from the standard library into the PLC) via S7-AnyPointer . The
specified target during calling is the address of the CP Slave module.
Note
Writing onto the Slave module can theoretically also occur with normal
transfer commands.
When accessing the I/O data with load/ transfer commands such as L, T
however, a maximum of one double word can be read or written with each
command. If several of such commands were used successively, the
consistency of the data across the entire data area would not be
guaranteed.
2 The operating system forwards the data package via the Profibus to the
addressed Slave module of the CP.
3 The CP receives the data package and stores it in its receiving buffer.
4 On calling the standard function FC2 “DP_RECV”, the content of the

receiving buffer of the CP is read into the DB specified when calling via
AnyPointer in the user interface of the Slave station.
4.2 Structural components of the communication task
Introduction
A simplified communication task is to “transport a certain amount of data
from station A to station B“. In practice, however, this simple task requires a
number of decisions to be made and structures to be realized.
In the following sections we show you a general approach for solving this
task. It includes selecting the communication path and the carrier protocol
as well as the software modules of the user program necessary for fulfilling
this requirement.
Rev A. Final 02.12.2003 35/83

Display of structure components

The following graphic illustrates the individual layers and modules of the
communication relationship between the two stations, whereby for a better
overview only the modules relevant during data transfer from station A
(Master) to station B (Slave) are taken into account.
Station B of course, also has the modules Raw data source, Telegram
generation and Sending routine, in addition to the here displayed modules,
station A also contains the Receiving routine, Consistency assurance and
Target data area.
Fig. 4-2
Description of the figure

The communication relationship contains
• Physical coupling of two stations via Profibus and respective connection
to the CPU or the CP.
• Usage of transfer protocol
• User modules which package and transfer the raw data via the user
interface of the protocol.
The individual layers and the implementation are introduced below.
Rev A. Final 02.12.2003 36/83

4.3 Physical bus medium
Profibus is the bus medium which is used here. Profibus is an open,

producer independent industrial field bus standard, which is employed in
the SIMATIC NET communication system as a network for the cell and field
area. From a physics point of view, the Profibus is an electrical network
based on a shielded two-wire circuit, or an optical fiber based network.
Profibus is based on the RS 485 standard. RS 485 is a multi-point capable
interface at which the logic statuses are illustrated by means of a
differential voltage between the two lines.
The following chapter discusses Profibus protocols, especially the Profibus
DP protocol used in this application.
4.4 Protocol specific mechanisms

Definition of a protocol
A protocol is an agreement, precise down to the bit, between

communication partners in order to perform a certain communication
service. The protocol defines the content structure of the data traffic on the
physical line and establishes, for example, the operating mode, the
procedure during connection setup, the data security or transfer speed.
Overview of available protocols/ services of the Profibus

Following the ISO/OSI model for communication standards (7 layer model),
the following graphic illustrates how the used DP/V0 protocol (marked with
a red frame) is based on the physical level of the Profibus as well as to FDL
(Fieldbus Data Link, the data security layer for Profibus).
Levels 3 to 7 do not exist in Profibus-DP. The slim architecture enables
quick data transfer.
The user interface used in this application exists for level 7.
Rev A. Final 02.12.2003 37/83

Fig. 4-3
Explanation of the used abbreviations

Abbreviatio Meaning/ explanation
ns
FDL Fieldbus Data Link, the data security layer (second
layer of the ISO/OSI reference model) at Profibus
SDA Send Data with Acknowledge; service at which the
sender of the data receives feedback on whether the
receiver has received the data (individual remote
station). During an error in the transfer, the FDL of the
sender repeats the data transmission.
SDN Send Data with No Acknowledge; send service
without feedback, which also allows multicast
(sending to several stations) and broadcast (sending
to all stations).
SRD Send and Request Data with Reply
DP/V0 DPV0 is the cyclic data traffic between Master and
Slave, which transmits I/O data.
DP/V1 DPV1 is a cyclic as well as an acyclic service, i.e. the
transmission of the data records is triggered by a
certain event. The data records may contain raw data
or parameterization data for modules, or diagnostic
data.
DP/V2 DPV2 is the acyclic data traffic between Master and
Slave.
FMS Fieldbus Message Specification, layer 7 of the ISO
Rev A. Final 02.12.2003 38/83

referencing model at Profibus; amongst other things,

it comprises the functions protocol machine, coding/
decoding and interpretation of the protocol data unit.
S7 S7 Communication / S7 Standard Communication
Core properties of the DP protocol

The data transfer via PROFIBUS-DP offers a standardized interface (EN
50170 Vol.2) for transferring process input and output data between
SIMATIC S7 and field devices (DP-Slaves). The transfer behavior via
PROFIBUS-DP is marked by the quick cyclic data exchange between DP
Master and the DP Slaves.
How the user interface works

1.) I/O transfer of 1, 2 or 4 bytes
Consistent reading and writing of one, two or four peripheral bytes occurs
via the L/T commands.
2.) I/O transfer of 3 or more than 4 bytes

If 3 or more than 4 I/O bytes are to be consistently read or written, special
S7 blocks of the SFC type are required in the user program in order to
modify and monitor the communication via PROFIBUS–DP. The SFC
blocks ensure
• Transferring the process output data from one data area of the S7-CPU
to be specified to the I/Os (SFC15 “DPWR_DAT“);
• Entering the process input data read by the I/O into a data area of the
S7-CPU to be specified (SFC15 “DPWR_DAT“);
Rev A. Final 02.12.2003 39/83

Configuration model of this protocol via the DP interface

The figure below illustrates the principle how data can be exchanged via
the DP mechanism.
Fig. 4-4
• The CP (as DP Slave) can read or write the complete data record (up to
240 bytes) via its user interface (DP_SEND, DP_RECV).
• The Master on the other hand can only consistently write or read data
via its user interface (DPRD_DAT, DPWR_DAT) to the extent of its
configured I/O modules.
Respective user programming must take this core property into account.
User interface to the Profibus-DP protocol

On the Master side, the standard functions SFC14 “DPRD_DAT“ and
SFC15 “DPWR_DAT“ are used which are a standard feature on the CPU.
On the Slave side, the functions FC1 “DP_SEND“ and FC2 ”DP_RECV“
from the SIMATIC NET library or the standard library are used.
These interfaces are introduced here along with their parameters.
• SFC14 “DPRD_DAT“
Fig. 4-5
Rev A. Final 02.12.2003 40/83

With SFC 14 "DPRD_DAT" you read consistent data (for the term data
consistency refers to the Glossary) of a DP standard slave, whereby the
maximum length is defined specific to the CPU. These are available in
the technical data of your CPU. The read data are entered into the target
area defined by the parameter RECPRD.
The target area must have the same length which has been configured
by you with STEP 7 for the selected module.
The SFC 14 "DPRD_DAT" is necessary because the load command (L)
which access the I/Os or the process image of the inputs can only be
used to consistently read one, two or four bytes.
Parameters:
LADDR Configured start address which is to be read from the I/O area of
the module.
The address must be hexadecimal, for example, start address
100 means: LADDR:=W#16#64.
RET_VAL If an error occurs during processing of the function, the
returned value will contain a hexadecimal error code.

RECORD Target area for read user data. It must be equally long as
configured for the selected module with STEP7. Only the data
type BYTE is permitted.
• SFC15 „DPWR_DAT“
Fig. 4-6
Using SFC 15 "DPWR_DAT" you transfer the data RECORD consistent

to the addressed DP standard slave. Data transfer is synchronous, i.e.,
after completing the SFC, the write procedure is finished. The source
area must have the same length which has been configured by you with
STEP 7 for the selected module.
The SFC 15 "DPWR_DAT" is necessary because the transfer commands
which access the I/Os or the process image of the outputs can only be
used to consistently write a maximum four bytes.
Rev A. Final 02.12.2003 41/83

Parameters:
LADDR Configured start address of the PAA area of the module to be
written to.
Note: The address must be hexadecimal, for example, start
address 100 means: LADDR:=W#16#64.
RECORD Source for the user data to be written. It must be equally long
as configured for the selected module with STEP7. Only the
data type BYTE is permitted.
RET_VAL If an error occurs during processing of the function, the
returned value will contain a hexadecimal error code.
• FC1 “DP_SEND“
Fig. 4-7
When used in the DP Slave, the DP_SEND module transfers the data of
the given data area of the CPU into the send buffer of the PROFIBUS-
CP in order for it to be transferred to the DP Master. Execution without
error is signaled, if the entire DP data area could be accepted from the
PROFIBUS-CP.
The FC block DP_SEND must be called at least once in the user
program of the DP Slave.
Parameters:
CPLADDR module start address. When configuring the CP with STEP 7
HW-Config, the module start address is given in the
configuration table.
SEND Specifying address and length. The address of the DP data
area alternatively refers to the PA area, flag area or data
block area.
DONE The status parameter indicates whether the order has been
processed without errors.
ERROR Error display
STATUS Status display
Rev A. Final 02.12.2003 42/83

• FC2 “DP_RECV“
Fig. 4-8
When used in the DP Slave, the DP_RECV function accepts the

transferred DP data from the receive buffer of the PROFIBUS-CP into a
specified DP data area of the CPU.
The data area specified for data acceptance can be a PA area, a marker
area or a data block area.

Execution without error is signaled if the entire DP data input area could
be transferred by the PROFIBUS-CP.
The DP_RECV block must be called at least once in the user program.
Parameters:
CPLADDR module start address. When configuring the CP with STEP 7
HW-Config, the module start address is given in the
configuration table.
RECV Specifying address and length. The address of the DP data
area alternatively refers to the PA area, flag area or data
block area.
NDR The status parameter indicates whether new data has been
accepted.
ERROR Error display
STATUS Status display
DP-STATUS DP status display
Note
Further information on the respective block is also available in the STEP7 online
help.
Rev A. Final 02.12.2003 43/83

Presentation of sequence model

The figure below illustrates the send procedure of a data package from
Master to Slave, as well as acknowledgement together with the involved
hardware and software objects, using a sequence model. The individual
sequences are explained in the corresponding table.
Fig. 4-9
Description of the sequence chart

Table 4-2
No. Description
1 Transferring of a new data package is triggered in the user program of the
Master.
2 The source data is transferred from a DB storage area into the I/O image
by calling the DPWR_DAT function.
3 The data is available in the memory of the CP and is read from the Slave
with the DP_RECV function and saved in the target area by the user
program.
Note:
The data block marked as “Q“ contains the acknowledgement. This data
block is only relevant during acknowledgement, for receiving user data it
is not acknowledged.
Rev A. Final 02.12.2003 44/83

4 If the acknowledgement routine confirms the error-free and complete

reception of the data, the acknowledgement block is transferred to the
input modules of the CP using the DP_SEND call (together with data
blocks 1-4 which are irrelevant here).
5 The Master reads the acknowledgement information with the DPRD_DAT.
At positive acknowledgement, the „Send_Acknowledged“ bit is set, in
case of an error it is reset.
4.5 Application structure in this example
Introduction
This chapter describes and comments on the structure of the application
using two data flow models.
4.5.1 Data flow model DP Master -> Slave communication


The data flow model illustrates which modules have been implemented in
this application and how they are interconnected. The figure shows the
send procedure from Master to Slave.
The red frames mark those components of the data flow model which are
processed within the user program.
Rev A. Final 02.12.2003 45/83

Fig. 4-10
Description of the operation in the sending section (DP-Master)

Table 4-3
Step Description
1 The data simulator generates a data record of variable length (1 – 240
bytes) by means of manual triggering via the variable table
2 Depending on the configuration of the CP342-5 Slave modules at the
Master line, the data record is divided into respectively large parts.
3 A distributor labels each subdata record with a frame pattern which
marks all data records as belonging together.
4 The individual data records are transferred via the user interface to the
Slave modules in the correct order.
5 An error evaluation checks whether the transferal to the DP Slave has
worked.
Rev A. Final 02.12.2003 46/83

Description of the operation in the receiving section (DP-Master)

Table 4-4
Step Description
1 The receiving routine reads the complete range of all input modules via
the user interface of the CP.
2 The receive mailbox is continuously checked until all frame codes are
recognized.
3 If the receiving routine has recognized a new data record as complete,
the data record is removed into the target buffer.
Rev A. Final 02.12.2003 47/83

4.5.2 Data flow model DP Slave -> Master communication

The data flow model illustrates which modules have been implemented in
this application and how they are interconnected. The figure shows the
send procedure from Slave to Master.
The red frames again mark which components of the model are processed
in the user program.
Fig. 4-11
Description of the operation in the sending section (DP-Master)

Table 4-5
Step Description
1 The data simulator generates a data record of variable length (1 – 240
bytes) by means of manual triggering via the variable table
2 Depending on the configuration of the CP342-5 Slave modules at the
Master line, the data record is divided into respectively large parts
(splitter).
Rev A. Final 02.12.2003 48/83

Step Description
3 A distributor labels each subdata record with a frame pattern which
marks all data records as belonging together.
4 If all partial data records have been generated, they are transferred to
the CP completely in one call of the ”DP_SEND“ user interface.
5 An error evaluation checks whether the transferal to the CP has worked.
Description of the operation in the receiving section (DP-Master)

Table 4-6
Step Description
1 The receiving routine scans all configured input modules of the DP
Slave via the user interface and transports the data into the
corresponding partial receive mailboxes.
2 A control function checks whether the subdata records belong together.
3 If all data records have been recognized as correct and complete, frame
codes and header are removed and the raw data record are copied into
a target area.
4 An error evaluation controls the error-free transferal from the user
interface.
Rev A. Final 02.12.2003 49/83

4.6 Function elements of the application software
Content of the chapter

This chapter provides an overview of the used blocks of Master and Slave
station in form of a block-call hierarchy.
A further image illustrates the data blocks involved in the communication.
Subsequently, the function elements contained in the application are
explained. The individual elements are:
• Data source
• Telegram generation
• Sending routine
• Receiving routine
• Acknowledgement routine
• Error processing
Rev A. Final 02.12.2003 50/83

4.6.1 Block hierarchy
Block hierarchy of the Master station

The call of the S7 blocks of the Master station or the access to the data
blocks respectively, follows the hierarchy displayed below:
Fig. 4-12
Rev A. Final 02.12.2003 51/83

Block hierarchy of the Slave station

The call of the S7 blocks of the Slave station or the access to the data
blocks follows the hierarchy displayed below:
Fig. 4-13
Rev A. Final 02.12.2003 52/83

4.6.2 Data flow between Master and Slave
The following diagram illustrates which data blocks are used for data
communication on the Master and Slave side, and which path the data
takes.
Fig. 4-14
4.6.3 Function element “Data source”
Functionality of the FB28 “DATA_GENERATOR“

The “DATA_GENERATOR“, which is called as soon as a new request is
set for sending, functions as data source. The data generated by this FB is
saved in DB1, which contains storage space for 202 bytes in the form of a
byte array. More than 202 bytes of raw data at once cannot be sent with
this application.
Rev A. Final 02.12.2003 53/83

User interface and parameter

The figure below illustrates the user interface of this block.
Fig. 4-15
Parameters:
Name Data type Description

Destination Any Address under which the new generated

data record is to be saved.
Length WORD Number of bytes to be generated.
Headerlength Byte Length of headers in byte
4.6.4 Function element “Telegram generation”
Functionality of the FC30 “SPLIT_RAW_DATA“

The FC30 “SPLIT_RAW_DATA“ function splits the data into subdata
records, provides it with header information for consistency assurance and
copies it from DB1 into DB10.
Consistency assurance
Consistency assurance is performed on user level. It is ensured in the user
program that all subdata records which belong together arrive at the
receiver in the original sequence. In order to do this, each subdata record
to be sent is marked with an ID at the beginning and end and which is
identical for all data record parts belonging together.
The header of the first subdata record to be sent additionally contains the
entire length of the data as well as a time stamp containing the time of
sending.
Rev A. Final 02.12.2003 54/83

Structure of the individual send units of the DB10

The individual send units of the DB10 each consist of a specific data
structure (UDT). The following figure shows how the DB10 is composed of
these structures.
DB10
Fig. 4-16
As illustrated in the figure, the 202 bytes of user data of the DB1 have
been divided between four send units and provided with header
information. The last send unit “Acknowledge“ is not used for transferring
user data, but for acknowledging a send procedure.
In this form, the send units can now be written to the Slave modules.
4.6.5 Function element “Sending routine”
Relationship between DB10 and the Slave modules

The following figure shows the structure of the DB10 “SEND_DATA“ in the
declaration view and how this setup is reflected in the configuration of the
Slave module.
The red arrows show which send unit is written to which Slave module.
Rev A. Final 02.12.2003 55/83

Fig. 4-17
• Communication direction Master Æ Slave

The data of the DB10 are written to the Slave modules with the FC10
“WRITE_TO_SLAVE” function by means of calling the “DPWR_DAT“
system function for each of the send units.
• Communication direction Slave Æ Master
The data of the DB10 are completely sent to the CP with the FC10 “SEND”
function, by means of calling the “DP_SEND“ function.
4.6.6 Function element “Receiving routine”
Functionality
The receiving routine works cyclically on the Master as well as the Slave
side.
• Communication direction Master Æ Slave
The FC20 “RECEIVE“ function reads the data sent by the master
completely from the CP using the “DP_RECV“ system function and saves it
in the various receive units in the DB11.
• Communication direction Slave Æ Master
The FC20 “READ_FROM_SLAVE“ function reads the data from the
configured Slave input modules and saves it in the various receive units in
the DB11.
Rev A. Final 02.12.2003 56/83

Structure of DB11 “RECV_DATA”

The structure of DB11 “RECV_DATA” is the same as for DB10
“SEND_DATA“, only with different names for the entries.
Relationship between DB11 and the Slave modules

The following figure illustrates the relationship between the Slave modules
and the structure of the DB11.
The red arrows show from which Slave module the data is read into which
receive unit.
Fig. 4-18
Consistency assurance
A main aspect during data transfer is data consistency. The data to be
transferred together should origin from one processing cycle and thus
belong together, i.e. be consistent.
The DP routine works with I/O areas. In order to ensure data consistency,
the header information of the subdata records is evaluated in the FC20
”READ_FROM_SLAVE“ (Master-Station) or the “RECEIVE“ (Slave-Station)
function, and it is checked whether all codes (IDs), which embrace the data
records at the beginning and end, are identical (see figure 4-15).
Rev A. Final 02.12.2003 57/83

Structure of DB12 “DATA_COMPLETE”

Like the DB1 “RAW_DATA”, the DB12 “DATA_COMPLETE” is composed
of an array of 202 bytes. In this memory area, the FC20 function copies the
user data (without header and acknowledgement information) from DB11
“RECV_DATA“.
4.6.7 Function element “Error evaluation”
Functionality of the FB33 “ERROR_C“

The error evaluation, encapsulated in the FB33 “ERROR_C“, is activated in
case of an error, by storing the error status of a communication function
(DP_SEND, DP_RECV, DPWR_DAT, DPRD_DAT) together with a time
stamp in the DB95 “PROTOCOL_DB“, canceling the send function after a
sending error and providing a respective returned value at the user
interface.
Defining reactions to errors

In DB90 “ERROR_DB_WRITE“, the user can define which actions are to be
performed if certain errors occur during writing.
In DB91 ”ERROR_DB_READ“, the user can define which actions are to be
performed, if certain errors occur during writing.
4.6.8 Function element “Acknowledgement routine”
The FC20 function sends an acknowledgement to the sender after new

data has been received. The acknowledgement is sent via a Slave module
reserved for this, which is not employed for user data. The
acknowledgement structure looks as follows:
Fig. 4-19
Rev A. Final 02.12.2003 58/83

The individual entries are:

• Acknowledgement ID: A code stating that the following data is an
acknowledgement
• ID: here the ID of the received data package is sent back
• Length: the number of the received bytes
• Status: 1, if the data has been received completely and without errors, 0
in case of an error
Rev A. Final 02.12.2003 59/83

Part B: Installation of the Example Application
Objectives of Part B
Part B of this document provides the reader with information on the
following:
• Installation of the sample application with all hardware and software
components
• Explanation of necessary configuration steps
• How to manipulate the application
Content of part B
5 Installation of Hardware and Software................................................... 60

5.1 Hardware configuration .............................................................................. 61

5.2 Installation of the software ......................................................................... 62

5.3 Configurations of the application................................................................ 63
5.3.1 Configuration of the Profibus CP................................................................ 63
5.3.2 Configuring a clock synchronization........................................................... 65
6 Operator Control and Monitoring of the Application ............................ 67
6.1 Functions of the user interface................................................................... 68
6.2 Modification of data transfer....................................................................... 72
Rev A. Final 02.12.2003 60/83

5 Installation of Hardware and Software
5.1 Hardware configuration
For the required hardware, please refer to chapter 2 "Automation solution”.
For the hardware installation, proceed in accordance with the table below:
Note
! Switch on the power supply only after the last step.
Table 5-1
Step Focus Action
1 Master station Set up the Master station analogues to the figure in chapter 2.1
“Display of involved components“.

2 Slave station Set up the Slave station analogues to the figure in chapter 2.1
“Display of involved components“.
3 Profibus Connect the Profibus interface of the Master CPU to the Profibus
interface of the CP of the Slave station.
4 Configuration Connect the MPI interfaces of both CPUs with a further Profibus
cable/ MPI cable cable and attach the MPI cable you connected to your PG
alternatively to the Profibus connecter of the Master or the Slave
CPU.
Rev A. Final 02.12.2003 61/83

5.2 Installation of the software
STEP7
We will not go into the installation of STEP7 here. The installation takes
place in the familiar Windows environment and is self-explanatory.
Installation of the STEP7 project

Proceed as follows:
Table 5-2
Step No. Action Note / Explanation
1 Open the Step 7 manager.
2 Extract the project via the menu File -> Retrieve... Search for the project
20987807_DP_Comm_CODE_v
10.zip using the browser
function and acknowledge

with OK.
3 Select a directory into which the project files are to After extracting you are
be extracted. asked whether you wish to
open the project with Step 7,
acknowledge this query with
Yes.
4 After opening the project you open the project tree
of the project.
5 Click Station1_Master in the project tree and load If necessary, please ensure
that the correct MPI address
the program onto the Master station with or (2) has been selected.
PLC -> Download.
6 Click Station2_Slave and load the program onto If necessary, please ensure
that the correct MPI address
the Slave station with or PLC -> (4) has been selected.
Download.
Rev A. Final 02.12.2003 62/83

5.3 Configurations of the application
Note
The complete configuration is already contained in the project, the application can
run immediately.
If you are already familiar with the procedure during configuring a Profibus CP as
well as the clock synchronization between Master and Slave you may skip this
chapter.
5.3.1 Configuration of the Profibus CP
The core configuration of this application is the configuration of the Profibus

CP.
Requirement
The following step by step instruction requires an existing STEP7 project, in

which two S7-300 stations, Master and Slave are contained, which already
contain the following hardware components:
Master station:
○ Rack
○ Current Supply
○ CPU 315-2 DP (networked with Profibus)
Slave station:
○ Rack
○ Current Supply
○ CPU 315-2 DP
○ CPU 342-5 (networked with Profibus)
Rev A. Final 02.12.2003 63/83

Procedure for configuring the Profibus CP

Table 5-3
Step Action Result/ Screenshot
1 Open the HW configuration of the
Master station
2 In the hardware catalog you open
the path “Profibus-DP“ ->
“Configured stations“ -> “S7-300 CP
342-5 DP“ -> ”6GK7 342-5DA02-
0XE0“.
3 Click on “V5.0“ and pull the CP to The “Properties - DP Slave” dialog appears.
the Profibus line “DP-Master
System“.
4 Click “Connect“ in order to connect
the Slave with the Profibus Master.
Click "OK".
5 Select the CP.

“Configured stations“ -> “S7-300 CP
342-5 DP“ -> ”6GK7 342-5DA02-
0XE0“ -> ”V5.0“
7 Enter the following modules
successively into the CP slots:
- 3x 64 bytes DI
- 1x 32 bytes DI
- 1x 16 bytes DI Each with “Total consistency“
- 3x 64 bytes DO
- 1x 32 bytes DO
- 1x 16 bytes DO
8 Save and compile the hardware
configuration.
Rev A. Final 02.12.2003 64/83

Attention
! The STEP7 hardware configurator also allows configuring 64 words sized Slave
modules. Due to the maximum consistency frame of 64 bytes for S7-300 CPUs,
such a configuration however is not sensible.
5.3.2 Configuring a clock synchronization
General information on clock synchronization

In order to ensure that the time is identical in all modules of a network,
there is the option of configuring the Master of the network as clock Master.
The time of the Slaves is then adjusted to that of the Master in certain time
intervals.
Procedure during configuration

The following steps must be performed in order for the Slave station to take
on the time of the Master:
Table 5-4
No Action Note / Screenshot
.
Master station
2 Open the “Object properties” dialog
via the context menu of the CPU, and
then the “Diagnostics/Clock” tab.
3 Configure the CPU as clock Master in The Slave time is updated via MPI at time intervals of
the bottom part of the dialog as one second.
shown in the screenshot.
4 Acknowledge the dialog with OK and
save and compile the HW-Config.
Slave station
Rev A. Final 02.12.2003 65/83

6 Open the “Object properties” dialog

via the context menu of the CPU and
then the “Diagnostics/Clock” tab.
7 Configure the CPU as clock Slave in The Slave time is updated via MPI at the time interval
the bottom part of the dialog as configured for the Master.
shown in the screenshot.
8 Acknowledge the dialog with OK and
save and compile the HW-Config.
Rev A. Final 02.12.2003 66/83

6 Operator Control and Monitoring of the Application
Overview
This chapter explains the steps required to familiarize with operating
application. These steps include:
Chap. Chapter Name

6.1 Functions of the user interface
6.2 Modification of data transfer
Preconditions
The application can be commissioned if the following requirements are met:
• Requirements from chapter 5 “Installation of Hardware and Software”.
• All devices are switched on.

• The STEP7 projects are online in the S7-CPUs.
Rev A. Final 02.12.2003 67/83

6.1 Functions of the user interface
The user interface for this application is a variable table respectively for the
Master as well as the Slave station. These variable tables can be visualized
via a PG/PC.
It is used for
• Modifying the data transfer
• Displaying the returned value/status of the communication functions
• Visualizing the net data.
Variable table for Station1_Master

The following figure shows the variable table for the Master station. The
individual entries are explained in the following table.
Anzeige := Display
Statuswert := Status value

Steuerwert := Modify value
Fig. 6-1
Rev A. Final 02.12.2003 68/83

Table 6-1
Address Symbol Function
M22.0 “Start“ Must be TRUE for the application to run.
M22.1 “Stop” Must be FALSE for the application to run.
M22.0 “Reset“ At positive edge the error codes are deleted and
the “Send_Trigger“ bit is reset.
M0.0 “Send_Trigger” Starts a new send job.
MW2 "Length_of_data_record" Defines how many bytes are to be sent.
MW20 “ID” Number for the unique identification of the data
packages to be sent.
MW10 "ret_val_dpwr" Returned value of the dpwr_dat function
MW12 "ret_val_dprd" Returned value of the dprd_dat function
M0.5 "stop_request" Set for errors which require stopping the CPU.
M0.6 "restart_request" Set for errors which require restarting the CPU.
MD4 "timediff_md" Send duration of the last received data package
in milliseconds
M1.7 "Send_acknowledged" If TRUE: Slave has received the complete data

sent by the Master and has sent an
acknowledgement.
DB1.DBW0 The first six words of the data area to be sent.
to DB1.DBW10
DB12.DBW0 to The first six words of the data area to be
DB12.DBW10 received.
Rev A. Final 02.12.2003 69/83

Variable table for Station2_Slave

The following figure shows the variable table for the Slave station. The
function of the individual entries are explained in the subsequent table.
Anzeige := Display
Statuswert := Status value
Steuerwert := Modify value
Fig. 6-2
Rev A. Final 02.12.2003 70/83

Table 6-2
Address Symbol Function
M40.0 “Start“ Must be TRUE for the application to run.
M40.1 “Stop” Must be FALSE for the application to run.
M40.2 “Reset“ At positive edge the error codes are deleted and
the “Send_Trigger“ bit is reset.
M0.0 “Send_Trigger” Starts a new send job.
MW2 "Length_of_data_record" Defines how many bytes are to be sent.
MW34 “ID” Number for the unique identification of the data
packages to be sent.
M10.0 "dp_send_done"
Returned value of the DP_SEND function
M10.1 "dp_send_error"
MW12 "dp_send_status"
M10.2 "dp_recv_done"
M10.3 "dp_ recv _error" Returned value of the DP_RECV function
MW16 "dp_ recv _status"

MB11 "dp_recv_dpstatus"
M0.6 "stop_request" *Set for errors which require stopping the CPU.
M0.7 "restart_request" Set for errors which require restarting the CPU.
MD26 "timediff_md" Send duration of the last received data package
in milliseconds
M1.7 "Send_acknowledged" If TRUE: Master has received the complete data
sent by the Slave and has sent an
acknowledgement.
DB1.DBW0 The first six data words of the data area to be
to DB1.DBW10 sent.
DB12.DBW0 to The first six data words of the data area to be
DB12.DBW10 received.
Rev A. Final 02.12.2003 71/83

6.2 Modification of data transfer
Steps to be performed
You can simulate the process of data transfer following the steps listed
below: An example here is the data transfer from Master to Slave. Data
transfer from Slave to Master is modified in the same way.
Table 6-3
Step Action Note / Explanation
1 Open the variable table VAT1 in the block folder of
the Station1_Master station.
2 Open the variable table VAT2 in the block folder of
the Station1_Slave station.
3 You can now monitor and
Click on the icon with the glasses or in the modify the variable online.
menu on Variable -> Monitor.

4 Check whether the following conditions are true in If not, you modify these
both tables: variables to the given values.
Start = TRUE Enter the desired value in the
Stop = FALSE “Modify value“ column and click
on .
5 For the variable "Length_of_data_record" you If you specify a higher value
enter a value between 1 and 202. than 202, still no more than 202
bytes will be sent.
6 Modify the “Send_Trigger“ variable in the VAT1 of The send procedure is started.
the Master station to the value 1. Before triggering another send
job, the trigger must be reset to
0, as a positive edge is required.
Rev A. Final 02.12.2003 72/83

Results
As soon as the 6 upper steps have been performed, you obtain the
following results:
Table 6-4
Table Result Note / Explanation
VAT1 ID was increased by 1. This is the ID which identifies the
just sent data record.
VAT1 If the error-free reception of the data was If the bit has already been set by a
acknowledged by the Slave, the previous data transfer, a brief
"Send_acknowledged" bit is set to 1. flickering may occur if the bit briefly
takes on the status 0 before being
reset.
VAT1 In case of an error, the "ret_val_dpwr"
function delivers an error code.
VAT2 The returned values of the DP_RECV
function indicate the status of this function.
VAT1 The first six words of the send area of the If you wish to monitor other/several
Master have been filled with random values. data of the send area, add the
respective entries in the VAT.
VAT2 The six words have now been transferred If you wish to monitor other/several
into the receive area of the Slave. data of the receive area, add the
respective entries in the VAT.
VAT2 The variable “timediff” indicates how long Unit: ms
the send job has taken.
Rev A. Final 02.12.2003 73/83

Part C: Program Description
Objectives of Part C:
The purpose of this section is to -
• explain the code details of some core elements of the program to the
reader
• provide the reader with notes on useful extensions.
Requirement
This is not an introduction to the STEP7 language STL. The reader should
be familiar with the basics of this language.
Before reading the description of the code, it may be useful to read the
chapters of Parts A1 and A2.
Contents of part C
7 Explanations on the STEP7 Program..................................................... 75

7.1 Block FC100 “DP_KOMM“ ......................................................................... 75
7.2 Block FC10 “WRITE_TO_SLAVE“ of the Master station ........................... 76
7.3 Block FC20 ”READ_FROM_SLAVE“ of the Master station ....................... 77
7.4 Block FC10 “SEND“ of the Slave station.................................................... 78
7.5 Block FC20 “RECEIVE“ of the Slave station.............................................. 79
8 Changes in the STEP7 Program ............................................................. 79
8.1 Using other Slave modules ........................................................................ 79
9 Glossary.................................................................................................... 82
10 Bibliography ............................................................................................. 83
Rev A. Final 02.12.2003 74/83

7 Explanations on the STEP7 Program
Introduction
This chapter demonstrates and explains the most important core code
sequences for the function elements.
7.1 Block FC100 “DP_KOMM“
The block FC100 “DP_KOMM“ is respectively the central block in the

Master as well as the Slave application. Both blocks differ only little, which
is why only the FC100 of the Master station is discussed here.
The FC100 organizes the entire process of data transmission.
Only if a new send job was requested (via a bit which is set via the variable
table) will new data be generated and sent to the Slave.
The evaluation of the acknowledgement information as well as reading of
Slave data in contrast occurs cyclically.

Program flow chart

The following program flow chart illustrates this process.
Fig. 7-1
Rev A. Final 02.12.2003 75/83

7.2 Block FC10 “WRITE_TO_SLAVE“ of the Master station
Core sequence
The following figure shows an elementary code section from the FC10
“WRITE_TO_SLAVE” block of the Master station. In this core sequence, a
time stamp is generated which is copied into the header of the first send
unit, subsequently the complete send unit is written to a Slave module.
Generate time stamp
Format change
DATE_AND_TIME -> TIME_OF_DAY
Copying the time stamp into the

header of the 1st send unit
Write 1st send unit completely to the Slave

module with the address 100Hex
If the function returns a value not equal to 0, an error has

occurred
Fig. 7-2
Rev A. Final 02.12.2003 76/83

7.3 Block FC20 ”READ_FROM_SLAVE“ of the Master station
Core sequence
The following figure shows the core sequence of the FC20
“READ_FROM_SLAVE“ block of the Master station. In this code sequence,
the data sent by the Slave are read by the Master into a receive mailbox via
an input module and are copied over into the final memory area.
Read data from Slave module with address

100Hex and save in the receive mailbox 1
of the DB11 „RECV_DATA“.
If the function returns a value not equal to 0, an error

has occurred.
Copying the data without header from

the receive mailbox into DB12
"DATA_COMPLETE".
If less than 54 bytes have been sent,

reading is terminated here.
Fig. 7-3
Rev A. Final 02.12.2003 77/83

7.4 Block FC10 “SEND“ of the Slave station
Core sequence
The figure below shows the core sequence of the FC10 “SEND“ block of
the Slave station in which a time stamp is first copied into the header of the
first send unit (network 1).
In network 2 the data of the send mailbox in DB10 are sent to the CP using
the DP function “DP_SEND“.
Generate the time stamp

Format change
DATE_AND_TIME -> TIME_OF_DAY
Copying the time stamp into the

header of the 1st send unit
Complete transfer send mailbox data

in DB10 to the CP with the address
100 Hex
Fig. 7-4
Rev A. Final 02.12.2003 78/83

7.5 Block FC20 “RECEIVE“ of the Slave station
Call of the DP function “DP_RECV”

The figure below illustrates the call of the DP_RECV function in the FC20
”RECEIVE“ block of the Slave station.
The function is parameterized so

that data of the CP with the
address 100 Hex are read and
stored in DB11.
Fig. 7-5
8 Changes in the STEP7 Program
8.1 Using other Slave modules
For the application on hand, 5 slave input modules (3x64 bytes, 1x32 bytes
and 1x16 bytes) and 5 Slave output modules (also 3x64 bytes, 1x32 bytes
and 1x16 bytes) are configured. The size of the input area as well as of the
output area is therefore 240 bytes. These 240 bytes are the maximum
value that can be configured.
If you want to use other Slave modules, changes in the hardware
configuration as well as in several program blocks become necessary.
These changes are explained here step by step.
Rev A. Final 02.12.2003 79/83

Changes for the hardware configuration

For including other Slave modules into the project proceed as follows.
Table 8-1
Step Action Result / Note
1 Open the project „Appl10“.
2 In the project tree click on Open the hardware configuration

“Station1_Master“ and then on
”Hardware“.
3 Click on the CP 342-5 at the The configured Slave modules are
Profibus line. displayed in the bottom window.


“Configured stations“ -> “S7-300
CP 342-5 DP“ -> ”6GK7 342-
5DA02-0XE0“ -> ”V5.0“
5 Delete the Slave modules you A maximum total of 240 input and 240
don’t want to use and replace output bytes can be inserted.
them with others by inserting the
desired modules into a CP slot by
means of drag-and-drop.
6 Save and compile the hardware
configuration.
Attention
! The STEP7 hardware configurator also allows configuring 64 words sized Slave
modules. Due to the maximum consistency frame of 64 bytes for S7-300 CPUs,
such a configuration however is not sensible.
Rev A. Final 02.12.2003 80/83

Changes in the program
In some program blocks changes become necessary if other Slave modules

have been inserted. The respective locations are mentioned here.
Table 8-2
Station Bloc NW Changes to be made
k
Master/Slave UDT2 ----- Adapt the respective array size to the user data,
UDT3 depending on how large your Slave module is. If
UDT5 you are using more than 3 different modules,
generate further UDTs.
Master/Slave DB10 ----- Insert the send/receive units depending on the
DB11 Slave module size.
Master FC10 1 Adjust the module size.
Master FC10 2 If using more than 4 Slave modules for user
data, insert jump labels and supplement the

code analogues to the existing code.
Master FC20 1 If using more than 4 Salve modules for user

data, supplement the code analogues to the
existing code.
Master FC20 5 Supplement evaluation of the ID
Master/Slave FC30 1-5 If using more than 4 Slave modules for user
data, supplement the code analogues to the
existing code.
Slave FC10 NW2 Adjust the DP_SEND call if DB10 is smaller than
240 bytes
Slave FC20 NW1 Adjust the DP_RECV call if DB11 is smaller than
240 bytes
Slave FC20 NW7 Adjust addresses for copying data into the DB12
Slave FC20 NW8 If using more than 4 Slave modules, supplement
code for verifying the IDs.
Rev A. Final 02.12.2003 81/83

9 Glossary
Any-Pointer S7 data type which contains an operand or a pointer on any memory address
and the additional data type of the operand as well as a repetition factor.
CP Communication Processor. Module for communication tasks
Data consistency
Size of the data area which cannot simultaneously be changed is referred to as
consistent data area. A data area which is larger than the consistent data area
can hence be overall falsified.
Services Offered services (data exchange options) of a communication protocol.
DP Decentralized Periphery (DP) refers to input/output modules which are used by

the CPU decentralized. The connection between the automation device and the
distributed I/O is made via the PROFIBUS-DP bus system.
FDL Fieldbus Data Link, the data security layer (layer two of the ISO/OSI reference
model) at Profibus So far, the services SDA (Send-Data with Acknowledge) and
SDN (Send Data with No Acknowledge) have been implemented within
SIMATIC.
ISO/OSI Reference model

Model for communication standards, consisting of 7 layers
1. Physical layer
2. Data connection layer
3. Network layer
4. Transport layer
5. Session layer
6. Display layer
7. Application layer
Protocol A protocol is an agreement, precise down to the bit, between communication

partners in order to perform a certain communication service. The protocol
defines the content structure of the data traffic on the physical line and defines,
for example, the operating mode, connection setup procedure, data security or
the transfer speed.
Station A station is identified by a PROFIBUS address at the PROFIBUS
Rev A. Final 02.12.2003 82/83

10 Bibliography
This list is by no means exhaustive and only gives a selection of
appropriate sources.
Table 10-1
Topic Title
Profibus
\1\ SIMATIC NET NCM S7 für PROFIBUS Handbuch
CP 342-5
\2\ Gerätehandbuch S7-CPs / Teil B1 Beschreibung CP
342-5
STEP7
\3\ Automatisieren mit STEP7 in AWL und SCL
Hans Berger
Publicis MCD Verlag
ISBN 3-89578-113-4
Rev A. Final 02.12.2003 83/83

DP Comm Doku v10 e

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

DP Comm Doku v10 e

Diunggah oleh

Hak Cipta:

Format Tersedia

Application for Communication

Direct Data Exchange between separate

A solution option is presented here as an example which links two stations

Benefits for the user

Rev A. Final 02.12.2003 2/83

Basic solution principle of this application

This documentation informs you about the individual components involved

Notes on further communication examples

Rev A. Final 02.12.2003 3/83

Structure of the document

Rev A. Final 02.12.2003 4/83

Warranty, Liability and Support

We do not accept any liability for the information contained in this

Copyright© 2004 Siemens A&D. It is not permissible to transfer or

For questions about this document please use the following

Rev A. Final 02.12.2003 5/83

Part A1: Application Description................................................................................. 8

3.1 Basic performance data of the hardware without application

3.2 Basic performance data of the S7 protocol ................................................ 31

Rev A. Final 02.12.2003 6/83

5.2 Installation of the software ......................................................................... 62

7.5 Block FC20 “RECEIVE“ of the Slave station.............................................. 79

8 Changes in the STEP7 Program ............................................................. 79

Rev A. Final 02.12.2003 7/83

Part A1: Application Description

1 The Automation Task................................................................................. 9

2.1 Overview of complete solution ................................................................... 12

2.2 Description of functionality of the application ............................................. 13

Rev A. Final 02.12.2003 8/83

1 The Automation Task

Station 1 consists of a CPU 315-2 with DP master system. Station 2 is set

Rev A. Final 02.12.2003 9/83

Specific requirements on the application

Rev A. Final 02.12.2003 10/83

Content of automation solution chapter

Chapter Chapter heading You are informed on…

the focus of the application

Rev A. Final 02.12.2003 11/83

2.1 Overview of complete solution

Display of involved components

Focus of the application

Rev A. Final 02.12.2003 12/83

2.2 Description of functionality of the application

What is the main functionality of the application?

Description of the actions performed by the program

of required size is generated.

Rev A. Final 02.12.2003 13/83

No. Action Explanation

Description of the function elements/ learning units

generator size of the I/O module of the Slave. Furthermore, it generates a

Rev A. Final 02.12.2003 14/83

Advantages of this solution

2.3 Alternative solutions

The application on hand illustrates a solution which only requires one CP

for a communication between two S7 stations via Profibus in order to send

What are the alternatives?

Rev A. Final 02.12.2003 15/83

○ Application of a DP/DP coupler. It is used for interconnecting two

Rev A. Final 02.12.2003 16/83

2.4 Required components

2.4.1 Hardware components

Current Supply PS 307 2A 6ES7307-1BA00-0AA0 Or similar power

e.g. a CPU 314.