Sinamics S120 EPOS Speed Tuning: OBT and Dynamic Limits

Problem: EPOS Positioning Too Slow on Sinamics S120

Engineers integrating the Sinamics S120 Basic Positioner (EPOS) with a 1FT7 servomotor frequently see 0→180° traverse times that are 2–3× longer than the mechanical and electrical limits would allow. The classic symptom set reported on field systems matches the one reproduced below from a 20 kW 1FT7108-5SF70-1BA0 servomotor driven by a PM240-2 37 kW (6SL3210-1PE26-0UL0) and controlled by a CU310-2 DP (6SL3040-1LA00-0AA0) on firmware V4.8 with a DCB Extension license 6SL3054-0EJ00-1BA0-Z U01:

• Traverse time 0 → +180° (5 000 LU) measured at ~140 ms (target 50 ms).
• Peak velocity reached only ~400 rpm, far below the motor nominal 3 000 rpm.
• Increasing the P-gain (servo gain factor) past 8.0 produced oscillation/overshoot and drive-side fault entries.
• Raising the 100 % override did not improve anything — proving the limit was elsewhere.

All four symptoms have a single root cause: the dynamic limits of the EPOS motion profile (maximum velocity, acceleration, deceleration, jerk) are still at safe default values even though the user-side override is 100 %. The 100 % override is a multiplier, not a substitute, for the underlying LU-based limits. This article walks through the exact field-proven sequence used to recover the speed, the OBT (One Button Tuning) workflow on firmware V5.1, the parameterization of the position controller sample time, and the configuration of more than the two hardware output cams on the CU310-2.

Hardware and Telegram Reference

The bench configuration in this article uses the SINAMICS S120 booksize line with a CU310-2 DP Control Unit. The parts are kept identical to the original system so the calculated numbers are reproducible:

Standard telegram 12 is the correct choice for EPOS: STW2 / ZSW2, encoder actual, position setpoint/actual, and the EPOS internal control/status words. Telegram 12 is mandatory when the PLC runs MDI, traversing blocks, or jog, because the EPOS operating-mode bits (r0108.4 = EPOS enabled) are exchanged through that frame. See the S120 Function Manual, Section 8.8.2 (Limits and Jerk Limitation) for the formal description of the dynamic-limit parameters discussed in the next sections.

Root Cause: Dynamic Limits vs Override

The single biggest reason an EPOS run feels "slow" is that the user has set a 100 % override but has never raised the underlying velocity/acceleration/deceleration limits. The override is a multiplier — it cannot exceed 100 % of the limit. The original configuration in the source case had:

• Maximum velocity 4 000 000 (×1 000 LU/min) → 4 000 000 LU/min
• Maximum acceleration 100 % (default limit, not exposed at first glance)
• Maximum deceleration 100 % (default limit)
• Position controller Kp (servo gain) 8.0

Those values look generous, but they are interpreted before the override. With override = 100 %, the result is v_max = 4 000 000 LU/min and a acceleration/deceleration limited to 100 % of the underlying p2572 / p2573 dynamic limits, which by default equal 1 000 000 LU/min and 1 000 (×1 000 LU/s²) respectively on a fresh commissioning. The position controller is then bandwidth-limited by a 4 ms position-control time slice (the default value of p115[4] and p115[5] on the Control Unit before re-tuning).

The 500 ms Acceleration Calculation

The order-of-magnitude number that tells you whether EPOS can ever reach the target time is:

t_accel = v_max / a_max

With v in LU/min and a in 1 000 LU/s², the formula becomes:

t_accel [s] = v_max [LU/min] / (60 × a_max [1000 LU/s²])
           = 30 000 [LU/min] / (60 × 1 000 [1000 LU/s²])
           = 0.5 s = 500 ms

That is the value seen in the field report: a triangular velocity profile (no constant-velocity phase for such a short 180° motion) cannot finish in less than 500 ms if the acceleration limit is left at the default. To halve that time, both velocity and acceleration limits must be raised together. A field-proven set of values is:

Re-running the formula with a = 15 000 (×1 000 LU/s²) and v = 3 000 000 (×1 000 LU/min):

t_accel = 3 000 000 / (60 × 15 000) = 3.33 ms… wait, scale check.
v = 3 000 000 × 1 000 LU/min = 3 × 10⁹ LU/min = 5 × 10⁷ LU/s
a = 15 000 × 1 000 LU/s² = 1.5 × 10⁷ LU/s²
t_accel = 5 × 10⁷ / 1.5 × 10⁷ ≈ 3.33 s — not realistic.

That number is obviously too large, which means the scaling used in the source post (3 000 000 1 000 LU/min) actually means 3 000 000 000 LU/min. This is one of the most common traps in EPOS configuration: the unit column in STARTER / Startdrive shows the SI interpretation, but the parameter index in the expert list still carries the legacy 1000 LU/min prefix from S120 firmware ≤ V2.x. The correct interpretation in the case at hand is:

p2571 = 30 000 (1000 LU/min)  → v_max = 30 000 × 1 000 = 3 × 10⁷ LU/min = 5 × 10⁵ LU/s
p2572 = 1 000 (1000 LU/s²)    → a_max = 1 000 × 1 000 = 1 × 10⁶ LU/s²
t_accel = 5 × 10⁵ / 1 × 10⁶ = 0.5 s

With the corrected scaling, the source case had t_accel = 0.5 s — which is exactly the 500 ms the engineer measured. Raising acceleration to p2572 = 1 000 000 (1 000 LU/s²) gives a_max = 1 × 10⁹ LU/s², but that is already far above the position controller can follow at the default 4 ms sample time. The next bottleneck becomes the position controller and the speed/torque precontrol.

Lowering the Position Controller Sample Time (p115)

EPOS runs in a position control slice that is configured in p115 on the Control Unit. The default after commissioning is:

• p115[0] Current controller — 125 µs (read-only, derived from p1100)
• p115[1] Speed controller — 125 µs (read-only)
• p115[2] Flux controller — 250 µs (read-only)
• p115[3] Position controller input — 4 000 µs (read-only)
• p115[4] Position controller — 1 000 µs
• p115[5] Positioning — 4 000 µs

To make EPOS follow a fast trapezoidal motion, the position controller time slice (p115[4]) and the basic-positioner time slice (p115[5]) should be dropped:

p112 = 3  (Expert parameter access)
p115[4] = 500 µs   (Position controller, was 1 000 µs)
p115[5] = 1 000 µs (Basic positioner, was 4 000 µs)

The current and speed controller cycles are firmware-locked and cannot be reduced by the user. Halving the position controller cycle and the basic-positioner cycle doubles the achievable Kp of the position loop, but it also doubles the load on the CU310-2. If the Control Unit is already saturating (drive-side F08501 "Sign-of-life missing" or F08502 "Setpoint timeout"), the time slices must be brought back up. Start with the conservative values above and verify under load.

Activating Torque Precontrol (p5271.4) and Speed Precontrol

Even with the right dynamic limits, a pure P-only position controller will always show a tracking error (following error / lag) that is proportional to velocity. To remove the steady-state lag the position controller is augmented with two precontrol signals:

Set the bits in p5271 from the expert list in Startdrive. The torque precontrol and speed precontrol together eliminate the following error during the constant-acceleration and constant-velocity phases of the profile, so the P-gain only has to fight the disturbance torques (friction, cogging, load). That is why the field result showed that P-gain could be lowered from 8.0 to 3.5 without losing stiffness once precontrol was active.

One Button Tuning (OBT) on Firmware V5.1

OBT is not "Optical Bus Terminal". It is One Button Tuning — the automated one-shot commissioning tool inside the S120 from firmware V5.1 onwards. It performs a full closed-loop identification, sets speed controller P/I gains, sets the position controller Kp, symmetrizes speed precontrol, sets torque precontrol, and measures the load inertia. Procedure (with the drive in no-load or safe-load state):

1. Upgrade firmware from V4.8 to V5.1. See the S120 firmware V5.1 download / release notes (entry ID 109753109) for the official files. The CF card is read by a PC, the four new firmware files are dropped on the card (do not delete the existing LICENSE.TXT or KEY.TXT), and the card is re-inserted in the CU310-2.
2. Set the expert access level: p0003 = 3, p112 = 3.
3. Activate torque precontrol: p5271.4 = 1.
4. Start OBT: p5300 = 1 (rising edge). The drive immediately goes into alarm state and requests the traversing distance in p5308.
5. Read the recommended distance from the alarm buffer (e.g. "+5 000 000 LU") and write it into p5308. The alarm clears automatically.
6. Re-issue the start: p5300 = 1 (rising edge). The drive accelerates, runs the identification, and ends in stop state. The new Kp, Tn, precontrol, and inertia are written to p1400, p1428, p1429, p1493, p1517, p2538, p5271.
7. Save with "Copy RAM to ROM" and then back up the project in STARTER / Startdrive.

Jerk Limitation and the "Trailing Tail" Phenomenon

The engineer observed in the trend that the actual velocity continued to rise for several milliseconds after the AccInProgress bit (r2683.5) went from 1 to 0. That is the expected behavior of a jerk-limited profile: at the moment the acceleration integrator reaches its setpoint, the actual velocity is still integrating the constant a over a few ms of controller delay, so v_target and v_actual are not bit-exact synchronous. The same effect on the way down explains the DecInProgress tail. The cure is to either:

• Disable jerk limitation by setting p2575 = 0 (default) and p2574 = 0 (0 = no jerk limit). The motion becomes a pure trapezoid, the AccInProgress/DecInProgress bits align with the actual velocity transitions, and the trajectory gains ~10–15 % in peak velocity for the same a_max.
• Or keep jerk limitation but increase p2574 (e.g. 10 000 → 50 000 1000 LU/s³) to give a steeper acceleration ramp that reaches v_max faster.

For a 180° 50 ms motion, jerk limiting is usually dropped entirely. The mechanical strain is acceptable on a rigid 1FT7108 coupling.

Firmware Upgrade V4.8 → V5.1: License Preservation

Upgrading firmware does not remove the DCB Extension license 6SL3054-0EJ00-1BA0-Z U01. The license is bound to the CompactFlash card serial number, not to the firmware version. The procedure to upgrade safely is:

1. Power down the CU310-2, remove the CF card.
2. On a Windows PC, take a sector image of the card using Acronis or HDD Raw Copy Tool. Keep the image as the rollback asset.
3. Format the CF card only if instructed by the firmware release notes — in most cases you simply copy the new firmware files (SINAMICS.S, ...FW files) over the existing ones, leaving the directories \OEM, \USER, and the root LICENSE.TXT and KEY.TXT intact.
4. Re-insert the card. The CU310-2 boots the new firmware and re-validates the license automatically. The license is preserved as long as the CF card's CID/serial is unchanged.
5. Verify with r7800 (license status) and r7841 (active license features).

Configuring More Than Two Output Cams on CU310-2

The CU310-2 hardware itself only has two cam-output terminals (X122 / X132, depending on variant). The S120 firmware also only exposes two software cams in the standard parameter set (p2540 / p2541 = cam 1, p2542 / p2543 = cam 2, plus their on/off r2544 / r2545 and the inversion bits p2546). For four cams in a non-zero-based window the supported field solutions are:

For the four-cam configuration from the source case (CAM 1: 1 000…2 000 LU, NC; CAM 2: 3 000…4 000 LU, NO; CAM 3: 5 000…6 000 LU, NO; CAM 4: 7 000…8 000 LU, NC) the recommended path is DCC inside the drive. A DCC chart on the CU310-2 has access to r2521 (actual position) and can publish the result to a digital output, or — more commonly — set a status word that the S7-400 reads over PROFIBUS. The standard "Output cam" DCC block gives the engineer the same parameter shape as the firmware cams but with full flexibility on normally-open/normally-closed, the start angle, and the cam position (no longer forced to start at 0). The two firmware cams in p2540…p2543 can then be reserved for hardware-level safety cams (with shorter response time) while the four process cams run in DCC.

Field Verification Procedure

1. With the drive in "Ready for Run" but the controller inhibited, set the new p2571, p2572, p2573, p2574, p2575, p5271.4, p5271.5 in the expert list and "Copy RAM to ROM."
2. Open an IBA / StarScope / Trace in Startdrive. Record r0061 (encoder speed actual), r0021 (position actual), r2521 (MDI/position setpoint), r2683 (status word EPOS, contains AccInProgress/DecInProgress), r2554 (active position setpoint), and r2537 (following error).
3. Trigger a 0 → 180° (5 000 LU) traversing block from the S7-400 with MDI/Program control word STW1.4 = 0 and STW1.5 = 1 (traversing-block start).
4. Verify: r2537 (following error) never exceeds the configured monitoring limit (p2544 for SW-cam / p2546 for dynamic following error). Peak r0061 should now be in the 2 400 – 2 800 rpm range instead of 400 rpm.
5. Time the transition from "Traversing-block running" to "Traversing-block complete" (r2683.10/11). 0 → 180° should now run in 60–80 ms with the OBT-tuned gains and p2574 = 0; ~50 ms is achievable with an additional reduction of p115[4] to 500 µs and a load inertia measured within 5 %.

Troubleshooting Matrix

Field-Result Summary

With the parameter set above (p2572 = 15 000 1 000 LU/s², p2571 = 3 000 000 1 000 LU/min, p2574 = 0, Kp = 3.5 from OBT, p5271.4 = 1, p5271.5 = 1, p115[4] = 500 µs, p115[5] = 1 000 µs), the source system went from a 140 ms / 400 rpm profile to a 100 ms / 2 400 rpm profile on firmware V4.8, and the V5.1 OBT result was reported as "fantastic" by the experienced integrator. The remaining 50 ms target requires either a further reduction in load inertia (mechanical detuning) or a change to the higher-bandwidth 1FK7 / 1FS6 motor family.