Configuring Dynamic Ramp Up/Down on S7-1500 with SINAMICS G120C

Overview

Driving a SINAMICS G120C from a SIMATIC S7-1500 (or S7-1500T) is a common configuration for conveyors, mixers, pumps, and basic winder applications. The drive receives closed-loop speed control commands over PROFINET using PROFIdrive telegrams (typically Telegram 1 for speed control, or Telegram 3 with supplementary torque). The PLC side uses a Technology Object (TO) that either bypasses the PLC's own speed controller and writes setpoints directly to the drive (TO_SpeedAxis), or runs a full position control loop locally (TO_PositioningAxis / TO_SynchronousAxis).

One of the most frequent engineering questions in this architecture is: How do I make the ramp up and ramp down time a variable that the PLC program can change at runtime? The answer depends on which technology object you selected, which CPU you are using, and which TIA Portal version is installed. This reference walks through the supported methods, the math, and the commissioning checks needed to make dynamic ramps reliable on a G120C with S7-1500.

Prerequisites

Before configuring dynamic ramps, verify that the following conditions are met:

• PLC hardware: SIMATIC S7-1500 CPU (any S7-151x, S7-152x, S7-1505S) or ET 200SP CPU (S7-151xSP). Firmware version 2.5 or higher is recommended for full motion control feature coverage; V2.9 adds MC_ChangeDynamic to selected S7-1500 CPUs (see notes below).
• Drive hardware: SINAMICS G120C with PROFINET interface (article numbers 6SL3210-1KE1x-xUFx for the PN variants). Firmware V4.7 or higher is recommended for clean PROFIdrive compliance.
• Engineering software: TIA Portal V15.1, V16, V17, or V18 with the SINAMICS Startdrive option installed.
• Communication: PROFINET IRT or RT configured between the PLC and the G120C. Standard Telegram 1 (speed setpoint, 16-bit status / 16-bit control) is the minimum for closed-loop speed control. Telegram 3 adds a 32-bit speed setpoint and 16-bit torque reduction, often used with TOs.
• Configuration: The G120C is configured in the project as a PROFINET IO device with a PROFIsafe slot only if safety is required. Set the ramp-function source to "Ramp-Function Generator inside the PLC" in the drive's commissioning wizard, or alternatively leave the ramp generator inside the drive and use the drive's own parameters P1120 (ramp-up) and P1121 (ramp-down). Both approaches are valid; the choice determines where the jerk-limited profile is computed.

Architecture: TO_SpeedAxis vs. TO_PositioningAxis

The choice of technology object is the most important decision in the dynamic ramp discussion because it changes the location of the speed controller and the way ramps are produced.

Because TO_SpeedAxis does not run a position controller, many of the high-level dynamic-change functions behave differently than with TO_PositioningAxis. The Motion Control function manual is explicit on this point: TO_SpeedAxis inherits the drive's own closed-loop speed control, and the PLC-side motion control merely commands the setpoint trajectory.

Why MC_ChangeDynamic Is Not the Default on S7-1500

The function block MC_ChangeDynamic is the most ergonomic way to update ramp parameters at runtime. It is documented in the SIMATIC S7-1200 Motion Control manual and is fully supported on S7-1200 CPUs. On S7-1500, the equivalent function became available in selected CPU firmware revisions and TIA Portal versions, but it is not the standard recommended path for setting dynamic values on a moving command.

On S7-1500 (and S7-1500T), Siemens documents a different, more flexible approach: every motion control command that initiates motion (such as MC_MoveAbsolute, MC_MoveRelative, MC_MoveVelocity, MC_MoveJog, MC_Halt, MC_Stop) exposes four connectors that take effect for that single call:

• Velocity (LREAL) — target velocity in the unit configured in the TO (typically rpm for rotational drives, mm/s for linear)
• Acceleration (LREAL) — acceleration in (unit)/s²
• Deceleration (LREAL) — deceleration in (unit)/s²
• Jerk (LREAL) — jerk in (unit)/s³

Each connector accepts either a positive value or the special value -1.0. Writing -1.0 tells the TO to use the default value from the axis configuration for that call. This allows a program to issue identical motion commands while passing dynamic values from a process data block (DB) — exactly the "dynamic ramp up/down value" the original question asked about.

Configuring the Technology Object for Variable Ramps

To make ramp times variable, configure the TO with sensible default dynamic values, then override those values on the call to the motion block. Follow this procedure in TIA Portal:

1. Open the technology object in the project tree (e.g., TO_SpeedAxis_1).
2. Navigate to Configuration > Extended Parameters > Dynamic defaults (the exact path depends on the TIA Portal version, but it is the page where Velocity, Acceleration, Deceleration, and Jerk are listed as default values).
3. Enter the maximum safe velocity and acceleration values. The defaults act as ceilings when an -1.0 is passed.
4. Compile the project. The compiled TO data block exposes a member such as TO_SpeedAxis_1.DynamicDefaults.Velocity, ...Acceleration, ...Deceleration, ...Jerk. These members are read-only at runtime and reflect what the TO was commissioned with.
5. In your user program, allocate a global DB (e.g., DB_MotionParams) and create LREAL tags for runtime ramps: RampUpTime_s, RampDownTime_s, TargetVelocity_rpm, Acceleration, Deceleration, Jerk.

Conversion Math: Ramp Time to Acceleration

The PLC expects an acceleration value in the engineering unit unit/s². Operators and most application programs are more comfortable thinking in ramp times (the time it takes to go from zero to target velocity). Convert the two as follows:

For example, to reach 1500 rpm in 5.0 s and decelerate from 1500 rpm in 7.5 s, the values passed to the motion block are:

If the user engineering unit is mm/s for a linear axis, the same math holds, with mm/s and mm/s² in place of rpm and rpm/s.

Implementation: Structured Text Example

The following SCL snippet shows a typical pattern. It reads ramp time values from a global DB, converts them to the acceleration / deceleration form, and uses them on an MC_MoveVelocity call. The same pattern works for MC_MoveJog, MC_MoveRelative, and MC_Halt.

// Global DB "DB_MotionParams"
VAR
    TargetVelocity_rpm   : LREAL := 1500.0;   // desired speed
    RampUpTime_s         : LREAL := 5.0;      // ramp-up time
    RampDownTime_s       : LREAL := 7.5;      // ramp-down time
    UseDynamicOverride   : BOOL  := TRUE;     // TRUE = use DB values, FALSE = TO defaults
END_VAR

// Local computation in the motion FC
VAR
    dynAccel   : LREAL;
    dynDecel   : LREAL;
    dynJerk    : LREAL := 0.0;
END_VAR

IF UseDynamicOverride AND RampUpTime_s > 0.0 AND RampDownTime_s > 0.0 THEN
    dynAccel := TargetVelocity_rpm / RampUpTime_s;
    dynDecel := TargetVelocity_rpm / RampDownTime_s;
    dynJerk  := 0.0;
ELSE
    dynAccel := -1.0;   // use TO default
    dynDecel := -1.0;   // use TO default
    dynJerk  := -1.0;   // use TO default
END_IF;

// Issue the motion command
MC_MoveVelocity_1(
    Axis          := TO_SpeedAxis_1,
    Execute       := StartMove,
    Velocity      := TargetVelocity_rpm,    // rpm
    Acceleration  := dynAccel,               // rpm/s
    Deceleration  := dynDecel,               // rpm/s
    Jerk          := dynJerk,                // rpm/s^3
    Direction     := mcPOSITIVE_DIR,
    Busy          => , 
    CommandAborted=> , 
    Error         => , 
    ErrorID       => 
);

The MC_MoveJog block in TIA Portal V16 exposes the same Velocity, Acceleration, Deceleration, and Jerk inputs and supports the -1.0 = "use default" convention. This means the same DB-driven mechanism also covers manual jogging modes.

Where Ramp Generation Actually Happens

When the G120C is configured with Ramp-Function Generator inside the PLC (the path most users want when they ask for "dynamic ramps"), the G120C accepts the PLC's PROFIdrive setpoint directly without applying its own ramp limiter. The PLC's TO, using the Acceleration and Jerk inputs, computes the time-discrete speed trajectory and writes it to the drive each bus cycle (typically 1 ms or 4 ms depending on PROFINET configuration). In that case the drive's P1120 and P1121 ramp-time parameters are inactive.

Alternatively, when the drive's internal RFG is used (default for many commissioning wizards), the PLC writes a target velocity and the drive's P1120 (ramp-up) and P1121 (ramp-down) parameters control the slope. To change ramps dynamically in that mode you have three choices:

1. Use the SINAMICS parameter access via the function block WR_REC / RD_REC (non-cyclic parameter read/write over PROFINET) to write P1120 and P1121 at runtime. This is a low-frequency change (a few times per second maximum) and adds acyclic bus load.
2. Use the supplementary PROFIdrive setpoints in Telegram 7 or 9 (if configured) to override ramp parameters cyclically.
3. Switch the configuration to PLC-side ramp generation as described above. This is the recommended path for variable ramps.

Verification and Commissioning

Validate dynamic ramp behavior with the following checks before the line is released to production:

1. Watch table test: In TIA Portal, open the TO's online diagnostics and trigger MC_MoveVelocity from a watch table with three different combinations of Acceleration and Deceleration. Plot the actual speed trace via the trace function and confirm the slope matches the calculated value within ±5%.
2. HMI ramp parameter screen: Add an HMI faceplate that exposes RampUpTime_s, RampDownTime_s, and the calculated Acceleration/Deceleration values. Operators should never see the raw dynAccel value without the conversion factor displayed nearby.
3. Edge cases:
   • Target velocity = 0 — the axis should not move; Acceleration and Deceleration become irrelevant but must not generate a TO error.
   • Ramp time = 0 — division by zero. The application must clamp to a minimum ramp time (e.g., 0.05 s) before computing acceleration.
   • Reversal — the deceleration of the outgoing motion is reused as the acceleration of the incoming motion when both are passed on the same command. Test reversal at the configured maximum velocity.
4. Drive-side trace: Startdrive can record the drive's actual speed, the PROFIdrive setpoint, and the torque. Trigger a record during a controlled ramp to confirm the drive sees a smooth setpoint slope and does not enter a current-limit condition.

Troubleshooting Matrix

Best Practices for Field-Ready Dynamic Ramps

• Validate inputs at the HMI boundary. Reject negative or zero ramp times at the HMI; never trust a panel operator to enter 0.
• Use a single source of truth for the active ramp time. A dedicated DB (e.g., DB_MotionParams) referenced by all motion blocks prevents drift between axes.
• Decouple the application from the engineering unit. Pass ramp times in seconds; let the FC convert to unit/s² right before the motion call.
• Keep jerk at zero unless the mechanics require it. Trapezoidal profiles are easier to commission and cause fewer surprises at low speeds.
• Document the unit on every HMI tag. "Ramp-up (s)" displayed on the panel prevents operators from typing the value in unit/s² by mistake.
• Make the default value path explicit. Use -1.0 only where the motion block expects it. If the FC substitutes defaults, write a clear comment so the next maintainer does not "fix" the constant.

FAQ