Transferring data with variable message lengths via the TCP
protocol
Display part number
QUESTION:How can I receive data with variable message lengths as
a TCP data stream?ANSWER:Behavior of the TCP protocol:When data is
transferred with the TCP, the transfer is made in the form of a
data stream. In this case no information is given about the length
nor about the beginning and end and so the recipient cannot tell
where one message ends in the data stream and where the next
begins. Therefore the sender has to define amessage structurethat
can be interpreted by the recipient. The message structure can
comprise of thedata plus a terminating control charactersuch as
"carriage return" that indicates the end of the message.The
following sample program includes a TCP connection via which the
data can be sent with variable message lengths with FC5 to a
station and received with FC6.Sample program:Transfer of data (with
FC5 "AG_SEND" and FC6 "AG_RECV") with variable message lengths via
the TCP protocolGeneral description:The STEP 7 project includes two
S7-300 stations with CPU 315-2DP and CP 343-1 for communication via
Industrial Ethernet. The communication basis is a TCP connection
between the two stations. If you open the Properties of the TCP
connection in NetPro via "Right- click > Object Properties", you
can view the block parameter "ID" of the communication function
block. This specification is to be noted when calling FC5 and FC6
so that the data can be transferred via the TCP connection.
Fig. 1:Properties of the TCP connectionIn order to be able to
retrieve the messages from the data stream sent the data to be sent
must have a specific structure. The message can comprise of the
data plus a terminating control character such as "carriage return"
so that the recipient can tell where the message ends.
Fig. 2: Structure of a messageNote:The sample program is based
on the message structure shown in Fig. 2, but you can also define
your own message structure. If you do want to use a different
message structure (e.g. change the end character), then simply
change the sample program supplied accordingly to meet your
particular requirements.The data that you want to send with FC5
(AG_SEND) therefore has to be prepared with this predefined
structure in a data block (DB221). The data is then receive byte
for byte with FC6 (AG_RECV).Description of the STEP 7 programThe
STEP 7 program consists of blocks OB100, OB1, FB100, DB100
(instance DB of FB100), FB102 (multi-instance in DB100), DB221,
DB222, FC5, FC6. OB100OB100 is a startup OB and is run when the CPU
is restarted (warm restart). The first communication trigger is
issued in this OB with M1.0 and M0.1.
Fig. 3: OB100 OB1OB1 is called cyclically. This OB contains the
call of FB100 (instance dB: DB100) with M1.0 and M0.1. Once FB100
has been run M1.0 is reset.
Fig. 4: OB1 FB100:FB100 is called in the OB1 cycle. This FB
contains the call of FC5 "AG_SEND" and FB101 "AG_RECV_CR".
Send block FC5 "AG_SEND"FC5 is activated by the input parameter
"ACT" when clock marker M10.7 has a rising edge and "SND_BUSY" is
not set. "SND_BUSY" is set while the job is running and no function
can be triggered during that time.This function block is
particularly important because the function is asynchronous and can
take several cycles. Constant activation of the function without
waiting for it to terminate can cause a communication overload.The
input parameters "ID" and "LADDR" have to taken from the Properties
dialog of the TCP connection in NetPro (Fig. 1). In the "SEND"
parameter you have to specify the address of the data to be sent
(P#DB221.DBX2.0 BYTE 48). For "LEN" you enter the number of bytes
to be sent (26). The output parameters "DONE", "ERROR" and "STATUS"
are required for job evaluation and are only valid in one and the
same cycle.
Fig. 5: FB100 - call of FC5If the block is run through without
error, "SND_BUSY" is reset and you can then call FC5 again. If the
block is terminated with an error, the status word of the block is
saved for error analysis and "SND_BUSY" is also reset.
Fig. 6: FB100: evaluation of the FC5 callReceive block FB102
"AG_RECV_CR"
When you call FB102 "AG_RECV_CR, you must take the parameters
"ID" and "LADDR" from the Properties dialog of the connection in
NetPro (Fig. 1). In "RECV_BUF" you have to specify the storage
location for the data to be received (P#DB222.DBX0.0 BYTE50). The
output parameters "NDR", "ERROR" and "STATUS" are required for job
evaluation and are only valid in one and the same cycle.
Fig. 7: Call of FB102If the block is run through without error,
the length of the data received is saved. If the block is
terminated with an error, the status word of the block is saved for
error analysis.
Fig. 8: Evaluation of the FB102 call FB102 "AG_RECV_CR"
Initializing:Initialization steps are executed in Network1 and
Network2 of FB102, like resetting the byte counter (#COUNT) to zero
and resetting the Error and NDR bit (Out parameter of FB102
"AG_RECV_CR").
Receiving the data:With FC6 "AG_RECV" the data is received byte
for byte. If the function terminates with an error, "#STATUS" is
issued as output parameter on FB102 ("AG_RECV_CR").
Fig. 9: Receiving data byte for byteIf the data is received
without error with FC6, the received byte is saved and the byte
offset (#B_OFFSET) is calculated via the "#COUNT" parameter for the
ANY Pointer receive area. Then the end character "CR" (carriage
return) is checked. The the byte received corresponds to the
"carriage return", then the length of the data is forwarded as
output parameter "#LENGTH" and the byte counter "#COUNT" is set to
zero.Fig. 10: Determining the byte offset and checking for CR
Creating the receive bufferThe receive buffer (ANY Pointer)
specified when FB101 is called is verified with the byte offset
determined and saved in a temporary ANY Pointer (VAR_BUF). The byte
received is written to the receive buffer via the "BLKMOV"
function.
Fig. 11: Creating the receive buffer and saving the byteIf an
error occurs while writing the byte to the receive buffer, this is
indicated in FB102 via the "#STATUS" and the "#ERROR" bit.
Fig. 12: Error evaluation DB221:DB221 contains the data
structures that are sent with FC5.Fig. 13: Data structures
DB222:The data received with FC6 is saved in DB222.The download
contains the sample program described. It has been created with
STEP 7 V5.3 and SIMATIC NET V6.2.T_cp_var_cr.exeCopy the
"T_cp_var_cr.exe" file into a separate directory and then start the
file with a double-click. The STEP 7 project unpacks automatically
with all the subdirectories. You can then use theSIMATIC Managerto
open and process the project.
transferring data (with FC5 "AG_SEND" and FC6 "AG_RECV") with
variable message lengths via the TCP protocol
Display part number
QUESTION:How can I transfer data with variable message lengths
via the TCP protocol using the communication functions FC5
"AG_SEND" and FC6 "AG_RECV"?ANSWER:Behavior of the TCP
protocol:When data is transferred with the TCP, the transfer is
data-stream-based. In this case no information is given about the
length nor about the beginning and end of a message. This is not a
problem when sending, because the sender knows how many data bytes
are to be sent. The recipient however cannot tell where one message
ends in the data stream and where the next begins. Therefore you
have only two options for linking via pure TCP:1. You work with
afixed message length, i.e. both the sender and the recipient work
with a predefined data length. This means that the message limit is
always clearly defined.2. You work with avariable message length.
This this requires more time on the Receive and on the Send side,
because in the first bytes you have to enter a start delimiter as
well as the data length of the data sent. In this way the message
sent can be exactly interpreted by the recipient.The following
sample program includes a TCP connection via which the data can be
sent with variable message lengths with FC5 to a station and
received with FC6.Sample program: Transfer of data (with FC5
"AG_SEND" and FC6 "AG_RECV") with variable message lengths via the
TCP protocolGeneral description:The STEP 7 project includes two
S7-300 stations with CPU 315-2DP and CP 343-1 for communication via
Industrial Ethernet. The communication basis is a TCP connection
between the two stations. If you open the Properties of the TCP
connection in NetPro via "Right- click > Object Properties", you
can view the block parameter "ID" of the communication function
block. This specification is to be noted when calling FC5 and FC6
so that the data can be transferred via the TCP connection.
Fig. 1: Properties of the TCP connectionTo make data transfer
work via the TCP protocol the data to be sent must have a specific
data structure. A message must consist of start delimiters (so that
the recipient can recognize where the message begins),
specification of the length of the data (to define the receive
buffer) and the data itself. In this example we have defined start
delimiters of 4 bytes (preset with the values: 0x11, 0x12, 0x13,
0x14) and an S7 string for a message. An S7 string consists of two
bytes of length information and the actual data string. All ASCII
characters can be transferred with the S7 string.
Fig. 2: Structure of a messageNote:The sample program is based
on the message structure shown in Fig. 2, but you can also define
your own message structure. If you do want to use a different
message structure (e.g. start delimiters of only 3 bytes), then
simply change the sample program supplied accordingly to meet your
particular requirements.The data that you want to send with FC5
(AG_SEND) therefore has to be prepared with this predefined
structure in a data block (DB220). The data is then received with
FC6 (AG_RECV) in several steps:1. Receive start delimiters (byte
for byte) and identify the message2. Receive length information of
the S7 string3. Receive dataDescription of the STEP 7 programThe
STEP 7 program consists of blocks OB100, OB1, FB100, DB100
(instance DB of FB100), FB101 (multi-instance in DB100), DB220,
DB221, FC5, FC6. OB100OB100 is a startup OB and is run when the CPU
is restarted (warm restart). The the release for the first
communication trigger is issued in this OB with M1.0 and M0.1.
Fig. 3: OB100 OB1OB1 is called cyclically. This OB contains the
call of FB100 (instance DB: DB100) with M1.0 and M0.1. Once FB100
has been run M1.0 is reset.
Fig. 4: OB1 FB100:FB100 is called in the OB1 cycle. This FB
contains the call of FC5 "AG_SEND" and FB101
"AG_RECV_VARIABLE".
Send block FC5 "AG_SEND"FC5 is activated by the input parameter
"ACT" when clock marker M10.7 has a rising edge and "SND_BUSY" is
not set. "SND_BUSY" is set while the job is running and no function
can be triggered during that time.This function block is
particularly important because the function is asynchronous and can
take several cycles. Constant activation of the function without
waiting for it to terminate can cause a communication overload.The
input parameters "ID" and "LADDR" have to taken from the Properties
dialog of the TCP connection in NetPro (Fig. 1). In the "SEND"
parameter you have to specify the address of the data to be sent
(P#DB220.DBX0.0 BYTE 48). For "LEN" you enter the number of bytes
to be sent (48). The output parameters "DONE", "ERROR" and "STATUS"
are required for job evaluation and are only valid in one and the
same cycle.
Fig. 5: FB100 - call of FC5If the block is run through without
error, "SND_BUSY" is reset and you can then call FC5 again. If the
block is terminated with an error, the status word of the block is
saved for error analysis and "SND_BUSY" is also reset.
Fig. 6: FB100 - evaluation of the FC5 callReceive block FB101
"AG_RECV_VARIABLE"
When you call FB101 "AG_RECV_VARIABLE", you must take the
parameters "ID" and "LADDR" from the Properties dialog of the
connection in NetPro (Fig. 1). In "RECV_BUF" you have to specify
the storage location for the data to be received (P#DB221.DBX0.0
BYTE50). The output parameters "NDR", "ERROR" and "STATUS" are
required for job evaluation and are only valid in one and the same
cycle.
Fig. 7: FB100 - call of FB101If the block is run through without
error, the length of the data received is saved. If the block is
terminated with an error, the status word of the block is saved for
error analysis.
Fig. 8: FB100 - evaluation of the FB101 call FB101
("AG_RECV_VARIABLE"):
State machine:
The entry point into the program in FB101 is defined via the
variable "STATE_CNT". Depending on the state of the variable
"STATE_CNT" a skip is made to the relevant network for further
processing of the program.Program processing according to
"STATE_CNT":"STATE_CNT"Description
0The first byte of the start delimiter has been received(skip
from NW9 to NW13)
1The second byte of the start delimiter has been received(skip
from NW10 to NW14)
2The third byte of the start delimiter has been received(skip
from NW11 to NW15)
3The fourth byte of the start delimiter has been received(skip
from NW12 to NW16)
4Start delimiters have been recognized. Data information is
being received(skip from NW3 to NW17)
5Receive buffer is created and data received(skip from NW4 to
NW20)
Receiving the start delimiters (byte for byte) and identifying
the message (network 5 - 16)
The start delimiters (4 bytes) are received byte for byte with
FC6 "AG_RECV".When you call FC6 "AG_RECV", the parameters "ID" and
"LADDR" from the input parameters of FB101. In "RECV" you have to
specify the storage location for the byte received (SD buffer: byte
variable). The output parameters "NDR", "ERROR" and "STATUS" are
required for job evaluation and are only valid in one and the same
cycle.If the block is run through without error, the byte received
is saved for further processing. If the block is terminated with an
error, the status word of the block is saved for error
analysis.After the byte has been received the defined start
information is checked (Byte0 = 11; Byte1 = 12; Byte2 = 13; Byte3 =
14).
Fig. 9: Identifying a message via the start delimitersReceiving
the length information of the S7 string (network 3, 17 - 20)If the
information received is identified as start delimiters, then the
length information of the S7 string (2 bytes) is received with FC6
"AG_RECV".When you call FC6 "AG_RECV", the parameters "ID" and
"LADDR" are taken from the input parameters of FB101. In "RECV" you
have to specify the storage location for the two length information
bytes (VAR_LEN: structure with 2 bytes). The output parameters
"NDR", "ERROR" and "STATUS" are required for job evaluation and are
only valid in one and the same cycle.If the block is run through
without error, the actual length of the data received is used for
the Receive buffer (ANY-Pointer). If the block is terminated with
an error, the status word of the block is displayed as output
parameter on FB101.Fig. 10: Receiving the length informationThe
information about the actual length of the string (VAR_LEN.ACT_LEN)
is required for creating the Receive buffer (ANY Pointer). Here
when FB101 is called, the Receive buffer specified (ANY Pointer) is
verified with the actual length of the data and stored in a
temporary ANY Pointer (VAR_BUF).
Fig. 11: Creating the Receive bufferReceiving the data (network
4, 21- 23)The data is then received with FC6.When you call FC6
"AG_RECV", the parameters "ID" and "LADDR" are taken from the input
parameters of FB101. In "RECV" you have to specify the storage
location for the data (VAR_BUF: temporary ANY Pointer). The output
parameters "NDR", "ERROR" and "STATUS" are required for job
evaluation and are only valid in one and the same cycle.If the
block is run through without error, the length of the data received
is saved and forwarded to FB101 as output parameter. If the block
is terminated with an error, the status word of the block is
displayed as output parameter on FB101.
Fig. 12: Receiving data DB220:The data structures used with FC5
are located in DB220.
Fig. 13: DB220 - Send data structures DB221:The data received
with FC6 is stored in DB221.The download contains the sample
program described. It has been created with STEP 7 V5.3 and SIMATIC
NET V6.2.Tcp_data_exeCopy the "T_cp_data.exe" file into a separate
directory and then start the file with a double-click. The STEP 7
project unpacks automatically with all the subdirectories. You can
then use the SIMATIC Manager to open and process the project.
Filter criteria:Hardware platform:Industrial Ethernet, SIMATIC
S7-300/S7-400
Software:STEP 7 up to V5.x
Entry contents:Function blocks/tools
Entry ID:8707570Date:2004-06-03
PROFIBUS DP diagnostics block for CP342-5 (Master)
Display part number
QUESTION:.How can I do a PROFIBUS DP station diagnosis for the
CP342-5?ANSWER:Using the FC block "DP_DIAG" (FC 3) contained in the
"SIMATIC_NET_CP" library you can query and evaluate diagnostics
information from the CP342-5 in your user program. In addition to
job types like Request DP diagnostics lists, Request DP single
status, Acyclic reading of input/output data of a DP slave, Read
older DP single diagnostics, Read DP operating mode for PLC/CP
STOP, Read current status of the DP slave, you can also request a
DP station list from the CP. For this you must transfer the
following input parameters to the diagnostics block.FC parameters
for station diagnostics:ParameterDeclara-tionData
typeValueDescription
CPLADDRINPUTWORDW#16#.....Block start address of the CP
DTYPEINPUTBYTEB#16#0Code for station diagnostics
STATIONINPUTBYTEB#16#0Not relevant for station diagnostics
DIAGINPUTANYANY length 16 bytesStorage location of the
diagnostics data, 16 bytes in DB, marker or PA area
NDROUTPUTBOOL1: new data
ERROROUTPUTBOOLError display
STATUSOUTPUTWORDStatus display
DIAGLNGOUTPUTBYTELength of the data record available, here
always 16 bytes
If you call this function with the parameters described, you
obtain a diagnostics data record 16 bytes long. This data record
displays whether a station you have configured has failed. If a
station has failed, you can acquire the associated PROFIBUS
address.Structure of the data record:The individual bits of the
16-byte long data record reflect the possible 127 slave addresses.
If the configured station is not available, then in the data record
a 1 is set on bit belonging to the slave address.Bit 7Bit 6Bit 5Bit
4Bit 3Bit 2Bit 1Bit 0
Byte 1.:01234567Slave address
Byte 289101112131415Slave address
Byte 3.1617181920212223Slave address
....................
....................
Byte 16120121122123124125126127Slave address
By monitoring the data record provided by the CP you can detect
station failures and determine the slave address of the failed
station.Note:The FC block "DP_DIAG" is only useful in "DP Master"
mode. More information on this block is available in the online
Help.Sample function:The following STEP 7 project contains the
function block FB13 that implements a PROFIBUS DP slave diagnosis.
By continuously calling the function "DP_DIAG" in the function
block FB13 each DP slave recognizes failure and enters the
information given below into a ring buffer in the instance data
block DB13.The following entries are stored in the ring buffer:
Serial error number Slave failure incoming/outgoing Number of
failed slaves PROFIBUS address of the failed station; if there are
several, the highest address is entered Time stamp of the failure
or recoveryAlso stored in the instance data block are the current
station status (station list) of the FC3 and the data record of the
last station failure. Errors are specified via the output parameter
"STATUS".The function block FB13 has the following call
parameters:ParameterDeclara-tionData typeDescription
activINPUTBOOLActivate block
addrINPUTWORDAddress of the CP342-5
checkINPUTBOOLNot needed
STATUSOUTPUTWORDSTATUS BYTE of FC3
The download contains a STEP 7 V5 project with the function
block FB13, the associated instance data block and an organization
block OB1. You can adapt the blocks as you wish to suit your
requirements.diag_fb.exeCopy the "diag_fb.exe" file into a separate
directory and then start it with a double-click. The S7 V5 project
is now unpacked with all the associated subdirectories. You can
then open and process the unpacked project with the SIMATIC
Manager.