Alain1533

Bonjour, Sorry, but I'm very busy today. I found where the time to wait came from, I use a Timer component in order to cycle the requests, 1 Emission / Reception every 2 ms at the miximum, otherwise the PLc is out of order. This timer uses "Synchronize" to call a "Callback" which signals the timer, and that's what was taking time. What is strange is that it does not pose a problem with a Windows 10 32bits. I specify that this is not the standard component of the VCL but one of our components. So, now I use a Thread which controls the start of the Send / Receive cycle and which at the end of the loop waits a fixed time of 2ms before resuming another Send / Receive cycle. This time is adjustable, it uses "TStopwatch" to measure the time. On my simulator it works perfectly, on a machine with Windows 32bits or Windows 64 bits, we will do the tests with the real PLC. So the problem was not with the ICS components, which gives us complete satisfaction on all our machines. We'll see tomorrow thank you very much for your help Alain

No I don't use sleep The data is binary data, on the PC side it comes from a memory Mapper file. in fact, it is a Byte buffer. No, i don't use 3rd-party library, only overbyte On the other hand, it is a real time timer which tests every 2 ms if the PLC has finished sending its DBs, if so, it will send its data again, and so on, I will make you a zip of the drivers

Alright, I'll prepare the code and do the test tomorrow morning Merci

Unfortunately it is not easy to reproduce the problem without having a PLC, I will try to give you the simulator that I use with a minimum of code. Yes I tried with a 64-bit compilation without noticeable change

Hello, I performed the tests under the following conditions: Same PC Same PLC (S1500S) Direct cable connection Same application: Delphi 10.3 overbytes Release: V8.65 32bits compilation PLC IP = 192.168.7.3, Port = 2000 PC IP = 192.168.7.11 Test1: With windows 10 32bits Test2: With windows 10 64bits For test1 the cycle time = 3 Milliseconds For test2 the cycle time = 15 Milliseconds I made images of the WireShark for the two tests, I put in red the notable differences between the sequences: [ACK] and [PSH, ACK] which marks the beginning of the exchange. With windows 10 32 bits delta time is between 1 and 3 Ms With windows 10 64 bits delta time is between 12 and 13 Ms I think the slowdown in communication is due to this, however I'm not sure what to do to solve this problem. I have tried different configuration without noticeable change, for the moment we will therefore stay under windows10 in 32bits, but I would like to know where it can come from. Thanks for your help. Alain

hello, "TCP CheckSum incorrect' I solved the problem, it was a faulty cable

I had a probleme with my cable, i switched to WIFI and there i have no more checksum error in WIFI the cycle time is 15 ms, i try again on Monday at the office with direct connection. netstat -e -> Errors = 0 Thank you for your help Alain

I don't have screenshot of the fast version, i do it Monday at the office

I have just redone the following tests: Server: Simple S1500S simulator, Receive / transmit 4096Bytes binary frame IP: 192.16.7.100 Client : Basic program used on our machines IP: 192.16.7.150 Loop Cycle = 69 Milliseconde Wireshark: There is a huge amount of error: Incorrect TCP checksum I added an image of wireshark Copy Paste of a '19 774 kb' file with windows explorer is instantaneous

No domain name IP: S1500S 192.168.7.21 PC 192.168.7.100

Hello Angus, Yes I am using simple TWSocket, the data is binary data. /// <summary> /// Buffer de traitement des DB /// </summary> TS7Buffer = array[0..MAXWORD] of Byte; ... /// <summary> // Send Mapstream to Siemens DB100 /// </summary> FS7BufferOut : TS7Buffer; ActiveCliSocket.Send(@FS7BufferOut,iSize); .... The reception buffer is large, the data exchanged between the S1500S PLC and the PC is only 4096 Bytes I tried to reduce the size of the buffers, but it didn't change anything No domain name IP: S1500S 192.168.7.21 PC 192.168.1.100 I will try to compile with the EMbarcadero beta test version (10.4) I received the new version yesterday Thank you very much everyone for your help Alain

I'm gonna do these tests and tell what's going on

all our machines are in IPV4

compilation 32 or 64 bits no change

Hello François, Thank you for your reply. Yes the connection is Ok Jumbo, I tried with and without, no change I did some tests with and without anti-virus no change Yes the new computer hardware is superiror to the old one merci