Application for Communication

Application for Communication Client-Server Communications between WinAC Basis and S7-200 Stations via S7 Communication (PUT/GET)

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

Table of Contents 1 Task... 4 2 Setup of the Automation Solution... 5 2.1 Required components... 5 3 Function Mechanisms and Program Structures... 7 3.1 Core properties of the S7 protocol and its services... 7 3.2 Configuration of an S7 connection... 8 3.3 User interface PUT / GET... 10 3.4 Principle structure of this example... 12 3.5 Program structures... 13 3.6 Program flow in the client station... 15 3.7 Server interface... 18 4 Installation of Hardware and Software... 19 4.1 Hardware configuration... 19 4.2 Installation of the software... 19 4.3 Core configurations of the application... 22 4.4 Operator control and monitoring... 24 Rev. A Final 22.01.2004 3/27

1 Task Technological task / overview Fig. 1-1 Via the MPI bus, a WinAC base station is connected to several S7-200 substations to which it sends data records upon their request. Requirements on the application The WinAC station is to provide small to medium-sized data records (parameter records) which e.g. variably control the response of the substations. If one of the substations requests a specific data record, the master station (WinAC) is to send this data record to the substation. In order to do this, an active polling mechanism is to access a passive bit interface of the substation on the master station side to determine whether a request has been made. The communication is to be effected using the S7 communications service PUT / GET via MPI. Rev. A Final 22.01.2004 4/27

2 Setup of the Automation Solution Display of the components involved The overview picture below shows the hardware setup of the sample application with the standard and user software components. Fig. 2-1 2.1 Required components Hardware components The following hardware components are required to use the application: Table 2-1 Component MLFB / Order number Note Power PG 6ES7750-2CA52-4FB4 S7-CPU 222 212-1BB22-0XB0 Or similar CPU, e.g. 221 On Board CP 5611 Part of the PG hardware MPI cable 6ES7 901-0BF00-0AA0 Rev. A Final 22.01.2004 5/27

Software components The following software components are required to use the application: Table 2-2 Component MLFB / Order number Note Standard software STEP7 V5.2 SP1 STEP7 Micro/Win 32 V3.2 SIMATIC NET V6.1 SP1 WinAC Basis V4.0 Windows 2000 SP3 or higher User software GS11.zip GS11.mwp 6ES7810-4CC06-0YX0 6ES7810-2BC02-0YX0 6GK1704-0AA06-3AA0 6ES7 671-0CC02-0YA0 Contained in the file 20987586_PutGet_S72 00_CODE_v10.zip Example project The user software components include STEP7 project GS11.zip Hardware configuration Connection configuration Immediately executable user program (STL) Operator interface (variable table) V 3.2.3.17 was used for this application Or operating system supported by STEP V5.2 SP1 STEP7 project Micro/Win project Micro/Win project GS11.mwp Immediately executable user program Operator interface (variable table) Chapter 4.2 Installation of the software includes installation instructions. Rev. A Final 22.01.2004 6/27

3 Function Mechanisms and Program Structures 3.1 Core properties of the S7 protocol and its services Physical independence of the S7 protocol The S7 protocol is a physically independent protocol. It allows 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 In the ISO / OSI 7 layer reference model for communication, the S7 protocol itself is located 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 they are provided by functions of the operating system. Rev. A Final 22.01.2004 7/27

Basic performance data of the S7 protocol services From a user point of view, the S7 protocol consists of the following services: PUT / GET BSEND / BRCV USEND / URCV The table below contains an overview of the respective performance data for the S7 families. The colored service is the service dealt with in this Getting Started; it will be described in detail in the following. Table 3-1 Services / Features Max. data length S7-300 / S7-400 Possible address areas Data consistency S7-300/-400 Communications principle Max. number of connections Block types PUT / GET BSEND / BRCV USEND / URCV 164 bytes / 400 32 KB / 64 KB 2) bytes 1) M, D / M, T, Z, E, A, D 8 32 bytes / 32 bytes to total length 3) M, D / M, T, Z, E, A, D 8 32 bytes / 32 bytes to total length 3) 440 bytes / 440 bytes 1) M, D / M, T, Z, E, A, D 8 32 bytes / 32 bytes to total length 3) Client / Server Client / Client Client / Client See CPU specification SFB / FB 15 PUT SFB / FB 14 GET See CPU specification SFB / FB 12 BSEND SFB / FB 13 BRCV See CPU specification SFB / FB 8 USEND SFB / FB 9 URCV 1) Corresponds to the total size of the 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 CPU used. 3.2 Configuration of an S7 connection The S7 protocol is based on fixed configured connections which were stored in the programmable logic control. One as well as several connections can be configured for one connection partner. The following connection configurations are possible and can be used by the following services: Rev. A Final 22.01.2004 8/27

Overview Table 3-2 B e l o Service PUT / GET (Read / Write) USEND / URECEIVE BSEND / BRECEIVE Configuration Unilaterally configured connection Bilaterally configured connection Bilaterally configured connection Below, a brief overview of both configuration types is given to illustrate the structure in the programmable logic controls. Unilaterally configured connection Unilaterally configured connection refers to a connection which was exclusively stored on the active side in the configuration (WinAC base station in our example). Based on this principle, a fixed connection resource for the communication is only assigned on the active side. The passive side reacts to the requests of the active partner and thus only requires a resource if that partner establishes a connection. A unilaterally configured connection can be used exclusively for write read services. These services are realized in the S7 as PUT and GET. Unilaterally configured connections are used for client-server communications. Bilaterally configured connection Configurations in which both connection partners have created a fixed connection between each other in the connection configuration (client-client connection) are considered bilaterally configured connections. This is also independent of whether both partners possibly exist in the same project. The connection configuration causes both communication partners to reserve a fixed connection resource for this communication, irrespective of whether the communication partner is physically approachable or not. Two different services are available for bilaterally configured connections, an uncoordinated (USEND / URECEIVE) and a block-orientated (BSEND / BRECEIVE) send / receive service. Rev. A Final 22.01.2004 9/27

3.3 User interface PUT / GET In this Getting Started, the PUT/GET service is used as user interface for the S7 protocol. PUT/GET is a unidirectional write / read service for the transmission of small aggregates between two stations. SFB15 PUT The figure below shows the parameterization of the SFB15 PUT block. Table 3-3 Fig. 3-2 The individual parameters will be described in the following. Parameters Declara tion Description REQ IN Activates the data exchange in case of positive edge. ID IN Connection ID is taken from the connection configuration. DONE OUT Positive edge on DONE indicates the error-free execution of the function. ERROR OUT Together with the parameter STATUS, the status parameter ERROR indicates an error. STATUS OUT Delivers a warning if ERROR = 0 or detailed information on the type of the error if ERROR = 1. ADDR_i SD_i IN-OUT Pointer on those areas in the partner CPU onto which is to be written. IN-OUT Pointer on those areas in own CPU which contain the data to be sent. Rev. A Final 22.01.2004 10/27

SFB14 GET The figure below shows the parameterization of the SFB14 GET block. Fig. 3-3 The individual parameters will be described in the following. Table 3-4 Parameters Declara tion Description REQ IN Activates the data exchange in case of rising edge. ID IN Connection ID is taken from the connection configuration. NDR OUT Positive edge on NDR indicates the successful completion of a command. ERROR OUT Together with the parameter STATUS, the status parameter ERROR indicates an error. STATUS ADDR_i RD_i IN-OUT Delivers a warning if ERROR = 0 or detailed information on the type of the error if ERROR = 1. IN-OUT Pointer on those areas in the partner CPU which are to be read. IN-OUT Pointer on those areas in own CPU in which the read data are to be stored. Rev. A Final 22.01.2004 11/27

3.4 Principle structure of this example Introduction This example illustrates in a simple manner how data from one of three different source areas on a programmable logic control can be transferred into a target area in a remote programmable logic control via one S7 connection. The following data flow model illustrates the sequence realized in this example. Data flow model Fig. 3-4 Description of the sequence The data transmission is started when the server CPU requests a new data record by means of a request bit. Using a GET call, the client cyclically polls whether there is a request. If this is the case, SFB15 PUT is called on the client side; SFB15 PUT is parameterized with a pointer on one of the three DBs (101, 102 or 103) depending on the requested data record. The connection ID (R_ID) is identical in each case. SFB PUT writes the data record into the target area (DB1) of the server CPU. Rev. A Final 22.01.2004 12/27

3.5 Program structures This chapter describes the program structure of the example with regard to the function and data block level of the automation system. Representation block structure The figure below illustrates the call hierarchy of all blocks used in this example as well as the access to the data blocks used. Fig. 3-5 Description block structure Only DB1 is displayed on the server side, since there is only one passive interface which the client accesses. On the client side, FC1 COMMUNICATION is called cyclically by OB1 which cyclically calls SFB14 GET to access the passive bit interface of the server. That way, the client determines whether there is a request for a new data record. Due to the call of SFB15 PUT, the requested data record is subsequently sent into DB1 of the server, Rev. A Final 22.01.2004 13/27

OB35 is called at intervals of 1000ms and provides the trigger for the cyclic polling of the server s bit interface in order in order to check whether there is a request. The actual polling takes place in OB1. Data blocks used Table 3-5 Name Client DB2 ERROR_LOG DB14 DB15 DB101 DATA_RECORD1 Application If an error occurs during the execution of the functions PUT or GET, the function status is stored in this DB. Instance DB for SFB14 Instance DB for SFB15 Contains the first data record DB102 DATA_RECORD2 DB103 DATA_RECORD3 Server DB1 Contains the second data record Contains the third data record Variable area of the S7-200 CPU. In this example, it contains 3 bytes functioning as passive communication interface as well as 100 bytes memory space as target area for the received data. Rev. A Final 22.01.2004 14/27

3.6 Program flow in the client station Flowchart The flowchart below shows the program flow on the client side. The communication functionality is integrated in FC1 COMMUNICATION which is called cyclically by OB1. FC1 is realized as single interface. Table 3-6 Flowchart Explanation First, the request bit of the server station is read using the GET function and it is checked whether there is a request. This process is repeated until a request is detected. Subsequently, an Any pointer is created which points to the requested data record. This pointer is then used during the call of the PUT function to send the data record to the server. Sending the data record is effected asynchronously, i.e. the function is called until a bit indicates the completion of the function. If the data record was sent without errors, the server receives an OK bit as acknowledgement. Rev. A Final 22.01.2004 15/27

Code excerpt FC1 COMMUNICATION call of the GET function The following code excerpt is responsible for the so-called polling of the communication partner: Once a second, a new read request determining whether a request for a data record exists in the partner is triggered with the positive edge on REQ. The read procedure is started with a positive edge on this bit once a second. TRUE indicates that the function has been completed. Indicates which bytes of the partner CPU (S7-200) are to be read. Fig. 3-6 Receive area on the local CPU (WinAC) in which the read data are to be stored. In case of an error, the status of the function is stored in a DB and the function is completed. If there is a request of the server (read in M 0.7), the RequestFrom Server bit is set. Rev. A Final 22.01.2004 16/27

Code excerpt FC1 COMMUNICATION call of the PUT function In the following code excerpt, the requested data record is sent to the partner CPU. A positive edge is required after a null run in order to start the write procedure. Target area for the data record in the partner CPU This data record is to be sent to the partner CPU. Fig. 3-7 In case of an error, the status of the function is stored in a DB and the function is completed. If the execution of the function is completed, the next step is started. Rev. A Final 22.01.2004 17/27

Code excerpt FC1 COMMUNICATION sending the acknowledgement In the following code excerpt, the acknowledgement is sent to the partner CPU. The write procedure is started after the function at the REQ input receives the value TRUE after a null run. Target area for the OK bit in the partner CPU (server) This byte contains the OK bit and is to be sent to the partner CPU (server). Fig. 3-8 3.7 Server interface In case of an error, the status of the function is stored in a DB and the function is completed. If the execution of the function is completed, the next step is started. Functionality A program is not required on the side of the server, there is only a passive interface in the variable area (DB1) which is set up as follows: Table 3-7 Symbolic name Address Explanation Request V 0.7 If this bit is set to TRUE, a new data record request is made. DataRecord VB 1 Specifies the number of the requested data record (here: 1, 2 or 3). OK V 2.6 This bit is set to TRUE by the client, if the transmission of a data record was complete and error-free. Rev. A Final 22.01.2004 18/27

4 Installation of Hardware and Software 4.1 Hardware configuration Table 4-1 Step The components of the hardware configuration are listed in chapter 2.1 Required components. Action 1 Connect the MPI interface of the PG to the MPI interface of the CPU via the MPI cable. 2 Supply power to the CPU. 4.2 Installation of the software Standard software At this point, we will not go into the installation of STEP7, Micro/Win and WinAC. The installation takes place in the familiar Windows environment and is self-explanatory. Setting the PG/PC interface Before the project can be loaded into the control, the PG/PC interface has to set according to the steps described below. Tabe 4-2 Step No. Action Screenshot / Note 1 Open the SIMATIC Manager. 2 Open the dialog box of the same name via the Options > Set PG/PC Interface menu and set PC internal (local) as access point of the application. 3 Acknowledge the dialog box with "OK". Rev. A Final 22.01.2004 19/27

Configuring WinLC station You have to configure the PC station before you can load the STEP7 project into the WinLC. This requires the following steps: No. Action Screenshot / Note 1 Start the station configurator via Start > Station Configurator. 2 Make sure that the component WinLC is entered on slot 2 and that CP5611 is entered on slot 3. 3 Click Station Name. In accordance with the hardware configuration of the STEP7 project. 4 Enter SIMATIC PC-Station. Note These steps have to be performed prior to the start of the WinLC. Rev. A Final 22.01.2004 20/27

Loading the STEP7 project In order to load the STEP7 project into the WinAC controller, proceed as follows: Table 4-3 Step No. Action Screenshot / Note 1 Retrieve the file 20987586_PutGet_S7200_CODE_v10.zip into a user-definable directory. 2 Start the WinAC controller via Start > SIMATIC > PC Based Control > WinLC. This zip-file contains the files GS11.zip and GS11.mwp. 3 Retrieve the project via the File > Retrieve... menu Search for the GS11.zip project using the browser function and acknowledge with OK. 4 Select a directory into which the project files are to be retrieved. 5 After opening the project, open the project tree of the project. 6 Click SIMATIC PC-Station in the project tree and After retrieving you are asked whether you wish to open the project with Step 7, acknowledge this query with Yes. load the program into the WinLC controller via or PLC > Download. 7 Switch the WinAC controller to RUN. Rev. A Final 22.01.2004 21/27

Loading the MicroWin project In order to load the Micro/Win project into the S7-200 CPU, proceed as follows: Table 4-4 Step No. Action Screenshot / Explanation 1 Open the Micro/Win project GS11.mwp. 2 Open the dialog box of the same name by clicking the Communications button and make sure that Micro/Win has an access point to the control via CP5611(PROFIBUS). Define the settings as illustrated below. 3 Click or the File > Download menu item. 4 Set all checkmarks in the following dialog box and acknowledge this dialog box and the two following dialog boxes with OK. The program is loaded into the control. 5 Switch the S7-200 CPU to RUN. 4.3 Core configurations of the application Connection configuration The application on hand receives a fixed configured connection which is required by the PUT/GET S7 communications service used here. The table below shows how to configure such a connection. Rev. A Final 22.01.2004 22/27

Note The following connection configuration is already contained in the project. The purpose of the configuration instructions is to familiarize with the procedure. Table 4-5 Step Action 1 Open the STEP7 project GS11, click GS11 in the project tree and open NetPro by clicking the MPI network. 2 Select WinLC. 3 Select Insert > New Connection. 4 In the following dialog box select - Connection Partner: unspecified - Connection Type: S7 connection 5 Acknowledge with OK. 6 Edit the following dialog box as shown in the screenshot. Step Action 7 Acknowledge the dialog box with OK and save and compile the connection configuration by clicking Compile. or with the menu item Network > Save and Rev. A Final 22.01.2004 23/27

4.4 Operator control and monitoring Introduction The application is operated and monitored via the variable tables contained in the example. Activating the variable tables In order to be able to control and monitor the process, activate the variable tables as follows: Note Requirement: The steps described in chapter 4 Installation of Hardware and Software have been performed. Table 4-6 No. Description 1 Open the STEP7 project GS11 and open the variable table VAT_1 in the block folder by double-clicking. 2 Select the menu item Variable > Monitor or click. 3 Open the Micro/Win project GS11.mwp and open the variable table CHT1 by clicking the Status Chart button. 4 Select the menu item Debug > Chart Status or click. 5 Now you can monitor both variable tables and modify values. Rev. A Final 22.01.2004 24/27

Variable table in the client Fig. 4-1 Meaning of the variables (client) The variables have the following meaning: Symbol LookForRequest RequestFromServer DataRecordNumber DataBlockNumber DONE_put ERROR_put STATUS_put NDR_get ERROR_get STATUS_get STEP1 STEP2 STEP3 Meaning This bit is set once per second and used as trigger for the polling of the server station. In every rising edge it is checked whether there is a request. TRUE: There is a request from the server. Number of the requested data record Number of the DB in which the required data record is located. Return value of the PUT function. For details, see chapter 3.1.2 User interface for this protocol. Return values of the GET function. For details, see chapter 3.1.2 User interface for this protocol. The function FC1 COMMUNICATION is executed as sequence chart. These bits indicate which step is currently active. Rev. A Final 22.01.2004 25/27

Variable table in the server The figure below shows the variable table CHT1 of the Micro/Win project. Fig. 4-2 Meaning of the variables (server) The variables have the following meaning: Symbol / Address OK Request DataRecord VB3, VB4,...VB102 Meaning If this bit has the value 1, the respective data record has been received without errors upon the last request. A positive edge on this bit represents a new data record request. It can be indicated which data record is to be requested (data record 1, 2 or 3 in our example). The client writes the requested data into this memory area. Rev. A Final 22.01.2004 26/27

Modification of the data transfer You can start the data transfer process from client to server according to the steps listed below. Table 4-7 No. Action Figure / Result 1 Open the status chart CHT1 of the Micro/Win project. 2 Enter e.g. the value 3 for DataRecord into the New Value column and set Request to 1. Note: Only the values 1, 2 or 3 may be entered for DataRecord. 3 Click or in the menu Debug > Write all. 4 Click or in the menu Debug > Single Read. The values are accepted into the control. Now, you see that the requested data were received. The OK bit indicates that the send procedure was completed without errors and completely. 5 Modify the OK bit and the Request bit back to 0 before you transmit a new request. Rev. A Final 22.01.2004 27/27