Sampling speed to S7400 in Service Lab

naturephoenix

Member
Join Date
Jan 2015
Location
Vienn
Posts
181
Hello guys,

I have S7400 and network inside is Profibus DP and MPI with it is speed 187.5kbs. I am connecting with service lab to record data from PLC with CP5711 adapter choosing MPI in SetPG/PC. Inside Service Lab I have option to choose sampling time. What is maximum sampling time I can choose in this network configuration. There are 3 more device with Profibus DP in this network as well
 
In my experience, you can use whatever sampling rate you want that ServiceLab will do its best to achieve it, but without actually stopping your network to do so.
 
In my experience, you can use whatever sampling rate you want that ServiceLab will do its best to achieve it, but without actually stopping your network to do so.

I know, but there must be some logical sample rate which you can expect regarding network settings. Problem is to determine relation between kbps and kHz
 
Last edited:
I know, but there must be some logical sample rate which you can expect regarding network settings. Problem is to determine relation between kbps and kHz


kbps = kilobits per second or 1024 bits per second


kHz = logging 1000x per second


In simple terms, if the all the bandwidth available is used for logging, at 1 kbps you could: log 1 bit at 1 kHz, or 2 bits at .5kHz (500Hz), or 16 bits/1 Word at 62.5Hz (.0625 kHz).

In reality, it is much more complicated than that. There is network overhead, PLC performance, etc. MPI is also a shared medium, which means that the bandwidth is at most 50% of what is described above.

For the network overhead, there is a fixed amount of data that is required to send the request, but then after that it scales linearly (each request adds about the same amount of data). In Ethernet, the minimum request is 64 bytes, even for just one tag. I'm not sure how that all plays out in MPI.

Realistically, you should probably start with logging at something like 1 Hz (not 1 kHz), and then see if you can push it to something like 2 or 5 Hz. The 400 is pretty good at handling comms, but MPI is SLOW.
 
Last edited:
kbps = kilobits per second or 1024 bits per second


kHz = logging 1000x per second


In simple terms, if the all the bandwidth available is used for logging, at 1 kbps you could: log 1 bit at 1 kHz, or 2 bits at .5kHz (500Hz), or 16 bits/1 Word at 62.5Hz (.0625 kHz).

In reality, it is much more complicated than that. There is network overhead, PLC performance, etc. MPI is also a shared medium, which means that the bandwidth is at most 50% of what is described above.

For the network overhead, there is a fixed amount of data that is required to send the request, but then after that it scales linearly (each request adds about the same amount of data). In Ethernet, the minimum request is 64 bytes, even for just one tag. I'm not sure how that all plays out in MPI.

Realistically, you should probably start with logging at something like 1 Hz (not 1 kHz), and then see if you can push it to something like 2 or 5 Hz. The 400 is pretty good at handling comms, but MPI is SLOW.

You, we're right! I got only 10Hz. (15 Reals). Point is when you calculate it can 187 bits at 1kHz. So that's around 6 Reals, 12 Reals 500Hz, 24 Reals at 250 Hz. If we take 50% bandwidth into account that would be 12 Reals at 250Hz. In reality it is 15 Reals at 10Hz. Difference between 250 and 10 Hz went to CPU performance and network overhead? I mean how did you know it is gonna be only around 5Hz
 
On top of MPI is the FDL layer and then on top the S7 protocol layer which I guess most drivers are using.

The S7 protocol overhead for polling 15 real values in worst case (15 values are not consecutive in memory or bad driver) is:

Request: 10 bytes header + 2 + 15 * 12 = 192 bytes
Response: 12 bytes header + 2 + 15 * (4 + 4) = 134 bytes
-> 326 bytes

Bbrutto (326) to netto (60) = 82% overhead only on S7 protocol.

If you place the 15 reals so they can be read in one block and the driver supports this, this can be reduced to:

Request: 10 bytes header + 2 + 12 = 24 bytes
Response: 12 bytes header + 2 + 4 + (15 * 4) = 78 bytes
-> 102 bytes

reduces it to 41% overhead.

The protocol and most CPUs support cyclic reading of a limited amount of variables, where you don't have to poll the variables (only one request needed).
 

Similar Topics

Dear, I need to take water sample for water quality measurement from a buried pipe, the pipe is buried in the sand, so the contractor will have...
Replies
3
Views
1,767
Hi there, i am looking for a method to sample 600 points on a motor that is running at 800 rpm or sometimes at 1000rpm. Then, i would like to...
Replies
12
Views
3,341
Protocol: Modbus RTU PLC: AB/Rockwell Micro850 as master The PLC is able to read and write holding registers from 20 devices. I want to...
Replies
0
Views
2,965
I am using 15 history data display objects (event trigger) to display 15 different data then I used the backup object in order to save each one of...
Replies
4
Views
1,718
Hi, I'm having problem with data sampling on HMI.I'm using EZware plus software.My program functionality is to capture the hours and minutes on...
Replies
4
Views
2,072
Back
Top Bottom