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?
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?
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.
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?
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?
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.
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?
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
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?
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.
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.
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:
ThePROFIBUS DP standard definesupper limitsfor 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?
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
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:
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.
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:
STEP 7
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.
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.
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 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?
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 2008SP3
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.
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
Open the HMI station in WinCC flexible.
Select the menu command "Project > Transfer > Transfer Settings".
Select the operator panel.
Select the mode and check the "Enable routing" option box.
The mode must match the communication channel.
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.
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?
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?
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.
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?
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.
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?
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.
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?
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.
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.