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

Alain

  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

  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

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

Hello,

I use your components (wsocket) in industrial applications, binary TPC transfer between applications and Siemens PLCs. (s1500s).

The exchanged data blocks have a size of 4096 Bytes ,.

The transfer time under Windows 7 32bits is 4Milliseconds which is perfect for

our applications.

On our new machines, we need to install Windows 10 64bits.

The transfer programs still work perfectly, however the transfer time has dropped to 15 milliseconds, which is absolutely not suitable

for our applications.

I tried several different configurations, compilation in 32bits, 64bits, adjustment of the buffer sizes, without much change.

WIndows 10, Window 7 32Bits: Transfer = 4 Milliseconds

Window 10 64Bits: Transfer = 13 to 15 Milliseondes

It therefore seems that as soon as the OS is in 64bits the communication is slower.

We absolutely have to install Windows 10 64bits versions, this is a request from our customers, so I absolutely have to find a solution.

IDE Rad Studio Achitect

RIO 10.3 compiler

Overbyte Release: V8.65

Delphi language.

I would like to thank your team, your components are excellent and have always given us complete satisfaction.

Alain Verdier