Hi everybody

This topic is about a problem with slow Ethernet communication between S7400 plc.

The installation I am telling you have a central PLC with has actually two Ethernet communication partners. I get a project about adding a new PLC. This new PLC also has to communicate with the central one.

Unfortunately, I note some long transmission delay within the actual communication. That made me anxious. Some transmission can take up to 15 seconds. So before adding the new partner device, I would like to fix those problems.

Some precision about existing:

1) All communication are made with AG_SEND/AG_RECEIVE

2) Implementation of communication is made as show in STEP7 help. A new send is directly done when bit DONE is 1.

3) The sizes of communication’s DB are 10 and 32 octets.

4) All PLC has 20% of cycle reserved for communication

5) One partner has a short OB1 cycle. Communication with this partner seems to be the slowest. The communication with this PLC is called in second position, in the central PLC program.

6) There is a topic on Siemens support site: SEND/RECEIVE link between CP 443-1 (1EX40) and CP 443-1 (1BX00). We are not in this case because all CP443-1 are EX11.

7) If we try a ping echo request, the transmission delay of Ethernet network is below 250ms.

8) There is no communication error.

I think the problem dose not come from the Ethernet network because ping echo give short response time. It is probably the result on some kind of saturation between PLC and CP.

For me, is more important to guarantee predictable transmission delay (always<1s) than fast communication.

What should I do?

9) Should I change the way of calling of AG_SEND? Could it be better, if I call one AG_SEND after one, instead of all sends working independently in parallel?

10) Should I add delay before new send when bit DONE is 1? How long?

11) Should I change % of time for reserved communication or set a minimal cycle length?

Thank you for any help.

Retel-Collombey SA

Thank you for your help

The network it is a 100Mb/s fiber/cooper mix Ethernet network with different level of switches. 250mS is response time we expect for our communication, but real network response time is smaller. Personally, a doubt that the problem come from the network. I did never had indecent response time will online visualization.

Firmwares of Ethernet card are V2.3.

1) In case of low Ethernet coupler, how should I program communication to avoid saturation?

2) Is it possible that the first communication monopolizes the coupler resources?

Rey Cyril

Thank all of you for your comments and sorry for long time I need for answering.

While I try different configurations:

1) I update all firmware with latest version : no visible effect

2) I change the parameter time reserved for communication from 20% to 50% : no visible effect

3) I set “minimal cycle time to 100ms: Communication time increase. waiting time is reserved for OB90 and can not be utilized for communication.

4) Modification of the send procedure. I only activate send if data change happened in the send DB: Transmission is fast for one single data change (< one change pro sec). In case of multiple changes, delays increase. It mean than a single transmission is fast but cycling communication not.

I use ISO on TCP communication protocol. There is a lot of different communication protocol. Dec, It is the most appropriate for my application? I did not be able to test other protocol because production is running now. I need to have similar performances as profibus but trough Ethernet/IP. I have some kind of heart bit watch dog control system implemented. Then UDP or ISO on Ethernet may be enough and faster?

5) With a hub (unfortunately 10Mb/s) I capture communication with a analyzing software (Wireshark) :

Communication delay seems to be fast. I note that one partner give recurrently a windows size of 0 while 100ms. That may confirm what Smurf said. The CPU is not enough fast to eat all received data. Or maybe the communication between CPU and CP is slower than ethernet?

Notice that fast communications is not as important as having predictable (soft real time) communication time. What should I do?

Sincerely

Rey Cyril

Dec

Protocol used: TCP port 2003.
Both IP addresses 10.168.194.33/38 have Siemens MAC class 08.00.06.xx.xx.xx so you are communicating perhaps S7-400 CP443 to S7-400 CP443. AG-SEND/AG-RECV.
Why not AG-LSEND/AG-LRECV?
Why not use S7 (ISO) protocol and BSEND/BRCV? You can't get better.

Dec

The telegrams are consistent in time, I don't see your point;
IP-33 is sending 32bytes, IP-38 sends back 32bytes after ~4ms, IP-33 sends 1byte? after 1ms and IP-38 send KEEP-ALIVE ACK after 90ms. This is consistent on all the packets.

• Wy IP-33 send only 1 byte data. My data send vector is always 32 bytes length?
• Wy IP-33 has recurentely window’s size =0? It is like if the CP receive buffer memory where full (window=0)? Then when the CPU get (remove) data from this buffer, the CP can receive again and send a new windows size value (windows=32)?