Calculating Maximum Sampling Rate on S7-400 MPI at 187.5 kbps

This technical reference defines the maximum achievable logging frequency for a Siemens S7-400 connected to Siemens Service Lab via a CP5711 communications processor on a mixed MPI / Profibus DP segment running at 187.5 kbps. It covers the relationship between physical bit rate (kbps) and effective log frequency (Hz), the S7 protocol overhead that dominates a real installation, and the engineering steps required to verify, optimize, and document the achievable cycle time before commissioning trending or condition-monitoring jobs.

Problem Definition

An S7-400 CPU is wired into a Profibus segment that also carries MPI traffic. The Service Lab application must log a set of REAL (32-bit) tags from the CPU at the highest sustainable rate without disrupting cyclic control communication. The bottleneck is not the CPU scan time; it is the shared serial bus. Engineers frequently overspecify the polling rate, fill the bus with request/response pairs, and as a result starve Profibus DP slaves (in this case, three additional devices) of their token time.

Prerequisites

Before calculating the theoretical maximum, confirm the following on the physical layer and in the engineering station:

1. CPU family and firmware. S7-400 (e.g., CPU 412, 414, 416, 417). All S7-400 CPUs from 6ES741*-... firmware V4 and later support the S7 communication services used by Service Lab without PG/PC routing restrictions on MPI.
2. CP5711 USB adapter (Siemens 6GK1571-1AA00) installed on the engineering PC, drivers loaded via SIMATIC PC Adapter USB driver package, and the Set PG/PC Interface utility set to S7ONLINE -> CP5711 MPI.
3. Step7 / TIA Portal project with the MPI network defined at 187.5 kbps (default Profibus baud rate for legacy MPI segments). Verify with PG/PC Interface -> Diagnostics that the CP5711 has reached the OPERATE state.
4. Service Lab license (Siemens 6ES7851-0CC03-0YA5 or successor) installed and able to enumerate DB/M/I/Q areas from the S7-400.
5. Bus topology documented: CPU MPI/DP port, three Profibus DP slaves, CP5711 tap, and segment termination resistors enabled at both physical ends.

Reference Network Configuration

Theoretical Bandwidth Analysis

The nominal line rate of 187.5 kbps equals 187,500 bits per second. The widely used conversion is:

Equation 1 - Bits per second to samples per second:

f_log [Hz] = R [bps] / (n_bits_per_sample × overhead_factor)

Where R = 187,500 bps, n_bits_per_sample is the user payload in bits per logging cycle, and overhead_factor is a multiplier (typically 1.4 to 2.0) representing FDL framing, inter-frame gaps, token time, and S7 protocol headers.

Naive (No-Overhead) Calculation

If 100% of the wire bandwidth were usable and every bit carried a sample, 1 Hz per bit on a 187.5 kbps line would yield:

• 187 bits logged at 1,000 Hz (1 kHz)
• 6 REAL values (192 bits) at 1 kHz
• 12 REAL values (384 bits) at 500 Hz
• 24 REAL values (768 bits) at 250 Hz

This is the optimistic ceiling. The shared-medium rule of thumb immediately cuts the figure in half:

Available payload = 187,500 × 0.50 = 93,750 bps

The expected rate for 15 REAL values (15 × 32 = 480 bits) becomes:

f_log ≈ 93,750 / 480 ≈ 195 Hz

The 50% shared-medium rule is, however, only the first reduction layer. The dominant loss in practice is the S7 protocol overhead described in the next section, which drops the actual ceiling to single-digit Hz for tag counts above 10.

S7 Protocol Overhead Calculation

MPI and Profibus FDL carry the S7 communication (S7Comm) layer used by Service Lab, STEP 7, and most OPC servers. Each variable read carries a fixed request/response envelope plus a per-item read or write header. The two relevant scenarios are non-contiguous (worst case) and contiguous (best case) tag layout in the S7-400 data block.

Worst Case - Non-Contiguous Tags

When Service Lab cannot bundle the 15 REALs into a single read request, every variable requires its own S7 item:

Request envelope:

10 byte TPKT/COTP header + 2 byte S7 header + 15 × 12 byte read-item = 192 bytes

Response envelope:

12 byte TPKT/COTP header + 2 byte S7 header + 15 × (4 byte data + 4 byte item) = 134 bytes

Total on-wire payload: 192 + 134 = 326 bytes = 2,608 bits.

Of that, user data is 15 × 32 = 480 bits. Overhead is 82%.

Best Case - Contiguous DB Block

If the 15 REALs are placed consecutively in a single DB and the S7 driver (LibNoDave, S7NetPlus, Snap7, or the Service Lab native stack) issues a single multi-variable read, the math collapses dramatically:

Request envelope:

10 + 2 + 12 = 24 bytes

Response envelope:

12 + 2 + 4 + (15 × 4) = 78 bytes

Total on-wire payload: 24 + 78 = 102 bytes = 816 bits.

User data is still 480 bits. Overhead drops to 41%.

Resulting Sampling Ceiling

Combining 50% shared-medium loss with the S7 overhead yields the expected sample period T in seconds:

The difference between 36 Hz and 10 Hz is dominated by CPU-side S7 communication handling (SFB/SFC dispatch, priority class 1 or 2 scheduling, DB pointer resolution), FDL acknowledgement time, and Service Lab's own buffering. The S7-400 cycle is fast compared with a 100 ms sample period, but a 19" rack at firmware V6 still has measurable per-call cost when the call originates from an MPI class 2 station.

Optimization Strategies

To push the sustainable rate above 10 Hz, work the following levers in order of impact.

1. Consolidate Tags in a Single Contiguous Block

Move all 15 REALs into one DB with no gaps (no BOOL, no INT inserted between them). Document the absolute address, e.g., DB200.DBD0 through DB200.DBD56. This single change moves the overhead from 82% to 41% and roughly triples the theoretical ceiling.

2. Use S7 Cyclic Read (Subscription)

Service Lab and most S7 drivers support a subscription or cyclic read mode where a single PUT/GET-style subscription is established and the CPU pushes updates at a defined cycle. The CPU pre-fetches the variables in its OB1 cycle, so the on-wire count collapses to one request and one response per cycle. This bypasses per-tag arbitration.

3. Move the Logger to Ethernet / Profinet

If the S7-400 has a CP443-1 (6GK7443-1EX30) or an integrated PN interface, relocate Service Lab to Industrial Ethernet / PROFINET. Even at 10 Mbps the bandwidth is 53× the MPI rate, and overhead is identical in bytes but completes in microseconds rather than milliseconds. This is the recommended path for any job that needs more than 50 Hz.

4. Raise the MPI Baud Rate

MPI supports 19.2 kbps, 187.5 kbps, 1.5 Mbps, 3 Mbps, 6 Mbps, and 12 Mbps. The 187.5 kbps setting is conservative for legacy reasons. If the three DP slaves accept the higher rate (their GSD files must permit it), raising the bus to 1.5 Mbps or 12 Mbps gives 8× to 64× headroom. Note: when MPI and DP share the segment, all masters and slaves must agree on the rate.

5. Reduce Token Holding Time for the Logger

Configure Service Lab with the longest acceptable GAP factor and the lowest retry count. Excessive retries balloon FDL traffic without contributing new data.

6. Offload the Logger to a Dedicated Class 2 Master

Some Profibus DP masters refuse to release the token to a class 2 station. Confirm in STEP 7 that the CPU's MPI/DP port is configured to allow at least one class 2 connection, and that no other diagnostic tool is competing for that connection.

Verification Procedure

1. Set baseline. In Service Lab, set sample time to 1000 ms (1 Hz) and confirm all 15 REALs are reading stable, monotonic values.
2. Step up. Double the rate to 2 Hz, then 5 Hz. Wait 60 s at each step and check the Lost Samples counter.
3. Capture bus load. Use a Profibus analyzer (e.g., Softing PBprofi or Siemens BT200) to record the bus utilization. Healthy headroom is below 60%; persistent values above 80% mean the logger is starving control traffic.
4. Record effective rate. Note the Effective Sampling Rate and Jitter columns in Service Lab. If jitter exceeds 25% of the period, drop one step.
5. Document. Save the configuration with the DB base address, baud rate, and maximum verified rate into the project quality file. This is the rate that downstream engineers may quote.

Comparison: MPI vs. Profinet vs. Industrial Ethernet

Commissioning Workflow

1. Open STEP 7 / TIA Portal and connect to the S7-400 online.
2. Inspect HW Config: confirm MPI/DP port, baud rate, configured connections, and the highest class 2 address allowed.
3. Place tags in a contiguous DB (e.g., DB200) at known offsets. Note the byte offset in the project documentation.
4. Configure CP5711 in Set PG/PC Interface with bus parameters identical to the PLC (187.5 kbps, station address 0, highest station 31 or 126).
5. Launch Service Lab, create a new trace, and add the 15 tags by absolute address.
6. Run at 10 Hz as a safe starting point. Verify that Profibus DP slaves are not generating diagnostic interrupts.
7. Tune upward as the verification procedure allows, recording the maximum sustainable rate.

Field-Proven Caveats

• CP5711 driver behavior: The 6GK1571-1AA00 USB adapter enumerates as a virtual COM port on Windows. Driver mismatches between SIMATIC PC Adapter USB and SIMATIC NET PC Software can cause the adapter to fall back to 19.2 kbps silently. Confirm the rate in Set PG/PC Interface -> Diagnostics -> Read.
• PG/PC port conflict: If the engineering PC has both the CP5711 and a CP5611 / CP5613 PCI card installed, MPI routing can flap between adapters and halve the effective rate. Disable the unused adapter in Device Manager.
• Token rotation: The S7-400 default Ttr (target rotation time) is 10000 bit-times. At 187.5 kbps that is ~53 ms. The logger has just one slot per token rotation to issue a read, so even a 5 Hz rate can become bus-bound when DP slaves are active.
• Real-time OS effect: Running Service Lab on a Windows machine with consumer antivirus can delay thread dispatch by 30-80 ms, capping the achieved rate to 10-30 Hz regardless of bus bandwidth. A deterministic host (IPC with Beckhoff TwinCAT/Siemens WinAC RTX, or a hardened Linux panel) is recommended for sustained rates above 20 Hz.
• S7-400 firmware: V5.x and V6.x behave slightly differently for S7Comm. V6 added multi-variable read optimization; if you must remain on V4 or V5, accept that the contiguous-tag optimization gives less than 3× improvement and budget 5-7 Hz as the ceiling for 15 REALs.

Troubleshooting Matrix

References to Internal Documentation

For analog input sampling limits, see the SiePortal thread on maximum sampling rate for analog input modules. For high-speed encoder sampling, the TIA Portal documentation for ET 200S 1SSI specifies a 1.2 kHz encoder sampling rate with a 500 µs processing cycle, illustrating the CPU-side upper bound that contrasts with the bus-side limits described above. For the underlying definition of sampling rate and Nyquist considerations, refer to the National Instruments sampling-rate reference.