MC_MoveVelocity Smallest Speed Step in S7-1500 Motion Control

The MC_MoveVelocity function block drives a single axis to a continuous velocity setpoint. Re-triggering the block with a new velocity overwrites the live setpoint at the rising edge of Execute. The smallest speed increment the controller can physically realise is not an explicit MC_MoveVelocity parameter — it is a derived quantity set by the underlying pulse train, the position control cycle, and the encoder or load gearing. This reference quantifies that limit for S7-1500 / S7-1500T motion control, compares it with related PLC platforms, and gives a field procedure for verification.

1. Function Block Architecture

MC_MoveVelocity is defined in the PLCopen motion control specification and is implemented by every major controller vendor with the same I/O surface. The block transitions the axis to ContinuousMotion and accepts a new target while running.

Per the Siemens S7-1500 Motion Control V8 documentation for S7-1500 / S7-1500T, "An MC_MoveVelocity job with Velocity = 0.0 stops the axis with the configured deceleration. When the velocity setpoint / speed setpoint zero is reached, the axis transitions to Standstill." The setpoint is overwritten on the rising edge of Execute — there is no in-cycle blending between consecutive setpoints; the controller ramps from the actual velocity to the new target under the active acceleration limit. Source: Siemens TIA Portal V20 — MC_MoveVelocity V8 (S7-1500, S7-1500T).

2. Where the Resolution Limit Comes From

Three independent boundaries determine the minimum speed step the drive will actually follow:

1. Pulse-train quantisation — pulse-train output (PTO) hardware can only change output frequency in integer pulse counts per cycle.
2. Position control cycle (IPO / servo cycle) — the setpoint is updated once per cycle, so a velocity change that does not produce at least one pulse per cycle has no physical effect on the output stage.
3. Mechanical resolution — at very low speeds, stiction and the encoder's own quantisation can hide velocity steps that are otherwise electrically real.

For an S7-1500 PTO axis the dominant constraint is (2): the velocity command must be large enough to emit at least one full pulse per IPO cycle. This is the exact phenomenon the source thread calls out when it states "if your cycle time is 10 ms you must have at least 100 pulses/sec velocity changing (at least 1 pulse per cycle)."

3. Pulse-to-Velocity Conversion

For a PTO or pulse-direction output, velocity in user units is:

v_user = (f_pulse / ppr) × gear

where:

• f_pulse = output pulse frequency (pulses/s)
• ppr = pulses per motor revolution (configured in the technology object)
• gear = mechanical ratio (load units per motor revolution)

Inverting gives the pulse frequency needed for a target velocity, and the smallest increment is simply:

Δf_pulse_min = 1 / T_IPO

which is one full pulse per position-control cycle. Anything below this is sub-LSB and is dropped by the pulse generator.

4. Worked Numerical Examples

Assume the 2000 pulses-per-revolution motor and 10 ms IPO cycle discussed in the source thread.

The 100 pulses/s figure (1 pulse per 10 ms cycle) matches the engineering rule from the field report. The 20 pulses/s "just audible" observation in the source thread is below the quantisation limit at 10 ms IPO; what was heard was the controller's ramp saturating at the next available pulse boundary, not a 20 pulses/s delta.

5. S7-1500 vs. S7-200 PTOx_MAN Comparison

The source thread references the S7-200 PTOx_MAN block, which carried an explicit relative-change limit on the SPEED input variable. The S7-200 PTO is a slower, microcontroller-class pulse generator with a documented minimum increment (typically a few Hz) before the hardware cannot generate a valid frequency change. Modern S7-1500 motion control does not expose a discrete "minimum speed step" tag; the equivalent is the implicit 1 / T_IPO bound plus the dynamic limits of the drive amplifier's torque loop.

6. S7-1500T Considerations

On S7-1500T controllers, MC_MoveVelocity also supports the optional Jerk input. S-curve profiling has no effect on resolution; it only changes the path between two resolvable setpoints. The smallest step that the axis will follow remains bounded by IPO quantisation. For a 1 ms servo cycle, the bound is 1000 pulses/s, or 30 RPM on a 2000 ppr motor — but the tighter 250 µs cycle available on S7-1500T brings that down to 250 pulses/s, or 7.5 RPM, an effective 4× improvement in speed-setpoint resolution.

7. Cross-Vendor Behaviour

MC_MoveVelocity is PLCopen-standard, but each vendor's re-trigger semantics and resolution behaviour differ slightly.

Sources: Schneider Electric — MC_MoveVelocity; Beckhoff Information System — MC_MoveVelocity (TC2_MC2); AutomationDirect — Using MC_MoveVelocity (XMC).

8. Designing a Trajectory Generator

When building a custom trajectory on top of MC_MoveVelocity, follow this design pattern:

1. Compute the desired velocity in user units (mm/s, °/s) at the trajectory's update period T_traj.
2. Convert to pulse frequency using the load-gear / ppr ratio defined in the technology object.
3. Quantise to the integer pulse grid: f_q = round(f_pulse × T_IPO) / T_IPO. This step is automatic inside the S7-1500 motion control firmware but must be modelled in any PC-side preview path.
4. Only re-trigger MC_MoveVelocity when |f_q_new − f_q_last| ≥ 1 / T_IPO. Re-triggering on a smaller delta is a no-op at the pulse generator and wastes CPU on the PLCopen state machine.
5. Clamp the step with the axis' configured Acceleration so a single setpoint jump does not command an unachievable Δv/Δt.

Structured Text skeleton for a velocity-setpoint smoother:

// Trajectory cycle, e.g. 10 ms
IF cycle_tick THEN
    v_target_user := trajectory(t);                       // user units / s
    f_pulse       := v_target_user * ppr / gear;          // Hz
    f_quantised   := REAL_TO_LREAL(REAL_TO_DINT(f_pulse * T_IPO)) / T_IPO;

    IF ABS(f_quantised - f_last) >= (1.0 / T_IPO) THEN
        MC_MoveVelocity_0(Execute := FALSE);             // reset edge
        MC_MoveVelocity_0(Velocity := f_quantised / ppr * gear);
        MC_MoveVelocity_0(Execute := TRUE);              // rising edge overwrites
        f_last := f_quantised;
    END_IF;
END_IF;

9. Verification Procedure

Use this bench procedure to determine the effective resolution on your specific axis.

1. Wire the <Axis>.StatusVelocity tag (S7-1500) or equivalent to an HMI trend. This tag returns the actual filtered velocity, not the command, and is the right signal for resolution checks.
2. Configure the axis with the same ppr and IPO cycle you will use in production.
3. From a standstill, command a series of velocities in 1 / T_IPO Hz increments and record StatusVelocity for each.
4. Identify the smallest Δcommand that produces a measurable change in StatusVelocity. This is your effective resolution.
5. Repeat at higher base velocities (e.g. 10 %, 50 %, 90 % of max) — many drives show degraded Δv resolution at high speed because of speed-loop gain scheduling.
6. Cross-check with a trace on the drive's actual speed feedback (e.g. via PROFIdrive telegram, parameter r0061 on SINAMICS) to confirm the controller is not silently dropping sub-LSB steps.

10. Diagnostic Tags

InVelocity uses the axis' PositionTolerance and VelocityTolerance settings. For ultra-fine setpoint work, lower the velocity tolerance but expect longer settle times.

11. Troubleshooting Matrix

12. Safety and Process Limits

For PROFIsafe / PROFIdrive Safety Integrated applications, set the SLS limit at least 2× the smallest resolvable step observed in section 9, and verify under worst-case load.

13. Summary

The "smallest speed difference MC_MoveVelocity can handle" is not a fixed property of the FB. It is:

Δv_min = (1 / T_IPO) × (gear / ppr)

For a 2000 ppr motor on a 4 ms S7-1500 axis with a 1:1 gear, that is 7.5 RPM. Use <Axis>.StatusVelocity to confirm the bound empirically, and design the trajectory layer to emit only quantised setpoints. On S7-1500T, dropping the servo cycle to 250 µs gives 4× finer resolution at the cost of CPU.