Objectives
This article provides performance characteristics of the CP1L-EL20, CP1L-EM30 and CP1L-EM40 built-in Ethernet port under common operating conditions such as:
- FINS TCP/UDP Command Response
- High Network Load Condition
- TCP Socket Communication
- PLC Cycle Time
Introduction
The CP1L-EL/EM series PLC has a built-in Ethernet port with a variety of protocols that allow a wide range of applications on an Ethernet network. The protocols can be selected and include sending and receiving data by TCP/IP or UDP/IP (socket services) and sending and receiving commands by OMRON's standard protocol FINS.
Content
FINS TCP/UDP Command Response Test
FINS TCP/UDP Command Response Test
FINS TCP/UDP packets can be sent to the CP1L-E with a communication tool to determine the response time for each command.
Testing Method
FINS TCP or UDP packets were sent to the CP1L-E and the FINS response time was recorded for different situations as shown in the results table below. The figure below illustrates the test environment.
- The PC and CP1L-E are directly connected with a network cable.
- FINS packets are sent 1000 times with the PC communication tool.
- The CP1L-E only contains an END instruction and no program.
- Cycle time and peripheral service time are default.
Results
The normal writing of DM or CIO memory requires less than 30ms on UDP and less than 40ms for TCP for a maximum data sized packet. The longer response time of TCP is due to the overhead processing that TCP has compared to UDP. The overhead on TCP is in the extra data that TCP puts in a frame like sequence counting and session number but also TCP-connection creation and ACKnowledgement of the reception of a TCP-message.
When reading DM or CIO memory, there are considerable delays when TCP is used for larger data sizes above 536 bytes (UDP @ 12ms versus TCP @ 191 to 215ms depending on read size). This time difference is introduced because the TCP reply is split into two frames and the wait time between the two frames is approximately 200ms. This delay is caused by the ACK delay 200ms timer. This 200ms delay timer is fixed and not negotiated during the opening of the TCP connection and is considered a function of the TCP/IP stack (the CP1L-E as well as the ETN21 and PC also have this function). If the response from the PLC is received and there is no command to send the ACK response, there will be a 200ms delay as observed below.
More information can be found regarding this topic at the website below.
http://support.microsoft.com/kb/214397
*Key words are TCP_NODELAY and the Nagle algorithm
The read FINS/TCP read procedure steps are as follows (e.g. 500 words > 536 bytes):
- The PC sends a "read 500 DM words" FINS command to the CP1L-E (short message in one packet).
- The PLC sends the first part of the response (536 bytes) to the PC and waits for the ACK from the PC.
- The PC receives the first packet response from the PLC and does not send the ACK response until the 200ms timer has elapsed.
- After the ACK response is received by the PLC, the second part (remaining 494 bytes) is sent to the PC.
Therefore, it is recommended to use UDP connections for applications such as SCADA or when the read size may be above 253 words.
The FINS header and command error messages respond quickly to commands with incorrect header or incorrect size in the FINS command.
The following table provides detailed results of various read/write protocol and incorrect message response times for the CP1L-EL20/EM30/EM40 CPUs.
| Function | Protocol | FINS/UDP | FINS/TCP | |
| Response Time (ms) | ||||
| Normal FINS |
DM Write |
Minimum (1ch) | 6.0 |
7.1 |
| TCP_1*1 (251ch) | 15.8 | 23.0 | ||
| TCP_2*2 (252ch) | 15.9 | 23.8 | ||
| Maximum (499ch) | 25.4 | 38.7 | ||
| DM Read | Minimum (1ch) | 5.4 | 7.7 | |
| TCP_1*1 (253ch) | 9.2 | 10.5 | ||
| TCP_2*2 (254ch) | 9.4 | 192.1 | ||
| Maximum (501ch) | 12.0 | 215.7 | ||
| CIO Write | Minimum (1ch) | 5.9 | 7.0 | |
| TCP_1*1 (251ch) | 16.6 | 23.6 | ||
| TCP_2*2 (252ch) | 16.6 | 24.7 | ||
| Maximum (499ch) | 27.2 | 39.9 | ||
| CIO Read | Minimum (1ch) | 5.4 | 7.2 | |
| TCP_1*1 (253ch) | 9.4 | 10.5 | ||
| TCP_2*2 (254ch) | 9.3 | 191.7 | ||
| Maximum (501ch) | 12.0 | 215.6 | ||
| FINS with Header Error |
DM Write | Minimum (1ch) | 2.5 | 7.2 |
| Maximum (499ch) | 5.5 | 37.3 | ||
| DM Read | Minimum (1ch) | 2.4 | 7.1 | |
| Maximum (501ch) | 2.4 | 7.2 | ||
| FINS Command Error |
- | Short (8 byte) | 5.6 | 7.0 |
| Long (1016 byte) | 23.8 | 36.4 | ||
Notes
*1: For TCP_1 protocol, only one FINS/TCP frame is needed because the frame data size <= 536 bytes.
*2: For TCP_2 protocol, two FINS/TCP frames are needed because the frame data size > 536 bytes.
High Network Load Condition
The CP1L-E has an internal buffer for storing Ethernet messages while processing takes place. Excessive Ethernet traffic can fill this buffer and desired functionality may not occur. High network loads can be caused by any source on the network. The messages can be addressed directly to the CP1L-E (unicast) or or it can be a multcast or broadcast.
Testing Method
A high rate of messages are sent to the CP1L-E unit at approximately 250 messages/second.
Results
The CP1L-E protects itself from excessive network loads by dropping packets.
If this is the case then some communication and/or the connection may be lost. It is strongly advised to protect the CP1L-E from unnecessary communication by designing a proper network infrastructure. This can be achieved by placing Ethernet switches and routers in the network to channel the traffic. Creating VLANs, firewall rules and port throttling may also reduce excessive network traffic to the CP1L-E.
Furhter make sure that a in the protocol used a time out and resend mechanism is used. TCP communication for instance has this build in as standard.
TCP Socket Communication
The CP1L-E has three ports available to perform TCP or UDP communication. This topic will focus on Modbus/TCP communication as a common application.
Testing Method
Several available Function Blocks for Modbus communication were used. Only the management of the connections needed to be adapted to the bit control of the CP1L-E. The test application executed the following steps:
- Opening a Socket
- Performed a Holding Register Read
- Performed an Input Register Read
- Performed a Single Coil Force
- Performed a Holding Register Write
- Closed the Socket
*These are generally the functions a Modbus/TCP slave performs.
Results
Although function blocks work for the opening and closing of sockets during ModbusTCP communication, there are certain delays that need to be realized during the process. These delays are active during status transitions as shown in the diagram below.
| Status | Meaning |
| CLOSED | Connection closed |
| LISTEN | Waiting connection |
| SYN SENT | SYN sent in active status |
| SYN RECEIVED | SYN received and sent |
| ESTABLISHED | Already established |
| CLOSE WAIT | FIN received and waiting for completion |
| FIN WAIT 1 | Completed and FIN sent |
| CLOSING | Completed and exchanged FIN and awaiting ACK |
| LAST ACK | FIN sent and completed and awaiting ACK |
| FIN WAIT 2 | Completed and ACK received and awaiting FIN |
| TIME WAIT | After closing, pauses twice the maximum segment life (2MSL) |
For example, there is a 2 minute delay where the TCP socket is closed by the CP1L-E itself. This is the 2MSL timer and it is defined at 120 seconds. The 2MSL timer starts at the TCP socket that first closes the socket and will run for 120 seconds in the TIME_WAIT status (see the Appendices of Cat. No. W516, SYSMAC CP Series CP1L-EL/EM CPU Unit Operation Manual). However, this also depends on the implementation of the TCP communication at the other device and if this device does not close the socket properly, then the CP1L-E will never go to the closed state.
In general, the socket communications must be managed to accommodate for delays and the CP1L-E is vulnerable to overload during these periods. Careful use and control of the socket service status flags and control switches will ensure proper functionality (see the socket services section of Cat. No. W516, SYSMAC CP Series CP1L-EL/EM CPU Unit Operation Manual).
A valuable tool to check the communication is a ethernet network sniffer. There are several available on the internet.
PLC Cycle Time
By default, the PLC cycle time is not fixed and of this cycle time, 8% is dedicated to Ethernet communication servicing.
Testing Method
Socket communications were performed.
Results
PLC cycle time can be greatly varied and affected by Ethernet communications in some cases if peripheral servicing settings are default as part of the cycle time. In cases of high network loads, it is recommended to change the peripheral servicing time to a constant, fixed value which will prevent Ethernet processing variations from altering PLC cycle time and application functions.
Precautions
This article is intended to supplement official Omron documentation. The provided configurations and information should be thoroughly tested before implementation and may or may not function in specific applications. The user assumes full responsibility of the configuration, integration, performance and application of the provided configurations. For detailed information on the use and general configuration of Omron products, refer to official Omron manuals or contact your local Omron support representative.
All information contained in this document is current as of October 2012 but is subject to change due to product and/or software improvements.
