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.