Resolving MDX61B Position Refresh 5s on S7-300 CPU314C Profibus

Problem Statement

A recurring field issue when integrating a SEW-Eurodrive MDX61B (MoviDrive) servo inverter with a Siemens SIMATIC S7-300 CPU314C over Profibus DP is an unacceptably long refresh cycle for the actual motor position. In one documented case, the user read servo position from the drive into a STEP 7 data block, but the value updated only every 5 seconds, while the application required sub-second feedback for closed-loop control. The mechanical feedback device on the motor in that case was a resolver, but the same symptom appears with HIPERFACE and sin/cos encoders because the bottleneck is on the bus side, not the encoder side.

This article documents the root cause (a 30-parameter cyclic read loop inside a polling function block such as FB252) and the field-proven solution (replacing the multi-parameter loop with a single-parameter read and, preferably, mapping the actual position into the PZD channel). Verification steps, alternative fixes, and best practices for any CPU314C + MDX61B project are included.

System Architecture

The reference configuration is a typical Profibus DP-V0 segment:

• PLC: Siemens SIMATIC S7-300 CPU314C-2 DP (6ES7314-6CG03-0AB0) or CPU314C-2 PN/DP (6ES7314-6EH14-0AB0), firmware versions V2.x through V3.3 depending on the catalog number.
• Drive: SEW-Eurodrive MDX61B-001-5A3-4-0T (or equivalent power stage) with a DFP11B Profibus DP option card (or DFP21B for newer units).
• Feedback: Resolver (also valid: HIPERFACE encoder, sin/cos incremental) wired to the MDX61B encoder interface X14/X15.
• Engineering: STEP 7 V5.5 + SPx (or TIA Portal V13+ for read-only project reuse). The CPU314C is programmed with STEP 7 V5.5; TIA Portal can view the project but cannot fully edit an S7-300 project on older STEP 7 versions.
• GSD file: SEW_6007.GSD (DFP11B) or SEW_6008.GSD (DFP21B), imported into HW Config.

CPU314C Key Specifications

MDX61B + DFP11B Telegram Structure

The MDX61B with the DFP11B option card supports the SEW standard telegrams 1 through 102. For position feedback, the most common selection is:

• PZD-OUT (PLC → drive): 2 to 6 words (control word, setpoint speed, ramp, etc.)
• PZD-IN (drive → PLC): 2 to 10 words (status word, actual speed, actual position, current, etc.)
• PKW channel: 4 words (8 bytes) for acyclic parameter access

The PKW channel supports 4-word acyclic access (read/write) and is used for the parameter read loop. The PZD channel is updated automatically every Profibus cycle.

Profibus Communication Fundamentals

To understand the 5-second refresh, the difference between PKW and PZD on a SEW drive must be clear.

PKW (Parameter-Kennung-Wert) Channel

The PKW channel is an acyclic, request/response mechanism. The master sends a parameter request (read or write); the slave replies in the next bus cycle. Each PKW transaction consumes 2 bus cycles (1 request + 1 response), plus the bus token rotation time.

The 4-word PKW layout is:

For a 32-bit parameter such as actual position, the read request uses AK = W#16#1003 (read double-word) and the response fills words 4 and 5.

PZD (Prozessdaten) Channel

PZD is cyclic, broadcast-style: the master writes the PZD-OUT and the slave writes the PZD-IN every bus cycle. No request is required. The PLC simply reads the process image and the latest values are always there.

For the MDX61B, configure the actual position in the drive so that it appears in one of the PZD-IN words:

• Set P091 Actual position value (or its index, depending on the firmware revision) to a fixed PZD slot, or
• Use the SEW standard telegram 4/2 or 6/4 which includes actual position in the PZD-IN by default.

Cycle Time Math

At 1.5 Mbit/s Profibus (default), the bit time is 0.667 µs. A typical MDX61B telegram with 4 PZD-out + 4 PZD-in + 4 PKW words = 12 words = 24 bytes = 192 bits = 128 µs of pure telegram time. Adding token rotation (~3 ms with 5 slaves), the bus cycle is 4-6 ms. At 12 Mbit/s, this drops to 1-2 ms.

For a 30-parameter PKW read loop, with each read consuming 2 bus cycles, the theoretical PKW time is 60 × 5 ms = 300 ms. This is well under 5 seconds, which means the bottleneck is not the bus cycle time but the placement and scheduling of the parameter reads inside OB1.

Root Cause Analysis: The 30-Parameter Read Loop

The user project contained a function block (FB252, a parameter polling block used in the project) that:

1. Executed 30 drive-parameter reads per OB1 cycle, each using SFC14 (DPRD_DAT) on the PKW channel, OR
2. Sequentially issued 30 PKW request/response transactions in a single OB1 scan.

Although each individual PKW read can complete in 1-2 bus cycles, several factors combine to produce a 5-second worst-case refresh:

With 30 parameters and a per-parameter cost of 50-200 ms in a slow loop, the last parameter in the loop (which may or may not be the position) can have a wall-clock refresh of 1.5-6 seconds. If the position is the 30th, it sees the full 5 seconds.

Diagnostic Procedure

Before changing code, confirm the bottleneck with measurements.

Step 1: Measure OB1 and Profibus Cycle

1. Open STEP 7 V5.5, go online to the CPU.
2. PLC → Online → Module Information → Performance tab.
3. Record:
   • OB1 minimum / current / maximum cycle time (typical S7-300 range 5-150 ms).
   • Longest cycle time in the buffer (look for the entry with the highest cycle value).
4. Open PLC → Online → Profibus Diagnostics (or use the diagnostic repeater if installed) to read the bus cycle.

Step 2: Trace the Parameter Read

1. In STEP 7, open the call tree of OB1. Locate FB252 (or equivalent) and its instance DB.
2. Right-click the instance DB → Cross-References. Identify which OB calls FB252 and at what point in OB1.
3. Open the FB source. Count the number of CALL SFC14 or CALL SFC59 blocks per invocation. Confirm 30.

Step 3: Time-Stamp Each Parameter Read

Add a temporary counter inside FB252 to log:

• Index of the parameter currently being read.
• Time stamp (from SFC1 / system clock) at the start and end of the read.
• Return code of SFC14 / SFC59.

Watch the position parameter over 10 seconds in a VAT. If it only updates once per ~5 s, the loop is the cause.

Step 4: Check SFC Return Codes

If RET_VAL is non-zero, the parameter read itself is failing and FB252 may be waiting or retrying — which also extends the loop time. Most cases with the 5-second symptom show RET_VAL = 0 (no error, just slow).

Solution 1: Single-Parameter Cyclic Read

The simplest fix, validated in the field, is to read only the actual position parameter in OB1, instead of polling all 30 drive parameters.

STL Implementation

// Read MDX61B PZD channel only
CALL "DPRD_DAT"                  // SFC14, read consistent data
     LADDR   := W#16#100         // Profibus I/O start address of MDX61B
     RET_VAL := MW 100           // 0 = no error
     RECORD  := P#M 110.0 BYTE 8  // 4 PZD words = 8 bytes
     NOP  0

// Optional: copy actual position (assumed at PZD-IN word 3)
LAR1  P#M 110.0
L     W [AR1, P#6.0]              // Word 3 = low word of position
T     DB10.DBD 0                  // "ActPosition" double word in DB10
L     W [AR1, P#4.0]              // Word 2 = high word
T     DB10.DBD 4

LAD Implementation

1. Insert an empty network in OB1 at the top (before the FB252 call if kept for other purposes).
2. Add the SFC14 / DPRD_DAT block from the Standard Library → System Function Blocks.
3. Set LADDR to the configured Profibus I/O start address of the MDX61B (e.g., 256 decimal = W#16#100).
4. Set RECORD to a non-process-image bit memory area (e.g., MB110 to MB117 for 4 words).
5. Copy the actual position word(s) to a DB tag using MOVE.

With this change, the position updates every OB1 cycle (typically every 5-50 ms), well under the 1-second requirement.

Solution 2: PZD Mapping for Actual Position

Better than reading the parameter is to map the position into the PZD channel in the drive itself. Once mapped, the value arrives in the PII automatically every Profibus cycle, with zero application code overhead.

Drive Configuration (MDX61B / MOVITOOLS MotionStudio)

1. Open the project in MOVITOOLS MotionStudio.
2. Go to Communication → Profibus.
3. Select a process data configuration with at least 4 PZD-IN words.
4. Assign actual position (parameter P091 in classic parameter scheme, or Index 0 of P8080 in newer schemes) to PZD-IN word 3 (or 4).
5. Save to the drive and power-cycle if required.

STEP 7 HW Config

1. HW Config → MDX61B slave → DP slave properties → assign PZD length of at least 4 IN / 4 OUT words.
2. Note the I/O start address (e.g., IW 100 for PZD-IN, QW 100 for PZD-OUT).
3. Use direct I/O access in OB1:

   L IW 104   // PZD-IN word 2 (high word of position)
   T DB10.DBW 0
   L IW 106   // PZD-IN word 3 (low word of position)
   T DB10.DBW 2

Position update interval is now equal to the Profibus cycle (1-6 ms at typical baud rates). This is the recommended long-term architecture for any application needing sub-millisecond feedback.

Solution 3: Time-Slicing with Cyclic Interrupts (OB35)

If PZD mapping is not possible (e.g., the drive firmware does not expose the position as a PZD signal) and a multi-parameter read must remain, split the loop across multiple OB35 cycles:

1. Configure OB35 with a 100 ms cycle (default in HW Config, CPU Properties → Cyclic Interrupts).
2. Call FB252 with an index that advances by 1 each OB35 cycle (0-29).
3. Read only one parameter per OB35 invocation, not all 30.

This guarantees that every parameter is read at least once per 3 seconds. To read the position more frequently, add a separate CALL SFC14 for the position in OB1 (Solution 1) while moving the 30 less time-critical parameters to OB35.

Solution 4: Hardware and Topology Upgrades

If the application is being designed for the long term, several options exist:

Verification Procedure

After applying Solution 1 or Solution 2, perform the following checks.

Static Verification

1. Go online, open a VAT for the position tag (e.g., DB10.DBD0 "ActPosition").
2. Manually move the motor axis by a small amount via MOVITOOLS (in inching mode, parameter 0.1 mm increments).
3. Confirm the VAT value updates within 1 second of the motion.

Dynamic Verification

1. Add a temporary count block in OB1:

   L DB10.DBD 10       // refresh counter
   + 1
   T DB10.DBD 10
   
   // reset every second using timer
   // verify counter reaches ~1000 after 1 second at 1 ms OB1
   // = position is read every OB1 scan

2. Run the drive at 1000 rpm, watch the counter increment at 1000/s if OB1 is 1 ms (or 50/s if OB1 is 20 ms).

Bus Health Verification

1. Open the diagnostic buffer (PLC → Module Information → Diagnostic Buffer). Confirm no Profibus faults over 1 hour of operation.
2. Check RET_VAL of SFC14 in a watch table; it must remain 0.
3. Use the BT 200 Profibus tester or a diagnostic repeater (e.g., 6ES7972-0BA40-0XA0) to log bus errors.

Best Practices

• Use PZD, not PKW, for time-critical data. Position, speed, current, and status should always be mapped to the cyclic process data channel.
• Reserve PKW for commissioning, diagnostics, and non-critical parameters. Read motor temperature, hours, etc., in OB35 with a 1-second cycle.
• Never use a generic 30-parameter drive block in OB1. If you must, time-slice it across OB32-OB35 with at most 5-10 parameters per call.
• Set Profibus baud to 12 Mbit/s on any new installation if cable length allows. The 1.5 Mbit/s default is conservative for legacy reasons.
• Use SFC14 / SFC15 (DPRD_DAT / DPWR_DAT) for any PZD read/write > 4 bytes to guarantee consistency. Direct PII access is allowed only for single-word or 4-word aligned data.
• Document the GSD file version in the project header. SEW has released multiple DFP11B GSD revisions; mismatched firmware/GSD causes PKW errors that mask as "slow" responses.
• Monitor the longest OB1 cycle time in the diagnostic buffer. If it ever exceeds 100 ms, the application needs a faster CPU or distributed I/O.
• For new designs, use a CPU314C-2 PN/DP with PROFINET and a DFE11B/DFE12B option on the drive. This eliminates the entire class of bus-cycle issues.

Field-Proven Notes and Edge Cases

• Resolver vs HIPERFACE has no impact on Profibus cycle time. The encoder signal is decoded inside the drive, and the resulting position value is what the drive publishes to PZD. The bus side is identical for both.
• Long OB1 cycles (> 100 ms) are not always the user's fault. SFC14 / SFC59 with non-aligned data, or a CP342-5 in front of the integrated DP port, can introduce 50-200 ms of additional latency per call.
• DFP21B cards (used on newer MDX61B units) support Profibus DP-V1. With DP-V1, the acyclic PKW reads no longer occupy a bus cycle: they use the DP-V1 read/write service. Combined with the PZD mapping, this can yield position feedback at the bus cycle with no PKW overhead at all.
• Some users report a 5-second refresh even with a single PKW read. This is almost always caused by the I/O update being driven by OB1 (not OB35), combined with a long OB1 cycle dominated by FB252 and other drive code. The solution is the same: shorten the loop and move the position to PZD.
• The GSD file SEW_6007.GSD supports up to 16 PKW words and 32 PZD words per direction. The CPU314C's integrated DP master is rated for the full Profibus DP-V0 spec; no hardware upgrade is needed for a faster cycle.