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

d e v r e s e e _ r s 0 1 t h v g _ i r U l l K A O 5 D _ 0 B 0 2 P _ G D A N s E n S e B m _ e 8 i S 5 3 7 © t 8 h 9 g 0 i r 2 y p o C

1

Task ...................................................... .......................... ......................................................... ....................................................... .......................... 3

2

Setting up the Automation Solution ........................................................ ............................ .............................. 4

2.1

Required Components Components ........................................................ ............................ ..................................................... ......................... 5

3

Function Mechanisms and Program Structures ..................................... .......................... ........... 7

3.1

The S7 protocol specifications ....................................................... ........................... .......................................... .............. 7

3.2

Configuration of a S7 connection......................... connection .................................................... ........................................ ............. 8

3.3

User Interface (block oriented service) ..................................................... ........................ ................................ ... 9

3.4

Logical core structures – An example ...................................................... ........................... ............................. .. 14

3.5

Program structures............................... structures........................................................... ...................................................... .......................... 16

3.6

Program procedure of sender ........................................................ ............................ ........................................ ............ 18

3.7

Program procedure of the receiver ......................................................... ............................. ............................... ... 21

4

Installation of Hardware and Software................................... Software..... .............................................. ................ 23

4.1

Hardware configuration............................. 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

2/33

1

Task

Technological task/ overview The following example illustrates simple coupling of two S7 controllers using 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

Data quantity

1. Area

2. Area

3. Area

4. Area

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 coordinated data transfer via a configured connection. 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. 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 6ES7400-1JA01-0A A0

Any UR or CR may be used here.

PS 407 10A

6ES7407-0KA01-0AA0 6ES7407-0KA01-0AA 0

Any PS with sufficient suffici ent 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

Component

MLFB / Order number

Note

PS 307 2A

6ES7307-1BA00-0AA0 6ES7307-1BA00-0AA 0

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.

Component

MLFB / Order number

Note

Power PG

6ES7750-2CA52-4FB4

See PG configurator in A&D Mall

Table 2-3: Used PG components

On Board CP 5611

Rev. A- Final 22.01.2004

N/A

Part of PG hardware.

5/33

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

Component

MLFB / Order number

Step 7 V 5.2

6ES7810-4CC06-0YX0

NCM S7 Profibus

N/A

Note 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 configuration for both stations, the connection configuration 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 20987358_BSEND_PB_DOKU_v10_d /e.pdf

This documentation

Further information on commissioning hardware and software is available i n chapter 4 “Installation of Hardware and Software“. 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 networks:


▪

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 performance data of S7 protocol services From a user point of view, the S7 protocol consists of the following services: •

BSEND / BRCV

•

USEND / URCV

•

PUT / GET

The following table contains an overview of the respective performance performance data for the S7 families. The colored service is the topic of this Getting Startet and is discussed in greater detail below. Table 3-1: Characteristics of the S7 protocol


Services/ Features

BSEND / BRCV

Max. data length S7-300 / S7-400

32 KB / 64 KB

Possible address areas S7-300 / S7-400

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

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

Data consistency S7-300/-400

8 – 32 bytes / 32 bytes to total (3 length



Communications service

Client / Client

Client / Client

Client / Server

Max. number of connections

See CPU specification

See CPU specifi- See CPU specification cation

Block types

SFB / FB 12 “BSEND“

SFB / FB 8 “USEND“

SFB / FB 15 ”PUT“

SFB / FB 13 “BRCV“

SFB / FB 9 “URCV“

SFB / FB 14 ”GET“

(2

USEND / URCV

PUT / GET

440 bytes / 440 (1 bytes

164 bytes / 400 (1 bytes

(1 Corresponds Corresponds to the total amount of user data for the SFB / FB in case of Industrial 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 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 Bilaterall y 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 connection refers to t o a connection exclusively 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 request by the active partner and thus requires a resource only if that partner establishes a connection. d e v r e s e e _ r s 0 1 t h v g _ i r U l l K A O 5 D _ 0 B 0 2 P _ G D A N s E n S e B m _ e 8 i S 5 3 7 © t 8 h 9 g 0 i r 2 y p o C

A one-sidedly configured configured connection can can be exclusively used for Write – Read services. Those have been realized in the S7 controller as “PUT“ and “GET“. Bilaterally configured connection Configurations Configurations with a fixed connection between both partners are considered 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 connection resource for this communication, irrespective of whether the communication 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 controller in a simple manner. •

Uncoordinated send and receive services

Rev. A- Final 22.01.2004

9/33

Uncoordinated Uncoordinated send or received services are capable of exchanging a block asynchronous and bi-directionally between two controllers using a bilaterally configured connection. •

Block oriented send and receive services

In the following chapters the block oriented send and receive services are viewed individually. 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 running data exchange at positive edge.

R_ID

Address parameter R_ID is responsible for sub-addressing 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 completion 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 information 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 dynamically 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 communication SFBs / FBs for configured S7 connections. connections. The transferred data areas are divided into sections corresponding corresponding to the t he frame conditions of the used subnetwork. Each segment is sent to the partner individually and acknowledged 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 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 completion 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 information 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 LEN

Pointer to the target area within the local CPU 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 dynamically with parameters.

Description for “BRCV“ The SFB / FB 13 “BRCV“ receives data from a distant partner – SFB / FB of the “BSEND“ type. d e v r e s e e _ r s 0 1 t h v g _ i r U l l K A O 5 D _ 0 B 0 2 P _ G D A N s E n S e B m _ e 8 i S 5 3 7 © t 8 h 9 g 0 i r 2 y p o C

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 paramter 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. 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 considered 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 procedure 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 target 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 t he 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 transferred 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 configured connection the parameter R_ID is available in addition to the services USEND /URECEIVE and BSEND / BRECEIVE. This parameter is used for sub-addressing sub-addressing receive paths within a connection 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 corresponds 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 different R_IDs. The initial send call is set by a trigger in the form of an input edge. Each further 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, 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 t he 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 supplying 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 processing 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. d e v r e s e e _ r s 0 1 t h v g _ i r U l l K A O 5 D _ 0 B 0 2 P _ G D A N s E n S e B m _ e 8 i S 5 3 7 © t 8 h 9 g 0 i r 2 y p o C

th

After the 4 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

Flowchart

Description 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 exists, 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 request is reset and the send request of the next block is started. In case of a failure, the status information 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 performs 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 t he BSEND function is called. The control parameter are default, except for the REQ control parameter. The output parameters 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

Flowchart

Description 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”. 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 guidelines.

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 respective sockets.

4

Bus cabling

Connect the MPI interfaces of both automating systems and the programming interface of the PG via a prepared Profibus cable.

5

Bus cabling

Ensure that the cabling end points of both bus systems are terminated 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

1

Open the Step 7 manager.

2

Extract the project via the menu File -> Retreive...

Note / Explanation 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

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. 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 select the

6

icon for loading the station

Now select the S7 300 station in from the menu also select the


4.3

Note / Explanation

icon for loading the station

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

Operator control and monitoring

Introduction A variable table is available for operating the example application. This enables 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

Rev. A- Final 22.01.2004

button starts the “Monitor variables“ functions.

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 via the Variables able table, and thus the send process is started. 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 values: d e v r e s e e _ r s 0 1 t h v g _ i r U l l K A O 5 D _ 0 B 0 2 P _ G D A N s E n S e B m _ e 8 i S 5 3 7 © t 8 h 9 g 0 i r 2 y p o C

•

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. procedure.

Rev. A- Final 22.01.2004

27/33

Step 2


The first BSEND block is active.

Rev. A- Final 22.01.2004

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 s econd 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. th After terminating the 4 BSEND block, the step chain is terminated. The send procedure must be restarted with step 1 of this table.

Rev. A- Final 22.01.2004

31/33

Continuative Literature •

•

Manual: “Kommunikation “Kommunikation mit SIMATIC “ (In product support under ID entry: 1254686 1254686)). Manual: “Systemsoftware für S7-300/400 System- und Standardfunktionen“ (In product support under ID entry: 1214574 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 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, liability, e.g. under the German Product Liability Act (“Produkthaftungsgesetz”), (“Produkthaftungsgesetz”), in case of intent, gross negligence, or injury of life, body or health, guarantee for the quality of a product, fraudulent concealment concealment of a deficiency or breach of a condition which goes to the root of the contract (“wesentliche Vertragspflichten”). 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 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 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: [email protected]

Rev. A- Final 22.01.2004

33/33

S7 Communication between S7-300 and S7-400 via Profibus with BSEND / BRECEIVE

Recommend Documents