Possible causes of random errTCPDataReceive
32/64 bit multi-platform Ethernet S7 PLC communication suite
Brought to you by:
davenardella
Menu
▾
▴
Good morning, I am using the Sharp7 class in a read and write loop. The connection to the PLC is via Wi-Fi (but I have also tried directly with a cable). Occasionally, sometimes every 10 minutes and sometimes more frequently, I receive the code S7Consts.errTCPDataReceive because it times out in the WaitForData method. I have turned off the firewall. What else can I check?
Hi Laura,
These problems are also common in WinCC, it seems that they depend on the communication queues inside the PLC that have become very complex over time.
You can act on the communication priority, but it depends on the use you make of your automation, it may not be the most efficient way. (In my opinion, the communication load should never affect the CPU cycle time)
Or, as WinCC does, you can mask the problem: in case of TCP error, disconnect the client, then at the next turn of your communication loop, if you are disconnected reconnect and then read/write.
Attached the schematic loop. It allows you also the automatic cable removed management.
Let me know
Last edit: Davide Nardella 2025-03-20
I masked the problem as suggested, but since I log every time it disconnects, I would like to address the root causes if possible. How can I act on the communication priority to avoid timeouts? Also, what is a good value for the readtimeout parameter in the msgSocket class of sharp7? Currently, it is set to 2000. Increasing it obviously improves the situation, but I want to avoid any unwanted side effects. Thanks for the suggestions!
Last edit: Stop81 2025-03-20
Currently, it is set to 2000. Increasing it obviously improves the situation
this is not good news, if at 2000ms you have more problems than 3000ms it means that, statistically, some transaction takes 2500ms, and this is unacceptable.
In our high productivity lines we use Snap7 (of course ;-) ) and the maximum time we record is 500ms for a complete transaction (PLC->SQL->Feedback to PLC) in a wired network, more than that we cannot tolerate.
10/15 ms is the maximum time you should expect.
Possible causes:
1- PLC very congested (you can do little about it)
2- Network very congested (check topology, bottlenecks etc..)
3- Problem on cables (it happens sometimes, try changing them)
4- Problem on a switch (try moving the cables to another path)
For problems 3 and 4 you can use WireShark to see if there are TCP packet errors.
The protocol, apart from the PDU negotiation, is quite simple and is based on TCP/IP, you send the request and wait for the response.
If the time is high, either the transmission medium is compromised or the device is congested.
If you want to remove any doubts about the software and if you have the possibility, connect your software to an empty PLC in a controlled network (PC-Switch-PLC) and check the times.
Let me know.
If you don't have an empty PLC, ask the PLC programmer to skip OB1 for some minutes and connect your PC directly to the PLC PN Port.