Вы находитесь на странице: 1из 121

Application for communication

Master-Slave Communication via Ethernet


with UDP Using Multicast and
Unspecified Connections
UDP Multicast Communication

Preamble

Requirement
Particularly in conveyor and transport systems it is frequently required that
a data record can be sent quickly and simultaneously from a transport unit
(master) to many loosely connected units (slaves) to ensure that actions
can be processed quasi-synchronously. This ensures that all units perform
one identical action simultaneously.
In systems in which the number of units may vary, it is additionally required
to be able to change the number during runtime. Mostly, this also implies
the requirement to be able to set any unit as new master during runtime.

This application shows possibilities with which communication protocol an


acknowledged data transfer to a number of bus stations (stations) which is
variable and dynamically changeable during runtime can be realized via
Industrial Ethernet.
Copyright © Siemens AG 2005 All rights reserved
20983558_UDP_Multicast_DOKU_v10_e

Possible solutions
SIMATIC supports a variety of relevant protocols for different bus systems.
UDP (see Glossary), specifically developed for connectionless
communication, offers the best conditions particularly for the solution
described in this example and requires only insignificant programming effort
to realize the specific requirements.

Example application
The example of 3 stations is used to show how 3 units operating
independently of one another can be connected in such a way that the
requirements can be met. The following is listed:
• A changeable master-slave relationship with basis “Industrial Ethernet”
realized in the program.
• Simultaneous sending of data from one master to many slaves by using
“multicast communication”.
• Secure data transfer due to an acknowledged data transfer realized in
the program (implementation of a “level7 acknowledgement” in the
program).

Benefit for the user


The completely prepared and executable application software as well as
this documentation provide the following benefit:
• Acquisition of background knowledge on the topics
○ UDP connection

Rev. A - Endgültig 20.04.2004 2/121


UDP Multicast Communication

○ Multicast communication
○ Unspecified connections
○ Application of the SEND/RECEIVE interfaces with the blocks
AG_SEND / AG_RECV.
• Use of program modules which can be used as base element in other
applications independently of the overall application, e.g. error analysis.
• Saving of time during the creation of internal developments due to easy
use of the function elements employed in the example application.

Basic solution approach of this application


The application requires different hardware and software components.
Some of them are included in the delivery of this application, others have to
be provided by you.
Copyright © Siemens AG 2005 All rights reserved
20983558_UDP_Multicast_DOKU_v10_e

Fig. 0-1
This documentation informs you on the components concerned and how
these components are connected with regard to hardware and software.

Rev. A - Endgültig 20.04.2004 3/121


UDP Multicast Communication

Foreword

Structure of the document


The documentation of this application is divided into the following main
parts.
Part Description Note
A1 Part A1 provides you with a general overview of
the application. You get to know 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 provides a detailed description of the You can skip this part if
function processes of the hardware and you only want to test the
Copyright © Siemens AG 2005 All rights reserved

software components involved. It is only application first using the


20983558_UDP_Multicast_DOKU_v10_e

necessary to read this part if you are interested step by step instructions.
in the detailed processes and the interaction of
the solution components.
B Part B leads you step by step through setup
and commissioning of the application on the
basis of the software included in the delivery
and introduces the necessary core
configuration steps.
C Part C is of interest if you want to take the
software and expand or adapt it to your setup.

Rev. A - Endgültig 20.04.2004 4/121


UDP Multicast Communication

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
Copyright © Siemens AG 2005 All rights reserved

life, body or health. The above provisions does not imply a change in the
20983558_UDP_Multicast_DOKU_v10_e

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 - Endgültig 20.04.2004 5/121


UDP Multicast Communication

Table of Contents
Part A1: Application Description................................................................................. 8
1 The Automation Task................................................................................. 9
1.1 Technological task / overview ...................................................................... 9
1.2 Schematic overview on control level .......................................................... 10
1.3 Specific requirements on the application ................................................... 11
2 Automation Solution................................................................................ 12
2.1 Overview of the overall solution ................................................................. 13
2.2 Description of the functionalities of the application .................................... 14
2.3 Alternative solutions ................................................................................... 16
2.4 Required components ................................................................................ 17
Copyright © Siemens AG 2005 All rights reserved
20983558_UDP_Multicast_DOKU_v10_e

3 Basic Performance Data.......................................................................... 21


3.1 Basic performance data of the hardware without application
components................................................................................................ 22
3.2 Basic performance data of UDP................................................................. 23
3.3 Basic performance data of the overall application ..................................... 23
Part A2: Function Mechanisms ................................................................................. 25
4 Function Mechanisms ............................................................................. 26
4.1 Data flow model in this HW configuration .................................................. 27
4.2 Basic principle of a communication task .................................................... 29
4.3 Physical bus medium ................................................................................. 30
4.4 Mechanisms of UDP .................................................................................. 32
4.5 User interface of UDP ................................................................................ 37
4.6 Application structure in this example.......................................................... 43
4.7 Function modules in the application software ............................................ 50
Part B: Installation of the Example Application....................................................... 67
5 Installation of Hardware and Software................................................... 68
5.1 Hardware configuration .............................................................................. 69
5.2 Installation of the software ......................................................................... 69
5.3 Configurations of the application................................................................ 70
6 Operator Control and Monitoring of the Application ............................ 76
6.1 Functions of the user interface................................................................... 77

Rev. A - Endgültig 20.04.2004 6/121


UDP Multicast Communication

6.2 Control of the data transfer ........................................................................ 79


6.3 Simulation of transfer errors....................................................................... 81
6.4 System parameters / system measurements ............................................. 82
6.5 Diagnostic functions ................................................................................... 82
Part C: Program Description ..................................................................................... 87
7 Explanations on the STEP7 Program..................................................... 88
7.1 Pointer generator: FC21 “GenPointerOnDB” ............................................. 89
7.2 Error control: FB33 “Error Control”............................................................. 91
7.3 Manager: FB1 “Manager”........................................................................... 94
7.4 Send cycle manager: FB10 “SendCycleManager”..................................... 99
7.5 Receive cycle manager: FB11 “ReceiveCycleManager”.......................... 105
7.6 Slave manager: FB2 “SlaveManager”...................................................... 110
8 Changes in the STEP7 Program ........................................................... 115
Copyright © Siemens AG 2005 All rights reserved
20983558_UDP_Multicast_DOKU_v10_e

8.1 Changing the net data record length........................................................ 116


8.2 Adding a further station ............................................................................ 117
9 Glossary.................................................................................................. 119
10 Bibliography ........................................................................................... 121

Rev. A - Endgültig 20.04.2004 7/121


UDP Multicast Communication

Part A1: Application Description

Objectives of Part A1
Part A1 of this document provides the reader with information on
• the automation task
• a possible solution
• the performance of the overall application.

Content of Part A1

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


1.1 Technological task / overview ...................................................................... 9
1.2 Schematic overview on control level .......................................................... 10
Copyright © Siemens AG 2005 All rights reserved
20983558_UDP_Multicast_DOKU_v10_e

1.3 Specific requirements on the application ................................................... 11


2 Automation Solution................................................................................ 12
2.1 Overview of the overall solution ................................................................. 13
2.2 Description of the functionalities of the application .................................... 14
2.3 Alternative solutions ................................................................................... 16
2.4 Required components ................................................................................ 17
3 Basic Performance Data.......................................................................... 21
3.1 Basic performance data of the hardware without application
components................................................................................................ 22
3.2 Basic performance data of UDP................................................................. 23
3.3 Basic performance data of the overall application ..................................... 23

Rev. A - Endgültig 20.04.2004 8/121


UDP Multicast Communication

1 The Automation Task

Classification
This chapter describes the automation task. It forms the basis for the
automation solution described in this document.

1.1 Technological task / overview

Particularly in conveyor and transport systems, it is frequently required to


quickly and simultaneously send one data record to a large number of
connected units.
In free-moving transport units which are connected via a linear bus
structure, a quasi-synchronous reaction can be initiated with only one
message.
This message could e.g. contain the information to turn all units to the left
by 15 degrees.
Copyright © Siemens AG 2005 All rights reserved
20983558_UDP_Multicast_DOKU_v10_e

Fig. 1-1 Technological task

A combination of transport units often consists of variably combined units.


Thus, it is to be possible during runtime to disconnect a unit from the
combination of transport units and to e.g. newly connect two other units.
These requirements imply the following characteristics:
• The combination of transport units features a guiding transport unit
controlling the entire combination of transport units by means of data
messages.
• The guidance can be transferred from one transport unit to another
transport unit.
• All units except the guiding unit acknowledge the commands.

Rev. A - Endgültig 20.04.2004 9/121


UDP Multicast Communication

1.2 Schematic overview on control level

This application shows how the requirements listed above can be realized
with SIMATIC components.
It is shown how data transfer to a number of bus stations (stations)
changeable during runtime can be realized. One station will take the part of
the guiding transport unit (referred to as master in the following), while the
other bus stations take on the part of the trailers (slaves).
In order to ensure that the data transfer is acknowledged, each slave
responds to a request of the master.
In addition, the application ensures that there is a maximum of one guiding
unit (master) within the combination of transport units at any time.
The communication structure on the control level is – starting from the
technological task – structured as follows:
Copyright © Siemens AG 2005 All rights reserved
20983558_UDP_Multicast_DOKU_v10_e

Fig. 1-2 Schematic structure

Rev. A - Endgültig 20.04.2004 10/121


UDP Multicast Communication

1.3 Specific requirements on the application

• Transfer of user-specific data from one master to all slaves using a


“multicast message”
• Each slave acknowledges the reception of a message to the master via
an “unspecified connection”
• Uniform software package for master and slaves
• Efficient transfer of the data
• Adding further stations has to be possible at any time without having to
modify already existing stations
• Each station can become guiding station during operation (master-slave
switchover)
• Check of all slave acknowledgements by the master
• Provision of a universal, reusable user interface for the core function
“acknowledged multicast communication”
Copyright © Siemens AG 2005 All rights reserved
20983558_UDP_Multicast_DOKU_v10_e

• Proprietary message runtime calculation.

Rev. A - Endgültig 20.04.2004 11/121


UDP Multicast Communication

2 Automation Solution

Introduction
This chapter provides you with detailed information on how this application
solves the automation task described in chapter 1. It illustrates what the
application can perform, which submodules it contains and how they work.
Its functions are 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 the chapter Automation Solution


Table 2-1
Chapter Chapter heading You are informed on…
No
Copyright © Siemens AG 2005 All rights reserved

2.1 Overview of the overall solution ... the components involved in the application.
20983558_UDP_Multicast_DOKU_v10_e

2.2 Description of the functionalities of ... how the application operates and the implemented
the application core elements.
2.3 Alternative solutions ... further possibilities to realize this functionality.
2.4 Required components ... the hardware and software components used
in this application.

Rev. A - Endgültig 20.04.2004 12/121


UDP Multicast Communication

2.1 Overview of the overall solution

Display of the components involved


The figure below shows the hardware setup of the example application:
Copyright © Siemens AG 2005 All rights reserved
20983558_UDP_Multicast_DOKU_v10_e

Fig. 2-1
Each station contains an identical program and each program is roughly
divided into the following function elements:
• Manager
• Send cycle manager
• Slave manager
• Receive cycle manager
• Error control.

Rev. A - Endgültig 20.04.2004 13/121


UDP Multicast Communication

2.2 Description of the functionalities of the application

What are the solution elements of the application?


• Data transfer via “multicast message” between master and all assigned
slaves.
• Acknowledgement of the data reception by the slaves via an
“unspecified connection” (unspecified UDP connection).
• Automatic establishment of the master-slave relationship.
• Monitoring of the slaves by cyclic sending of keep alive messages.
• Logging of occurring communication errors.
• Free configurability of each station as master or slave.
Copyright © Siemens AG 2005 All rights reserved

The figure below shows the core principles of the application on schematic
20983558_UDP_Multicast_DOKU_v10_e

level:

Fig. 2-2 Schematic sequence

Rev. A - Endgültig 20.04.2004 14/121


UDP Multicast Communication

Sequence of selected core functionalities


The following tables describe the actions performed by the application to
comply with selected core functionalities:
1. Establishment of the master-slave relationship:

Table 2-2
Step Action Explanation
1 The master sends a keep alive A keep alive message causes a slave to
message to the slaves. react with a simple response.
2 Each slave sends a response The address of the master is contained in
message to the master. the keep alive message.
Note:
The address information corresponds to the
port and IP address.
3 The master enters the The address of the slave is contained in the
responses in a slave response message.
management structure.
Copyright © Siemens AG 2005 All rights reserved
20983558_UDP_Multicast_DOKU_v10_e

2. Sending user data from the master to all slaves:

Table 2-3
Step Action Explanation
1 The master has user data The data simulator generates a sequence of
generated with a data simulator. characters.
2 The user data are sent to the The sending of multicast messages is
slaves with a multicast performed by the function element “send
message. cycle manager”.
3 The slaves store the user data
of the master in a data area
provided for this purpose and
acknowledge the reception of
the data.
4 The master receives the If a slave contained in the slave
acknowledgements of the management structure does not respond,
slaves. this is indicated by the master station and
any send mode is stopped until a
reinitialization was performed.
A watchdog timer is used to check the
maximum message runtime.
Note:
Part A2 provides information on how the
message runtime is determined.

Rev. A - Endgültig 20.04.2004 15/121


UDP Multicast Communication

Advantages of this solution


• Reusability of the software modules due to modular program structure
• Each program package contains the master as well as the slave
functionality
• Almost identical configuration of the individual stations
• Transfer of small to medium-sized data amounts (up to 2 KB) possible
• Short message runtime due to use of the quick UDP (in case of a mean
number of slaves)
• Dynamic expansion requiring only insignificant effort possible at any time
• Secure transfer due to acknowledgement routine
• Easy error analysis.

2.3 Alternative solutions


Copyright © Siemens AG 2005 All rights reserved
20983558_UDP_Multicast_DOKU_v10_e

2.3.1 Alternative hardware components

All stations can be set up as SIMATIC S7-300 or S7-400.


The solution with S7-300 components was chosen for this application.

2.3.2 Alternative bus systems

Alternatively, Profibus can be used as transmission medium.

Table 2-4 Comparison


Criterion Profibus Industrial Ethernet
Deterministics Is ensured Not available (see chapter 4.3.1)
Number 126 254 (due to the use of a multicast circuit)
slaves
Baud rate 12 Mbit/sec 1 Gbit/sec
Message size Max. 236 bytes * Max. 2048 bytes (minus header data)
* Since FDL (SDN) has to be used in order to be able to meet the requirements

This transmission medium was selected for the example application


because of the higher data throughput with Industrial Ethernet.

2.3.3 Alternative protocols

If Industrial Ethernet is used, UDP has to be used, since it is the only


protocol supporting a multicast connection.

Rev. A - Endgültig 20.04.2004 16/121


UDP Multicast Communication

If Profibus is selected as bus medium, the FDL (SDN) protocol has to be


used; yet, this limits the maximum message length to 236 bytes. In
addition, it is necessary to consider dummies during Profibus address
assignment to enable to dynamically add further slaves.

2.4 Required components

2.4.1 Hardware components

The following hardware components are required to realize the application.

Table 2-5 S7–300 components used


Component MLFB / Order number Note
PS 307 5A 6ES7307-1EA00-0AA0 Any PS with sufficient power specifications can be
used.
3x CPU 315-2 DP 6ES7315-2AG10-0AB0 Firmware V 2.0, or similar CPU
Copyright © Siemens AG 2005 All rights reserved

3x CP 343-1 6GK7343-1EX20-0XE0 CPs 6GK7343-1EX11-xxxx or later versions can


20983558_UDP_Multicast_DOKU_v10_e

also be used.
3x Micro Memory 6ES7953-8LM00-0AA0 Minimum 64k MMC
Card
Standard travel Each multiport repeater (TwistedPair – RJ45
connection) can be used.

Table 2-6 PG components used


Component MLFB / Order number Note
Power PG 6ES7750-2CA52-4FB4 See Configurator in A&D Mall
On Board CP 5611 N/A Part of PG hardware.

Rev. A - Endgültig 20.04.2004 17/121


UDP Multicast Communication

2.4.2 Software components

The following software components are required to realize this application.

Table 2-7: Application components used


Component MLFB / Order number Note
Step 7 V 5.2 6ES7810-4CC06-0YX0
NCM S7 Industrial N/A Part of the Step 7 SW.
Ethernet
SCL V5.1 6ES7811-1CC04-0YX0 Recommended for adaptation of maximum number
of stations.

2.4.3 Application software components

The application consists of the project


Copyright © Siemens AG 2005 All rights reserved

“20983558_UDP_Multicast_CODE_v10.zip” and includes the following S7-


20983558_UDP_Multicast_DOKU_v10_e

stations:
• SIMATIC 300 station 1
• SIMATIC 300 station 2
• SIMATIC 300 station 3

Fig. 2-3

The programs in the S7-300 stations are identical. Merely DB50


“AddressDB” which contains the IP and port address of a station is
different.

Rev. A - Endgültig 20.04.2004 18/121


UDP Multicast Communication

The table below contains a brief description of the function elements of the
application.
A detailed function description is available in Part A2.

Tasks of the central function elements


The following figure roughly displays the interaction of the most important
function elements.
Copyright © Siemens AG 2005 All rights reserved
20983558_UDP_Multicast_DOKU_v10_e

Fig. 2-4
The following table summarizes the tasks:

Table 2-8 Function elements


No. Function elements Tasks
1 Manager • Master/slave control
• Triggering a keep alive message
• Parameter supply of the send and of the receive cycle manager
• Check whether the station may be operated as master.
Corresponds to a check whether another station in the multicast
circuit is already master.
2 Send cycle manager • Transfer of one multicast message to all slaves
• Reception of the response messages of the slaves
• Triggering of the slave management in the slave manager
• Check of the maximum message runtime
3 Slave manager • Management of a maximum of 20 slaves
• Establishment of the master-slave relationship
• Storage of the data received by the slaves
• Consistency check of the slaves
4 Receive cycle manager • Reception of multicast messages
• Generation of a response message
• Sending a response message to a master

Rev. A - Endgültig 20.04.2004 19/121


UDP Multicast Communication

Effort required for programming/configuration


• Assuming average SIMATIC knowledge, an estimated 5-10 man-days
are required to implement a comparable application.
• To become familiar with the application described in this document, an
introductory period of 1-2 man-days should be estimated.
• 3-4 man-days are to be expected in order to realize in-depth error
control.
It is required that the person realizing this error control has familiarized
with the application on hand.
• The configuration effort is insignificant, since it is restricted to the
connection configuration in NETPro.
• When using standardized programming units, the SIMATIC basic
package already includes all engineering tools which necessarily have to
be used.
Copyright © Siemens AG 2005 All rights reserved
20983558_UDP_Multicast_DOKU_v10_e

Rev. A - Endgültig 20.04.2004 20/121


UDP Multicast Communication

3 Basic Performance Data

Introduction
This chapter provides an overview of the performance of this application
and the components used.
Content of the chapter Basic Performance Data
Table 3-1
Chapter Chapter heading You are informed on…
No
3.1 Basic performance data of the ... the basic performance data to be observed with
hardware without application regard to the hardware.
components
3.2 Basic performance data of UDP ... the basic performance data to be observed with
regard to the protocol.
3.3 Basic performance data of the ... the basic performance data of the overall
overall application application.
Copyright © Siemens AG 2005 All rights reserved
20983558_UDP_Multicast_DOKU_v10_e

Rev. A - Endgültig 20.04.2004 21/121


UDP Multicast Communication

3.1 Basic performance data of the hardware without application


components

The parameters used in this application are marked by

Basic performance data of Industrial Ethernet


Table 3-2
Criterion Basic performance data Additional note
Transmission rate 10 Mbit/sec half / full duplex A baud rate of 100Mbauds in full
100 Mbit/sec half / full duplex duplex is set in this application.

11 Mbit/sec (in the wireless


area)
Transmission principle CSMA/CD / CSMA/CA Standardized in IEEE 802.3 and IEEE
802.11
Length of the network (1.5m - >100 km) The maximum length of the network
Copyright © Siemens AG 2005 All rights reserved

can be achieved by the use of optical


20983558_UDP_Multicast_DOKU_v10_e

components.
Physical bus characteristics • Co- or tri-axial network (up
used to 10 Mbauds)
• Twisted Pair (RJ45)
• Optical fiber
Number of stations on the bus Up to 1024 at one collision The number of stations can be
domain. expanded by connecting different
domains via routers or switches.
Usable protocols / stacks SIMATIC supports The selection of the protocols is
• ISO stack with the restricted by the CPs.
protocols:
○ ISO transport
○ S7 protocol
as well as:
• TCP stack with the
protocols:
○ UDP
○ TCP
○ RFC 1006
○ PPP
○ FTP
○ SMTP
○ S7 protocol on the basis
of RFC 1006

Rev. A - Endgültig 20.04.2004 22/121


UDP Multicast Communication

3.2 Basic performance data of UDP

Table 3-3
Criterion Basic performance data Additional note
Definition RFC 768 Independent of
manufacturer
Transmission medium Cable, optical fiber, radio
Transmission rate Depending on physical network
characteristics, up to 1 Gbit
Connectable devices and bus • Host-to-host Permissible methods:
access methods
• Broadcast • CSMA/CD
• Multicast • CSMA/CA
Acknowledgement The protocol only acknowledges the UDP is located on level 4
successful sending of the data into the of the ISO/OSI reference
network, not the arrival of the data in the model.
destination CP. Thus, the arrival of the
Consequence: The S7 user program has data is not acknowledged
Copyright © Siemens AG 2005 All rights reserved

to ensure consistency check and data automatically.


20983558_UDP_Multicast_DOKU_v10_e

editing.
Data volume Max. 2Kbytes

3.3 Basic performance data of the overall application

Table 3-4
Criterion Basic performance data
Program size 14334 bytes Main memory (with 200 bytes of
user data)
Maximum cycle time Approx. 6 ms On average approximately 3ms
Criterion Basic performance data Additional note
Max. data transmission rate 100 Mbit/sec full duplex Default: 100 Mbit/sec full duplex
(Ethernet)
Max. message length Approx. 2 Kbytes The size is limited by UDP.
Consider that also the header
information has to be contained in
the 2Kbytes.
Max. number of connections 2 connections Since each station can be master
as well as slave, each station
must feature a multicast
connection (for master operation)
and an unspecified connection
(for slave operation).
Message runtime based on the See below
described hardware

Rev. A - Endgültig 20.04.2004 23/121


UDP Multicast Communication

Criterion Basic performance data


Number of supported stations in this Up to 20 Note:
application The number of supported stations
can be increased by adaptation
(see chapter 8.2).
Direction of data transfer • Master Æ slave Each slave only responds upon
request, it is thus passive

Considering the message runtime


Due to the transfer characteristics in Industrial Ethernet, the message
runtime increases with the number of slaves and the size of the user data.
If the network load exceeds 50%, a communication suitable for the
application is hardly possible.
A decoupling of the collision domains has to be strived for in order to
reduce the network load. This can e.g. be achieved by the use of “switches”
or “bridges”.
Copyright © Siemens AG 2005 All rights reserved
20983558_UDP_Multicast_DOKU_v10_e

The figure below visualizes the relation between user data and message
runtime in 2 slaves.

Fig. 3-1
The figure illustrates a linear relation between user data length and
message runtime.

Rev. A - Endgültig 20.04.2004 24/121


UDP Multicast Communication

Part A2: Function Mechanisms

Objectives of Part A2
Part A2 of this document provides the reader with the following:
• Explanation of all integrated function elements
• Description of the reusable components
• Respective background knowledge.

Content of Part A2

4 Function Mechanisms ............................................................................. 26


4.1 Data flow model in this HW configuration .................................................. 27
4.2 Basic principle of a communication task .................................................... 29
4.3 Physical bus medium ................................................................................. 30
Copyright © Siemens AG 2005 All rights reserved
20983558_UDP_Multicast_DOKU_v10_e

4.4 Mechanisms of UDP .................................................................................. 32


4.5 User interface of UDP ................................................................................ 37
4.6 Application structure in this example.......................................................... 43
4.7 Function modules in the application software ............................................ 50

Rev. A - Endgültig 20.04.2004 25/121


UDP Multicast Communication

4 Function Mechanisms

What will you find here?


You will find information on
• the solution structure of the overall application and of the individual
elements
• the bus and protocol used
• the function elements used and their functioning
• the general procedure for communication tasks with
AG_SEND/AG_RECV.
For further details please refer to Part C.

What can you do with it?


Copyright © Siemens AG 2005 All rights reserved

Basically, this application can be used immediately. The installation


20983558_UDP_Multicast_DOKU_v10_e

instructions tell you how to start it without reading this chapter. If however,
you want to e.g. modify certain modules of the application to meet your
requirements, in-depth information is necessary.

Structure chapter 4
Below, the structure of chapter 4 is shown for information.

Table 4-1
Chapter Chapter heading You are informed on…
4.1 Data flow model in this HW configuration ... the path the data take within the
application.
4.2 Components of the communication task ... the structural design of the
application case.
4.3 Physical bus medium ... the bus medium used.
4.4 Mechanisms of UDP ... details of the operating principle
and methods of UDP
4.5 User interface of UDP ... how UDP can be used with
SIMATIC.
4.6 Application structure in this example ... the modules used.
4.7 Function elements in the application software ... the mode of operation of the
individual function blocks (partial
functions).

Rev. A - Endgültig 20.04.2004 26/121


UDP Multicast Communication

4.1 Data flow model in this HW configuration

The diagram below shows the data flow model of the application from a
point of view focusing on SIMATIC components.
Copyright © Siemens AG 2005 All rights reserved
20983558_UDP_Multicast_DOKU_v10_e

Fig. 4-1

Note
Only 1 slave is shown to provide greater clarity.

Rev. A - Endgültig 20.04.2004 27/121


UDP Multicast Communication

Description of the data flow model shown above


Table 4-2
No. Description
1 After the master has generated the message to be sent, the data area to be sent is
transferred to the user interface (AG_SEND) using an S7 Any pointer.
With ACT:=TRUE, the data are sent to the CP via the P bus (process data bus).
With a multicast message, this CP sends the data to the CPs of the slaves in
accordance with the connection configuration.
2 As soon as the AG_RECV block in the slave has signaled the successful reception
of the data, the data are analyzed in the user program of the slave. In this process,
the master request (response to keep alive, storing of data of the master, sending
back data of the slave) as well as its IP and port address are determined.
After executing the master request, IP and port address of the master are written
to the beginning of the acknowledgement message. The destination of the
message is communicated to the CP with ACT:=TRUE.
The CP packs the data in a UDP frame packet and sends it to the CP of the
master station as defined in the connection configuration.
Copyright © Siemens AG 2005 All rights reserved
20983558_UDP_Multicast_DOKU_v10_e

The AG_RECV block in the master user program then signals the reception of the
acknowledgement of the slave via the NDR bit.

Note
The following is not described:
The master station evaluates the acknowledgement message of the slave and
enters the data in the slave management structure.
After all slaves have replied, the next message can be sent.

Rev. A - Endgültig 20.04.2004 28/121


UDP Multicast Communication

4.2 Basic principle of a communication task

Introduction
In simplified terms, a communication task can be described as follows:
“Transfer my 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 will show you a general approach which has to
be worked out depending on the selectivity of the task, the selection of the
communication path / network, carrier protocol, user modules, etc.

Display of the structure components


The following figure roughly displays the individual layers and the modules
of the association between master and slave.
Copyright © Siemens AG 2005 All rights reserved
20983558_UDP_Multicast_DOKU_v10_e

Fig. 4-2

Description of the structure components


The communication consists of the following components:
• The stations are connected physically via the bus
• A specific bus protocol is used to standardize the data transfer
• Program modules transferring the user data to the user interface are
required for the actual data transfer. In this process, user and protocol
data have to be composed depending on the protocol used. As a packet,
user and protocol data constitute the data to be transferred.
The following sections describe the individual layers and possible
implementations. The description is limited to the bus media, protocols and
user interfaces used in the application.

Rev. A - Endgültig 20.04.2004 29/121


UDP Multicast Communication

4.3 Physical bus medium

Due to the use of suitable communications processors, a SIMATIC control


system supports a large range of bus systems:
• MPI, made available by the CPU interface,
• Industrial Ethernet and
• PROFIBUS.

Industrial Ethernet, which is used in the application, will be dealt with in


detail in the following.

4.3.1 Industrial Ethernet network


Copyright © Siemens AG 2005 All rights reserved

Introduction
20983558_UDP_Multicast_DOKU_v10_e

Industrial Ethernet developed from “Alto Ethernet” which marks the


beginning of the development of today’s network standard Ethernet.
Since then, numerous companies such as 3COM, IBM and Cisco have
advanced the development of the hardware standard Ethernet.

Basic hardware
The basic Ethernet version was designed as a tri-axial or co-axial network.
This hardware concept enabled line structures with an expansion of up to
2500m and a data transmission rate of up to 10MBit/sec.
Over the years these limits could be exceeded due to new developments
such as e.g. fiber optic technology. In view of increasing demands on data
throughput and availability, the concept of tri-axial networks was no longer
continued. Today's networks are designed with twisted pair technology in
star configuration using RJ45 connections and usually operate with baud
rates of 100 MBit/sec.
Measures providing protection from electromagnetic interferences were
taken in order to enable to use Ethernet also in the industrial environment.
These measures comprised e.g. more robust plugs as well as thicker cable
sheathings. “Industrial Ethernet” developed.
Current developments focus on wireless networking via Wireless Ethernet.
In the foreseeable future, radio technology will reach the transmission rates
of today’s cable-based networks while the transmission rates in the cables
will be further increased until reaching the gigabit range.

Rev. A - Endgültig 20.04.2004 30/121


UDP Multicast Communication

The CSMA access procedure


Unlike Profibus, there is no managing of a send authorization (Token) in
Ethernet. All stations connected to the bus have equal rights to send
messages. To prevent problems during data communication, the Ethernet
system uses an access procedure called CSMA
(CarrierSensMultipleAccess). This enables unlimited access to Ethernet
(MultipleAccess) as soon as there is no data traffic (CarrierSens).
CSMA/CD (with CollisionDetection), which detects data collisions, is usually
used for cable-based Ethernet whereas CSMA/CA (with Collision
Avoidance) is used for Wireless Ethernet.
This document does not provide further information on the method of this
principle.
Due to the access method, Ethernet does not enable to transfer data in a
defined period of time (lacking deterministics).

Protocols on Industrial Ethernet


Copyright © Siemens AG 2005 All rights reserved

Over the years, a variety of protocols has been developed in the course of
20983558_UDP_Multicast_DOKU_v10_e

Ethernet development. These protocols have partly been transferred to


Ethernet from other networks. The most popular example is probably the
TCP/IP protocol.
Aside from the TCP/IP protocol, the ISO Transport protocol and the
TF/MAP protocol have been developed in automation engineering; yet,
these protocols were not successful since they are very specific and partly
specifically designed for Siemens products.
Nowadays, many applications are realized with TCP, UDP or the RFC 1006
protocol (based on TCP) which is derived from ISO Transport.
Within the SIMATIC S7, the S7 protocol based on the ISO Transport
protocol or the TCP stack has established itself.

Rev. A - Endgültig 20.04.2004 31/121


UDP Multicast Communication

4.4 Mechanisms of UDP

Introduction
UDP (UserDatagramProtocol) was implemented for performance reasons.
It offers multiple possibilities of use due to its slim message header.
In addition, almost every component in Industrial Ethernet supports UDP.
The unacknowledged transfer of the data has unfavorable consequences.

4.4.1 Classification of UDP in the ISO-OSI reference model

The ISO-OSI reference model describes the structure of different frame


structures in layers in order to send data from A to B. In general, each layer
features an individual data structure.
In each layer transition, the size of the data packet to be sent is increased
by management information.
Copyright © Siemens AG 2005 All rights reserved
20983558_UDP_Multicast_DOKU_v10_e

Due to the fact that UDP is located on layer 4 (transport layer), the size of
the data packet to be sent is only increased by minimum management
information which affects the data throughput.
The figure below shows the classification of UDP within the SIMATIC
environment in the ISO-OSI reference model.

Fig. 4-3 ISO-OSI layer model

Rev. A - Endgültig 20.04.2004 32/121


UDP Multicast Communication

4.4.2 Main properties of UDP

Introduction
The following sections provide a general introduction to UDP followed by a
description of its application in the SIMATIC world.

General requirements on UDP


UDP was introduced in order to enable to send data from A to B quickly
and in an uncomplicated way.
As a member of the TCP/IP protocol family, UDP is also based on the IP
layer (layer 3). Thus, the receiver of the data is addressed using IP
addresses.
Yet, this functionality is not sufficient considering that actually not the
stations are to be connected but their user programs or processes.
Copyright © Siemens AG 2005 All rights reserved
20983558_UDP_Multicast_DOKU_v10_e

Fig. 4-4

The TCP/IP layer model provides the transport layer (layer 4) for this
functionality.
UDP is such a transport protocol.

Application of the ports


On multitasking operating systems (e.g. WinNT), several processes can run
simultaneously and each process can make several services available.
They should be addressable separately.
To solve this problem, special interfaces for the data communication – the
ports – are defined in the TCP/IP as well as in UDP.

Socket
Together with the IP address of the station, the port number forms a socket
defined as unique address of the user program in the entire network.
Any service of a process on a station within a network can be addressed
with a socket.

Rev. A - Endgültig 20.04.2004 33/121


UDP Multicast Communication

Scope of UDP
Since it is required to transfer data quickly, UDP only makes basic functions
available. That way, data can be exchanged between communicating
parties with minimum effort. UDP does not include security mechanisms as
available in TCP/IP.

Fig. 4-5

In addition, UDP is
• connectionless and
Copyright © Siemens AG 2005 All rights reserved
20983558_UDP_Multicast_DOKU_v10_e

• not stream-oriented, i.e. data packets are sent as a whole.

Disadvantages of UDP
The lacking security mechanisms cause disadvantages which have to be
taken into consideration during use.
• There is no renewed sending of lost data packets.
• Data packets with incorrect checksum are rejected and not newly
requested.
• Multiple deliveries of individual packets are possible due to the
properties of the IP protocol as subordinate protocol.
• The arrival sequence of the data at the receiver cannot be predicted.

4.4.3 Using UDP in the SIMATIC world

Introduction
In the SIMATIC world, it is not possible to create several processes or user
programs running quasi “simultaneously” on one CPU. Still, several
communication jobs can be triggered simultaneously. An assignment has to
be performed via the connection configuration in order to ensure a unique
addressing.

Rev. A - Endgültig 20.04.2004 34/121


UDP Multicast Communication

Connection configuration
The IP and the port address of the service of the Simatic station is set using
NetPro and stored in specific resources of the CPU or the CP by Step7.
Depending on the automation system, so-called “connection resources” are
required.
This document does not provide any additional information on “connection
resources”.

Possibilities with regard to configuration


The following connection types can be configured for UDP:

Table 4-3
Type of connection Description
Specified UDP connection • Local station and connection partner are fixed configured.
(point-to-point)
• The connection partner can be located inside or outside the
STEP7 project.
Copyright © Siemens AG 2005 All rights reserved

Unspecified UDP connection • Only the local station is defined via connection configuration in
20983558_UDP_Multicast_DOKU_v10_e

the individual STEP7 project.


• The connection partner is addressed via the port and IP
address during the block call.
Broadcast connection • An active station sends a message to all other stations.
Multicast connection • An active station sends a message to a fixed configured group
of stations. The group is specified by an IP address band
(multicast circuit).

User interface of UDP


UDP operates with the SEND/RECEIVE interface “AG_SEND/AG_RECV”
made available by SIMATIC.
It is a bidirectional service for the transfer of medium-sized amounts of data
between two stations.

Data quantity
UDP enables the data transfer between SIMATIC stations from 1 byte to 2
Kbytes.

Applicable bus systems


Due to its specifications, UDP can only be used with Industrial Ethernet.

Systems supporting UDP


The following systems support UDP:
• S7 controls including the communications processors available for
Industrial Ethernet

Rev. A - Endgültig 20.04.2004 35/121


UDP Multicast Communication

• PC and other third-party systems with respective interfaces and driver


equipment.
Copyright © Siemens AG 2005 All rights reserved
20983558_UDP_Multicast_DOKU_v10_e

Rev. A - Endgültig 20.04.2004 36/121


UDP Multicast Communication

4.5 User interface of UDP

Step7 makes the SEND/RECEIVE interface with the


“AG_SEND/AG_RECV” blocks available for UDP.
They will be described in the following.

The communication blocks of the SEND/RECEIVE interface


The FC blocks of the SEND / RECEIVE interface are available for the
communication job in the user program.

Table 4-4
FCs S7-300 S7-400 Description
AG_SEND yes yes The block transfers user data from a specified user data area of
the CPU in the sending station to the Industrial Ethernet CP for
transfer.
AG_RECV yes yes The block transfers the user data received by the Industrial
Copyright © Siemens AG 2005 All rights reserved

Ethernet CP of the receiving station into a specified user data


20983558_UDP_Multicast_DOKU_v10_e

area of the CPU.

Notes
• A communication job spans several CPU cycles.
• The blocks AG_SEND and AG_RECV can be used for Industrial Ethernet as
well as for PROFIBUS.
• For the later S7-300 Industrial Ethernet CPs, version V3.0 or later, the blocks
AG_SEND and AG_RECV are used exclusively also for the transfer of long
data records. The blocks AG_LSEND and AG_LRECV are not used in the later
versions. Further details and downloads are available on the Customer Support
site, Entry ID 8797900.
• This user program uses the new block versions for AG_SEND and AG_RECV
of version V3.0 or later. In the S7-300, the blocks are also compatible with older
module versions of the CP 343-1.
• Further information on the new block versions is available on the Customer
Support site, Entry IDs 7806643 and 187699.

Block FC5 “AG_SEND”


• The FC block AG_SEND consistently transfers data from a data area of
the CPU to the Industrial Ethernet CP of the sending station. The CP
forwards the data according to the connection configuration or
parameters on the block.
• As soon as the CP in the sending station has transferred all data, it
considers the execution error-free and signals it with DONE ==1.

Rev. A - Endgültig 20.04.2004 37/121


UDP Multicast Communication

Table 4-5 Formal parameters of FC5 “AG_SEND”


Parameter Type Note
ACT BOOL Control parameter to activate the data exchange at positive
edge:
Copyright © Siemens AG 2005 All rights reserved


20983558_UDP_Multicast_DOKU_v10_e

ACT = 1: LEN bytes are sent from the data area specified
with the parameter SEND.
• ACT = 0: The status displays DONE, ERROR and
STATUS are updated.
ID INT Connection number as defined in the connection
configuration.
LADDR WORD Module start address of the CP as defined in the connection
configuration.
SEND ANY Data area to be sent.
LEN INT Number of bytes to be sent with the send job.
DONE BOOL Status parameter indicating whether the job was executed
without errors. (1
ERROR BOOL Signals if an error has occurred during executing the job. (1
STATUS WORD This parameter provides detailed information on job execution.
(1

(1 The parameters DONE, ERROR and STATUS form the block status display and are
always to be considered as a whole for error analysis. Tables for status display analysis are
included in the documentation on NCM Part 1 for PROFIBUS or in the online help on blocks
of STEP 7.

Block FC6 “AG_RECV”


• The block “AG_RECV” transfers data sent by the sending station from
the CP of the receiving station into the data area of the CPU.
• Execution without error is signaled with NDR ==1, if the CP was able to
successfully write the entire data area into the destination data area via
Industrial Ethernet.

Rev. A - Endgültig 20.04.2004 38/121


UDP Multicast Communication

Table 4-6 Formal parameters of FC6 “AG_RECV”


Parameter Type Description
ID INT Connection number as defined in the connection
configuration.
Copyright © Siemens AG 2005 All rights reserved

LADDR WORD Module start address of the CP as defined in the


20983558_UDP_Multicast_DOKU_v10_e

connection configuration.
RECV ANY Destination data area
LEN BYTE Number of bytes transferred into the buffer of the CP.
NDR BOOL Status parameter indicating that new data have been
transferred. (1
ERROR BOOL Signals if an error has occurred during executing the job.
(1

STATUS WORD This parameter provides detailed information on job


execution. (1
(1 The parameters NDR, ERROR and STATUS form the status display of the block and are
always to be considered together for error analysis. Tables for status display analysis are
included in the documentation on NCM Part 1 for PROFIBUS or in the online help on blocks
of STEP 7.

Programming and configuration guidelines


The most important guidelines on using the blocks AG_SEND and
AG_RECV are summarized below:
AG_SEND:
• The parameter ACT must only be ACT = 1 for the duration of one cycle for
triggering a new send job. In the further block calls, the block call is to be
initiated with the parameter ACT = 0 in order to update the status display.
• The parameter LEN must not be larger than the data length specified in the
source area SEND.

AG_RECV:
• The block AG_RECV has to be called in each program cycle.

Rev. A - Endgültig 20.04.2004 39/121


UDP Multicast Communication

• The destination area RECV of the AG_ RECV must not be smaller than
the parameter LEN of the associated AG_SEND.
• After an NDR = 1, the data have to be transferred from the destination
area SEND into an individual user data area, since they are overwritten
with the data read next if this is not done.
Detailed information on the connection configuration, on the use of the
blocks AG_SEND and AG_RECV and on error analysis is available in the
SIMATIC NET NCM S7 FOR PROFIBUS manual Volume 1 and 2.
Copyright © Siemens AG 2005 All rights reserved
20983558_UDP_Multicast_DOKU_v10_e

Rev. A - Endgültig 20.04.2004 40/121


Copyright © Siemens AG 2005 All rights reserved
20983558_UDP_Multicast_DOKU_v10_e

UDP Multicast Communication

Representation of the sequence / process model


The figure below graphically shows the chronological order with which a data record is sent through the different objects consisting of HW
and SW components during the call of AG_SEND and AG-RECV using UDP.

Fig. 4-6

Rev. A - Endgültig 20.04.2004 41/121


UDP Multicast Communication

The following table describes the sequential procedure of the data transfer
shown in the figure above.

Table 4-7
No. Description
1 The positive edge at the input ACT of the “AG_SEND” transmits the job for a data
transfer to the CP. The send data are written from the source data area into the CP
and the data transfer is started.
2 The receive CP reads and transfers the data to the operating system.
The send CP quasi-synchronously acknowledges the successful sending of the
data.
Thus, not the reception of the data in the receive CP but the sending of the data of
the send CP is acknowledged!
3 The operating system of the sending station detects the positive acknowledgement
of the send CP. When calling “AG_SEND” with ACT ==0, a DONE==1 is displayed
at the output parameter of AG_SEND; due to this, the user program detects the
successful execution of the last send procedure.
4 By calling the AG_RECV block on the receiving side, the operating system of the
CPU writes the read data from the buffer of the CP into the destination area of the
CPU specified at the parameter RECV. The output parameter NDR is set.

Note
The fact that a message is segmented into blocks of 512 bytes in the SIMATIC
world is not displayed in the sequence model in order to provide greater clarity.
Yet, the user is not concerned with that.

Rev. A - Endgültig 20.04.2004 42/121


UDP Multicast Communication

4.6 Application structure in this example

Introduction
This chapter describes the structural design of the application on hand.
The rough display of the data flow model is followed by a detailed
representation during master and slave operation.

4.6.1 Representation of the data flow model from software view (rough)

The figure below shows a rough overview of the basic data flow model.

Fig. 4-7

Explanation on the data flow model


Table 4-8
Step Action
1 At a positive edge, the master sends simulated user data (SendDB) to all
slaves with a multicast message.
2 The slaves create a data packet (AckDB) from the received data (RcvDB) with
which they acknowledge the reception of the data.

Rev. A - Endgültig 20.04.2004 43/121


UDP Multicast Communication

Step Action
3 The master enters the received acknowledgements in a slave management
structure.
Attention:
The assignment of the slave acknowledgement buffers in the slave
management structure is determined in an initialization process.

4.6.2 Dynamic assignment of the slaves to the slave management buffers

The slave management structure has to be set up dynamically to ensure


that the number of slaves can be changed during runtime. Within this
structure, a buffer in the slave management structure is assigned to each
slave.
This assignment is performed in an initialization process.
In this process, the slaves are addressed via a “keep alive message” and
the slave management structure is set up in the order of the incoming
responses of the slaves.
Due to this procedure, each initialization process may result in a different
slave management structure, since the response sequence may differ due
to the CSMA/CD principle of Industrial Ethernet (see chapter 4.3.1).
The figure below describes the initialization process:

Fig. 4-8

Rev. A - Endgültig 20.04.2004 44/121


UDP Multicast Communication

Table 4-9
Step Action
1 As soon as a station is configured as master, the send cycle manager starts an
initialization procedure.
2 Within this initialization procedure, a keep alive message is sent to all slaves.
3, 5, m The slaves respond in an arbitrary chronological order (“multiple access”
principle of the IE specification, chapter 4.3.1).
The send cycle manager waits for as many response messages as slaves are
specified. The master has to be informed on the number of the slaves
beforehand (the further parameters are listed in chapter 4.7).
4, 6, m+1 Each time a response message arrives, the following happens:
The response message is stored in a slave management structure using the
slave manager. Aside from other data, IP and port address of the just
responding slave is assigned to each buffer in the slave management
structure.

The described scenario has the following structure:


Table 4-10

Chronological response Response from Assigned buffer


sequence
3 Slave 2 1
5 Slave n 2
m Slave 1 3

In all future send cycles the responses of the slaves are entered in the
respective buffer in which the IP address stored in the buffer corresponds
to the IP address of the responding slave.
Comment:
The detailed setup of the individual data structures is available in chapter 7
for Part C.
Note
For a detailed description of slave management, please refer to chapters 4.7.8 and
4.7.

Rev. A - Endgültig 20.04.2004 45/121


UDP Multicast Communication

4.6.3 Representation of the data flow model in the function elements

The interaction of the central function elements is illustrated below. The


following function elements are dealt with:
• Send cycle manager
• Receive cycle manager
• Data simulator
• Header generator
• Message runtime monitoring (watchdog timer)
• Slave manager.
An overview picture is shown to illustrate which central function elements
are connected between master and slave station; subsequently, the data
flow in these function elements is described.

Overview picture

Fig. 4-9

Rev. A - Endgültig 20.04.2004 46/121


UDP Multicast Communication

Master: Send cycle manager


The master functionality is basically executed by the send cycle manager
(FB10 “SendCycleManager”):

Fig. 4-10
Explanation on the data flow model:

Table 4-11
Step Action
1 The Manager generates user data with the Data simulator.
2 After transferring all parameters to the SendCycleManager, a multicast
message is generated with the Header generator and the address stored in
the AddressDB.
3 The AG_SEND block sends the data to the slaves.
4 As soon as the AG_SEND block sets the DONE bit, the SendCycleManager
changes to the receiving status. With AG_RECV, the SendCycleManager
waits for incoming acknowledgement messages.
5 After the AG_RECV block has set the NDR bit, the acknowledgement message
is checked by the slave manager whether it is valid and entered in the
respective slave buffer.

Rev. A - Endgültig 20.04.2004 47/121


UDP Multicast Communication

Step Action
6 As long as not exactly as many acknowledgements were received as slaves
should be available, AG_RECV calls are performed cyclically.
Step 5 is repeated for each new acknowledgement message.
7 After all slaves have been acquired, the block changes to the sending status
and waits for the next job.
In addition, an error analysis supplies the error/status interface of the block.
The following errors are identified:
• Time out (no logging; only display) by means of watchdog timer.
• Error during AG_SEND/AG_RECV; these errors are logged via FB33
“Error Control” by the fact that the error status of the respective block is
stored in a protocol data block (this block is not displayed to provide
greater clarity).
• The acknowledgement of a slave is invalid (no logging; only display).
As soon as the SendCycleManager sets an error bit, the manager no
longer calls this block. This bit is a “global” error bit. The application stops
the send mode.

Slave: Receive cycle manager


The slave functionality is basically determined by the receive cycle
manager (FB11 “ReceiveCycleManager”):

Fig. 4-11

Rev. A - Endgültig 20.04.2004 48/121


UDP Multicast Communication

Explanation on the data flow model:

Table 4-12
Step Action
1 The Manager calls the ReceiveCycleManager (see overview picture).
2 After data were successfully received with the AG_RECV block, an
acknowledgement message is generated.
If the message is a PUT-DATA request (master wants to send data to slaves),
the master data are stored in a data block of the slave.
Additionally, the block changes to the sending status.
3 The generated acknowledgement message, which contains the port and IP
address of the master in the first 6 bytes, is stored in an acknowledgement
data block.
Note:
Since the acknowledgement message is to be sent via an unspecified
connection, the destination has to be entered in the message to be sent (see
chapter 4.4.3).
4 With the AG_SEND block, the generated acknowledgement message is sent to
the master using the unspecified connection.
5 After the AG_ SEND block has been completed successfully, the block is set
back to the receiving status. The block is thus ready to receive the next
message.

Error control only takes place in case of occuring AG_SEND/AG_RECV


errors. Other errors are not handled! The detected errors are stored in a
protocol DB (for additional information, see chapter 4.7.7).

Rev. A - Endgültig 20.04.2004 49/121


UDP Multicast Communication

4.7 Function modules in the application software

Content of the chapter


This chapter provides you with an overview of the integrated function
elements.
The block hierarchies illustrate how the blocks or function elements are
connected to one another.
To ensure that the representation is clear, only the blocks and function
elements in the area of the respective function element are displayed.
For a detailed description of the main elements please refer to the code
level described in Part C or chapter 7.
This chapter includes the following subchapters:

Table 4-13
Chap. Title Main task
4.7.1 Manager Controls the application.
4.7.2 Send cycle manager Coordinates the sending of multicast messages.
4.7.3 Receive cycle manager Receives a multicast message and sends an
acknowledgement.
4.7.4 Pointer generator Generates an Any pointer to a data block.
4.7.5 Data simulator Fills a data block with simulated user data.
4.7.6 Header generator Uses the input data to generate a header and adds it to a
given data block.
4.7.7 Error control Logs errors occurring during AG_SEND / AG_RECV calls
determines an error reaction.
4.7.8 Slave manager Manages the slave responses.

Rev. A - Endgültig 20.04.2004 50/121


UDP Multicast Communication

4.7.1 Manager

Block hierarchy

Fig. 4-12

Task specification
FB1 “Manager” has the following tasks:
General tasks:
• Execution and controlling of the application
• Supplying the interfaces of the subordinate function elements.
Special tasks:
• Check whether a station may function as master (only one master is
permitted in the multicast circuit)
• Triggering in order to generate simulated user data
• Creation of a keep alive request
• Message runtime measurement.

Rev. A - Endgültig 20.04.2004 51/121


UDP Multicast Communication

Status diagram

Fig. 4-13 Status graph of the manager

Solution approach
If the station operates as “slave”, FB1 “Manager” only calls the receive
cycle manager realizing the slave functionality.
However, if the station is configured as “master”, the manager waits for a
send request which occurs at the latest by a keep alive trigger event. After
that, the send cycle manager is called which sends the data to the slaves
and checks the slave responses.
If several send requests are active simultaneously, the manager prioritizes
the send requests as follows:
• PUT request
• GET request
• Keep alive

Furthermore, a start time and an end time are determined for the “message
runtime measurement”.
In order to do this, the start time at the time of the send request and the end
time at the time of the arrival of the end flag of the send cycle manager are
taken.

Notes
• As long as the send cycle manager has not reported the end of the data
transfer, the manager won’t process any further send requests.
• If the send cycle manager reports an error, the manager stops the send mode.
The manager only restarts the send mode if the user triggers a reset signal.

Rev. A - Endgültig 20.04.2004 52/121


UDP Multicast Communication

User interface

bInResetSend bIOMaster
byInKAInterval In/ bIOPutData
nInTimeOut FB1 "Manager" Out bIOGetData
nInSlaves bIOAutomaticSend

Fig. 4-14

Table 4-14
Name Type Explanation
bInResetSend Bool Sets manager and send cycle manager to a defined
status.
Reinitializes the slave management structure with the
next keep alive message.
byInKAInterval Byte Keep alive interval
nInTimeOut Int Time for watchdog timer. If not all acknowledgement
messages of the slaves have arrived at the master after
this period of time, the master reports an error and stops
the send mode.
nInSlaves Int Number of slaves
bIOMaster Bool Station is to run as master
bIOPutData Bool Data are to be sent
bIOGetData Bool Data are to be read by the slaves
bIOAutomaticSend Bool Controlling the application:
The requests (PUT or GET) are sent again and again.

Rev. A - Endgültig 20.04.2004 53/121


UDP Multicast Communication

4.7.2 Send cycle manager

Block hierarchy

Fig. 4-15

Task specification
FB10 “SendCycleManager” has the following tasks:
• Triggering in order to compose a multicast message
• Sending the message
• Receiving the acknowledgement messages
• Having acknowledgement messages checked and stored
• Monitoring the specified timeout
• Triggering the error recording.

Rev. A - Endgültig 20.04.2004 54/121


UDP Multicast Communication

Status diagram

Fig. 4-16 Status graph of the send cycle manager

Solution approach
The send cycle manager changes to a “send data” status as soon as there
is a request.
It generates a multicast message by using the “header generator” to store
the necessary header and user data in a data block.
The generated message is sent to the slaves with the block FC5
“AG_SEND”.
As soon as the data have been sent successfully, the acknowledgements
of the slaves are waited for. This spans several cycles so that the send
cycle manager does not send any further multicast messages during this
period of time.
If the block is not in the “block is available” status, the watchdog timer is
checked. If the timer has elapsed, an error bit is set and the block signals
the end of processing. The same process takes place in case of error
messages of AG_SEND/AG_RECV blocks (the latter are logged).
The slave responses are checked and stored with the slave manager. As
soon as all slaves have responded, the send cycle manager sets the “End”
bit. It is thus available for the next message request.

Rev. A - Endgültig 20.04.2004 55/121


UDP Multicast Communication

User interface

anyIOData FB 10 bOutFinished
bOutError
"SendCycleManager"
nInSlaves wOutErrorCode
nInTimeOut bIOPutData
In/
bIOGetData
Out
bIOKeepAlive

Fig. 4-17

Table 4-15
Name Type Explanation
anyInData Any Any pointer to the user data
bInResetSend Bool Sets send cycle manager to a defined status.
Reinitializes the slave management structure in the next
keep alive message.
nInSlaves Int Number of slaves
nInTimeOut Int Time for watchdog timer
bOutFinished Bool If true, processing is finished
bOutError Bool If true, an error has occurred
wOutErrorCode Word Error codes:
1: An invalid argument was transferred; e.g. incorrect
number of slaves
2: Slave management structure is inconsistent (e.g. an IP
exists twice)
3: The monitoring time was exceeded
4: An error has occurred during AG_SEND/AG_RECV
calls
bIOPutData Bool Data are to be sent
bIOGetData Bool Data are to be read by the slaves
bIOKeepAlive Bool Keep alive request

Rev. A - Endgültig 20.04.2004 56/121


UDP Multicast Communication

4.7.3 Receive cycle manager

Block hierarchy

Fig. 4-18

Task specification
FB11 “ReceiveCycleManager” performs the tasks of a slave:
• Receiving a multicast message
• Executing the request (FB12 “TreatData”)
• Generating an acknowledgement message (FB12 “TreatData”)
• Sending the acknowledgement message
• Triggering the error recording.

Rev. A - Endgültig 20.04.2004 57/121


UDP Multicast Communication

Status diagram

Fig. 4-19 Status graph of the receive cycle manager

Solution approach
The receive cycle manager is only called by FB1 “Manager” if the station
operates as slave. This function element, which is realized in FB11
“ReceiveCycleManager”, remains in the receiving status as long as it does
not receive data.
If the block FC6 “AG_RECV” signals the reception of data, the block
changes to the “send response” status. Data in the block FB12 “TreatData”
are analyzed and processed according to the master request. Depending
on the message type, the procedure is as follows:
• PUT request: The master user data are transferred into DB6
“SlaveData”.
• GET request: The slave writes the number of received messages as well
as the keep alive messages contained in these messages into the
acknowledgement DB (DB5 “AckDB”).
• Keep alive request: The slave sends an “empty” response message
back to DB5 “AckDB”.
In addition, the port and IP address of the master are written into the
acknowledgement DB. Port and IP address are encoded in the header of
the multicast message (see chapter 7.4 or 7.5).
The message is sent with the block FC5 “AG_SEND” which uses the
unspecified connection. As soon as the block FC5 “AG_SEND” signals the
end of the transfer, the receive cycle manager changes back to the
receiving status.
Errors occurring during AG_SEND/AG_RECV calls are logged but not
reported, since the master reports such errors indirectly (at the latest the
watchdog timer determines that a slave has not responded).

Rev. A - Endgültig 20.04.2004 58/121


UDP Multicast Communication

User interface

nInRcvDBNr
FB11
byInKAInterval
"ReceiveCycleManager"

Fig. 4-20

Table 4-16
Name Type Explanation
nInRcvDBNr Int Number of the receive block to be used.
byInKAInterval Byte Keep alive interval is required in order to restart the timer used to
determine whether a station may become master or not.

4.7.4 Pointer generator

Block hierarchy

Fig. 4-21

Task specification
Any pointers have to be used to enable dynamic addressing of data blocks;
they specify the data block number, the start address and the length of the
data area to be addressed.
Since the creation of Any pointers is rather complex although they are used
quite frequently, a pointer generator has been implemented.

Solution approach
The pointer generator creates an Any pointer for a given data block
number; this Any pointer points to the start of the data block and its overall
length.
In the application, this block is mainly used to address the send and receive
buffers.

User interface

nInDBNr FC21
anyOutPointer
"GenPointerOnDB"

Fig. 4-22

Rev. A - Endgültig 20.04.2004 59/121


UDP Multicast Communication

Table 4-17
Name Type Explanation
nInDBNr Int Input parameter for the DB number.
Note:
The DB must be available!
anyOutPointer Any pointer Any pointer to the data block.

4.7.5 Data simulator

Block hierarchy

Fig. 4-23

Task specification
The function element “data simulator” generates the user data to be
transferred on the basis of the target data pointer generated by the pointer
generator and the given data length.

Solution approach
FB 28 “Data_Simulator_S7_300” was created to realize this functionality. It
automatically generates the required data area.
In order to do this, the function block starts by moving the starting point of
the data by the header size. Subsequently, the data are written into the
destination area in ASCII characters in alphabetical order from “A” to “Z”.
When the letter “Z” is reached, the procedure starts again with “A”.

User interface

anyInDestination FB 28
wInLength "Data_Simulator
byInHeaderLength _S7_300"

Fig. 4-24

Table 4-18
Name Type Explanation
anyInDestination Any pointer Destination data area to which the data is to be
written.
wInLength Word Length of the data area

Rev. A - Endgültig 20.04.2004 60/121


UDP Multicast Communication

Name Type Explanation


byInHeaderLength Byte Length of the area to be reserved for the header
data.
Attention:
For this simulation, this parameter is set to 0 to
simulate a data area containing only user data.

4.7.6 Header generator

Block hierarchy

Fig. 4-25

Task specification
In addition to the user data, control information has to be available to
ensure that the slaves can identify the specific request.
Furthermore, port and IP address of the master have to be communicated
to the slave so that it can send back an acknowledgement message via the
unspecified connection.
The structure of the header is as follows:

Fig. 4-26
(For further details on the header structure, please refer to chapter 7.44
under “required data structures”.)

Solution approach
Based on the given input parameters, the header generator generates a
message header with a defined structure.
The generated structure is written to the beginning of a defined data area.

Rev. A - Endgültig 20.04.2004 61/121


UDP Multicast Communication

User interface

anyInDestination
FB 21 bOutDone
byInTelType
"Headergenerator" nOutStatus
tInSource

Fig. 4-27

Table 4-19
Name Type Explanation
anyInDestination Any pointer Data block to be modified
byInType Byte Type of the master request
1: PUT
2: GET
3: Keep alive
tInSource “JobHeader” Port and IP address
bOutDone Bool DONE bit
nOutStatus Int Status of the header generation

4.7.7 Error control

Block hierarchy

Fig. 4-28

Task specification
The function element error control performs the following tasks:
• Logging of an error occurring during AG_SEND/AG_RECV calls with the
respective status (protocol DB).
• Check whether the identified error status is known and whether it can be
reacted to (reaction DB).
• Determination of the configured error reaction and transmission of this
reaction to the calling function.

Rev. A - Endgültig 20.04.2004 62/121


UDP Multicast Communication

Solution approach
The function element “error control” is positioned after each AG_SEND /
AG_RECV call. This ensures that occurring errors are analyzed and logged
immediately. Furthermore, an error reaction is output.
A global protocol data block is available to log the errors. This data block
contains an array of data structures which enable to trace when and where
the error occurred.
In order to determine an error reaction, 2 further error reaction data blocks
were implemented which allocate a reaction to each status of an AG_SEND
or AG_RECV block.
The function element “error control” is used to search the corresponding
status in the respective error reaction data block and to output the reaction
defined in this block.
This enables the user to configure reactions (e.g. restart or stop) to specific
types of errors.
For further information on this function element please refer to chapter 7.2.

User interface

bInError
wInStatus
wInERR_DB
bOutRestart
wInPROT_DB
FB 33
bInSend_Receive bOutStop
"Error_Control"
cInBlockType
nInBlockNumber
nInID1
nInID2

Fig. 4-29

Table 4-20
Name Type Explanation
bInError bool If TRUE, the block is activated
wInStatus Word Status of AG_SEND/AG_RECV to be stored
wInERR_DB Word Data block with the configured reactions, e.g.:
• Restart
• Stop
wInPROT_DB Word Data block containing the last 20 errors
bInSend_Receive Bool Specifies whether an error occurred during an AG_SEND
or an AG_RECV call.
TRUE: AG_RECV
FALSE: AG_SEND
cInBlockType Char Optional: Specification indicating in which block type the
error occurred (call from FB, FC etc.)

Rev. A - Endgültig 20.04.2004 63/121


UDP Multicast Communication

Name Type Explanation


nInBlocknumber Int Optional: Specification indicating from which block
number BSEND/BRCV was called
nInID1 Int Optional: Available number
in this application, the local ID is stored here.
nInID2 Int Optional: Available number
in this application, the R_ID is stored here.
bOutRestart Bool Indicates whether the job is to be repeated.
This is not evaluated in this application.
bOutStop Bool Indicates whether the job is to be stopped (reset).
This is not evaluated in this application.

4.7.8 Slave manager

Block hierarchy

Fig. 4-30

Task specification
The slave manager has the following tasks:
• Entering a slave in the slave management structure
• Consistency check of the slave management structure
• Managing the slave responses within one send cycle
• Data storage of the slave data.

Solution approach
The slave management structure is integrated in the instance DB of the
slave manager as array. This leads to an encapsulation of all slave data.
Due to partly extensive array operations, the slave manager was
implemented in SCL.

Rev. A - Endgültig 20.04.2004 64/121


UDP Multicast Communication

Managing a slave requires the following structure:

Fig. 4-31
The slave manager has only two basic status:
• Initialization
• Check
The table below shows the tasks of the status:

Table 4-21
Status Tasks
Initialization • Entering the slave port/IP address in the slave management
structure
• Consistency check of the slave management structure (after
detection of all slaves)
Check • Checking the slave responses within one send cycle
• Selecting the corresponding slave in the slave management structure
• Making available the user data of a slave (only valid between Get
and keep alive request, since slave user data are deleted in a keep
alive)

For further information on the implementation of this function element


please refer to chapter 7.6.

User interface

anyInAckDB bOutFinished
bInInit bOutError
bInGetData FB 2
wOutStatus
nInSlaves "SlaveManager"
tOutSlaveData
nInDataNr

Fig. 4-32

Rev. A - Endgültig 20.04.2004 65/121


UDP Multicast Communication

Table 4-22
Name Type Explanation
anyInAckDB Any Any pointer to the acknowledgement data block
bInInit Bool Initialize slave management structure.
The initialization flag must be pending until
bOutFinished or bOutError == TRUE.
bInGetData Bool The parameter tOutSlaveData is filled with the
data of the slave “nInDataNr”.
This corresponds to the data of the slave stored
in the “nInDataNr” buffer.
nInSlaves Int Number of slaves
nInDataNr Int Only valid in connection with
“bInGetData”==TRUE.
Indicates the slave buffer of which the data are
to be returned.
bOutFinished Bool Indicates that operations were performed.
bOutError Bool If True, an error has occurred
wOutStatus Word If “bOutError” == TRUE, the following error
codes exist:
1: an invalid argument was transferred; e.g.
incorrect number of slaves
2: Checking the slave response has shown that
an error has occurred (incorrect IP address or
error in the slave management structure)
3: Slave management structure is inconsistent
(e.g. an IP exists twice)
tOutSlaveData structSlaveData Slave data of the “nInDataNr” buffer.

Note
To read out data of a slave, proceed as follows:
• Set the parameters bInInit to FALSE and bInGetData to TRUE
• Enter the index of the slave in the slave management structure in nInDataNr
• The parameter tOutSlaveData now contains the slave data.

Attention:
• Slave data should not be read out in the initialization status!
• To solve the problem of the “slave-buffer / slave-IP” assignment (see chapter
4.6.1), you should first read out the data of all slaves once and store them in a
separate table structure. This enables you to store the slave-buffer ÅÆ slave-
IP assignment.

Rev. A - Endgültig 20.04.2004 66/121


UDP Multicast Communication

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 example application including all HW and SW
components
• Necessary configuration steps
• Operation the application.

Content of Part B

5 Installation of Hardware and Software................................................... 68


5.1 Hardware configuration .............................................................................. 69
5.2 Installation of the software ......................................................................... 69
5.3 Configurations of the application................................................................ 70
6 Operator Control and Monitoring of the Application ............................ 76
6.1 Functions of the user interface................................................................... 77
6.2 Control of the data transfer ........................................................................ 79
6.3 Simulation of transfer errors....................................................................... 81
6.4 System parameters / system measurements ............................................. 82
6.5 Diagnostic functions ................................................................................... 82

Rev. A - Endgültig 20.04.2004 67/121


UDP Multicast Communication

5 Installation of Hardware and Software

Introduction
This chapter describes how to commission the application.

Content of the chapter Installation of Hardware and Software


Table 5-1
Chapter Chapter heading You are informed on…
No
5.1 Hardware configuration ... how to install the hardware components.
5.2 Installation of the software ... how to start up the software.
5.3 Configurations of the application ... how to configure this application.

Rev. A - Endgültig 20.04.2004 68/121


UDP Multicast Communication

5.1 Hardware configuration

The components of the hardware configuration are available in chapter 2.1


“Overview of the overall solution”.

To install the hardware proceed as described in the table below:


Note
! Switch on the power supply only after the last step.

Table 5-2
Step Focus Action
1 Station 1 Install station 1 as shown in the figure in chapter 2.1.

2 Station 2 Install station 2 as shown in the figure in chapter 2.1.

3 Station 2 Install station 3 as shown in the figure in chapter 2.1.


4 Industrial Ethernet Connect the Industrial Ethernet CPs of the stations with a travel or a
similar device.
6 MPI Connect all MPI interfaces of the CPUs with a bus cable and connect
this cable to the PG.

5.2 Installation of the software

STEP7
At this point, we will not go further into the installation of STEP7. The
installation takes place in the familiar Windows environment and is self-
explanatory.

Installation of the STEP7 project


If you want to use the project with a previously installed bus, the addresses
assigned by the project have to be considered and adapted if necessary:

Table 5-3
Station Module MPI address Profibus address IP address
CPU 315-2DP 2 (not relevant) -
Station 1
CP 343-1 3 - 140.80.0.1
CPU 315-2DP 4 2 (not relevant) -
Station 2
CP 343-1 5 - 140.80.0.2
Station 2 CPU 315-2DP 6 2 (not relevant) -

Rev. A - Endgültig 20.04.2004 69/121


UDP Multicast Communication

Station Module MPI address Profibus address IP address


CP 343-1 7 - 140.80.0.3
PG CP 1613 8 - -

Proceed as follows:

Table 5-4
Step No. Instruction Note / Explanation
1 Open the Step 7 Manager.
2 Retrieve the project via the menu File > Search for the project
Retrieve... 20983558_UDP_Multicast_
CODE_v10.zip using the
Note: browser function and
Parts of the application were implemented in SCL. confirm with OK.
3 Select a directory into which the project files are to be
retrieved and open the project.
4 Open the project tree of the project.
5 In the project tree, click Station1 and load the If necessary, make sure that
program into Station1 with PLC -> Download. the correct MPI address (2) is
selected.
6 In the project tree, click Station2 and load the If necessary, make sure that
program into Station2 with PLC -> Download. the correct MPI address (4) is
selected.
7 In the project tree, click Station3 and load the If necessary, make sure that
program into Station3 with PLC -> Download. the correct MPI address (6) is
selected.

Note
If STEP 7 cannot download a station, it is possible that the MPI addresses are not
correctly configured. Disconnect Ethernet and MPI cable from the stations and plug
the MPI cable of the PG into the MPI connector of the CPU to be loaded. Repeat
the download process for this station. Then reconnect the stations using the
cables.

5.3 Configurations of the application

Note
The complete configuration is already contained in the project, the application can
be executed immediately.
If you are already familiar with the configuration of UDP connections (multicast and
unspecified), you can skip this chapter.

Rev. A - Endgültig 20.04.2004 70/121


UDP Multicast Communication

5.3.1 Configuration of multicast and unspecified connections

General information on UDP connections


UDP connections describe communication paths between different
SIMATIC communication components. A UDP connection uses UDP. The
SEND/RECEIVE interface with AG_SEND/AG_RECV is used as
communications service.

Characteristic features of the multicast connection


To establish a multicast connection, it is required that a local port (receiving
data) as well as a remote port (sending data) are specified.
Since the application requires to be able to reconfigure a slave to a master
during operation, local and remote port address have to be identical. Only
this fact enables each station of a multicast circuit to send messages to all
slaves as master with one single multicast connection.
If this was not the case, it would be necessary to reconfigure or adapt the
program; this would require to stop the CPUs!
The figure below illustrates the situations:
• Local and remote port address are not identical:

Fig. 5-1
With this configuration, it is not possible to send data from station B to
station A and from station A to station B with the same configured
connection, since the port addresses are not identical.
• Local and remote port address are identical:

Fig. 5-2

Rev. A - Endgültig 20.04.2004 71/121


UDP Multicast Communication

In this configuration, local and remote port address are identical. It is thus
possible to send multicast messages from station A to station B as well as
from station B to station A with a configured connection.

Configuration of the required connections


To configure UDP connections, proceed as follows:

Table 5-5
No Instruction Note / Picture
.
1
Open NetPro by selecting in the
SIMATIC Manager.

2 In the network view, the 2 networks are


indicated in red (MPI) and green
(Industrial Ethernet). The controls
connected in the project are linked to the The connection table lists all connections configured for the
networks with their interfaces. By respective control.
selecting a CPU, in this case the CPU
315-2DP of station 1, the connection table
appears in the lower half of the window.
3 The first two connections are used as an Alternatively, the menu item Insert > New Connection or the
example to illustrate the principal shortcut CTRL + N can be used.
sequence of this connection configuration.
The connection dialog is started by

clicking “Insert New Connection” .

Rev. A - Endgültig 20.04.2004 72/121


UDP Multicast Communication

4 All communication partners contained in


the project are visible in the upper part of
the window.
The first connection is to be an
unspecified connection, since the partner
(the master station) is only determined
during runtime.
The lower part of the window shows the
connection type , here a UDP connection.
Click OK or Apply to open the properties
window of the connection.

5 The properties window is divided into 2


relevant parts.
The Local Connection End Point is
specified in the “General” part. The
connection type and the module
addresses to be specified on AG_SEND/
AG_RECV are displayed.

Rev. A - Endgültig 20.04.2004 73/121


UDP Multicast Communication

The addresses have to be entered in


“Adressen” [addresses].

The Address Details enable to divide


Local and Partner (remote) into 2 logical
parts.
• Local/remote IP
• Local/remote port
To enable to specify the address
during runtime, the “Adressvergabe
am Baustein” [address assignment on
block] box has to be activated.

Confirm by clicking “OK”.


6 The second connection is to be a
multicast connection.

Confirm the entries by clicking ”Apply”.

Rev. A - Endgültig 20.04.2004 74/121


UDP Multicast Communication

7 You see the parameters which have to be


specified on the AG_SEND/AG_RECV
block.

In the second part – address assignment


– you see the IP address assigned to a
multicast circuit.
I.e. all modules assigned to this multicast
circuit receive multicast messages.

Please note that the local and multicast


group port addresses have to be identical
in order to enable a change of the master
stations.

8 Complete the configuration of this station


by clicking OK.

Rev. A - Endgültig 20.04.2004 75/121


UDP Multicast Communication

6 Operator Control and Monitoring of the Application

Overview
This chapter explains the steps required to familiarize with operating the
application. The following is described:

Content of the chapter Operator Control and Monitoring of the Application


Table 6-1
Chapter Chapter heading You are informed on…
No
6.1 Functions of the user interface ... the structure of the user interface of the
application.
6.2 Control of the data transfer ... how to control the data transfer.
6.3 Simulation of transfer errors ... how to simulate transfer errors.
6.4 System parameters / system ... the measurements which can be performed in
measurements the application.
6.5 Diagnostic functions ... the diagnostic functions available in the
application.

Requirements
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 project is online on the S7-CPUs.

Rev. A - Endgültig 20.04.2004 76/121


UDP Multicast Communication

6.1 Functions of the user interface

The user interface is realized in form of identical variable tables (VAT) in


Step7.

Variable table (master)


The figure below shows variable table 1 for station 1. Station 1 operates as
master. The individual entries are explained in the following table.
for operating the
Global settings

outputs and control Settings for operating application


the station
Most important

bits
Data displays during master
operation
operation
displays
during
slave
Data

Figure 6-1 User interface

Rev. A - Endgültig 20.04.2004 77/121


UDP Multicast Communication

Table 6-2
Area Operand Symbol Explanation
Global MW 16 nSlaves Number of slaves in the multicast circuit
settings
MW 14 nTimeOut Message runtime to be checked (watchdog timer) in
tenths of seconds.
A value of 10 corresponds to 1 second.
MB 12 bKeepAliveInterval Time interval during which a keep alive message is to
be sent in seconds.
A value of 10 corresponds to 10 seconds.
Settings M10.1 bMaster If TRUE, this station is set as master.
for the
M10.0 bStart Starts the station.
stations
M10.4 bResetSend Sets the station to a defined status.
If the station is master, an initialization procedure is
performed (i.e., the slaves are identified).
M10.7 bSendAutomatic Activation of the automatic send mode (only relevant,
if bPutData or bGetData is TRUE ).
M10.2 bPutData If TRUE, a PUT message is sent.
If bSendAutomatic == FALSE, the bit is automatically
reset by the application.
M10.3 bGetData If TRUE, a GET message is sent.
If bSendAutomatic == FALSE, the bit is automatically
reset by the application.
If bPutData == TRUE, the Get-Data request is
ignored.
Control M10.5 bNotAllSlaves An error has occurred during message transfer or in
bits the responses of the slaves.
ATTENTION:
If this bit is TRUE, the station only restarts sending
after bResetSend == TRUE.
MW30 wErrorCode Error code:
1: An invalid argument was transferred; e.g. incorrect
number of slaves
2: Slave management structure is inconsistent (e.g.
an IP exists twice)
3: The monitoring time was exceeded
4: An error has occurred during
AG_SEND/AG_RECV calls
M10.6 bHaveNoMaster If TRUE, the station has no master.
It may function as master.
T1 MasterTimer Period of time which has to elapse until the station
assumes that it has no master.
After this period of time has elapsed, the station may
be declared as master. The bMaster bit may be set to
TRUE.
Data DB3.DBB12 SendDB.TelMulticast.UserD Displays the last sent date in a PUT-Data request.
displays ata.arrChar[0]
during Slaves.SlaveBuffer[0].Slave Displays the slave data of slave1 (after a GET-Data
DB13.DBD40
master Data.ReceivedTelegrams request)
operation
DB13.DBD44 Slaves.SlaveBuffer[0].Slave Displays the slave data of slave1 (after a GET-Data
Data.ReceivedKeepAlive request)

Rev. A - Endgültig 20.04.2004 78/121


UDP Multicast Communication

Area Operand Symbol Explanation


DB13.DBD56 Slaves.SlaveBuffer[1].Slave Displays the slave data of slave2 (after a GET-Data
Data.ReceivedTelegrams request).
DB13.DBD60 Slaves.SlaveBuffer[1].Slave Displays the slave data of slave2 (after a GET-Data
Data.ReceivedKeepAlive request).
MD22 dwTimeGapLo Shortest message runtime measured *
MD26 DwTimeGapAvg Average message runtime measured *
MD18 dwTimeGapHi Longest message runtime measured *
Data MD2 dwReceivedTelegrams Number of received messages
displays
MD6 dwReceivedKeepAlive Number of received keep alive messages
during
slave DB6.DBB0 SlaveData.UserData.arrCha Last received data (PUT-Data request)
operation r[0]
(*) Measured over 100 values

6.2 Control of the data transfer

You can start the process of data transfer with the steps listed below.

Table 6-3
Step Instruction Note / Explanation
Initializing variable tables
1 Open the variable tables VAT_1, VAT_2 and VAT_3. The index of the variable table
Make sure that the CPUs are in “Run” mode. corresponds to the index of the
station.
2 In all variable tables, click the icon with the You can now monitor and control
the variable online.
glasses or in the menu Variable ->
Monitor.
3 Check whether the following conditions are fulfilled in If these conditions are not fulfilled, you
all tables: should set these variables to the
values shown on the left. Select the
• nSlaves = 2: 2 slaves are to be managed respective lines and press Ctrl+F9 or
• nTimeOut = 5: Corresponds to a monitoring time
of 500ms. click the button .
• nKeepAliveInterval = 10: A keep alive
message is sent every ten seconds.
Setting master/slave
4 In order to have the station operate as master, Please refer to the note in step 3.
switch to it and set bMaster = TRUE.
5 Start the slaves with bStart = TRUE. Please refer to the note in step 3.
6 Start the master with bStart = TRUE and wait Please refer to the note in step 3.
approximately 10 seconds until the bHaveNoMaster If the master does not start operation
bit in the slaves is extinguished and the master has correctly, set the bResetSend bit to
started normal operation. TRUE and back to FALSE.
A renewed initialization procedure is
performed after approx. 10 seconds.

Rev. A - Endgültig 20.04.2004 79/121


UDP Multicast Communication

Step Instruction Note / Explanation


Note:
In case of an error, consider the
variables bNotAllSlaves and
wErrorCode.
Transfer of messages
7 Set whether a message is to be resent continuously Please refer to the note in step 3.
by setting bSendAutomatic = TRUE or FALSE.

8 Sending a PUT request: Please refer to the note in step 3.


Set the bPutData bit to TRUE.
9 Sending a GET request: Please refer to the note in step 3.
Set the bGetData bit to TRUE.
Note:
If bPutData = TRUE, bGetData is
ignored.

Results
You see the following results:
• Case1: PUT-Data
○ VAT_1:
▪ The send buffer is filled as quickly as possible.
Note:
Only 1 character is displayed in the VAT.
▪ The message runtimes are updated after 100 sent messages.
○ VAT_2/3:
▪ The data displays of the slaves are updated.
Note:
The same character as in the send buffer of the master appears in the
receive buffer of the slave.
• Case2: GET-Data
○ VAT_1:
▪ The slave buffers are filled with the current slave data.
○ VAT_2/3:
▪ The data displays of the slaves are updated.

Note
The slave data in the slave buffers are deleted after a keep alive. Thus, a possible
read out has to take place before the keep alive time elapses.

Rev. A - Endgültig 20.04.2004 80/121


UDP Multicast Communication

Diagnostics
For diagnostics, please consider the error display wErrorCode explained
above and the chapters 4.7.7 or 7.2.

6.3 Simulation of transfer errors

Requirement
Station1 runs as master, stations 2 and 3 are configured as slaves.

Simulation
The following steps describe how to simulate transfer errors:

Table 6-4
Step Instruction Reaction of the system
Error: IE cable not connected
1 Disconnect the IE cable from the • At the latest after nTimeOut/10 seconds, the master
CP of station 3. detects that a slave has not responded.
Consequences:
The master sets the bSlavesError bit to TRUE and
updates wErrorCode (value: 3 or 4)
- No further message is sent
• The slave “Station3” detects after
3*nKeepAliveInterval seconds that it has no
master. bHaveNoMaster set to TRUE.
Consequences:
- It would be permitted to configure station 3 as
master after this period of time
• The slave “Station2” detects at the latest after
3*nKeepAliveInterval + nTimeOut/10 seconds
that it has no master. bHaveNoMaster set to TRUE.
Consequences:
- It would be permitted to configure station 2 as
master after this period of time
2 Reconnect the IE cable to the CP -
of station 3.
3 Reinitialize the master station • Station 1 (master):
(station 1). - Change to initialization status
To do this, set bResetSend to - Sending a keep alive message
TRUE and back to FALSE. - Reinitializing the slave management structure
• Station 2/3 (after reception of a message):
- Starting the variable MasterTimer
- Master identification; bHaveNoMaster is set to
FALSE.
Incorrect number of slaves entered
5 The following steps always refer to In the next message, the master expects 5 responses.
VAT_1 (station 1). Since only 2 slaves can answer, the master reacts as
• nInSlaves = 5 follows:

Rev. A - Endgültig 20.04.2004 81/121


UDP Multicast Communication

Step Instruction Reaction of the system


• The master sets the bNotAllSlaves bit to
TRUE.
• No further message is sent.
With regard to the error codes, the following cases
have to be differentiated:
○ Case1: The error occurred during initialization
procedure
- wErrorCode = 1 (incorrect number of
slaves)
○ Case2: The error occurred during operation
- wErrorCode = 2 (slave management
structure is inconsistent)
- wErrorCode = 3 (timeout; at least one slave
has not responded during the required period of
time)

Note:
The slaves react as described in step 1.
6 Set nInSlaves = 2 -
7 Reinitialize the master station • Station 1 (master):
(station 1). - Change to initialization status
To do this, set bResetSend to - Sending a keep alive message
TRUE and back to FALSE. - Reinitializing the slave management structure
• Station 2/3 (after reception of a message):
- Starting the variable MasterTimer
- Master identification; bHa veNoMaster is set to
FALSE.

6.4 System parameters / system measurements

As already described in chapter 4.7.1, the message runtime is measured.


For information on how the measurement is performed, please refer to
chapter 4.7.1.
The effects of the message runtime can be simulated by adapting the user
data size, see chapter 8.1.

6.5 Diagnostic functions

Overview
The following chapter describes the diagnostic functions available for UDP
connections with the CPU and the CPs used in this application.
The diagnostic functions in Step 7 are dealt with exclusively.

Rev. A - Endgültig 20.04.2004 82/121


UDP Multicast Communication

For the diagnostics of communication errors in the application, please refer


to chapter 4.7.7 or 7.2.

S7 connection diagnostics using NCM S7


The NCM S7 configuration package offers options within CP diagnostics for
the diagnostics of S7 connections (e.g. via the properties dialog box of the
respective CP and start of “Special diagnostics”).

Table 6-5: Diagnostic functions offered by NCM S7


S7-300
Overview of
connections

Connection-
specific
information
(multicast)

Rev. A - Endgültig 20.04.2004 83/121


UDP Multicast Communication

S7-300
Connection-
specific
information
(unspecified)

Depending on the system family and the system used, there are different
types of diagnostic functions which can be easily used.
Within the S7-300 product family there are differences between the
following types of connections and the related diagnostic functions with
NCM:

Table 6-6: CP-related diagnostic functions of the S7-300 CP using NCM S7


Unidirectional connections Unidirectional and bidirectional
maintained via CPU connections
maintained via CP
NCM diagnostics does not offer the possibility NCM diagnostics can be used to examine
to check the resources or the message traffic. the CP and its connections. It provides
detailed figures on all sent and received
messages as well as details on current jobs
and background information whether
connection breakdowns have occurred.

Within the S7-400 product family, connection-specific diagnostics is not


possible because the connection information is stored in the CPU; this is
not the case in the S7-300.

Connection diagnostics using the S7 CPU


The S7 CPU offers the function "Module Information" with a
"Communication" tab where you can see an overview of the resources
configured and used for the communication.
Since UDP is a connectionless protocol and since the memory for the UDP
connection is on the CP for CPs of version 6GK7 343-1EX10-xxxx or later,
no connection resource is assigned on the CPU.
A connection control cannot be performed.

Rev. A - Endgültig 20.04.2004 84/121


UDP Multicast Communication

Bild 6-2 Screenshot CPU module diagnostics

Connection diagnostics using NetPro


Due to the connectionless datagram service UDP, NetPro displays the

following picture (after clicking ):

Fig. 6-3
The connection status cannot be controlled using this way.

Characteristic features in this application


In an unspecified connection, the destination address (Port/IP) is stored in
the first 6 bytes of the message to be sent.
The CP reads out these 6 bytes and sends the message to the specified
address.
The advantage to be able to dynamically calculate the destination address,
i.e. during runtime, may however lead to an unusual error if an incorrect
destination address is entered.
This document does not provide any further information on this error; for
details, please refer to the FAQ with the EntryID.

Rev. A - Endgültig 20.04.2004 85/121


UDP Multicast Communication

In the application, the described error is detected by the added level7


acknowledgement. Since the master would no longer receive a slave
response, an error would be detected by the watchdog timer.
In the slave, this can be identified without additional aids due to the entry of
the first 6 bytes of a message in the variable table.

Rev. A - Endgültig 20.04.2004 86/121


UDP Multicast Communication

Part C: Program Description

Objectives of Part C
The purpose of this part of the documentation 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 and SCL. 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.

Content of Part C

7 Explanations on the STEP7 Program..................................................... 88


7.1 Pointer generator: FC21 “GenPointerOnDB” ............................................. 89
7.2 Error control: FB33 “Error Control”............................................................. 91
7.3 Manager: FB1 “Manager”........................................................................... 94
7.4 Send cycle manager: FB10 “SendCycleManager”..................................... 99
7.5 Receive cycle manager: FB11 “ReceiveCycleManager”.......................... 105
7.6 Slave manager: FB2 “SlaveManager”...................................................... 110
8 Changes in the STEP7 Program ........................................................... 115
8.1 Changing the net data record length........................................................ 116
8.2 Adding a further station ............................................................................ 117

Rev. A - Endgültig 20.04.2004 87/121


UDP Multicast Communication

7 Explanations on the STEP7 Program

Introduction
This chapter provides information on the essential core code sequences of
the most important function elements. In individual cases we refer to the
commented code in the application.

Content of the chapter Explanations on the STEP7 Program


Table 7-1
Chapter Chapter heading You are informed on…
No
7.1 Pointer generator ... how the function element pointer generator was
implemented.
7.2 Error control ... how errors of AG_SEND/AG_RECV calls can be
logged and how a configurable reaction can be
realized.
7.3 Manager ... how the control operates and how the message
runtime is measured.
7.4 Send cycle manager ... how an added level7 acknowledgement can
operate with UDP.
7.5 Receive cycle manager ... how an added level7 acknowledgement can
operate with UDP.
7.6 Slave manager ... how to easily implement management tasks with
SCL.

Rev. A - Endgültig 20.04.2004 88/121


UDP Multicast Communication

7.1 Pointer generator: FC21 “GenPointerOnDB”

Tasks of the function element


Any pointers have to be used to enable dynamic addressing of data blocks;
they specify the data block number, the start address and the length of the
data area to be addressed.
The function element “pointer generator” is used to generate an ANY
pointer to a data block.

Principle of this function element


In order to generate an Any pointer to a DB, the following parameters have
to be known:
• DB number
• Length of the DB
• Start address/offset of the pointer within the DB (not required in this
function element).
After the Any pointer has been generated, it has to be copied to the output
pointer.
Since the Any pointer has a length of 10 bytes, this is performed by means
of a series of load and transfer commands.
Proceed as follows:

Table 7-2
Step Instruction Reference/code
1 Open the data block and FC21, network 1
calculate the length of the
DB
2 Generate and Any pointer to FC21, network 1 and FC20, network 1
the data block with the start
address 0

Rev. A - Endgültig 20.04.2004 89/121


UDP Multicast Communication

Step Instruction Reference/code

3 Copy the Any pointer into the


output parameter

The output Any pointer is defined area at address 0 in


the local data.

The formatting of the Any pointer and the restrictive task of this block to
point to one DB only involve that some information is predefined.
For example, the first byte of the Any pointer with a size of 10 bytes marks
the data area to be pointed to.
In case of a DB, 2 has to be entered here.
All other parameters are to be set accordingly.
Notes
• An Any pointer can be defined as OUT parameter only in an FC (function).
• The format and the respective parameters of an Any pointer are available in the
SIMATIC Help function.

Parameters of the function element


See chapter 4.7.4.

Rev. A - Endgültig 20.04.2004 90/121


UDP Multicast Communication

7.2 Error control: FB33 “Error Control”

Tasks of the function element


The function element error control performs the following tasks:
• Logging of an error occurring during AG_SEND/AG_RECV calls
including the corresponding status.
• Check whether the identified error status is known and whether it can be
reacted to.
• Determination of the configured error reaction and transfer of this
reaction back to the calling function.

Principle of error analysis


Error analysis is based on a list of rules. These rules are stored in form of a
data block (reaction DB). This data block contains the “expected” status of
the functions as well as the appropriate reactions.
If an error occurs in one of the functions to be checked, the status output is
used to find the reaction linked to this error in the error DB.
If a reaction is found, it is output; if no reaction can be found, the application
cannot respond to the error with a predefined reaction. The behavior of the
program is thus unspecified.

Rev. A - Endgültig 20.04.2004 91/121


UDP Multicast Communication

Function principle of Error_Control FB 33


Table 7-3
Flowchart Description
The first step is to check whether an error has occurred.
If so, processing of this block continues. Furthermore, all
outputs are reset.

Subsequently, the error DB is searched with regard to the


identified error status; if the error status is found, the
reaction information stored in the DB is selected. If the
status is not stored in the DB, a standard value for the
reaction is returned.

Now, information on the path in which the error occurred,


the error status and the corresponding reaction with the
current time stamp is stored for the current index of entry.
At the end of the function, the reaction (e.g. restart, stop)
is output according to the available output parameters.

Data structures required for error analysis


The reaction DB is a data block consisting of an array of variables of the
UDT 105 type. This data type is structured as follows:

Fig. 7-1: UDT 105 “Error_DB_Structure”


An array of this data type created in the reaction DB contains any number
of data records automatically identified by the function. These data records
are successively searched in order to determine a reaction (action)
corresponding to the relevant status.

Logging of occurring events


Logging occurring events requires the following information:
• Send_Receive information to allocate the error location (send or receive
path).

Rev. A - Endgültig 20.04.2004 92/121


UDP Multicast Communication

• Status information displayed in the block to be examined when the


function was called.
• The reaction to the relevant error as defined in the error DB.
• The time stamp which enables unique documentation of the time the
error occurred.
• The location where the error occurred including 2 integer user-defined
parameters (here: ID and LADDR used).
An array of the data type UDT111 “Errorstruct” generated in the protocol
DB contains any number of data records automatically identified by the
function. Each new entry is automatically added to the previous one. If the
maximum number of entries is reached, the function returns to the
beginning of the protocol DB.

Data structure required for the protocol DB


The protocol DB is a data block consisting of an array of variables of the
UDT111 “Errorstruct” type. This data type is structured as follows:

Fig. 7-2: UDT 111 “Errorstruct”


The following structure (UDT 109) is used to identify the location of the
error:

Figure 7-3: UDT 109 “Errorlocationstruct”

Parameters of the function element


See chapter 4.7.7.

Rev. A - Endgültig 20.04.2004 93/121


UDP Multicast Communication

7.3 Manager: FB1 “Manager”

Tasks of the function element


The tasks of FB1 “Manager” are divided into general and special tasks:
General tasks:
• Execution and controlling of the application
• Supplying the interfaces of the subordinate function elements.
Special tasks:
• Check whether a station may function as master (only one master is
permitted in the multicast circuit)
• Generation of simulated user data
• Creation of a keep alive request
• Message runtime measurement.

Rev. A - Endgültig 20.04.2004 94/121


UDP Multicast Communication

Flowchart of FB1 “Manager”

Yes
1
Reset variables Reset?
No

Yes
Error? End
No

Is
current-
ly being
read?
No

Do you
Yes 2
Reset master
have a
request
master?
No

Are you No
suppos Accept new
ed to be instructions
master?
End
Yes

3
No

No No
Yes Is there a Is there a Has keep
PUT GET alive time
request? request? elapsed? 4
Yes

Yes
Yes

Set status bits Set status bits Set status bits

Reset keep alive Reset keep alive Reset keep alive


timer timer timer

Generate user data

Measure start time Measure start time Measure start time

Send block

No
Is sending
procedure End
completed?
Yes

Yes

Reset keep alive

Is to be Yes No
sent
Has an
Measure end
6
error
automatical time
occurred?
-ly?
No

Reset PUT/GET
request

Figure 7-4 Flowchart of FB1 “Manager”

Rev. A - Endgültig 20.04.2004 95/121


UDP Multicast Communication

Explanation on the flowchart


Below, the implementations are assigned to the marked sections.

Table 7-4
No. Code excerpt
1
The send block has to be
reset.

The “MasterTimer” is a
“delay timer” which is
started during slave
operation.

Filling the simulated data


and measuring the start
time.

Rev. A - Endgültig 20.04.2004 96/121


UDP Multicast Communication

No. Code excerpt


4

The time for the keep alive


message is determined by bit 5
of the MB0 clock memory fixer.

Rev. A - Endgültig 20.04.2004 97/121


UDP Multicast Communication

No. Code excerpt


6

The statistic block is reset


after 100 measurements to
be able to receive new
values.

The message runtime is the


difference between end time
and start time.

Parameters of the function element


See chapter 4.7.1.

Rev. A - Endgültig 20.04.2004 98/121


UDP Multicast Communication

7.4 Send cycle manager: FB10 “SendCycleManager”

Tasks of the function element


FB10 “SendCycleManager” has the following tasks:
• Composing a multicast message
• Sending the message
• Receiving the acknowledgement messages
• Having acknowledgement messages checked and stored
• Monitoring the specified timeout
• Triggering the error recording.

Rev. A - Endgültig 20.04.2004 99/121


UDP Multicast Communication

Flowchart of FB10 “SendCycleManager”

Yes
Reset variables NoReset? 1

Is block in
receiving
status?
No

Generate pointer to
send buffer
Yes

Yes Yes

Reset send requests


Is block in 2
sending mode?
No

No
Is there a send 7
End
request?
AG_RECV
(unspecified)
Yes

3
No

Set block to send


mode
No
AG_RECV
Error in
completed
No No AG_RECV?
Is there a successfully?
Is there a PUT Is there a GET Yes
Keep Alive

Yes
request? request?
request?
Check or initialize
Exit receiving mode
Yes

slave

Set coding for


Yes

Yes

message type
Set end and error bit
as well as status
8
Calculate header Set coding for Set coding for
length message type message type Have all slaves
Log errors
responded or
has an error
Copy user data into occurred?
send buffer
End
No

Generate header
4

Yes
AG_SEND (multicast)
Set end and error bit
as well as status.
5 Yes
Exit receiving mode.
Exit sending mode.
AG_SEND
Go to receiving
successful?
mode
No

9
No No
Error in Has TimeOut
End
AG_SEND? occurred?
Yes

Yes

Exit sending mode Exit sending/


receiving mode

Set end and error bit


Set end and error bit
as well as status
as well as status
6
Log errors

End
End

Figure 7-5 Flowchart of FB10 “SendCycleManager”

Rev. A - Endgültig 20.04.2004 100/121


UDP Multicast Communication

Explanation on the flowchart


Below, the implementations are assigned to the marked sections.

Table 7-5
No. Code excerpt
1

The reset
Due to thesignal
reset causes
signal a
change
the change
to the
to the
initialization
status takes status.
initialization place.
As
Thesoon
slaveasmanagement
bInReset ==
FALSE,
structurethe slaveas soon
is reset
management
as bInReset == structure
FALSE.is
reset.

To enable to use an Any


pointer (e.g. for further
parameter transfer), it has to
be copied into the local data
area.

The length of the user data area is


coded in the Any pointer. To be
able to insert the message header,
the length of the user data has to
be subtracted from the length of
the message to be sent in order to
receive the length of the message
header.

Rev. A - Endgültig 20.04.2004 101/121


UDP Multicast Communication

No. Code excerpt


4

Port and IP address of


the station are listed in
the address DB.

The multicast connection has


the local ID 2.

- The error reaction is


configured in DB90.
- The error is to be logged in
DB110.
- The error ocurred during
AG_SEND in FB10 at ID=2
(multicast) and CP with
LADDR=100.

The acknowledgement is to
be received with the
unspecified connection.
Thus ID=1 and LADDR=100
(same CP).

Rev. A - Endgültig 20.04.2004 102/121


UDP Multicast Communication

No. Code excerpt


8

The data of the slave “nInDataNr”


are stored in the parameter
“tOutSlaveData”. Yet, this is not
used here.

The “Edge” block is only an


Bit 0 of the MB0 example for the implementation of
clock memory EP (Edge Positive) in SCL.
fixer.

Rev. A - Endgültig 20.04.2004 103/121


UDP Multicast Communication

Data structures required for the block


FB10 “SendCycleManager” has the message header of a multicast
message generated with the header generator (see step 4).
It requires data block DB50 “AddressDB”. This data block requires UDT50
“JobHeader” which is structured as follows:

Fig. 7-6 UDT50 “JobHeader”


Then, the header generator adds the message header shown below to the
message.

Fig. 7-7 UDT51 “structTelHeaderMulti”

A multicast message is thus structured as follows:

Fig. 7-8 UDT55 “structTelegramMulti”

Parameters of the function element


See chapter 4.7.2.

Rev. A - Endgültig 20.04.2004 104/121


UDP Multicast Communication

7.5 Receive cycle manager: FB11 “ReceiveCycleManager”

Tasks of the function element


FB11 “ReceiveCycleManager” performs the tasks of a slave:
• Receiving a multicast message
• Executing the request (FB12 “TreatData”)
• Generating an acknowledgement message (FB12 “TreatData”)
• Sending the acknowledgement message
• Triggering the error recording.

Flowchart of FB11 “ReceiveCycleManager”

Is block in
receiving
mode?
Yes

AG_RECV (multicast)
1

Has
AG_SEND
signaled a
No
status?
Yes

Restart master timer

Yes Has
AG_RECV
Log errors
signaled an
error? 3
AG_SEND
(unspecified)
No

Reset sending bit


No
AG_RECV
End
completed?

No Has No
AG_SEND AG_SEND
End
Yes

completed? signaled an
2 error?
Increase number of
received messages
Yes
Yes

Fill acknowledgement Set block to Set block to


data receiving mode receiving mode

Set block to sending


mode End Log errors

Set sending bit

Figure 7-9 Flowchart of FB11 “ReceiveCycleManager”

Rev. A - Endgültig 20.04.2004 105/121


UDP Multicast Communication

Explanation on the flowchart


Below, the implementations are assigned to the marked sections.

Table 7-6
No. Code excerpt
1

Waiting for instructions on


the multicast connection.

Now, the data have to be


processed.

Rev. A - Endgültig 20.04.2004 106/121


UDP Multicast Communication

No. Code excerpt


3
The acknowledgement is
sent with the unspecified
connection.

Change to the receiving


mode.

Rev. A - Endgültig 20.04.2004 107/121


UDP Multicast Communication

Block FB12 “TreatData” interprets the master message and generates an


acknowledgement message.
Since the master sends 3 different messages (PUT, GET, Keep Alive), the
slave has to make a switch-case decision.
To ensure that the acknowledgement message reaches the master, it is
required to extract the master IP address from the multicast message of the
master and to insert it in the message header of the acknowledgement
message.
The code fragment below illustrates the procedure:

Jump label 1 for the 3 different


messages:
1. Put-Data
2. Get-Data
3. Keep Alive

The acknowledgement data are


compiled in “tTmpAckData”.

Here, the IP/port address of


the master is entered in the
acknowledgement
message.

Fig. 7-10 Generation of an acknowledgement message

Data structures required for the block


First, FB11 “ReceiveCycleManager” receives a multicast message. It thus
requires the same data structures as FB10 “SendCycleManager” (see
chapter 7.4).

Rev. A - Endgültig 20.04.2004 108/121


UDP Multicast Communication

Additionally, an acknowledgement message which is sent to the master can


be generated with FB12 “TreatData”.
The following structures are required:
• Structure with the process data of a slave:

Fig. 7-11 UDT52 “structSlaveData”

• Structure of an acknowledgement message:

Fig. 7-12 UDT56 “structTelegramAck”

Parameters of the function element


See chapter 4.7.3.

Rev. A - Endgültig 20.04.2004 109/121


UDP Multicast Communication

7.6 Slave manager: FB2 “SlaveManager”

Tasks of the function element


The slave manager has the following tasks:
• Entering a slave in the slave management structure
• Consistency check of the slave management structure
• Managing the slave responses within one send cycle
• Data storage of the slave data.

Rev. A - Endgültig 20.04.2004 110/121


UDP Multicast Communication

Flowchart of FB2 “SlaveManager”

Reset output
parameter

Copy data in receive


buffer into temporary
slave structure

1
Is the Yes No
Was the
structure to Delete structure. Set
structure
be „structure deleted“.
deleted?
initialized?
2

No
No

Reset „structure deleted“ Copy slave data into the


next available location in
the slaves array

Have all
Have all
slaves in the
slaves
slave array
been
been
acquired?
polled?
Yes
No

Reset „structure deleted“. Reset


No
end flag. Reset error flag.

No
No
Is IP of the slave in the
Set error bit. Set status
array identical with IP of Is the slave array
information.
the last responding slave? consistent?
Yes
Yes

Ende
Yes

Select slave in the array

No
Have all slaves in the
Reset end flag
array responded?
Yes

Set end flag. Reset error flag.


Yes

For the next cycle, mark all


Ende slaves in the array as „did not
respond“

Figure 7-13 Flowchart of FB2 “SlaveManager”

Rev. A - Endgültig 20.04.2004 111/121


UDP Multicast Communication

Explanation on the flowchart


The slave management structure is implemented as array; due to this, the
use of SCL is suitable since it enables to easily access arrays.
Below, the implementations are assigned to the marked sections.

Table 7-7
No. Code excerpt
1

The next slave is entered in the next


location available.

Consistency check:
No IP address may
exist twice.

Error: The parameter


“nInSlaves” was modified during
initialization status.

nIndexInit < nInSlaves applies


Î it is required that further
slaves respond.

Rev. A - Endgültig 20.04.2004 112/121


UDP Multicast Communication

No. Code excerpt


2

Returns the data of a specific


slave.

Comparing the IPs. If they


are identical, a registered
slave has responded.

Storing the slave data in the


slave management structure.

Check whether all slaves have responded.

Since all slaves have responded, the


“bHasSentAck” bit of each slave has to
be cleared for the next cycle.

Rev. A - Endgültig 20.04.2004 113/121


UDP Multicast Communication

Data structures required for the block


FB2 “SlaveManager” manages the messages of a slave.
The structure of the acknowledgement messages is stored in UDT56
“structTelegramAck”:

Fig. 7-14 UDT56 “structTelegramAck”


The slave data are extracted from this structure. The slave data are stored
in UDT52 “structSlaveData”:

Fig. 7-15 UDT52 “structSlaveData”


In order to manage the responses of the slaves, an array is required which,
in addition to the slave data, also has to contain information on the active
slave and the slave that has responded. UDT60 “structSlave” contains this
structure of an array element. The instance DB on FB2 “SlaveManager”
contains this slave array (slave management structure).

Fig. 7-16 UDT60 “structSlave”

Parameters of the function element


See chapter 4.7.8.

Rev. A - Endgültig 20.04.2004 114/121


UDP Multicast Communication

8 Changes in the STEP7 Program

Introduction
The steps to be performed in order to adapt the application to your
requirements are listed below.

Contents of the chapter Changes in the STEP7 Program


Table 8-1
Chapter Chapter heading You are informed on…
No
8.1 Changing the user data length ... how to proceed to adapt the user data length to
your specific requirements
8.2 Adding further stations ... how to proceed to add further stations.

Requirement
These steps should only be performed after having studied Part A1 and
Part A2 respectively.

Rev. A - Endgültig 20.04.2004 115/121


UDP Multicast Communication

8.1 Changing the net data record length

Note
Please note the basic performance data listed in chapter 3.

In order to change the user data length proceed as follows:

Table 8-2
Step Description
1 Replace UDT54 “structUserData” with your own data type.
2 Select “Check Block Consistency”.

3 Compile all blocks by selecting “Compile All”.

Note:
The warning messages can be ignored.
4 Perform steps 1-3 for all stations.
5 Stop the stations and load the programs via “PLC Æ Download“.

Rev. A - Endgültig 20.04.2004 116/121


UDP Multicast Communication

8.2 Adding a further station

To add a further station, S7-SCL should be installed on your system. If this


is not the case, the required modifications have to be performed using the
Statement List Editor. The table below describes how to proceed with S7-
SCL.

Table 8-3
Step Description
1 Set all CPUs to STOP.
2 Use the SIMATIC Manager to add the new stations and their hardware
configurations using HWConfig.
3 Configure the new UDP connections in NetPro (see chapter 5.3.1) and
recompile all.
ATTENTION:
• Make sure that the assignment of the UDP connections receives the same
local IDs as described in chapter 5.3.1.
If this is not the case, the parameters for the blocks AG_SEND/AG_RECV
have to be supplied differently (see chapters 7.4 and 7.5).
• Make sure that the local and the remote port address are identical in the
multicast connection.
4 If you don’t want to manage more than 20 slaves, go to step 9.
5 Open and compile the SCL source “SlaveManager” from station 1.

6 Close the SCL source.

Rev. A - Endgültig 20.04.2004 117/121


UDP Multicast Communication

Step Description
7 Select “Check Block Consistency”.

8 Compile all blocks by selecting “Compile All”.

Note:
The warning messages can be ignored.
9 Copy the blocks and the sources in the block or source folder of station 1 into
all stations.
ATTENTION:
Do not copy the system data!
If you do copy the system data, you have to compile the hardware
configuration again with NetPro.
10 Set the port and IP address configured in NetPro for each CPU in DB50
“AddressDB”.
11 If the newly added stations are S7-300 CPUs, please proceed with step 15.
12 Delete the blocks “AG_SEND” and “AG_RECV” in the block folder of the newly
added stations.
13 In the block folder of the newly added S7-400 stations, add the blocks
“AG_SEND” and “AG_RECV” by copying them from the library for S7-400 CPs.
14 Repeat steps 11 and 12 for all S7-400 CPUs.
15 Load all stations.
16 Open the variable tables and set the necessary parameters (see chapter 6).
17 Set all CPUs to RUN or RUN-P.
18 Start the application as described in chapter 6.

Rev. A - Endgültig 20.04.2004 118/121


UDP Multicast Communication

9 Glossary

Any pointer
S7 data type which includes an operand or a pointer to any memory
address, as well as the data type of the operand and a repeat factor.

CP
Communications processor. Module for communication tasks.

Datagram
An IP data packet
Includes a packet of data containing enough information to be able to be
transferred from one station to another station via a data network.

Deterministics
The term deterministics describes the degree of freedom within a closed
system. With regard to PROFIBUS, it defines the ability to predict when a
specific station will regain the right to send and thus the possibility to
transfer its data.
A system has no deterministics if it is not possible to determine a time from
which a specific event occurs with certainty.

Services
Offered services (options for data exchange) of a communication protocol.

FDL (SDN)
Fieldbus Data Link – Send Data with no Acknowledge
A protocol for the data transfer via Profibus (PROcessFIeldBUS).

Secure data transfer


The data transfer is secure if the sending of data has the following
properties:
• The arrival of the data is communicated to the sender
• The data cannot actually be duplicated by different paths
• The data are consistent
• The sequence of the data is known.

Rev. A - Endgültig 20.04.2004 119/121


UDP Multicast Communication

ISO/OSI reference model


Model for communication standards, consisting of 7 layers
1. Physical layer
2. Data link layer
3. Network layer
4. Transport layer
5. Session layer
6. Presentation layer
7. Application layer

Protocol
A protocol is a precise down-to-the-bit agreement between communication
partners required to perform a specific communication service. The protocol
defines the content structure of the data traffic on the physical line and
defines, for example, the operating mode, connection establishment
procedure, data security or the transfer speed.

UDP
User Datagram Protocol – a connectionless protocol based on the IP layer.

Rev. A - Endgültig 20.04.2004 120/121


UDP Multicast Communication

10 Bibliography

Bibliography
This list is by no means exhaustive and only provides a selection of
appropriate sources.

Table 10-1 Literature


Topic Title
Industrial Ethernet
\1\ Ethernet/IP http://www.ethernet-ip.org/
STEP7
\2\ “System software for S7-300/400 MLFB: 6ES7810-4CA06-8AR0
system- and standard functions”
manual
\3\ STEP 7 online help Part of the Step 7 installation.
\4\ SCL Automating with STEP7 in STL and
SCL
Hans Berger, Publicis MCD Verlag
ISBN 3-89578-113-4

Rev. A - Endgültig 20.04.2004 121/121