Changing Simotion C240 Gear Ratio On-the-Fly Without Abort Alarms

Changing Simotion C240 Gear Ratio On-the-Fly Without Abort Alarms

Continuous-process machines (printing presses, film lines, slitters, winders, paper machines, and similar web/conveyor systems) require the gearing ratio between a master axis and a slave axis to be changed while the slave is already coupled and running. On the SIMOTION C240 PN controller, re-triggering the basic Gear on command with a new ratio while a gearing relationship is already active raises a gear aborted technology alarm and the slave axis is decelerated to a stop by the default error reaction. The system has to either run a new synchronization (phasing) sequence or stay in a permanent couple through an indirection layer that hides the ratio change behind a master-setpoint switch.

This reference documents the field-proven pattern that solves the problem: a virtual master axis layer plus the _setMaster (or MCC Change master setpoint) command, optionally combined with _setGearOffset to absorb any residual position error. ST and MCC examples are shown, parameters and alarm codes are mapped, and the commissioning checks that prove a clean on-the-fly ratio swap are listed step-by-step.

1. Why Re-Triggering "Gear on" Fails

When the slave axis enters synchronous operation through the technology object command Gear on (MCC) or _gearingOn(...) (system function), the controller goes through the synchronous-operation state machine: STOPPING -> SYNCHRONIZING -> SYNCHRONOUS. The state transition from SYNCHRONOUS back into SYNCHRONIZING is only legal through a clean disengage (Gearing off / _gearingOff) or through the gearing-blending command. Calling Gear on a second time without an explicit disengage is rejected by the technology object with one of the following alarms:

Re-triggering therefore is not a valid method for live ratio updates. The next section shows the indirection architecture that the SIMOTION firmware does support natively.

2. Architecture: Virtual Master Axis Layer

The ratio is decoupled from the slave by inserting one or more virtual axes (technology object type TO_VirtualAxis) between the real master and the real slave. The real master follows virtual axis A with a fixed ratio; virtual axis A in turn follows virtual axis B; the real slave follows whichever virtual axis is currently selected as its master. By changing the selected master (with no slave stop, no resync) the effective ratio is swapped.

Both virtual axes run continuously (typically with the same velocity setpoint, setpointVelocity = masterVelocity). The slave can be "ganged" to either one of them at any time, and a switch between them is reported by the controller as a master change, not as a gear abort. With the slave following the virtual axis 1:1, all actual gear ratio change happens inside the virtual layer (real master → virtual axis ratio), which can be retuned live through _setMasterVelocity or by swapping its source between two real masters.

3. Function Blocks and MCC Commands

4. Configuration in SCOUT TIA

4.1 Axis topology

1. Create the real master TO (TO_ExternalEncoder or TO_SpeedAxis, depending on whether the master is a measured encoder or a drive-setpoint axis).
2. Create two virtual axes, e.g. VirtAxis_RatioA and VirtAxis_RatioB (type TO_VirtualAxis). Both default length unit = 1 LU, default modulo = 360000000 LU.
3. Create the real slave TO (e.g. Axis_Winder, type TO_SpeedAxis or TO_PositioningAxis).
4. Configure a following axis interconnection (Axis → Following axis) for each virtual axis, with the real master as leading and the virtual as following. Ratio 1.0; synchronous operation enabled; same cycle clock (e.g. 1 ms IPO, 1 ms position-control cycle).

4.2 Synchronous-operation parameters on the slave TO

5. MCC Implementation

The MCC chart runs once at process start to engage the gearing, and exposes two Boolean inputs bUseRatioA and bUseRatioB plus one floating-point fRatio for the active ratio that the virtual master applies.

1. Init: enable real master, then enable VirtAxis_RatioA and VirtAxis_RatioB; set both virtual axes to follow the real master (configure in SCOUT, do not command in MCC).
2. Engage slave: Gearing on command on Axis_Winder with master = VirtAxis_RatioA.
3. Live ratio change: on rising edge of bUseRatioA issue Change master setpoint with new master = VirtAxis_RatioA; on rising edge of bUseRatioB issue the same with VirtAxis_RatioB. Set the command parameter Smoothness = 1 (smooth cross-fade over 250 ms typical) to avoid a velocity step in the slave.
4. Compensate residual offset: after the master-change commandId returns DONE, call Set master offset (or _setGearOffset in a coupled ST block) with the actual position difference between the previously followed and the newly followed virtual axis. Apply scope = "current and future".

6. Structured Text Implementation

The same logic expressed as an ST function block. Place it in the unit assigned to the IPO task (typically 1 ms) so the master change is serviced in the same cycle as the trigger.

FUNCTION_BLOCK RatioSwapAxis
VAR_INPUT
    bUseRatioA  : BOOL;          // TRUE = follow VirtAxis_RatioA
    bUseRatioB  : BOOL;          // TRUE = follow VirtAxis_RatioB
END_VAR
VAR
    sAxis       : AXIS_REF;      // slave TO reference (Axis_Winder)
    sVirtA      : AXIS_REF;      // VirtAxis_RatioA
    sVirtB      : AXIS_REF;      // VirtAxis_RatioB
    rt          : R_TRIG;
    rtB         : R_TRIG;
    cmdRet      : COMMAND_RET_VAL; // system return type
    offsetLU    : LREAL;
END_VAR

// Detect a falling edge of the previous selection: this is the
// change-of-master event
rt(CLK := bUseRatioA);
rtB(CLK := bUseRatioB);

IF rt.Q AND sAxis.State = AXIS_STATE_SYNCHRONOUS THEN
    // Bind slave to virtual axis A in the same cycle as the trigger
    _setMaster(slave := sAxis, master := sVirtA,
               commandId := GET_COMMAND_ID(),
               mergeMode := MERGE_MODE_IMMEDIATELY,
               nextCommand := CMD_NO_NEXT);
END_IF;

IF rtB.Q AND sAxis.State = AXIS_STATE_SYNCHRONOUS THEN
    _setMaster(slave := sAxis, master := sVirtB,
               commandId := GET_COMMAND_ID(),
               mergeMode := MERGE_MODE_IMMEDIATELY,
               nextCommand := CMD_NO_NEXT);
END_IF;

// After a successful master change, absorb the residual position gap
// by issuing a master-side offset. Read it from the previously
// followed virtual axis position minus the new one.
IF cmdRet.commandIdState = COMMAND_ID_STATE_DONE THEN
    offsetLU := _getAxisActualPosition(sVirtA) -
                _getAxisActualPosition(sVirtB);
    _setGearOffset(master := sAxis,
                   offset := offsetLU,
                   offsetMode := GEAR_OFFSET_MODE_CURRENT_AND_FUTURE);
END_IF;
END_FUNCTION_BLOCK

7. Verification and Acceptance Test

1. Open the Trace tool in SCOUT, record the following signals on the slave TO for at least 3 s after the master change trigger: ActualPosition, SetpointPosition, VelocitySetpoint, FollowingError, OperatingState, and the new ActualMasterValue.
2. Confirm that OperatingState stays at SYNCHRONOUS throughout the change (no transient SYNCHRONIZING, no STOPPING).
3. Confirm FollowingError returns to within the configured tolerance (0.05 LU) within the configured synchronizing time.
4. Confirm the alarm buffer is clean: no 20102, 201802, 20005 entries in the diagnostic buffer for the slave TO.
5. Command a ratio change in both directions (A→B and B→A) and verify slave velocity changes by the expected factor with no axis stop.
6. Force a forced _gearingOff from the user program; verify clean re-engage with the currently selected virtual master.

8. Edge Cases and Field-Proven Caveats

• Modulo mismatch. If the two virtual axes have different modulo lengths, the slave's absolute position will jump by a multiple of the modulo at the switch. For winders, set the virtual axes to the same modulo as the slave (or to 0 = non-modulo) and use the gear-offset to absorb any phase error in linear units.
• IPO clock mismatch. When the slave TO is in a different IPO clock than the master, the master change is delayed by one IPO tick. This is normal and is visible in the trace as a one-cycle delay on the velocity step.
• Drive-side stop reactions. Even when the controller-side state stays SYNCHRONOUS, a SINAMICS drive that sees a velocity step larger than its p958 setpoint-off threshold may drop into follow-up mode. Verify the p958 / p959 SINAMICS parameters before commissioning.
• Position-controlled slave. For TO_PositioningAxis slaves, the controller limits the velocity step at the master change to the value of Max acceleration (MCC dynamic limit). A jump from ratio 1.0 to 0.25 with a master running at 1500 rpm is fine; a jump from 0.05 to 1.0 is not, and the slave will take several hundred milliseconds to reach the new speed.
• PROFIdrive telegram mismatch. The slave must have a SIEMENS telegram 1, 2, 3, 5, or 6 with the encoder word (Gn_XIST1/Gn_XIST2) enabled. Without that, the controller cannot read the actual position after the master change and the gearing will be aborted.
• Use of _setMaster versus MCC. _setMaster takes effect in the same IPO cycle; the MCC Change master setpoint takes effect in the next IPO cycle because it goes through the command interpreter queue. For high-speed changes (sub-2 ms) prefer the ST system function.

9. Alarms and Diagnostics

10. Reference Documentation

When commissioning, keep these Siemens documents open alongside this procedure:

• SIMOTION C240 PN Operating Instructions (09/2018) — hardware, address assignment, ET/MT topology.
• SIMOTION Motion Control — Basic Functions Function Manual (12/2018) — technology objects, synchronous operation, following axes, gearing command set.
• SIMOTION Motion Control — System Functions and System Variables List Manual — signatures of _setMaster, _setGearOffset, _setMasterVelocity.
• SIMOTION SCOUT TIA Online Help (V5.2 SP1) — MCC chart editor, Change master setpoint command, Command Interpreter.
• SIMOTION Programming and Operating Manual (ST / MCC) — command-id handling, return values, mergeMode options.
• SINAMICS S120/S150 List Manual — alarm F08501, parameter p958/p959

FAQ