S7 communication speed performance

[cmaryus]

Hi

We are trying to develop an interface through iso on tcp/ip from a linux machine with an S7 Siemens with CP 343.

I'm just curios: what's the biggest data block that can be exchanged? is is 8 Kbytes/sec?
Also about the speed: how fast do I read/write 8 Kbytes or more ?

Thank you,
Marius

 

[S7Guy]

I'm not sure about the 343, but with a 443 I routinely read over 30kb per second in 200 byte blocks, so reading/writing 8kb should be a piece of cake. But, you can't send/receive 8kb at once. You will have to break it into smaller packets (I think 2048 bytes works with the 443, but it probably depends on the protocol).

Do a search on the forum and you will find some threads on S7 udp and socket communications.

 

[RRobbins]

Use FC50 & 60 and you can send and receive 8196 bytes

 

[S7Guy]

Well, with FC50 and 60, you still can't send 8192 bytes at once, which is think is what cmaryus means when he asked how big the biggest data block could be. I am pretty sure the buffer in the 443 is 1024 bytes, so the FC would have to go through eight iterations to send 8kb. This may or may not be acceptable, and it would definitely entail some kind of handshaking so the partner knew that all of the data had arrived before doing anything with it.

 

[seppoalanen]

Use FC50 & 60 and you can send and receive 8196 bytes

I think even 65536 bytes. Socket connection: OutBool NDR- tells when data have received/sent. You not need know how many separate small package have used for it ?

 

[RRobbins]

I have attached the manual. Page B4-16 explains the communication sizes. TCP and ISO is 8192 Bytes. You can have multiple connections, if you need more data transfers.

 

[seppoalanen]

I have attached the manual. Page B4-16 explains the communication sizes. TCP and ISO is 8192 Bytes. You can have multiple connections, if you need more data transfers.

Anyhow 8192 bytes are much for PLC who is not SQL-Server !

 

[S7Guy]

One thing about the 8192 byte spec though is that you are still limited (according to the manual) to 26 kb per second even if you are on a 100mbps network, which is about three messages per second. You would think that if the CP card was able to buffer the whole 8192 bytes and send it, the throughput would be higher. And, if there was a 8192 byte buffer, why are UDP packets limited to a total of 2048 bytes? Something doesn’t figure.

I guess it all depends one what one wants to do. Since the bandwidth seems to be limited to about 26kb per second regardless of the protocol, whether someone wants to send huge blobs of data depends on the desired performance. For most projects that I’ve worked on, 300ms per 8192 bytes would seem sluggish, whereas 20ms per 512 bytes would be screaming, so I would use the smaller packets if possible. Then again, maybe cmaryus has a good reason for keeping the 8192 bytes contiguous (i.e., some sort of recipe data).

Once I get back to my lab, I’ll try to write an app that will capture exactly what is going on with these transmissions. And sepp, I'll try that with 65535 bytes. It seems like it should work.

 

[zottel]

if you want to communicate with an S7 over TCP/IP from a LINUX system,have a look at:
http://libnodave.sf.net
Just run the benchmark invoking the precompiled testISO_TCP:
./testISO_TCP -b <your_CPs_IP>
If you have a 400 family system, please let me know the results.

 

[cmaryus]

thank you all, i think i got a good idea about the communication.
i did some tests with libnodave, i can read/write from PLC BUT only 219 data bytes + 35 header bytes. If i send more than 219 bytes i don't receive any acknoledge from the PLC. what settings should i check on the plc side ?

 

[zottel]

Nearly nothing wrong with that, only I thought it should be 222 bytes for reads and 218 for writes
But I never tested libnodave with a 400 family PLC.
Basically, the size of a structure named PDU is limited in S7 communication. The limit can be read in the CPU properties dialog in Step7.

To overcome this limitation, you would need to use multiple calls to daveReadBytes or daveWriteBytes, transferring chunks of memory contents.

It may be that other libraries, e.g. Prodave from Siemens hide this complication from the application, but then you will see multiple packets going over the net for a single operation.
What may be wrong is that the limit off PDU size should be higher in 400 family PLCs with an ethernet CP.
If I remeber right, it is:
240 byte with 3xx and MPI
480 byte with 4xx and MPI
960 byte with 4xx and CP4xx
The payload is some (18 or 22 bytes if I remember right) lower, because adresses, error codes and other information go into the PDU block as well. Additionally, if reading multiple variables, the PLC fills up some parts of the answer to be aligned to word boundaries.
But I guess, in your case something in PDU negotiation (done in daveConnectPLC) went wrong and thus a minimum PDU length of 240 was assumed.

I will dry-check whether libnodave handles PDU length negotiation right, but it would be more helpful if you could send me debug output (use -d option) to the mail address given on
http://libnodave.sf.net.