show the entry list

S7-400 CPU 41x -- Configuring and programming communication -- Using communication blocks 
What is the difference between the initialization and runtime parameters on the blocks for Modbus TCP? 
Why is the status value A090 (hex) output for Modbus TCP although you have entered the correct license? 
What are the differences between the licensed version and the downloadable demo version of the blocks for Modbus TCP? 
Why is the value A083 (hex) output permanently at the STATUS output parameter of the block for Modbus TCP when the ENQ_ENR=true input parameter has been set? 
Which blocks for Modbus TCP can you rename or re-wire when the block numbers of the Mode blocks are already being used in the user program? 
How can you read out diagnostics data from a SIRIUS 3RK3 modular safety system using a S7-300/400 CPU? 
Which communication options are there in SIMATIC S7? 
How does data communication work between S7-300/S7- 400 and S7-200 via MPI using S7 basic communication? 
Consistent data in S7-400, summary of mechanisms 
Which ports are released for Modbus/TCP communication and how many Modbus clients can communicate with a SIMATIC S7 CPU as Modbus server? 
How do you implement chronological messaging with S7-400 CPUs and WinCC? 
How do you configure a specified and an unspecified S7 connection for data exchange between S7-300 and/or S7-400 by way of Industrial Ethernet CPs? 
How can you establish OPEN MODBUS / TCP communication from a SIMATIC S7 and where can you find further information? 
How do you use WinCC flexible to transfer a project to an operator panel via S7 routing? 
What restrictions are there for active jobs when communicating with SFC 58 / SFC 59 and SFB 52 / SFB 53 via PROFIBUS DP and PROFINET IO? 
How do you program the communication blocks FB63 "TSEND", FB64 "TRECV", FB65 "TCON" and FB66 "TDISCON" in order to use the ISO-on-TCP protocol for data exchange by way of the integrated PROFINET interface of a CPU or by way of the CP443-1 Advanced? 
How do you program the communication blocks FB63 "TSEND", FB64 "TRCV", FB65 "TCON" and FB66 "TDISCON" in order to use the TCP protocol for data exchange by means of the integrated PROFINET interface of an S7-300 or S7-400 CPU? 
How do you program the communication blocks FB67 "TUSEND", FB68 "TURCV", FB65 "TCON" and FB66 "TDISCON" in order to use the UDP protocol for data exchange by means of the integrated PROFINET interface of a CPU? 
How can you access consistent data without SFC14/15 as part of the process image? 
How great is data consistency in the PUT and GET S7 communication functions for the individual S7-400 CPUs? 

What is the difference between the initialization and runtime parameters on the blocks for Modbus TCP?Go to beginning
Part number:

Description
In this entry we describe the differences between the initialization and runtime parameters of the blocks for Modbus TCP. The Modbus blocks are called in the user program of the SIMATIC S7 for the communication.

The initialization parameters are written in lowercase characters. This makes it easier to distinguish them from the runtime parameters. The initialization parameters are only evaluated when called in OB100 and transferred to the instance data block of the Modbus block. Changing the initialization parameters during runtime has no effect, because only the stored value is processed. The initialization parameters specify what is possible. If you change these parameters, in Test mode, for example, the instance data block has to be re-initialized by a restart of the CPU (STOP > RUN).
In the initialization parameters, the data type of the Modbus register is specified (data_type_1), for example. Furthermore, the initialization parameters define whether the CPU is server or client (server_client).

The runtime parameters are written in uppercase characters. They can be changed in cyclic mode. The runtime parameters specify the current job.
In the "CPU/CP is client" mode, however, it is not useful to change the input parameters while a job is running. You should wait with the preparations for the next job and the associated change of parameters until the previous job has been terminated with DONE_NDR or ERROR.
In the "CPU/CP is server" mode you can only evaluate the output parameters if DONE_NDR is set.
The output parameters are dynamic displays and therefore apply only for 1 CPU cycle. For any necessary further processing or display in the variable table they must be stored in a different memory area.

Why is the status value A090 (hex) output for Modbus TCP although you have entered the correct license?Go to beginning
Part number:

Description
Below are the reasons why the status value A090 (hex) is output for Modbus TCP although you have entered the correct license.

  • You have not inserted the FC10 "EQ_STRNG" function in the project or the "EQ_STRNG" function has a different FC number.
  • You have entered the license key only in the Data View of the license data block.

Proceed as below to clear the reasons for output of the status value A090 (hex).

  • Make sure that you have inserted the FC10 "EQ_STRNG" function in your project. This is available in the Standard Library of STEP 7 under IEC Function Blocks -> Blocks. If the FC number is already being used in the user program, you must re-wire the "EQ_STRNG" function with the new FC number in the Modbus blocks.
  • If the license key is entered in the Data View of the license data block, this is overwritten with the initial value when the CPU is restarted. Therefore, you must enter the license key as the initial value in the Declaration View. Then the license key can be initialized in the Data View.

What are the differences between the licensed version and the downloadable demo version of the blocks for Modbus TCP?Go to beginning
Part number:

Description
A demo version of the S7 Open Modbus TCP software for connecting a SIMATIC controller to systems of different manufacturers is available at the link below.

S7 OpenModbus/TCP

The downloadable demo version has no function or time restrictions. Modbus communication can also run without a valid license.
If the Modbus blocks are not licensed, the INTF LED or SF LED of the CPU flashes. In addition, messages are entered cyclically in the diagnostics buffer of the CPU and the status value A090 (hex) is output on the Modbus block in the user program.

Why is the value A083 (hex) output permanently at the STATUS output parameter of the block for Modbus TCP when the ENQ_ENR=true input parameter has been set?Go to beginning
Part number:

Description
The products below with the corresponding Modbus blocks are available for Modbus communication with the SIMATIC S7.
 
Product Modbus block
Modbus TCP CP FB108
Modbus TCP Redundant FB1733
Modbus TCP Redundant V2 FB909, FB907
Modbus TCP PN CPU FB102

You call the relevant Modbus block in the user program of the CPU.
You set the ENQ_ENR=true input parameter and the value A083 (hex) is permanently at the STATUS output parameter of the Modbus block.

The value A083 (hex) at the STATUS output parameter means that a new Modbus message has been triggered with the input parameter ENQ=true or ENQ_ENR=true, although the previous task is still running.

Below we describe the causes of the status value A083 (hex) and the remedies you can apply.

  • The value A083 (hex) only occurs at the STATUS output parameter when the Modbus block has been parameterized as client. If the status value A083 (hex) is output even though the S7 CPU is supposed to be working as server, then you must correct the parameterization of the Modbus block in OB100.
  • Triggered Modbus messages are always terminated with DONE / DONE_NDR or ERROR. No new message may be triggered while a message is being processed.
  • If the server for the S7 CPU is no longer accessible while a Modbus job is running, the status value A083 (hex) might be present after reconnection. In this case, insert the line below when setting ENQ_ENR:

    O "CONTROL DAT".DONE_NDR
    O "CONTROL DAT".ERROR
    UN "CONTROL DAT".BUSY
    S "CONTROL DAT".ENQ_ENR

Which blocks for Modbus TCP can you rename or re-wire when the block numbers of the Mode blocks are already being used in the user program?Go to beginning
Part number:

Description
The blocks that are available for Mode communication with SIMATIC S7 are delivered with a unique block number.
If there are already blocks in the user program that have these block numbers, there is a block number conflict.

You can rename the Mode blocks that are called directly in the user program.

You cannot rename the blocks that are called internally in the Mode blocks. You have to re-wire those blocks.

The table below shows the Mode blocks that you can rename or re-wire.
 
Product Mode block > rename Internally called block > re-wire
Modbus TCP CP FB108 FB106, FB107
Modbus TCP Redundant FB1733 FB1734
Modbus TCP Redundant V2 FB909, FB907 FB908, FB906
Modbus TCP PN CPU FB102 FB103, FB104, FB105
Table 01

You must follow a specific order when re-wiring the blocks that are called internally in the Mode blocks. This order must be kept in particular when re-wiring the T blocks in the case of Modbus TCP PN CPU.

  • T blocks
  • Internally called blocks (FB106, FB107, FB1734, FB908, FB906, FB103, FB104, FB105)
  • Remaining blocks

You do not have to re-wire all the blocks. Even if you re-wire only a few internally called blocks, you must nevertheless keep to the order given above. In this case, you leave out the blocks that are not re-wired.

How can you read out diagnostics data from a SIRIUS 3RK3 modular safety system using a S7-300/400 CPU?Go to beginning
Part number:

Description
The "MSS_DIAG" block available for downloading in this FAQ permits you to diagnose a SIRIUS 3RK3 modular safety system(MSS) from an S7-300/400 controller. Here, the block reads out specific data records in the MSS and stores the diagnostics data in an associated instance data block. You can read out the diagnostics data from this data block and use it in the user program or have it displayed on an HMI.


Fig. 01: Communication setup between a SIMATIC S7 controller and an MSS

Downloads
40631654_S7_Diagnostic_FB_for_MSS_en.pdf ( 322 KB )

40631654_S7_Diagnostic_FB_for_MSS.zip ( 51 KB )

Which communication options are there in SIMATIC S7?Go to beginning
Part number:

Description
The compendium entitled "Communication with Automation Systems, Planning - Configuring - Referencing" was created for the topic of "Communication in Automation Technology". Taking communication technologies frequently used in automation technology, we have taken a closer look at their properties.

The compendium is available for downloading in Entry ID 20982954.

Keywords
Bus systems, Connection, Protocols, Bus medium

How does data communication work between S7-300/S7- 400 and S7-200 via MPI using S7 basic communication?Go to beginning
Part number:

Description:
You can access various S7-200 CPUs from the S7-300 / 400 using X_PUT / X_GET via MPI. Here, the S7-300 / S7-400 is the master and the S7-200 the slave.


Fig. 01

With S7-200 CPUs of the CPU 22x series, you can work with the baud rates 19.2kBd and 187.5kBd.

Refer to the technical data of the CPUs concerned for the transfer rates supported by your S7-300 / S7-400 CPU at the MPI interface.

The manual with the technical data of the S7-300 CPUs is available in Entry ID: 12996906

The manuals with the technical data of the S7-400 CPUs is available in the following Entry IDs:

The table below gives you information about the maximum number of connections available for S7 basic communication in the S7-300 CPUs.
 
CPU

Max. number of connections for
S7 basic communication

CPU 312, CPU 312C 2
CPU 313 4
CPU 313C, CPU 313C-2DP, CPU 313C-2PtP 4
CPU 314 8
CPU 314C-2DP, CPU 314C-2PtP 8
CPU 315 8
CPU 315-2DP, CPU 315F-2DP 12
CPU 315-2PN/DP, CPU 315F-2PN/DP 14
CPU 316 8
CPU 316-2DP 8
CPU 317-2DP, CPU 317F-2DP 30
CPU 317-2PN/DP, CPU 317F-2PN/DP 30
CPU 318-2DP 30
CPU 319-3PN/DP, CPU 319F-3PN/DP 30
CPU 614 8

The table below gives you information about the maximum number of connections available for S7 basic communication in the S7-400 CPUs.
 

CPU

Max. number of connections for
S7 basic communication

CPU 412-1 < FW V5.0

14

CPU 412-1 from FW V5.0

30

CPU 412-2DP < FW V5.0

14

CPU 412-2DP from FW V5.0

30

CPU 413-1

14

CPU 413-2DP

14

CPU 414-1

30

CPU 414-2DP

30

CPU 414-3DP

30

CPU 414-3PN/DP

30

CPU 416-1

42

CPU 416-2DP, CPU 416F-2DP

42

CPU 416-3DP

42

CPU 416-3PN/DP, CPU 416F-3PN/DP

42

CPU 417-4

42

Requirements for the S7-200 CPU:

  • Set the address of the S7-200 CPU.

  • Put the data to be sent into the relevant Send buffer or get the received data from the Receive buffer.

  • You define the Send and Receive buffers in STEP 7 when parameterizing the system functions SFC67 "X_PUT" and SFC68 "X_GET".

  • Refer to the notes on networking CPUs in the S7-200 system manual in Entry ID: 1109582.

Reading data from the S7-200 CPU with the system function SFC67 "X_GET"
You use the system function SFC67 "X_GET" for reading data from the S7-200 CPU. You call this in the OB1 of the S7-300 / S7-400, for example.

In this example, 10 bytes are read as from address 10 from the variable area of the S7-200 CPU. The 10 bytes of data received are stored in data block DB10 as from address 10 in the S7-300/S7-400.

The following table gives an overview of the input parameters of the system function SFC67 "X_GET".
 
Input parameter Variable Description
REQ M0.1 The input parameter REQ (request to activate) is a level-triggered control parameter.
A positive level at M0.1 of the S7-300 / S7-400 starts reading of the data from the S7-200.
CONT FALSE The input parameter CONT (continue) is a control parameter that determines whether or not the connection to the communication partner remains established upon completion of the job.

CONT=0: connection is cleared down after completion of data transfer.
CONT=1: connection remains established after completion of data transfer.

DEST_ID W#16#4 MPI address of the S7-200 CPU
VAR_ADDR P#DB1.DBX 10.0 BYTE 10 Reference to the area to be read in the partner CPU.
10 bytes of data are read as from address 10 from the variable area (VB) of the S7-200.

The following table gives an overview of the output parameters of the system function SFC67 "X_GET".
 
Output parameter Variable Description
RET_VAL MW 2 If an error occurs during processing of the function, the return value includes the relevant error code.

If no error occurs, the RET_VAL contains the length of data block copied into the receive area RD as a positive number in bytes.

BUSY M12.1 BUSY=1: The receive procedure has not yet finished.
BUSY=0: The receive procedure has been completed or no receive procedure is active.
RD P#DB10.DBX 10.0 BYTE 10 Reference to the receive data area.
The following data types are permitted:
BOOL, BYTE, WORD, DWORD, and arrays of these data types except BOOL.
The receive area RD must be at least as long as the read area VAR_ADDR of the communication partner.
In addition, the data types of RD and VAR_ADDR must match.

Writing data to the S7-200 CPU with the system function SFC68 "X_PUT"
You use the system function SFC68 "X_PUT" for writing data to the S7-200 CPU. You call this in the OB1 of the S7-300 / S7-400, for example.

In this example, 10 bytes are written as from address 10 to the variable area of the S7-200 CPU. The 10 bytes of data sent are stored in data block DB10 as from address 20 in the S7-300/S7-400.

The following table gives an overview of the input parameters of the system function SFC68 "X_PUT".
 

Input
parameter

Variable

Description

REQ

M100.1

The input parameter REQ (request to activate) is a level-triggered control parameter.
A positive level at M100.1 of the S7-300 / S7-400 starts writing of the data to the S7-200.

CONT

FALSE

The input parameter CONT (continue) is a control parameter that determines whether or not the connection to the communication partner remains established upon completion of the job.

CONT=0: connection is cleared down after completion of data transfer.
CONT=1: connection remains established after completion of data transfer.

DEST_ID

W#16#4

MPI address of the S7-200 CPU

VAR_ADDR

P#DB1.DBX 20.0 BYTE 10

Reference to the area to be written to in the partner CPU.
10 bytes of data are written as from address 20 to the variable area (VB) of the S7-200.

The following table gives an overview of the output parameters of the system function SFC68 "X_PUT".
 
Output
parameter
Variable Description
SD P#DB10.DBX 20.0 BYTE 10 Reference to the area in your own CPU that contains the data to be sent.
The following data types are permitted:
BOOL, BYTE, WORD, DWORD, and arrays of these data types except BOOL.
SD must have the same length as the VAR_ADDR parameter of the communication partner. In addition, the data types of SD and VAR_ADDR must match.
RET_VAL MW102 If an error occurs during processing of the function, the return value includes the relevant error code.
BUSY M112.1 BUSY=1: The send procedure has not yet finished.
BUSY=0: The send procedure has been completed or no send procedure is active.

More information on the system functions SFC67 "X_GET" and SFC68 "X_PUT" is available in Entry ID: 1214574.

A sample program for parameterizing the system functions SFC67 "X_GET" and SFC68 "X_PUT" is attached for downloading.

The sample program is a STEP 7 project that contains the complete hardware configuration including the user program of an S7-300 station. The STEP 7 project is available for downloading as a ZIP file.
Extract the "S7_basic_communication.zip" file into a separate directory. The STEP 7 project is unpacked automatically with all its subdirectories. You can then use the SIMATIC Manager to open and process the extracted STEP 7 project.

S7_basic_communication.zip ( 412 KB )

Note:
Set the S7-300/S7-400 control to STOP mode before loading the block that calls the system functions SFC67 "X_GET" and SFC68 "X_PUT" into the controller. This ensures that the system functions SFC67 "X_GET" and SFC68 "X_PUT" are initialized in any case and the data is transferred.

If you need faster data transmission, use PROFIBUS DP instead of S7 basic communication via MPI. PROFIBUS DP is not connection-oriented communication.
If you use PROFIBUS DP, then you need a PROFIBUS expansion module EM 277 in the S7-200. Detailed information on the expansion module EM 277 is available in the S7-200 system manual in Entry ID 1109582.

Consistent data in S7-400, summary of mechanismsGo to beginning
Part number:
 

QUESTION:   
What mechanisms are there for consistent data transfer in S7-400?

ANSWER:
Consistent data
Data that belongs together with respect to content and which describes a process state at a specific point in time is known as consistent data. For data to be consistent it must not be changed or updated during processing or transfer.   

Example 1:  
In order for there to be a consistent image of the process signals available to the CPU for the duration of the cyclic program processing, the process signals are read into the process image of the inputs before program processing and written to the process image of the outputs after program processing. Then during program processing the user program does not access the signal modules directly when addressing the operand areas Inputs (I) and outputs (Q), but accesses the internal memory area of the CPU in which the process image is located.
  
Example 2:
 
Inconsistency might occur if a communications block (e.g. SFB 14 "GET", SFB 15 "PUT") is interrupted by a process alarm OB of higher priority. Now, if in this process alarm OB the user program changes the data that has already been partially processed by the communications block, then the data transferred is partly from the time before the process alarm processing and partly from the time after process alarm processing. 
This means that this data is inconsistent.
    

SFC 81 "UBLKMOV"   
With SFC 81 "UBLKMOV" you copy the contents of one memory area (= source area) consistently into another memory area (= target area). The copying procedure cannot be interrupted by any other activities of the operating system.
 
With SFC 81 "UBLKMOV" you can copy the following memory areas:

  • Marker
  • DB contents
  • Process image of the inputs
  • Process image of the outputs

The maximum data volume that you can copy is 512 bytes. Please note the CPU-specific restrictions which you can take from the operations list for example.   

Since the copying procedure cannot be interrupted, the alarm response time of your CPU can be increased when implementing SFC 81 "UBLKMOV".   

Source and target areas must not overlap. If the specified target area is greater than the source area, then only as much data is copied into the target area as is in the source area. If the specified target area is less than the source area, then only as much data is copied as can be taken by the source area.    

Consistency in communications blocks and functions  
With the S7-400 communications jobs are not processed in the cycle checkpoint, but in fixed time slices during the program cycle. On the system side the data formats byte, word and double-word can always be processed consistently, i.e. transfer and processing of 1 byte, 1 word (= 2 bytes) or 1 double-word (= 4 bytes) cannot be interrupted.  
If communications blocks (e.g. SFB 12 "BSEND") that can only be used in pairs (e.g. SFB 12 "BSEND" and SFB 13 "BRCV") and which access common data are called in the user program, then the access itself to this data area, e.g. via the "DONE" parameter can be coordinated. The consistency of the data that is transferred locally with these communications blocks can thus be ensured in the user program.
 
The behavior is different with S7 communications functions with which no block is required in the user program in the target device (e.g. SFB 14 "GET", SFB 15 "PUT"). Here you have to take into account the size of the consistent data already when programming.
  

Access of the main memory of the CPU  
The communications functions of the operating system access the main memory of the CPU in blocks of a fixed size. The block size is CPU-specific and is 32 bytes for the S7-400 CPUs.
 
This ensures that the alarm response time is not prolonged when communications functions are implemented. Since this access is asynchronous to the user program, you cannot transfer just any number of bytes of data consistently.

The rules you have to follow to guarantee data consistency will be explained in the following.

Consistency rules for SFB 14 "GET" or reading variables

In the case of SFB 14 "GET" the data is transferred consistently if you observe all the following consistency rules:
  • Active CPU (data recipient): read out the receive area in the OB by calling SFB 14 or, if this is not possible, reading the receive area after processing of SFB 14 has finished.
  • Passive CPU (data sender): write only as much data to the send area as specified by the block size of the passive CPU (data sender).
  • Passive CPU (data sender): write the data to be sent to the send area with interrupt lockout.

The following figure gives an example of data transfer for which no data consistency can be guaranteed, because the second consistency rule has been broken: 32 bytes are transferred although the block size of the passive CPU (data transfer) is only 8 bytes.

Fig. 1: Example of data transfer

Consistency rules for SFB 15 "PUT" or writing variables

With SFB 15 "PUT" the data is transferred consistently if you observe the following consistency rules:

  • Active CPU (data sender): write to the send area from the OB in which you call SFB 15 or, if not possible, write to the send area after the first call of SFB 15 has been terminated.
  • Active CPU (data sender): write only as much data to the send area as specified by the block size of the passive CPU (data recipient).
  • Passive CPU (data recipient): read the data received with interrupt lockout from the receive area.

The following figure shows an example of data transfer for which data consistency cannot be guaranteed because the second consistency rule has been broken: 64 bytes are being transferred although the block size of the passive CPU (data recipient) is only 32 bytes.

 Fig. 2: data transfer without guaranteed data consistency

Consistent transfer of large data blocks across several variables can be made in the user program of S7-400 with SFC 81 "UBLKMOV" (uninterruptable block move).

Consistent access can then be made to this data, for example with SFB 14 "GET", SFB 15 "PUT and by reading/writing variables.  

Reading data consistently from a DP standard slave and writing it consistently to a DP standard slave 

Reading data consistently from a DP standard slave with SFC 14 "DPRD_DAT"  
With SFC 14 "DPRD_DAT" (read consistent data of a DP standard slave) you read the data of a DP standard slave consistently. If no errors occur during data transfer, the data read is entered into the target area covered by RECORD.
  
The target area must be of the same length as that you have configured with STEP 7 for the selected module. Each time you call SFC 14 you can only access the data of a module/DP ID at the configured start address.
 

Writing data consistently to a DP standard slave with SFC 15 "DPWR_DAT"

With SFC 15 "DPWR_DAT" (write consistent data to a DP standard slave) you transfer the data in RECORD consistently to the addressed DP standard slave.   
The source area must be of the same length that you have configured with STEP 7 for the selected module.
 

Notes:  
The
PROFIBUS DP standard defines upper limits for the transfer of consistent user data (see next section). Regular DP standard slaves keep to these limits. For older CPUs (<1999) there are CPU-specific restrictions for the transfer of consistent user data.   
Refer to the relevant technical data for these CPUs under the keyword "DP master – user data per DP slave" to find out the maximum length of the data that the CPU can read consistently from a DP standard slave and can consistently write to a DP standard slave. More recent CPUs exceed with this value the length of the data that a DP standard slave makes available or accepts.
  

Maximum upper limit for transferring consistent user data to a DP slave
The PROFIBUS DP standard stipulates upper limits for the transfer of consistent user data to a DP slave. This is why in a DP standard slave a maximum of 64 words = 128 bytes of user data can be transferred consistently in a block.   
When configuring you define the size of the consistent area. For this in the special code format (German abbreviation: SKF) you can set a maximum length for consistent data of 64 words = 128 bytes (128 bytes for inputs and 128 bytes for outputs). Anything longer is not possible.
 
This upper limit applies only for pure user data.
Diagnostics and parameter data are grouped into complete data records and are thus always transferred consistently.   
In the general code format (German abbreviation: AKF) you can set a maximum length for consistent data of 16 words = 32 bytes (32 bytes for inputs and 32 bytes for outputs). Anything longer is not possible.
  
In this context, please also note that a CPU 41x as DP slave generally on a non-system master (connection via GSD) has to be configurable via the general code format. For this reason the transfer memory of a CPU 41x as DP slave to the PROFIBUS DP is a maximum of 16 words = 32 byte in size.
  

Consistent data access without implementing SFC 14 or SFC 15  
Consistent data access of > 4 bytes is also possible for the CPUs listed below without SFC 14 or SFC 15. The data area of a DP slave that is to be transferred consistently is transferred to a process image partition. The information in this area is then always consistent. You can then access the process image via load/transfer commands (e.g. L EW 1).   
This offers a particularly convenient and powerful option (low runtime load) for accessing consistent data. This then makes it possible to efficiently incorporate and parameterize drives or other DP slave, for example. 

This applies for the following CPUs from firmware version 3.0 onwards:

S7-400 CPU 

MLFB

CPU 412-1 6ES7 412-1XF03-0AB0
CPU 412-2 6ES7 412-2XG00-0AB0
CPU 414-2 6ES7 414-2XG03-0AB0
CPU 414-3 6ES7 414-3XJ00-0AB0
CPU 416-2 6ES7 416-2XK02-0AB0
CPU 416-3 6ES7 416-3XL00-0AB0
CPU 417-4 6ES7 417-4XL00-0AB0
CPU 414-4H 6ES7 414-4HJ00-0AB0
CPU 417-4H 6ES7 417-4HL01-0AB0

Table 1: CPUs that support consistent data access without SFC14/SFC15

When you make a direct access (e.g. L PEW or T PAW) there is no I/O access error. 

Important for converting from the SFC14/15 solution to the process image solution:

  •   When converting from the SFC14/15 solution to the process image solution it is not recommended to use system functions and the process image at the same time. Basically, the process image is tracked when writing with the system function SFC15, but in the case of reading not. This means that the consistency between process image values and the values of system function SFC14 is not guaranteed. 
  • In the SFC 14/15 solution the SFC 50 "RD_LGADR" outputs different address areas to those in the process image solution.
  • If you implement a CP 443-5 ext, simultaneous use of system functions and the process image leads to the following errors: there is no read/write from/to the process image and/or it is no longer possible to read/write with the SFC 14/15.

Example:  
The following example (for the process image partition 3 "TPA 3") shows one possible configuration in the HW Config: 

  • TPA 3 at output: these 50 bytes are consistent in the process image partition 3 (drop-down list "Consistent over -> Total length") and can thus be read via normal "Load input xy" commands. 
  • The drop-down list selection "Process image partition -> ---" under Input means no storing in the process image. Handling is only possible with the system functions SFC14/15. 

Fig. 3: Configuring the DP slave properties in the HW Config

 


Which ports are released for Modbus/TCP communication and how many Modbus clients can communicate with a SIMATIC S7 CPU as Modbus server?Go to beginning
Part number:

Ports released for Modbus/TCP communication
The following ports are used by the Modbus/TCP protocol.

  • By default, the protocol uses Port 502 as local port in the Modbus server.
  • You can set the local port as you wish in the Modbus client. Usually, port numbers starting at 2000 are used.

If the communication partners offer the option of setting the port numbers for the server, then it is also possible to communicate using the Modbus/TCP protocol through a port other than Port 502.

If you use the SIMATIC as Modbus server, then there are restrictions for a number of CPUs regarding the released port numbers.
The following port numbers are released for the local port:
 
CPU Order number Firmware version Released ports Multiport
IM151-8 PN/DP CPU 6ES7151-8AB00-0AB0 up to V2.6 2000 to 5000 No
IM151-8 PN/DP CPU 6ES7151-8AB00-0AB0 from V2.7 all No
IM151-8 PN/DP CPU 6ES7151-8AB01-0AB0 from V3.2 all Yes
CPU314C-2 PN/DP 6ES7314-6EH04-0AB0 from V3.3 all Yes
CPU315-2PN/DP 6ES7315-2EG10-0AB0 and
6ES7315-2EH13-0AB0
up to V2.3.4 2000 to 5000 No
CPU315-2PN/DP 6ES7315-2EH14-0AB0 as from V3.1 all Yes
CPU317-2PN/DP 6ES7317-2EK13-0AB0 up to V2.3 2000 to 5000 No
CPU317-2PN/DP 6ES7317-2EK14-0AB0 as from V3.1 all Yes
CPU319-3PN/DP 6ES7318-2EL00-0AB0 up to V2.6 2000 to 5000 No
CPU319-3PN/DP 6ES7318-2EL00-0AB0 from V2.7 all No
CPU319-3PN/DP 6ES7318-2EL01-0AB0 from V3.2 all Yes
CPU412-2 PN 6ES7412-2EK06-0AB0 as from V6.0 all Yes
CPU414-3PN/DP 6ES7414-3EM05-0AB0 as from V5.0 all No
CPU414-3PN/DP 6ES7414-3EM06-0AB0 as from V6.0 all Yes
CPU416-3PN/DP 6ES7416-3ER05-0AB0 as from V5.0 all No
CPU416-3PN/DP 6ES7416-3ES06-0AB0 as from V6.0 all Yes
CPU412-5H PN/DP 6ES7412-5HK06-0AB0 as from V6.0 all Yes
CPU414-5H PN/DP 6ES7414-5HM06-0AB0 as from V6.0 all Yes
CPU416-5H PN/DP 6ES7416-5HS06-0AB0 as from V6.0 all Yes
CPU417-5H PN/DP 6ES7417-5HT06-0AB0 as from V6.0 all Yes
CPU 1211C 6ES7211-1AD30-0XB0 as from V1.02 all, except:
20, 21, 25, 80 102, 123, 5001, 34962, 34963 and 32964
No
6ES7211-1AE31-0XB0 from V3.0
6ES7211-1BD30-0XB0 as from V1.02
6ES7211-1BE31-0XB0 from V3.0
6ES7211-1HD30-0XB0 as from V1.02
6ES7211-1HE31-0XB0 from V3.0
CPU 1212C 6ES7212-1AD30-0XB0 from V1.02 all, except:
20, 21, 25, 80 102, 123, 5001, 34962, 34963 and 32964
No
6ES7212-1AE31-0XB0 from V3.0
6ES7212-1BD30-0XB0 from V1.02
6ES7212-1BE31-0XB0 from V3.0
6ES7212-1HD30-0XB0 from V1.02
6ES7212-1HE31-0XB0 from V3.0
CPU 1214C 6ES7214-1AE30-0XB0 from V1.02 all, except:
20, 21, 25, 80 102, 123, 5001, 34962, 34963 and 32964
No
6ES7214-1AG31-0XB0 from V3.0
6ES7214-1BE30-0XB0 from V1.02
6ES7214-1BG31-0XB0 from V3.0
6ES7214-1HE30-0XB0 from V1.02
6ES7214-1HG31-0XB0 from V3.0
CPU 1215C 6ES7215-1AG31-0XB0 from V3.0 all, except:
20, 21, 25, 80 102, 123, 5001, 34962, 34963 and 32964
No
6ES7215-1BG31-0XB0 from V3.0
Table 01

If you use the SIMATIC CPU as Modbus client, then there are no restrictions regarding the released port numbers. You can set any remote port of the CPU.

Number of possible communication connections using Modbus/TCP protocol
The maximum number of Modbus clients that can be connected to one S7-300 or S7-400 CPU with integrated PROFINET interface is limited by the CPU-specific quantity frameworks. If the CPU with integrated PROFINET interface does not support multiple ports, each local port of the CPU can only be used once, which means that when a communication connection has been established for a local port of the CPU, then you cannot set up another connection through that port.
If a non-multiport CPU is used as Modbus server, then there are two options for establishing communication connections to multiple Modbus clients.

  • You parameterize different port numbers for the Modbus server in the Modbus client.


Bild 01

  • All Modbus clients access the Modbus server through Port 502.
    In this case, it is necessary to have constant job-controlled establishment and clear-down of connections. The Modbus server can communicate with only 1 Modbus client through Port 502 at any one time. The connection to the first Modbus client must be cleared down and Port 502 released before another Modbus client can access the Modbus server. As soon as Port 502 is released, another Modbus client can access the Modbus server via that port.

Case 01

Bild 02

Case 02

Bild 03


Bild 04


Bild 05

Additional Information
More information about multiport-compatibility is available in the technical data of the CPU.
If the CPU supports multiple passive connections per port for open IE communication, it is multiport-compatible.
Manual Entry ID
SIMATIC S7-300 CPU 31xC and CPU 31x: Technical data 12996906
SIMATIC Distributed IO ET 200S Interface Module IM151-8 PN/DP CPU 47409312
Automation System SIMATIC S7-400 CPU Specifications 53385241
SIMATIC S7-1200 Automation System 36932465
Table 02

How do you implement chronological messaging with S7-400 CPUs and WinCC?Go to beginning
Part number:

Instructions
This entry shows you how to implement chronological messaging with an S7-400 CPU and WinCC. Chronological messaging means that the messages are sent from the PLC to the WinCC station. When they are created in the PLC, the messages are given a time stamp and then sent to the WinCC station. WinCC does not poll the PLC, which significantly reduces the bus load. The following two basic types of message and their configuration are demonstrated in the attached PDF file:
  1. Symbol-related messages
    Symbol-related messages can only be generated by CPUs of the S7-400 series. The messages are triggered asynchronously to the program.
  2. Block-related messages
    Block-related messages can be generated by CPUs of the S7-300 and S7-400 series.
    The block-related messages are created by the STEP 7 program using the system message blocks (e.g. ALARM_8P). The message is sent as soon as the STEP 7 program calls a system message block and the conditions for sending a message are fulfilled. The messages are triggered synchronously to the program.

More information

  • Reference manual "Programmable Logic Controller S7-400 CPU Data"
    This gives you detailed information on the available message procedures of a CPU. This documentation is part of the documentation package 6ES7498-8AA03-8AA0. The manual is available for downloading in Entry ID 19538001.
  • Manual "Operation List S7-400 CPU 412, 414, 416, 417"
    This gives you detailed information on available system functions and system function blocks for creating CPU messages. This documentation is part of the documentation package 6ES7498-8AA04-8AN0. The manual is available for downloading in Entry ID 1117645.
  • STEP 7 Online Help
    Detailed information on alarm processes, alarm types and system alarm blocks is available in the STEP 7 Online Help.

Requirements

  • The WinCC component "AS-OS Engineering" is installed.
    You can select this component when doing a user-defined setup of WinCC. Please use the following installation sequence:
     
    1. STEP 7
    2. WinCC with the "AS-OS Engineering" component

    Entry ID 22272911 includes a description of how to retro-install the "AS-OS Engineering" component.
     

  • The WinCC project is integrated in the STEP 7 project.
    Entry ID 11841504 contains information on how to integrate a WinCC project in STEP 7.
     
  • The "Alarm Logging Runtime" is enabled in the startup list in the "Computer Properties" dialog of the WinCC project.

Below we show you how to configure symbol-related and block-related messages.

WinCC_ZeitfolgeRichtigMeldenS7400 ( 586 KB )

This entry has been created with WinCC V6.0 SP4 and STEP 7 V5.3 SP2. The entry was also tested with WinCC V7.0 and STEP 7 V5.4 SP4.

Keywords
GMP, Pharma, Life Science, Validation, FDA 21 CFR Part 11

How do you configure a specified and an unspecified S7 connection for data exchange between S7-300 and/or S7-400 by way of Industrial Ethernet CPs?Go to beginning
Part number:

Instructions
You can use the S7 communication through S7 connections, among others, for data exchange by way of the Industrial Ethernet CPs of S7-300 and S7-400.

Below we describe how to configure a specified and an unspecified S7 connection for sending and receiving data by way of an Industrial Ethernet CP of S7-300 and S7-400.

 S7_Connection_en.pdf ( 2722 KB )

The function blocks and system functions below are called in the user program of the CPU for sending and receiving data by way of the configured S7 connection.

The Entry IDs below contain sample programs for programming the function blocks and system functions in the user program of S7-300 and S7-400 for sending and receiving data by way of a configured S7 connection.

Note
More information about communication over the Industrial Ethernet with S7-300 and S7-400 is available in the entries below.
 
Entry ID Description
26483647 What properties, advantages and special features does the S7 protocol offer?
30564821 Functions (FC) and Function Blocks (FB) for SIMATIC NET S7 CPs Programming Manual
44240604 System and Standard Functions for S7-300/400 Volume 1 and Volume 2
24352751 Which types of connection/protocols do the S7-300/400 CPUs and the CPs support by default?

 

How can you establish OPEN MODBUS / TCP communication from a SIMATIC S7 and where can you find further information?Go to beginning
Part number:

Description
You have three communication options for establishing a connection between a SIMATIC S7 and a third-party device using MODBUS/TCP:

  • For an external CP343-1 or CP443-1.
  • For the integrated PROFINET interface of the CPU.
  • For redundant communication in H systems

General information is available in the "MODBUS/TCP for SIMATIC Systems" product information below.
 

Contents of the downloads

Download

Product information (German)
Modbus TCP
File size: approx. 0.15 MB

( 148 KB )

Product information (English)
Modbus TCP
File size: approx. 0.15 MB

( 145 KB )

Table 01

The products below are offered.
 
Product Communication through Connection Supported function codes Order number
OPEN MODBUS /
TCP CP
CP343-1 and CP443-1 S7 controller with external CP343-1 or CP443-1 to third-party devices 1, 2, 3, 4, 5, 6, 15 and 16 2XV9450-1MB00
OPEN MODBUS /
TCP Redundant
CP443-1 in
H systems
S7-400 H station or S7-400 station with 2 CPs to third-party devices 3, 4 and 16 2XV9450-1MB01
OPEN MODBUS /
TCP Redundant V2
S7-400 H station or S7-300/400 station with 2 CPs to third-party devices 1, 2, 3, 4, 5, 6, 15 and 16 2XV9450-1MB11
OPEN MODBUS /
TCP PN-CPU
Integrated PROFINET interface of the CPU and
H CPU
CPU and
H CPU with integrated PROFINET interface to third-party devices
1, 2, 3, 4, 5, 6, 15 and 16 2XV9450-1MB02
Table 02

Note
Use the following local_device_IDs in the redundant H system:

  • For CPU(0) use the local_device_ID = B#16#5
  • For CPU(1) use the local_device_ID = B#16#15

The current manuals, demo versions and hardware requirements are available here:

S7 OpenModbus/TCP

More information about this topic is available at the following address:

Siemens AG
Industrial Technologies
IT4Industry Customer-Support
Werner-von-Siemens-Str.60
D-91052 Erlangen

Tel.:            +49 (0) 9131 7-46111
Fax:            +49 (0) 9131 7-44757
E-mail:        it4.industry@siemens.com
Internet:       IT4Industry

Note
The entry below includes the MODBUS TCP Wizard for creating the parameters for the MODBUS TCP communication for CPUs with integrated PROFINET interface 31535566.

The entry below includes a sample application for configuring a MODBUS TCP connection between SIMATIC S7 and Modicon M340 with the blocks from OPEN MODBUS / TCP CP and OPEN MODBUS / TCP PN-CPU: 38586568.

Additional Keywords
Loadable drivers, Communication blocks, MODBUS, Redundancy

How do you use WinCC flexible to transfer a project to an operator panel via S7 routing?Go to beginning
Part number:

Contents

Introduction
Notes and requirements for S7 Routing
S7 Routing example
Procedure for transfer via S7 Routing  

Introduction for S7 Routing
You can load an HMI project from a WinCC flexible configuration computer to an operator panel over different subnets.
If you implement a router, you can establish a connection between different subnets. A SIMATIC station can act as a router if it has suitable interfaces.
The modules with communications capability (CPUs or CPs), which create gateways between the subnets, must support routing.
To transfer a WinCC flexible project, the WinCC flexible configuration computer must be connected to an MPI bus, PROFIBUS or Ethernet.
The operator panel to which the WinCC flexible project is to be transferred must also be connected to an MPI bus, PROFIBUS or Ethernet.

Notes and requirements for S7 Routing

Notes

  • Refer to a component's technical documentation to establish whether it supports routing.
    Alternatively, open the component's object properties in NetPro or in HW Config. The "General" tab contains a brief description of the properties.
    Information about which modules possess routing capability is also available in Entry ID: 584459.
  • The requirements that have to be fulfilled to perform STEP 7 routing by means of a PG/PC station are given in Entry ID: 16620173.
  • A routing connection for the transfer can also be established by means of multiple routing partners. Routing cannot be used as a means of transferring to PC-based operator panels (PC Runtime) with an activated station manager (Station Configuration Editor).
  • In order to establish a routing connection, all the stations within a STEP 7 project must be configured and loaded.
  • You must use NetPro to configure all the devices and subnets connected to the network.

S7 Routing MPI / PROFIBUS and Ethernet
Below is a list of the requirements and the supported HMI operator panels and the possible routes for S7 Routing are shown in Fig. 01.

  • At least WinCC flexible 2005
  • At least STEP 7 V5.3 SP2
  • All panels including PC Runtime except PC Station with Station Configuration Editor


Fig. 01

S7 Routing Ethernet with WinCC flexible 2008
The S7 Routing function was extended with WinCC flexible 2008. Below is a list of the requirements and the supported HMI operator panels and the possible routes for S7 Routing are shown in Fig. 02.

  • At least WinCC flexible 2008
  • At least STEP 7 V5.4 SP3
  • You can use only the following devices for routing over the "S7 Ethernet" transfer channel:
    • TP 177B 4"
    • MP 177
    • Mobile Panel 277
    • MP 277
    • MP 377
  • Routing over Ethernet is not possible with WinCC flexible PC Runtime.
  • In the case of routing by way of SIMOTION CPU 4.1.2, transfer of the configuration over S7 Ethernet does not work.
  • Routing from MPI/DP to Ethernet is possible if MPI/DP has been selected in the Transfer settings.


Fig. 02

S7 Routing Ethernet and WinCC flexible 2008 SP3
More devices were added to the S7 Routing function with WinCC flexible 2008 SP3.
Below is a list of the requirements and the supported HMI operator panels and the possible routes for S7 Routing are shown in Fig. 03.

  • At least WinCC flexible 2008 SP3
  • At least STEP 7 V5.4 SP3
  • You can also use the following devices for routing over the "S7 Ethernet" transfer channel:
    • OP 77B
    • OP 177B
    • TP 177B
    • Mobile Panel 177
    • OP 277
    • TP 277 


Fig. 03

Download
The download below includes a summary of the possible routes for S7 Routing and their requirements.

WinCC_flexible_Routing.pdf ( 56 KB )

Example of S7 Routing with Ethernet
Fig. 01 shows a routing connection between the WinCC flexible configuration computer (network object: Stations > PG/PC) and operator panel "MP 377 15'' Touch" (network object): Stations > SIMATIC HMI station). The "SIMATIC 300(1)" programmable logic controller acts as a router.

Use NetPro to configure the routing connection between the devices involved.
You must assign the interface of the configuration computer. You can recognize the assignment by the yellow connection line to the subnet and by the yellow arrow in the station symbol.

The procedure for configuring a routing connection is described in Entry ID: 2383206.


Fig. 04

Procedure for transfer by means of S7 routing

  1. Open the HMI station in WinCC flexible.
  2. Select the menu command "Project > Transfer > Transfer Settings".
  3. Select the operator panel.
  4. Select the mode and check the "Enable routing" option box.
    The mode must match the communication channel.
  5. In the "Next station" box, you select the bus type of the next and the last connection.
    The network addresses of the next routing partner and destination device are displayed.
    Any routing partners positioned between them are not displayed here.
  6. Transfer your project by clicking the "Transfer" button.


Fig. 05: Transfer settings for MPI/PROFIBUS


Fig. 06: Transfer settings for Ethernet

More information in manual
More information on the topic of "Project transfer via S7 Routing" is available in the WinCC flexible manual in Entry ID: 18796010.

 

What restrictions are there for active jobs when communicating with SFC 58 / SFC 59 and SFB 52 / SFB 53 via PROFIBUS DP and PROFINET IO?Go to beginning
Part number:

Configuration Notes:
System functions and blocks SFB52 "RDREC" / SFC59 "RD_REC" (read record) are used to read data records of a component (module) of a DP slave/PROFINET IO device. System functions and blocks SFB53 "WRREC" / SFC58 "WR_REC" (write record) are used to write data records to a component (module) of a DP slave/PROFINET IO device.

Depending on the CPU used, the number of active jobs of the system functions and blocks SFB53/SFC58 and SFB52/SFC59 is limited.

The following table provides information about how many active jobs of the system functions and blocks SFB53/SFC58 and SFB52/SFC59 your CPU supports simultaneously.
 
System function/
system block
SFB 52 "RDREC"/
SFB 53 "WRREC"
SFC 59 "RD_REC"/
SFC 58 "WR_REC"
Explanation Data record from DP slave, PROFINET IO device Data record from DP slave
IM154 (ET 200pro)
IM151 (ET 200S)
IM147 (ET 200X)
4 jobs together with SFC 58/59 4 jobs together with SFB 52/53
CPU 312, CPU 313, CPU 314
CPU 315, CPU 316
4 jobs together with SFC 58/59 4 jobs together with SFB 52/53
CPU 317, CPU 319
CPU 318-2
8 jobs together with SFC 58/59 8 jobs together with SFB 52/53
CPU 41x1) 8 jobs each per PROFIBUS DP segment and PROFINET IO system 8 jobs each per PROFIBUS DP segment and PROFINET IO system
1) The number of simultaneous jobs on external PROFIBUS DP segments or PROFINET IO systems must not exceed 32 jobs per SFC/SFB.

Example:
With a CPU 414-2DP, a maximum of 48 jobs per SFC/SFB can be executed at the same time (8 each on the two PROFIBUS DP segments that are connected to the integrated interfaces of the CPU, and 32 on external PROFIBUS DP segments and PROFINET IO systems).

Rules:

  • There are no restrictions for simultaneous jobs in the subracks (CR, ER). The SFCs run synchronously via the backplane bus. Any number of synchronous SFCs can be called.
  • If you are operating multiple communication partners on the PROFIBUS network, then please make sure that never more than the specified jobs are active at the same time. Here one SFC/SFB can run several CPU cycles long.
  • The restrictions listed in this entry for the active jobs of the system functions and blocks SFB53/SFC58 and SFB52/SFC59 also apply to the blocks that call these system functions and blocks internally. These include the blocks FM_CS, PID_FM and FMCS_PID, for example.
    Example:
    When communicating with an FM 355 (4 channels parameterized) via the FMCS_PID block, 4 read jobs are occupied.

Note:
System functions SFC58/59 are available on all CPUs.

How do you program the communication blocks FB63 "TSEND", FB64 "TRECV", FB65 "TCON" and FB66 "TDISCON" in order to use the ISO-on-TCP protocol for data exchange by way of the integrated PROFINET interface of a CPU or by way of the CP443-1 Advanced?Go to beginning
Part number:

Description
You can use the open communication over Industrial Ethernet for data exchange by way of the integrated PROFINET interface of a CPU or by way of CP4431 Advanced, for example. The protocols below are supported for this:

  • TCP
  • ISO-on-TCP
  • UDP

The following communication blocks are available for open communication over Industrial Ethernet using ISO-on-TCP Protocol:

  • FB65 "TCON" for establishing the connection
  • FB66 "TDISCON" for ending the connection
  • FB63 "TSEND" for sending data
  • FB64 "TRECV" for receiving data

These communication blocks are available in the Standard Library -> Communication Blocks.
Copy the latest versions of the above-mentioned communication blocks from the standard library into your user program and then call them in your user program.
The connection parameters for establishing the ISO-on-TCP connection are saved in a data structure. In this example, the data structure UDT65 "TCON_PAR" is used, which is parameterized by the user. The ISO-on-TCP connection is not configured in NetPro.

Description of the sample program
The S7 program contains the call of the FB65 "TCON" and the data structure UDT65 "TCON_PAR" with the connection parameters for establishing the ISO-on-TCP connection. The S7 program also includes the call of the communication blocks FB63 "TSEND" and FB64 "TRECV" from the Standard Library -> Communication Blocks. The FB63 "TSEND" is for sending data to an S7 station or to an S5 station, to a PC station or to a third-party system. The FB64 "TRECV" is for receiving data from another S7 station or an S5 station, from a PC station or from a third-party system.

First create the hardware configuration for your S7-300 station. Configure Marker byte 10 as clock marker. The send request is triggered by this clock marker. Save and compile the hardware configuration of your S7-300 station and load it into the CPU.

The STEP 7 program consists of blocks OB100, OB1, FB400, DB400, FB420, UDT65 and FB63, FB64, FB65 and FB66.

OB100
The OB100 is a restart OB and is run when the CPU is restarted (warm start). In this OB the first communication trigger is enabled with marker M0.3.

OB1
OB1 is called cyclically. The FB400 is called in OB1 with the instance data block DB400 and marker M0.3 as INIT_COM parameter. The marker M0.3 is reset in OB1 after the FB400 has been called.


Fig. 01

FB400
The FB400 is called cyclically in OB1. The following function blocks are called in FB400:

  • FB420 "SET_ISO_PARAM"
  • FB65 "TCON",
  • FB63 "TSEND",
  • FB64 "TRECV",
  • FB66 "TDISCON"


Fig. 02

Using the input parameters of the function FB420 "SET_ISO_PARAM" you define the local and remote parameters of the ISO-on-TCP connection.
 
Input parameters Data type Description
ID Word Connection number
DEV_ID Byte B#16#0 for the CP443-1 Adv
B#16#1 for the IM151-8 PN/DP CPU or
B#16#2 for the CPU 31x-2PN/DP, IM154-8 CPU or
B#16#3 for the CPU 319-3PN/DP or
B#16#5 for the CPU 412-2 PN, CPU 414-3 PN/DP, CPU 416-3 PN/DP
ACTIVE Bool True = connection established actively
False = connection established passively
TSAP Struct Local TSAP in the CPU and remote TSAP of the communication partner
IP_ADDR1 Int IP address of the communication partner
IP_ADDR2 Int
IP_ADDR3 Int
IP_ADDR4 Int
Table 01

The input parameter "TSAP" of the Struct data type is structured as follows:
 
Parameter Data type Description
LOC_RACK_SLOT Byte

Define the LOC_RACK_SLOT parameter with the value B#16#0 if the local TSAP is not to be prefixed with the two bytes with the values 0xE0 (hex) and 0x02 (hex). In the case of CPUs that support the ASCII format for the TSAPs, then the first two bytes of the local TSAP must not be defined with the values 0xE0 and 0x02.

Define the LOC_RACK_SLOT parameter with the value B#16#0 if the local TSAP is not to be prefixed with the two bytes with the values 0xE0 (hex) and 0x02 (hex). This is necessary for CPUs that do not support the ASCII format for the TSAPs.

LOC_TSAP String
  • Local TSAP (connection end point)
  • The user-defined ASCII string has the following values: 'TCP-1'.
CP_RACK_SLOT Byte Specify the rack and slot of the CP when communication is made over a CP443-1 Advanced.
REM_RACK_SLOT Byte

Define the REM_RACK_SLOT parameter with the value B#16#0 if the TSAP in the communication partner is not to be prefixed with the two bytes with the values 0xE0 (hex) and 0x02 (hex). In the case of CPUs that support the ASCII format for the TSAPs, then the first two bytes of the local TSAP must not be defined with the values 0xE0 and 0x02.

Define the REM_RACK_SLOT parameter with the value B#16#2 if the TSAP in the communication partner is to be prefixed with two bytes with the values 0xE0 (hex) and 0x02 (hex). This is necessary for CPUs that do not support the ASCII format for the TSAPs.

REM_TSAP String
  • TSAP (connection end point) in the communication partner
  • The user-defined ASCII string has the following values: 'TCP-1'.
Table 02

The CPUs below support the ASCII format for the TSAPs.

  • CPU 314C-2 PN/DP
  • CPU 315-2 PN DP, CPU 317-2 PN/DP as from V3.1
  • CPU 319-3 PN/DP as from V2.7
  • CPU 414-3 PN DP, CPU 416-3 PN/DP as from V5.2
  • CPU 412-2 PN as from V6.0
  • IM 151-8 PN/DP CPU as from V2.7
  • IM 154-8 CPU as from V3.2

Define local TSAP and TSAP in the communication partner
In this case the following TSAPs (connection end points) are used.
 
  Local TSAP in the CPU Remote TSAP of the communication partner
Initial value (ASCII) TCP-1 TCP-1
Initial value (hex) E0.02.54.43.50.2D.31 54.43.50.2D.31
Table 03

In the interface parameterization of FB400, you change the value of the local and remote TSAP in accordance with your configuration (see Fig. 04). In the "T_TSAP" structure, for the "LOC_TSAP" and "REM_TSAP" parameters you enter the local and remote TSAP of your configuration as initial value.
If the first two bytes of the local TSAP in the CPU are to be defined with the values 0xE0 and 0x02, then you change the interface parameters of FB400. In the "T_TSAP" structure, you define the initial value "B#16#2" for the "LOC_RACK_SLOT" parameter.
If the first two bytes of the remote TSAP are to be defined with the values 0xE0 and 0x02, then you change the interface parameters of FB400. In the "T_TSAP" structure, you define the initial value "B#16#2" for the "LOC_RACK_SLOT" parameter.


Fig. 03

Define connection number
You can change the connection number separately. Change the connection number in network 2 of FB400 in accordance with your configuration. The connection number is stored in a static tag and so in the instance data block DB400.
The connection number "1" is defined in this example.


Fig. 04

Connection setup
Establishing a connection is started by a positive edge in the "REQ" input parameter of the FB65 "TCON". The data structure UDT65 "TCON_PAR" with the connection parameterization is incorporated in the instance data block of the FB400.
On the input parameter "CONNECT" of the FB65 "TCON", the memory area is specified that contains the connection parameterization.
The connection is set up at system start and remains until it is disabled with FB66 "TDISCON", or the CPU goes into STOP mode, or the power supply is switched off.


Fig. 05

The send request is triggered by a positive edge at the input parameter "REQ" of the FB63 "TSEND". The send job trigger is controlled by clock marker M10.6 and the "C1.SEND_BUSY" tag. If the send job is running, "C1.SEND_BUSY" is set. It is then not possible to trigger a new send request.
You specify the memory area that contains the data to be sent at the input parameter "DATA".
You enter the number of bytes to be sent at the input parameter "LEN".
The output parameters "DONE", "ERROR" and "STATUS" are required for job evaluation.


Fig. 06

If the send job is successfully completed, "C1.SEND_BUSY" is reset. A new send job can now be triggered.
If the send job is completed with an error, then "C1.SEND_BUSY" is likewise reset and the value of the output parameter "STATUS" of FB63 is saved for error analysis.


Fig. 07


Fig. 08

The data can be received as soon as the ISO-on-TCP connection is established.
At the input parameters "DATA" and "LEN" you specify the address and length of the data area where the received data is saved.


Fig. 09

The output parameter "NDR" is for showing that new data has been received. The "RECV_LEN" output parameter indicates the length of the data received.
If the data is received successfully, then the value of the "RECV_LEN" output parameter is saved.


Fig. 10 

If the data is not received successfully, then the value of the "STATUS" output parameter is saved and evaluated.


Fig. 11 

You can clear down the ISO-on-TCP connection with FB66 "TDISCON". You start the request to clear down the ISO-on-TCP connection with a positive edge on the "REQ" input parameter of FB66 "TDISCON".


Fig. 12 

The STEP 7 project as a download
The STEP 7 project contains a sample program for calling FB400 "TSEND_TRECV_ISO1" and the function blocks FB420 "SET_ISO_PARAM", FB65 "TCON", FB66 "TDISCON", FB63 "TSEND" and FB64 "TRECV" with status evaluation. It has been created with STEP 7 V5.4 SP5.

Sample_open_ISO.zip ( 52 KB )

Configuring additional ISO-on-TCP connections
To configure additional ISO-on-TCP connections you copy the FB400 so that you receive another function block (such as FB401). Change the parameters and generate a new instance data block.

Additional Information

  • Detailed information on open communication over Industrial Ethernet is available in the manual "System and Standard Functions for S7-300/400 Volume 1 and Volume 2" in Entry ID: 44240604.
  • Instructions for configuring an ISO-on-TCP connection for communication with S7-300 and S7-400 Industrial Ethernet CPs are available in Entry ID: 47885440.

How do you program the communication blocks FB63 "TSEND", FB64 "TRCV", FB65 "TCON" and FB66 "TDISCON" in order to use the TCP protocol for data exchange by means of the integrated PROFINET interface of an S7-300 or S7-400 CPU?Go to beginning
Part number:

Description
The CPUs with integrated PROFINET interface and the WinAC RTX support open IE communication.

Entry ID 18909487 gives you an overview of the communication services that are supported by the CPUs with integrated PROFINET interface and by the WinAC RTX. This overview gives you information about which protocols of open IE communication are supported by the CPUs with integrated PROFINET interface and by the WinAC RTX.

The following communication blocks are available for open communication by way of Industrial Ethernet using TCP Protocol:

  • FB65 "TCON" for establishing the connection
  • FB66 "TDISCON" for ending the connection
  • FB63 "TSEND" for sending data
  • FB64 "TRECV" for receiving data

These communication blocks are available in the Standard Library -> Communication Blocks.
Copy the latest versions of the above-mentioned communication blocks from the standard library into your user program and then call them in your user program.
The connection parameters for setting up the TCP connection are saved in a data structure.
In this example, the data structure UDT65 "TCON_PAR" is used, which is parameterized by the user. The TCP connection is not configured in NetPro.

Description of the sample program
The S7 program contains the call of the FB65 "TCON" and the data structure UDT65 "TCON_PAR" with the connection parameters for setting up the TCP connection. The S7 program also includes the call of the communication blocks FB63 "TSEND" and FB64 "TRECV" from the Standard Library -> Communication Blocks. The FB63 "TSEND" is for sending data to an S7 station or to an S5 station, to a PC station or to a third-party system. The FB64 "TRECV" is for receiving data from another S7 station or an S5 station, from a PC station or from a third-party system.

First create the hardware configuration for the S7-300 station. Configure Marker byte 10 as clock marker. The send request is triggered by this clock marker. Save and compile the hardware configuration of your S7-300 station and load it into the CPU.

The STEP 7 program consists of blocks OB100, OB1, FB300, DB300, FC97, UDT65 and FB63, FB64, FB65 and FB66.

OB100
The OB100 is a restart OB and is run when the CPU is restarted (warm start). In this OB the first communication trigger is enabled with marker M0.3.

OB1
OB1 is called cyclically. The FB300 is called in OB1 with the instance data block DB300 and marker M0.3 as INIT_COM parameter. The marker M0.3 is reset in OB1 after the FB300 has been called.


Fig. 01

FB300
The FB300 is called cyclically in OB1.
The function FC97 "SET_TCP_ENDPOINTx" and the function blocks FB65 "TCON", FB63 "TSEND", FB64 "TRCV" and FB66 "TDISCON" are called in the FB300.


Fig. 02

Using the input parameters of the function FC97 "SET_TCP_ENDPOINTx" you define the local and remote parameters of the TCP connection.
 
Input parameters Data type Description
ID Word Connection number
DEV_ID Byte "local_device_id" of the interface by means of which the TCP connection is established with the FB65 "TCON".

Entry ID 51339682 informs you about which "local_device_id" you should parameterize at the DEV_ID input parameter in order to establish a connection with FB65 "TCON" for open communication by way of Industrial Ethernet.

ACTIVE Bool 0 = connection established passively
1 = connection established actively
LOC_PORT DInt Local port in the CPU

The manual "System and Standard Functions for S7-300/400 Volume 1 and Volume 2", section 24.2, provides information about the port numbers permitted for TCP and UDP. The manual is available for downloading in Entry ID 44240604.

REM_PORT DInt Remote port of the communication partner

The manual "System and Standard Functions for S7-300/400 Volume 1 and Volume 2", section 24.2, provides information about the port numbers permitted for TCP and UDP. The manual is available for downloading in Entry ID 44240604.

Note
If the CPU connection is established passively, this means ACTIV=0, then you do not have to specify the remote port of the communication partner, this means that you define REM_PORT=0.

IP_ADDR1 Int IP address of the communication partner

Note
If the CPU connection is established passively, this means ACTIV=0, then you do not have to specify the IP address of the communication partner, this means that you define IP_ADDR1=0, IP_ADDR2=0, IP_ADDR3=0 and IP_ADDR4=0.

IP_ADDR2 Int
IP_ADDR3 Int
IP_ADDR4 Int

Note
You enter the connection number in Network 2 of FB300. This is stored in a static tag and so in the instance DB DB300.


Fig. 03

Establishing a connection is started by a positive edge in the input parameter "REQ" of the FB65 "TCON". The data structure UDT65 "TCON_PAR" with the connection parameterization is incorporated in the instance data block of the FB300.
On the input parameter "CONNECT" of the FB65 "TCON", the memory area is specified that contains the connection parameterization.
The connection is set up at system start and remains until it is disabled with FB66 "TDISCON", or the CPU goes into STOP mode, or the power supply is switched off.


Fig. 04

The send request is triggered via a positive edge at the input parameter "REQ" of the FB63 "TSEND". The send job trigger is controlled by clock marker M10.6 and the "C1.SEND_BUSY" tag. If the send job is running, "C1.SEND_BUSY" is set. Triggering a new send request is not then possible.
You specify the memory area that contains the data to be sent at the input parameter "DATA".
You enter the number of bytes to be sent at the input parameter "LEN".
The output parameters "DONE", "ERROR" and "STATUS" are required for job evaluation.


Fig. 05

If the send job is completed successfully, "C1.SEND_BUSY" is reset. A new send job can now be triggered.

If the send job is completed with an error, then the "C1.SEND_BUSY" tag is likewise reset and the value of the "STATUS" output parameter of FB63 is saved for error analysis.


Fig. 06


Fig. 07

The data can be received as soon as the TCP connection is established.
With the input parameter "DATA", you specify the address and length of the data area where the received data is saved.


Fig. 08

The output parameter "NDR" is for showing that new data has been received. The output parameter "LEN" indicates the length of the data received.
If the data is not received successfully, then the value of the "STATUS" output parameter is saved and evaluated.


Fig. 09

You can clear down the TCP connection with the FB66 "TDISCON". You start the request to clear down the TCP connection with a positive edge at the "REQ" input parameter of the FB66 "TDISCON".


Fig. 10 

Note
The TCP protocol is used in this sample program for data transfer, which means that the "connection_type" parameter is defined with the value "B#16#11" in the UDT65 parameterization.
The S7-300 CPUs V2.3 support the TCP (compatibility mode). If you want to run the sample program on an S7-300 CPU V2.3, then change the value of the "connection_type" parameter to "B#16#01" in the UDT65 parameterization.

The STEP 7 project as download
The STEP 7 project contains a sample program for calling FB300 and the function FC97 "SET_TCP_ENDPOINTx", the blocks FB65 "TCON", FB66 "TDISCON", FB63 "TSEND" and FB64 "TRECV" with status evaluation. It was created with STEP 7 V5.5.

Sample_open_TCP.zip ( 46 KB )

Configuring additional TCP connections
To configure additional TCP connections, you copy the FB300 so that you receive another function block (such as FB301). Change the parameters and generate a new instance data block.

Additional information

  • Detailed information on open communication by way of Industrial Ethernet is available in the manual "System and Standard Functions for S7-300/400 Volume 1 and Volume 2" in Entry ID: 44240604.
  • Instructions for configuring a TCP connection for communication by way of S7-300 and S7-400 Industrial Ethernet CPs are available in Entry ID: 22385024.

How do you program the communication blocks FB67 "TUSEND", FB68 "TURCV", FB65 "TCON" and FB66 "TDISCON" in order to use the UDP protocol for data exchange by means of the integrated PROFINET interface of a CPU?Go to beginning
Part number:

Description
You can use the open communication of the PROFINET for data exchange by means of the integrated Industrial Ethernet interface of a CPU, for example. The protocols below are supported for this:

  • TCP
  • ISO-on-TCP
  • UDP

The following communication blocks are available for open communication by way of Industrial Ethernet using the UDP protocol:

  • FB65 "TCON" for connecting the UDP endpoint
  • FB66 "TDISCON" for disconnecting the UDP endpoint
  • FB67 "TUSEND" for sending data
  • FB68 "TURCV" for receiving data

These communication blocks are available in the Standard Library -> Communication Blocks.
Copy the latest versions of the above-mentioned communication blocks from the standard library into your user program and then call them in your user program.
The parameters for connecting the UDP endpoint are saved in a data structure. In this example, the data structure UDT65 "TCON_PAR" is used, which is parameterized by the user. There is no need to configure a communication connection in NetPro.

Description of the sample program
The S7 program contains the call of the FB65 "TCON" and the data structure UDT65 "TCON_PAR" with the parameters for connecting the UDP endpoint. The S7 program also includes the call of the communication blocks FB67 "TUSEND" and FB68 "TURCV" from the Standard Library -> Communication Blocks. The FB67 "TUSEND" is for sending data to an S7 station, to a PC station, or to a third-party system. The FB68 "TURCV" is for receiving data from an S7 station, from a PC station or from a third-party system.

First create the hardware configuration for the S7-300 station. Configure Marker byte 10 as clock marker. The send request is triggered by this clock marker. Save and compile the hardware configuration of your S7-300 station and load it into the CPU.

The STEP 7 program consists of blocks OB100, OB1, FB500, DB500, FC95, FC96, UDT65, UDT66, and FB63, FB64, FB67 and FB68.

OB100
The OB100 is a restart OB and is run when the CPU is restarted (warm start). In this OB the first communication trigger is enabled with marker M0.3.

OB1
OB1 is called cyclically. The FB500 is called in OB1 with the instance data block DB500 and marker M0.3 as INIT_COM parameter. The marker M0.3 is reset in OB1 after the FB500 has been called.


Fig. 01

FB500
The FB500 is called cyclically in OB1.

The functions FC95 "SET_UDP_REMOTE"and FC96 "SET_UDP_ENDPOINT" as well as the function blocks FB65 "TCON", FB67 "TUSEND", FB68 "TURCV" and FB66 "TDISCON" are called in the FB500.


Fig. 02

Using the input parameters of the function FC96 "SET_UDP_ENDPOINT" you define the parameters of the UDP endpoint.
 
Input parameters Data type Description
ID Word Connection number
DEV_ID Byte B#16#01 for the IM151-8 PN/DP CPU
B#16#02 for the CPU 31x-2PN/DP, IM154-8 CPU
B#16#03 for the CPU 319-3PN/DP
B#16#05 for the CPU 412-2PN, CPU 414-3 PN/DP, CPU 416-3 PN/DP
LOC_PORT DInt Local port in the CPU
Permissible port numbers for S7-300 CPUs up to and including V2.6 and S7-400 CPUs up to and including V5.1: 2000 to 5000
Permissible port numbers for S7-300 CPUs V2.7 onwards and S7-400 CPUs V5.2 onwards: 1 to 49151


Fig. 03

Using the input parameters of the function FC95 "SET_UDP_REMOTE" you define the parameters of the UDP endpoint.
 
Input parameters Data type Description
REM_PORT DInt Remote port of the communication partner
Permissible port numbers for S7-300 CPUs up to and including V2.6 and S7-400 CPUs up to and including V5.1: 2000 to 5000
Permissible port numbers for S7-300 CPUs V2.7 onwards and S7-400 CPUs V5.2 onwards: 1 to 49151
IP_ADDR1 Int IP address of the communication partner
IP_ADDR2 Int
IP_ADDR3 Int
IP_ADDR4 Int

Note
You enter the connection number in Network 2 of FB500. This is stored in a static tag and so in the instance data block DB500.


Fig. 04

Connection of the UDP endpoint is started by a positive edge at the input parameter "REQ" of FB65 "TCON". The data structure UDT65 "TCON_PAR" with the parameterization of the local UDP endpoint is incorporated in the instance data block of FB500.
On the input parameter "CONNECT" of the FB65 "TCON", the memory area is specified that contains the parameterization of the local UDP endpoint.
The connection of the UDP endpoint is set up at system start and remains until it is disabled with FB66 "TDISCON", the CPU goes into STOP mode, or the power supply is switched off.


Fig. 05

The send job is triggered by a positive edge on the input parameter "REQ" of the FB67 "TUSEND". The send job trigger is controlled by clock marker M10.6 and the "C1.SEND_BUSY" tag. If the send job is running, "C1.SEND_BUSY" is set. It is then not possible to trigger a new send request.
You specify the memory area that contains the data to be sent at the input parameter "DATA".
You enter the number of bytes to be sent at the input parameter "LEN".
At the input parameter "ADDR" you specify the address of the data area where the recipient's IP address is stored. In this example, the address parameters of the communication partner are stored in the data structure UDT66 "TADDR_PAR". This is incorporated in instance data block DB500.
The output parameters "DONE", "ERROR" and "STATUS" are required for job evaluation.


Fig. 06

If the send job is successfully completed, "C1.SEND_BUSY" is reset. A new send job can now be triggered.
If the send job is completed with an error, then "C1.SEND_BUSY" is likewise reset and the value of the output parameter "STATUS" of FB67 is saved for error analysis.


Fig. 07


Fig. 08

The data can be received as soon as the UDP endpoint is connected.
With the input parameter "DATA", you specify the address and length of the data area where the received data is saved.
At the input parameter "ADDR" you specify the address of the data area where the sender's IP address is stored. In this example, the address parameters of the communication partner are stored in the data structure UDT66 "TADDR_PAR". This is incorporated in instance data block DB500.


Fig. 09

The output parameter "NDR" is for showing that new data has been received. The RCVD_LEN output parameter indicates the length of the data received.
If the data is not successfully received, then the value of the "RCVD_LEN" output parameter is saved.
If the data is not received successfully, then the value of the "STATUS" output parameter is saved and evaluated.


Fig. 10 

You can disconnect the UDP endpoint with FB66 "TDISCON". You start the job to disconnect the UDP endpoint with a positive edge at the input parameter "REQ" of FB66 "TDISCON".


Fig. 11 

The STEP 7 project as download
The STEP 7 project contains a sample program for calling FB500 and the functions FC95 "SET_UDP_ENDPOINT", FC96 "SET_UDP_REMOTE", the blocks FB65 "TCON", FB66 "TDISCON", FB67 "TUSEND" and FB68 "TURECV" with status evaluation. It was created with STEP 7 V5.4 SP3.

Sample_open_UDP.zip ( 44 KB )

Configuration of UDP connections
In order to send UDP datagrams to multiple communication partners, you configure additional local and remote UDP endpoints. Copy the FB500 so that you receive more function blocks (such as FB501). Change the parameters of the local and remote UDP endpoint and generate new instance data blocks.

The ID of the local UDP endpoint can be selected from the value range of 1 to 4095.
The local and remote ports for S7-300 CPUs as from V2.7 and S7-400 CPUs as from V5.2 can be selected from the value range of 1 to 49151.

The ID and the port must be unique for each local UDP endpoint, in other words you must define a different ID and a different port for each local UDP endpoint.

Define the remote port and the IP address according to the configuration of the communication partner.

The table below shows how to configure multiple local and remote UDP endpoints. In this example, the same ID and the same port are used for the local and the remote endpoints.
 
Local/remote UDP endpoint 1 2 3
ID 1 2 3
LOC_PORT 2000 2001 2002
REM_PORT 2000 2001 2002
IP address of the communication partner 172.16.43.40 172.16.43.50 172.16.43.60

Additional information

  • Detailed information on open communication by way of Industrial Ethernet is available in the manual "System and Standard Functions for S7-300/400 Volume 1 and Volume 2" in Entry ID: 44240604.
  • Instructions for configuring a UDP connection for communication by way of S7-300 and S7-400 Industrial Ethernet CPs are available in Entry ID: 47885893.

How can you access consistent data without SFC14/15 as part of the process image?Go to beginning
Part number:

Description:
Consistent data access > 4 bytes is now possible without the system functions SFC14/15. This option of being able to consistently access data > 4 bytes using download/transfer commands provides a particularly convenient and high-performance method of access (low runtime load).
The data area of a DP slave or IO device that is to be transferred consistently is transferred to a process image or process image partition. The data in this area is then always consistent. Afterwards you can use download/transfer commands (e.g. L IW 1) to access the process image or process image partition. There is no limitation of the area with respect to addressing.

  • The operating system automatically controls updating of the process image.
  • Updating of the process image partition is done either on the user side using SFCs or automatically on the system side through a link to an OB.
  • When you make a direct access (e.g. L PEW or T PAW) then there is no I/O access error.

Note:
Refer to the technical data to see whether your CPU supports process image partitions.

Overview:
You can use the following CPUs for configuring without "SFC14/15":
 

MLFB

S7 CPU 

Minimum firmware version

6ES7 31..

CPU 31x

2.5

6ES7 41.. CPU 41x 3.0
6ES7671-0RC03-0YA0 WinAC1 V4.0
1Only possible when using Hardnet CPs (CP 5613 / CP 5603 / CP 5623) and not Softnet CPs (CP 5611 / CP 5621).

Limits:
Transfer of consistent user data to a DP slave:

Upper limits for the transfer of consistent data to a DP slave are defined by the PROFIBUS DP standard. This is why only a maximum of 64 words = 128 bytes of user data can be transferred consistently in one block to a DP standard slave.

When configuring, you define the size of the consistent area. For this, in the special identification format (SKF) you can set a maximum length of 64 words = 128 bytes for the consistent data (128 bytes for inputs and 128 bytes for outputs); anything beyond that is not possible.

This upper limit applies only for pure user data. Diagnostics and parameter data is grouped into whole data records and is therefore always transferred consistently.

For this, in the general identification format (AKF) you can set a maximum length of 16 words = 32 bytes for the consistent data (32 bytes for inputs and 32 bytes for outputs); anything beyond that is not possible.

Please also note here that a CPU 41x as DP slave must be able to be configured on a third-party master (connection via GSD) via the general identification format (AKF). For this reason the transfer memory per virtual slot of a CPU 41x as DP slave to the PROFIBUS DP has a maximum size of 16 words = 32 bytes. You can configure up to 32 such virtual slots in the i-slave. The highest slot number is 35.

Transfer of consistent user data to an IO device:
The upper limit for the transfer of consistent data to an IO device is 255 bytes (254 bytes user data + 1 byte associated value). Even if more than 255 bytes can be transferred to an IO device, the upper limit is 255 bytes of consistent user data.

Important:
Do not use the system functions and the process image simultaneously. The consistency between process image values and the values of system function SFC14 is not guaranteed, because the process image is not tracked when reading with system function SFC14. In principle the process image is tracked when writing with system function SFC15, but not when reading. This means that the consistency between process image values and the values of system function SFC14 is not guaranteed.

Example:
The following example (for the process image partition 3 "TPA 3" of an S7-400 CPU) shows one possible configuration in the HW Config:

Requirements: The image process partition has already been updated via the SFC 26/27 or the process image updating has been linked to an OB.

  • TPA 3 under Output: These 50 bytes are consistent in the process image partition 3 and can thus be read with normal "load input xy" commands.
  • "---" under Input means: no storage in a process image. Only handling with system functions SFC14/15 is possible.

Keywords:
Hardware configuration, Consistency, Updating

How great is data consistency in the PUT and GET S7 communication functions for the individual S7-400 CPUs?Go to beginning
Part number:


Description:
In S7 communication with PUT and GET SFBs/FBs, data consistency is dependent on the individual servers (S7-400 CPU):
 
CPU Order no. Consistent data (bytes), max.
CPU 318-2DP 6ES7318-2AJ00-0AB0 1 Variable, max. 462 Byte
CPU 41x-1 6ES7412-1XF03-0AB0
CPU 41x-2 6ES7412-2XG00-0AB0
6ES7414-2XG03-0AB0
6ES7416-2XK02-0AB0
CPU 41x-3 6ES7414-3XJ00-0AB0
6ES7416-3XL00-0AB0
CPU 41x-4/H 6ES7417-4XL00-0AB0
6ES7414-4HJ00-0AB0
6ES7417-4HL01-0AB0
Table 1: Overview of the consistency ranges

Notes:

  • CPU 318-2DP behaves like a 41x series CPU.
  • The statements also apply to more recent order numbers:
    for example, for 6ES7412-2XG04-0AB0 instead of 6ES7412-2XG00-0AB0

You can find further information:

  • In the STEP 7 online help, 'Common parameters of the SFBs/FBs and of the SFC/FC for S7 communication')
  • In the "System software for S7-300/400 system and standard functions" manual, Entry ID 1214574:
    This contains a block-oriented overview of S7 communication and data consistency (Chap. 20). "Common parameters of the SFBs/FBs and of the SFC/FC for S7 communication" are described in Chap. 20.1.
     

 Entry ID:23522717   Date:2013-05-13 
I regard this article....as helpfulas not helpful                                 






























related links
How great is data consistency in ...
SIMATIC HMI WinCC flexible 2008 W ...
SIMATIC S7-400 S7-400 Automation ...
SIMATIC S7-400 S7-400 Automation ...
SIMATIC S7-400 S7-400 Automation ...
mySupport
My Documentation Manager 
Newsletter 
CAx-Download-Manager 
Support Request
To this entry
Print
Create PDF 
Send to a friend
QuickLinks
Compatibility tool 
Help
Online Help
Guided Tour