S7 Communication With BSEND- BRECEIVE via Profibus CPs

Application for Communication

S7 Communication between S7-300 and S7-400 via Profibus CPs with BSEND / BRECEIVE and several Adressing Parameters (R_ID)

Rev. A- Final 22.01.2004 2/33

Cop

yrig

ht

Sie

men

s AG

200

5 A

ll rig

hts

rese

rved

20

9873

58_B

SEN

D_P

B_D

OKU

_v10

_e

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 4.1 Hardware configuration .............................................................................. 23 4.2 Installation of the software ......................................................................... 23 4.3 Operator control and monitoring ................................................................ 24 Continuative Literature .............................................................................................. 32

Rev. A- Final 22.01.2004 3/33

Cop

yrig

ht

Sie

men

s AG

200

5 A

ll rig

hts

rese

rved

20

9873

58_B

SEN

D_P

B_D

OKU

_v10

_e

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 4/33

Cop

yrig

ht

Sie

men

s AG

200

5 A

ll rig

hts

rese

rved

20

9873

58_B

SEN

D_P

B_D

OKU

_v10

_e

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 5/33

Cop

yrig

ht

Sie

men

s AG

200

5 A

ll rig

hts

rese

rved

20

9873

58_B

SEN

D_P

B_D

OKU

_v10

_e

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 6/33

Cop

yrig

ht

Sie

men

s AG

200

5 A

ll rig

hts

rese

rved

20

9873

58_B

SEN

D_P

B_D

OKU

_v10

_e

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 7/33

Cop

yrig

ht

Sie

men

s AG

200

5 A

ll rig

hts

rese

rved

20

9873

58_B

SEN

D_P

B_D

OKU

_v10

_e

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 8/33

Cop

yrig

ht

Sie

men

s AG

200

5 A

ll rig

hts

rese

rved

20

9873

58_B

SEN

D_P

B_D

OKU

_v10

_e

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-tures

BSEND / BRCV USEND / URCV PUT / GET

Max. data length S7-300 / S7-400

32 KB / 64 KB (2 440 bytes / 440 bytes (1

164 bytes / 400 bytes (1

Possible address areas S7-300 / S7-400

M, D / M, T, Z, E, A, D

M, D / M, T, Z, E, A, D

M, D / M, T, Z, E, A, D

Data consistency S7-300/-400

8 32 bytes / 32 bytes to total length (3



Communications service

Client / Client Client / Client Client / Server

Max. number of connections

See CPU specifi-cation



Block types SFB / FB 12 BSEND SFB / FB 13 BRCV

SFB / FB 8 USEND SFB / FB 9 URCV

SFB / FB 15 PUT SFB / FB 14 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 9/33

Cop

yrig

ht

Sie

men

s AG

200

5 A

ll rig

hts

rese

rved

20

9873

58_B

SEN

D_P

B_D

OKU

_v10

_e

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 10/33

Cop

yrig

ht

Sie

men

s AG

200

5 A

ll rig

hts

rese

rved

20

9873

58_B

SEN

D_P

B_D

OKU

_v10

_e

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 11/33

Cop

yrig

ht

Sie

men

s AG

200

5 A

ll rig

hts

rese

rved

20

9873

58_B

SEN

D_P

B_D

OKU

_v10

_e

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 12/33

Cop

yrig

ht

Sie

men

s AG

200

5 A

ll rig

hts

rese

rved

20

9873

58_B

SEN

D_P

B_D

OKU

_v10

_e

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 13/33

Cop

yrig

ht

Sie

men

s AG

200

5 A

ll rig

hts

rese

rved

20

9873

58_B

SEN

D_P

B_D

OKU

_v10

_e

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 14/33

Cop

yrig

ht

Sie

men

s AG

200

5 A

ll rig

hts

rese

rved

20

9873

58_B

SEN

D_P

B_D

OKU

_v10

_e

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 15/33

Cop

yrig

ht

Sie

men

s AG

200

5 A

ll rig

hts

rese

rved

20

9873

58_B

SEN

D_P

B_D

OKU

_v10

_e

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 16/33

Cop

yrig

ht

Sie

men

s AG

200

5 A

ll rig

hts

rese

rved

20

9873

58_B

SEN

D_P

B_D

OKU

_v10

_e

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 17/33

Cop

yrig

ht

Sie

men

s AG

200

5 A

ll rig

hts

rese

rved

20

9873

58_B

SEN

D_P

B_D

OKU

_v10

_e

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 18/33

Cop

yrig

ht

Sie

men

s AG

200

5 A

ll rig

hts

rese

rved

20

9873

58_B

SEN

D_P

B_D

OKU

_v10

_e

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 19/33

Cop

yrig

ht

Sie

men

s AG

200

5 A

ll rig

hts

rese

rved

20

9873

58_B

SEN

D_P

B_D

OKU

_v10

_e

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 20/33

Cop

yrig

ht

Sie

men

s AG

200

5 A

ll rig

hts

rese

rved

20

9873

58_B

SEN

D_P

B_D

OKU

_v10

_e

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 21/33

Cop

yrig

ht

Sie

men

s AG

200

5 A

ll rig

hts

rese

rved

20

9873

58_B

SEN

D_P

B_D

OKU

_v10

_e

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 22/33

Cop

yrig

ht

Sie

men

s AG

200

5 A

ll rig

hts

rese

rved

20

9873

58_B

SEN

D_P

B_D

OKU

_v10

_e

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 23/33

Cop

yrig

ht

Sie

men

s AG

200

5 A

ll rig

hts

rese

rved

20

9873

58_B

SEN

D_P

B_D

OKU

_v10

_e

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 24/33

Cop

yrig

ht

Sie

men

s AG

200

5 A

ll rig

hts

rese

rved

20

9873

58_B

SEN

D_P

B_D

OKU

_v10

_e

Step No. Instruction Note / Explanation

3 Select a directory into which the project files are to be extracted.

After extracting you are asked whether you wish to open the project with Step 7, acknowledge this query with Yes.

4 After opening the project you open the project tree of the project.

The project tree is located 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

select the icon for loading the station

This function is also avail-able via Ctrl + L or the menu Target system -> Load

6 Now select the S7 300 station in from the menu

also select the icon for loading the station

This function is also avail-able via Ctrl + L or the menu 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 25/33

Cop

yrig

ht

Sie

men

s AG

200

5 A

ll rig

hts

rese

rved

20

9873

58_B

SEN

D_P

B_D

OKU

_v10

_e

Variable table in the sender

Figure 4-1: Screenshot of variable table VAT_1

Rev. A- Final 22.01.2004 26/33

Cop

yrig

ht

Sie

men

s AG

200

5 A

ll rig

hts

rese

rved

20

9873

58_B

SEN

D_P

B_D

OKU

_v10

_e

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

Pressing the button, see red marking in step 1 of table 4-5, sets the input Startinput to TRUE by means of the vari-able table, and thus the send process is started.

Alternatively the item Control or the Ctrl + F9 keys can be used 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 27/33

Cop

yrig

ht

Sie

men

s AG

200

5 A

ll rig

hts

rese

rved

20

9873

58_B

SEN

D_P

B_D

OKU

_v10

_e

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 28/33

Cop

yrig

ht

Sie

men

s AG

200

5 A

ll rig

hts

rese

rved

20

9873

58_B

SEN

D_P

B_D

OKU

_v10

_e

Step

2

The first BSEND block is active.

Rev. A- Final 22.01.2004 29/33

Cop

yrig

ht

Sie

men

s AG

200

5 A

ll rig

hts

rese

rved

20

9873

58_B

SEN

D_P

B_D

OKU

_v10

_e

Step

3

After successful run of the first BSEND block, the second BSEND block is activated.

Rev. A- Final 22.01.2004 30/33

Cop

yrig

ht

Sie

men

s AG

200

5 A

ll rig

hts

rese

rved

20

9873

58_B

SEN

D_P

B_D

OKU

_v10

_e

Step

4

After successful run of the second BSEND block, the third BSEND block is activated.

Rev. A- Final 22.01.2004 31/33

Cop

yrig

ht

Sie

men

s AG

200

5 A

ll rig

hts

rese

rved

20

9873

58_B

SEN

D_P

B_D

OKU

_v10

_e

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 32/33

Cop

yrig

ht

Sie

men

s AG

200

5 A

ll rig

hts

rese

rved

20

9873

58_B

SEN

D_P

B_D

OKU

_v10

_e

Continuative Literature

Manual: Kommunikation mit SIMATIC (In product support under ID entry: 1254686).

Manual: Systemsoftware fr S7-300/400 System- und Standardfunk-tionen (In product support under ID entry: 1214574).

Rev. A- Final 22.01.2004 33/33

Cop

yrig

ht

Sie

men

s AG

200

5 A

ll rig

hts

rese

rved

20

9873

58_B

SEN

D_P

B_D

OKU

_v10

_e

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: [email protected]

TaskSetting up the Automation SolutionRequired Components

Function Mechanisms and Program StructuresThe S7 protocol specificationsConfiguration of a S7 connectionUser Interface (block oriented service)Logical core structures An exampleProgram structuresProgram procedure of senderProgram procedure of the receiver

Installation of Hardware and SoftwareHardware configurationInstallation of the softwareOperator control and monitoring

Continuative Literature

Documents

S7 Communication With BSEND- BRECEIVE via Profibus CPs