S7 Communication Between S7-300 and S7-400 Via Profibus With BSEND / BRECEIVE

Application for Communication
S7 Communication between S7-300 and S7-400

via Profibus CPs with BSEND / BRECEIVE and
several Adressing Parameters (R_ID)
Table of Contents
1 Task ............................................................................................................. 3
2 Setting up the Automation Solution ......................................................... 4
2.1 Required Components ................................................................................. 5
3 Function Mechanisms and Program Structures ..................................... 7
3.1 The S7 protocol specifications ..................................................................... 7
3.2 Configuration of a S7 connection ................................................................. 8
3.3 User Interface (block oriented service) ........................................................ 9
3.4 Logical core structures – An example ........................................................ 14
3.5 Program structures..................................................................................... 16
3.6 Program procedure of sender .................................................................... 18
3.7 Program procedure of the receiver ............................................................ 21
4 Installation of Hardware and Software................................................... 23
Copyright © Siemens AG 2005 All rights reserved
4.1 Hardware configuration .............................................................................. 23

20987358_BSEND_PB_DOKU_v10_e
4.2 Installation of the software ......................................................................... 23

4.3 Operator control and monitoring ................................................................ 24
Continuative Literature .............................................................................................. 32
Rev. A- Final 22.01.2004 2/33

1 Task
Technological task/ overview

The following example illustrates simple coupling of two S7 controllers us-
ing the S7 protocol.
The task is to transmit smallest to largest data loads via Profibus CPs from
Station 1 to Station 2 as simple as possible.
Figure 1-1
Solution Requirements
The solution must fulfill the following points:
▪ Only one S7 connection is used
▪ 4 different data packages are to be transferred at 4 different areas
in the target CPU.
▪ The transfer must be performed in sequences, i.e. all components
of a sequence must have been transmitted before a new package
is transmitted.
Quantity framework of the sample application:

Table 1-1
1. Area 2. Area 3. Area 4. Area
Data quantity 100 bytes 700 bytes 2500 bytes 4700 bytes
The selected data quantities are user-defined and can be changed in the
sending and receiving application.
For data transfer, the functions BSEND and BRECEIVE are used for coor-
dinated data transfer via a configured connection.
Rev. A- Final 22.01.2004 3/33

2 Setting up the Automation Solution
Display of involved components

The following figure shows the hardware setup of the sample application
and the standard and user software components involved.
Fig. 2-1
Rev. A- Final 22.01.2004 4/33

2.1 Required Components
Hardware components
The following hardware components are required for using the application.
Table 2-1 Used S7-400 components

Component MLFB / Order number Note
Rack S7 400 UR2 6ES7400-1JA01-0AA0 Any UR or CR may be
used here.
PS 407 10A 6ES7407-0KA01-0AA0 Any PS with sufficient
power specifications
can be used here.
CPU 416-2 DP 6ES7416-2XK02-0AB0 FW V 1.2, or similar
CPU
CP 443-5 Basic 6GK7443-5FX01-0XE0 Any Profibus CR of the
S7 400 series may be
used here.
Table 2-2: Used S7-300 components


PS 307 2A 6ES7307-1BA00-0AA0 Any PS with sufficient
power specifications
can be used here.
CPU 315-2 DP c 6ES7315-2AG10-0AB0 FW V 2.0, or similar
CPU
CP 342-5 6GK7342-5DA02-0XE0 Only the CP 342-5
(here FW V 5.0) can be
used here.
Table 2-3: Used PG components

Power PG 6ES7750-2CA52-4FB4 See PG configurator in
A&D Mall
On Board CP 5611 N/A Part of PG hardware.
Rev. A- Final 22.01.2004 5/33

Software components
The following software components are required to use the application.
Table 2-4: Software components used

Step 7 V 5.2 6ES7810-4CC06-0YX0
NCM S7 Profibus N/A Part of Step 7 SW.
Example project
The example application consists of the following components
Table 2-5: Used application components

Component Note
20987358_BSEND_PB_CODE_v10.zip This packed file contains the hardware
configuration for both stations, the
connection configuration as well as the
application programs in STL source
code (except the system functions and

function blocks for BSEND and

BRECEIVE) .
20987358_BSEND_PB_DOKU_v10_d/e.pdf This documentation
Further information on commissioning hardware and software is available in chapter 4 “Installation of

Hardware and Software“.
Rev. A- Final 22.01.2004 6/33

3 Function Mechanisms and Program Structures
This chapter briefly explains the functionalities based on the S7 protocol
and their possible usage in an application.
Furthermore, it gives a detailed description of the BSEND and BRECEIVE
services used in this example application and discusses system specific
properties in detail.
3.1 The S7 protocol specifications
Physical independence of the S7 protocol

The S7 is a physically independent protocol, i.e. it is not bound to a network
such as Profibus or Industrial Ethernet.
It enables connections between two partners via the following physical net-
works:
▪ MPI
▪ Industrial Ethernet
▪ PROFIBUS
Position of the S7 protocol in the ISO / OSI reference model
Fig. 3-1
The protocol itself is located in the ISO / OSI 7 layer reference model for
communication on level 7, as the used interface of the system is merely
based on application data. Services for managing the connections or for
converting the data are not necessary, as these are provided by functions
of the operating system.
Rev. A- Final 22.01.2004 7/33

Characteristic performance data of S7 protocol services
From a user point of view, the S7 protocol consists of the following ser-
vices:
• BSEND / BRCV
• USEND / URCV
• PUT / GET
The following table contains an overview of the respective performance
data for the S7 families. The colored service is the topic of this Getting Star-
tet and is discussed in greater detail below.
Table 3-1: Characteristics of the S7 protocol

Services/ Fea- BSEND / BRCV USEND / URCV PUT / GET
tures
Max. data length 32 KB / 64 KB (2 440 bytes / 440 164 bytes / 400
S7-300 / S7-400 bytes (1 bytes (1
Possible address M, D / M, T, Z, E, M, D / M, T, Z, E, M, D / M, T, Z, E,
areas A, D A, D A, D
S7-300 / S7-400
Data consistency 8 – 32 bytes / 32 8 – 32 bytes / 32 8 – 32 bytes / 32

S7-300/-400 bytes to total bytes to total bytes to total

length (3 length (3 length (3
Communications Client / Client Client / Client Client / Server
service
Max. number of See CPU specifi- See CPU specifi- See CPU specifi-
connections cation cation cation
Block types SFB / FB 12 SFB / FB 8 SFB / FB 15
“BSEND“ “USEND“ ”PUT“
SFB / FB 13 SFB / FB 9 SFB / FB 14
“BRCV“ “URCV“ ”GET“
(1 Corresponds to the total amount of user data for the SFB / FB in case of Indus-
trial Ethernet.
(2 corresponds to the maximum length of a data block of the respective system.
(3 Depending on the used CPU.
3.2 Configuration of a S7 connection
The S7 protocol is based on fixed configured connections stored within the

automation device. One as well as several connections to one connection
partner can be configured.
The following connection configurations are possible and can be used by
the following services:
Rev. A- Final 22.01.2004 8/33

Overview
Table 3-2: Possible connection configurations and services.
Service Configuration
PUT / GET (Read / Write) Unilaterally configured connection
USEND / URECEIVE Bilaterally configured connection
BSEND / BRECEIVE Bilaterally configured connection
For illustrating the structure within the automation devices a brief overview
of both configuration types:
Unilaterally configured connection

Unilaterally configured connection refers to a connection exclusively only
on the active site within the configuration.
Based on this principle, a fixed connection resource for the communication
is only assigned on the “active” side . The “passive“ side reacts to the re-
quest by the active partner and thus requires a resource only if that partner
establishes a connection.
A one-sidedly configured connection can be exclusively used for Write –
Read services. Those have been realized in the S7 controller as “PUT“ and
“GET“.
Bilaterally configured connection

Configurations with a fixed connection between both partners are consid-
ered bilaterally configured connections. This also depends on whether both
partners exist in the same Step 7 project.
The connection configuration causes both partners to reserve a fixed con-
nection resource for this communication, irrespective of whether the com-
munication partner is physically approachable or not.
For bilaterally configured connections two different services are available,
one uncoordinated (USEND / URECEIVE) and a block orientated (BSEND /
BRECEIVE) send/ receive service.
3.3 User Interface (block oriented service)
Overview
User interfaces of the S7 protocols can be divided into 3 groups:
• Read and write services
Read and write services have been realized within the S7 protocols as
“PUT“ and “GET“. They enable data to be read from or written to a control-
ler in a simple manner.
• Uncoordinated send and receive services
Rev. A- Final 22.01.2004 9/33

Uncoordinated send or received services are capable of exchanging a
block asynchronous and bi-directionally between two controllers using a bi-
laterally configured connection.
• Block oriented send and receive services
In the following chapters the block oriented send and receive services are
viewed individually.
Rev. A- Final 22.01.2004 10/33

Call parameter “BSEND“ SFB / FB 12
Fig. 3-8
Table 3-11: Parameter of the SFB / FB 12

Parameters Description
REQ Control parameter REQ for activating data exchange at
positive edge.
ID Address parameter ID from the connection configuration
R Control parameter Reset, activates canceling of a still run-

ning data exchange at positive edge.

R_ID Address parameter R_ID is responsible for sub-addressing
within an S7 connection. A send/ receive pair is defined
exclusively via ID and R_ID.
DONE Status parameter DONE, informs of the successful comple-
tion of the function via a positive edge.
ERROR Together with the parameter STATUS, the status parameter
ERROR indicates an occurred error.
STATUS The status parameter STATUS indicates the detailed infor-
mation of the current status of the block. A value not equal
0h and 19h without simultaneous ERROR display must be
interpreted as warning.
SD_1 Pointer to the source area within the local CPU
LEN Length of the data block to be sent
Note
The block BSEND of the S7 300 is available in the SIMATIC-Net-CP library as FB
12, within the S7300 program container.
As opposed to the S7 400 SFBs the FBs of the S7-300 can also be provided dy-
namically with parameters.
Rev. A- Final 22.01.2004 11/33

Description for “BSEND“
The SFB / FB 12 sends data to a distant partner – SFB / FB of the “BRCV“
type. During this data transfer, a larger amount of data can be transported
between the communication partners than possible with all other communi-
cation SFBs / FBs for configured S7 connections.
The transferred data areas are divided into sections corresponding to the
frame conditions of the used subnetwork. Each segment is sent to the part-
ner individually and acknowledged by the function block SFB / FB “BRCV“
which runs there.
As a limiting factor, only one SD parameter is possible in the S7 300.
Note
Please note that parameters SD_1 and RD_1 of the blocks interconnected via ID
and R_ID have been concordantly defined by you in
• length (LEN) and
• data type
Call parameter for “BRCV“ SFB / FB 13

Fig. 3-9
Table 3-12: Parameter of the SFB / FB 13

Parameters Description
EN_R Control parameter EN_R signals readiness for receiving if
the input has been set.
ID Address parameter ID from the connection configuration
R_ID Address parameter R_ID is responsible for sub-addressing
within an S7 connection. A send/ receive pair is defined
exclusively via ID and R_ID.
NDR Status parameter NDR, informs of the successful comple-
tion of the function via a positive edge.
ERROR Together with the parameter STATUS, the status parameter
ERROR indicates an occurred error.
STATUS The status parameter STATUS indicates the detailed infor-
mation of the current status of the block. A value not equal
Rev. A- Final 22.01.2004 12/33

0h and 19h without simultaneous ERROR display must be
interpreted as warning.
RD_1 Pointer to the target area within the local CPU
LEN Length of received data
Note
The block BRCV of the S7 300 is available in the SIMATIC-Net-CP library as FB
13, within the S7300 program container.
As opposed to the S7 400 SFBs the FBs of the S7-300 can also be provided dy-
namically with parameters.
Description for “BRCV“

The SFB / FB 13 “BRCV“ receives data from a distant partner – SFB / FB of
the “BSEND“ type.
Each received data segment is responded with acknowledgement to a
partner - SFB / FB and the parameter LEN is updated.
The block only becomes ready for receiving after calling the control param-
ter EN_R with a value of 1 (TRUE). Setting the parameter to 0 (FALSE)
cancels the currently running job or prevents a new send request from the
sender by means of a respective error message, partner SFB / FB has the
wrong status.
As a limiting factor, only one RD parameter is possible in the S7 300.
Note
Please note that parameters SD_1 and RD_1 of the blocks interconnected via ID
and R_ID have been concordantly defined by you in
• length (LEN) and
• data type
Consistency consideration for block-oriented send/ receive functions

Data are consistent as soon as they meet the consistency requirements
given for a data base.
The consistency requirement in case of the data transfer is completeness.
Data which were transferred completely, can be considered as consistent.
In case of the block oriented send/receive functions, functions are used on
both sides, therefore the sending and receiving sides have to be consid-
ered separately.
Rev. A- Final 22.01.2004 13/33

Table 3-1
Page Consistency
Send side In order to guarantee the data consistency of the data to
be transferred, the data area in the SD_1 send area must
not be written to for as long as the current send proce-
dure is running.
The completion of the current send procedure is indicated
by the status parameter DONE == TRUE.
Receiving side The transferred data are consistently provided in the tar-
get area as soon as the status parameter NDR takes on
the value TRUE. Prior to the next start of the receive
block, data need to be saved or the received data be
evaluated.
As soon as the receive block is started with an EN_R ==
TRUE, the target area can again, at least partially, be
written to.
3.4 Logical core structures – An example
Introduction
This example illustrates in a simple manner how, via one S7 connection,
data from four different source areas of an automation device can be trans-
ferred exclusively to several target areas of a remote automation device,
using the address parameter R_ID.
The following graphic illustrates the processes realized in this example.
Rev. A- Final 22.01.2004 14/33

Data flow model
Fig. 3-10
Significance of address parameter R_ID

For referencing data paths within a bilaterally configured connection the pa-
rameter R_ID is available in addition to the services USEND /URECEIVE
and BSEND / BRECEIVE.
This parameter is used for sub-addressing receive paths within a connec-
tion and can thus be compared with a TSAP of the FDL – or ISO transport
protocol.
Such a sub-addressing is meant to prevent using a different connection,
hence resource, for each transferred data set.
This principle can be visualized as a letter box. An S7 connection corre-
sponds to street name and house number, the R_ID corresponds to the
name on the letter box.
This example application uses this functionality.
Description of the processes

In the application, BSEND blocks are successively called on the send side
which transfer between 100 and 4700 bytes via an S7 connection using dif-
ferent R_IDs.
The initial send call is set by a trigger in the form of an input edge. Each fur-
ther send request is started by the status parameter DONE of the previous
BSEND block.
Rev. A- Final 22.01.2004 15/33

After running through all 4 BSEND calls, the sending is terminated.
On the receiving side, 4 BRCV blocks run successively which directly refer
to the BSEND blocks running on the sending side.
3.5 Program structures
In the following chapter the setup and structure of the example is discussed
on the function and datablock level of the automation system.
Presentation of block structure

Fig. 3-11
Description of block structure

For a quick illustration of principal functionalities, a simple structure is used
in this example.
All of the 4 send and receive blocks are directly called from the OB 1 and
therefore run cyclically.
For each FB / SFB definitely assigned instance data blocks are generated.
In the sending station, the data are taken from a “large“ data block and
stored into 4 different data blocks of the target station by the receive blocks.
Rev. A- Final 22.01.2004 16/33

On the sending side, each individual send block in OB1 must be started
successively in a step chain, as active parallel operation on one connection
is not possible.
On the receive side, the receive blocks run parallel, as this has no impact
on the protocol behavior and represents the most simple method of supply-
ing target areas.
Note
The receive blocks cannot, from the start of the CPU on, run on TRUE by means of
an EN_R, as they must first be initialized. This requires a run with EN_R equal
FALSE.
Rev. A- Final 22.01.2004 17/33

3.6 Program procedure of sender
Program procedure
Table 3-14: Program procedure sending part 1
Flowchart Description
Using an edge evaluation, input 1.0 triggers proc-
essing of the BSEND chain by triggering the first
BSEND block.
Processing of the four individual BSEND functions

always follows the same pattern and is illustrated in
table 3-2.
After the 4th BSEND request is completed, the step

chain is terminated.
Rev. A- Final 22.01.2004 18/33

Table 3-15: Program procedure Send part 2
Each of the four BSEND blocks has the following
structure, illustrated at the example of the BSEND
number 1:
If the function is started or a send request still ex-
ists, the BSEND block is performed with REQ equal
TRUE, whereby all other BSENDs are processed
with REQ equal FALSE.
Each one of the four BSEND requests has its own
instance data block which was configured for this
call only.
If there is no send request, the BSEND block with
REQ equal FALSE is called which is equal to it not
being processed.
If successfully sent, the local REQ of the send re-

quest is reset and the send request of the next
block is started. In case of a failure, the status in-
formation is temporarily stored and the step chain
interrupted.
Note
A positive edge is sufficient for triggering a send request.
Rev. A- Final 22.01.2004 19/33

Code excerpt from the first BSEND call
The next chapter illustrates the procedure generated in STL code using the
call of the first BSEND block.
Fig. 3-12
Describing the BSEND call

Each individual BSEND call is divided into two networks, the first network
prepares the user data length for the function call. The second network per-
forms the function call and checks the returned values.
The first network defines the length of the data to be transferred in a data
section, in this case “Send1_Length“. This is necessary as the parameter
LEN of the BSEND block is an input/ output parameter and must therefore
be describable, which is not possible with a default value.
In the second network, the BSEND function is called. The control parame-
ter are default, except for the REQ control parameter. The output parame-
ters are supplied with variables which are evaluated after executing the
block. The input/ output parameters are supplied according to the planned
length to be transferred.
After successful execution of the function, which is indicated by the output
parameter DONE, the local REQ control parameter is reset and the REQ
control parameter of the next block is set.
In case of a failure, indicated by the parameter ERROR, the status pending
at that moment is temporarily saved in a memory word.
Rev. A- Final 22.01.2004 20/33

3.7 Program procedure of the receiver
Program procedure
Table 3-16: Program sequence receiving
All BRECEIVE function calls are cyclically called in
the OB 1 program, in order to guarantee a maximal
possible variability.
Each receive block must also have its own instance
data block assigned to it.
The control parameter EN_R, which is switched

parallel for all receive blocks, is only switched to
TRUE after the first OB1 cycle in order to guarantee
the block being initialized.
Rev. A- Final 22.01.2004 21/33

Code excerpt BRECEIVE calls
The following code excerpt contains all BRECEIVE calls and shows the
simple interconnection for the receive functions.
Fig. 3-13
Rev. A- Final 22.01.2004 22/33

4 Installation of Hardware and Software
4.1 Hardware configuration
The components of both controllers are available in chapter 2 “Setting up

the Automation Solution”.
Table: 4-1 Hardware configuration

Step Focus Instruction
1 S7 Hardware Mount the S7 400 into the prepared rack according to the installation
guidelines.
2 S7 Hardware Mount the S7 300 to the rack rail according to the installation guide-
lines.
3 Bus cabling Install a prepared Profibus cable between the Profibus interfaces of
the CP 342-5 and the CP 443-5. Screw the connector into the re-
spective sockets.
4 Bus cabling Connect the MPI interfaces of both automating systems and the pro-
gramming interface of the PG via a prepared Profibus cable.
5 Bus cabling Ensure that the cabling end points of both bus systems are termi-
nated at both ends of the bus system using the matching resistors in
the connectors.
4.2 Installation of the software
STEP7
We will not go into the installation of STEP7 here. The installation takes
place in the familiar Windows environment and is self-explanatory.
Installation of the STEP7 project

Proceed as follows:
Table 4-2
Step No. Instruction Note / Explanation
1 Open the Step 7 manager.
2 Extract the project via the menu File -> Retreive... Search for the project
20987358_BSEND_PB_CODE
_v10.zip using the browser
function and acknowledge
with OK.
Rev. A- Final 22.01.2004 23/33

Step No. Instruction Note / Explanation
3 Select a directory into which the project files are to After extracting you are
be extracted. asked whether you wish to
open the project with Step 7,
acknowledge this query with
Yes.
4 After opening the project you open the project tree The project tree is located
of the project. on the left side of the
SIMATIC Manager and in
the top line it displays the
name of the project, in this
case S7Komm_PB_easy.
5 First select the S7-400 station in from the menu This function is also avail-
able via Ctrl + L or the menu
select the icon for loading the station “Target system“ -> “Load“
6 Now select the S7 300 station in from the menu This function is also avail-
able via Ctrl + L or the menu
also select the icon for loading the station “Target system“ -> “Load“
4.3 Operator control and monitoring

Introduction
A variable table is available for operating the example application. This en-
ables depicting the statuses of the individual function calls.
Activating the variable table

For displaying the variable table perform the following steps.
Table 4-3
No. Description
1 Open the Step 7 project.
2 Within the project tree of the “SIMATIC 400“ select the object VAT_1,
which is located on the right side of the SIMATIC Manager window, via
CPU 416-2 DP -> S7-Program(1) -> Block.
3 As illustrated in figure 4-1, double-clicking VAT_1 opens the prepared
variable table.
4
Pressing the button starts the “Monitor variables“ functions.
Rev. A- Final 22.01.2004 24/33

Variable table in the sender
Figure 4-1: Screenshot of variable table VAT_1
Rev. A- Final 22.01.2004 25/33

Control of data transfer
You can start the data transfer process from sender to receiver according
to the steps listed below.
Table 4-4 Control in the variable table

No. Instruction Note
1 Please activate the user variable table: See table 4-3
2 Alternatively the item
Pressing the button, see red marking in step 1 of table Control or the Ctrl +
4-5, sets the input “Startinput“ to TRUE by means of the vari- F9 keys can be used
able table, and thus the send process is started. via the Variables
menu.
3 The individual packages are now successively transferred,
which can be seen at the status value of the REQ Boolean
and the value 19h of the respectively active status.
Each BSEND block is displayed in the variable table with the following val-
ues:
• SendX_REQ
• DoneX_SendreqY
• ErrorX
• StatusX
• History SendX
Note
In case of an error, the status information is stored in the History memory of the
respective call as soon as the error occurs.
Sequence of a program run:

The following screenshot scenario shows the sequence of a complete
transmission.
Rev. A- Final 22.01.2004 26/33

Table 4-5 Sequence fo the transmission
Step
1 After opening the variable table and operating the „Monitor variables“ function, the
following screen appears:
Pressing the “Modify variables“ button, see red circle, starts the send procedure.
Rev. A- Final 22.01.2004 27/33

2
Step
Rev. A- Final 22.01.2004

The first BSEND block is active.
28/33
Step
3
After successful run of the first BSEND block, the second BSEND block is activated.
Rev. A- Final 22.01.2004 29/33

Step
4
After successful run of the second BSEND block, the third BSEND block is activated.
Rev. A- Final 22.01.2004 30/33

Step
5
After successful run of the third BSEND block, the fourth BSEND block is activated.
After terminating the 4th BSEND block, the step chain is terminated. The send pro-
cedure must be restarted with step 1 of this table.
Rev. A- Final 22.01.2004 31/33

Continuative Literature
• Manual: “Kommunikation mit SIMATIC “
(In product support under ID entry: 1254686).
• Manual: “Systemsoftware für S7-300/400 System- und Standardfunk-
tionen“
(In product support under ID entry: 1214574).
Rev. A- Final 22.01.2004 32/33

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

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

e-mail-address:
csweb@ad.siemens.de
Rev. A- Final 22.01.2004 33/33

S7 Communication Between S7-300 and S7-400 Via Profibus With BSEND / BRECEIVE

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

S7 Communication Between S7-300 and S7-400 Via Profibus With BSEND / BRECEIVE

Загружено:

Авторское право:

Доступные форматы

Application for Communication

S7 Communication between S7-300 and S7-400

4.1 Hardware configuration .............................................................................. 23

4.2 Installation of the software ......................................................................... 23

Rev. A- Final 22.01.2004 2/33

Technological task/ overview

Quantity framework of the sample application:

Rev. A- Final 22.01.2004 3/33

Display of involved components

Rev. A- Final 22.01.2004 4/33

Table 2-1 Used S7-400 components

Table 2-2: Used S7-300 components

Component MLFB / Order number Note

Table 2-3: Used PG components

On Board CP 5611 N/A Part of PG hardware.

Rev. A- Final 22.01.2004 5/33

Table 2-4: Software components used

Table 2-5: Used application components

code (except the system functions and

function blocks for BSEND and

20987358_BSEND_PB_DOKU_v10_d/e.pdf This documentation

Further information on commissioning hardware and software is available in chapter 4 “Installation of

Rev. A- Final 22.01.2004 6/33

3.1 The S7 protocol specifications

Physical independence of the S7 protocol

Position of the S7 protocol in the ISO / OSI reference model

Rev. A- Final 22.01.2004 7/33

Table 3-1: Characteristics of the S7 protocol

Data consistency 8 – 32 bytes / 32 8 – 32 bytes / 32 8 – 32 bytes / 32

S7-300/-400 bytes to total bytes to total bytes to total

3.2 Configuration of a S7 connection

The S7 protocol is based on fixed configured connections stored within the

Rev. A- Final 22.01.2004 8/33

Unilaterally configured connection

Bilaterally configured connection

3.3 User Interface (block oriented service)

Rev. A- Final 22.01.2004 9/33

Rev. A- Final 22.01.2004 10/33

Table 3-11: Parameter of the SFB / FB 12

R Control parameter Reset, activates canceling of a still run-

ning data exchange at positive edge.

Rev. A- Final 22.01.2004 11/33

Call parameter for “BRCV“ SFB / FB 13

Table 3-12: Parameter of the SFB / FB 13

Rev. A- Final 22.01.2004 12/33

Description for “BRCV“

Consistency consideration for block-oriented send/ receive functions

Rev. A- Final 22.01.2004 13/33

3.4 Logical core structures – An example

Rev. A- Final 22.01.2004 14/33

Significance of address parameter R_ID

Description of the processes

Rev. A- Final 22.01.2004 15/33

3.5 Program structures

Presentation of block structure

Description of block structure

Rev. A- Final 22.01.2004 16/33

Rev. A- Final 22.01.2004 17/33

Processing of the four individual BSEND functions

After the 4th BSEND request is completed, the step

Rev. A- Final 22.01.2004 18/33

If successfully sent, the local REQ of the send re-

Rev. A- Final 22.01.2004 19/33