MC_GearInPos Busy at Master Standstill: S7-1500T Sync Fix

MC_GearInPos Busy at Master Standstill on S7-1500T: Root Cause and Documented Workaround

1. Problem Description: BusyState That Never Clears

A synchronized motion application exhibits the following properties:

• Leading (master) axis: real SINAMICS S120 position axis referenced to a SINAMICS axis TO, configured as either a real or virtual master.
• Following (slave) axes: two real SINAMICS S120 position axes, each with its own TO position axis.
• Engagement mode: MC_GearInPos with explicit synchronous positions.
• Master motion state: stationary, v = 0, but position already coincides with MasterSyncPos.
• Lifecycle: first PLC RUN engages normally; subsequent PLC STOP -> RUN cycles hang.

Observed symptom. After a warm restart (RUN -> STOP -> RUN, with all retained axis positions and homing states preserved), the call to MC_GearInPos never leaves BusyState. Busy stays TRUE indefinitely, while Done, CommandAborted, and Error all stay FALSE. AxisTrace recordings in TIA Portal show:

• Master.SetPointPosition == MasterSyncPos (input value)
• Slave.SetPointPosition == SlaveSyncPos (input value)
• Velocity of master = 0
• Velocity of slave = 0
• MC_GearInPos.Busy = TRUE since the rising edge of Execute

The configuration parameters match the Siemens documentation defaults:

The behavior is deterministic in PLCSIM with all axes configured as virtual axes, and identical on a real S120 bench. It is independent of SyncDirection (testing values 0, 1, 2, and 3 all reproduce the hang with a stationary master at sync).

2. Root Cause: Master Already at the Synchronous Position

The MC_GearInPos instruction computes a transition trajectory that brings the slave from its current velocity and position to the synchronous velocity that the master is expected to have at MasterSyncPos. The instruction internally relies on a defined delta between the synchronous position and the master's actual position at the rising edge of Execute; it then reserves a sync window and begins converging the slave along the chosen direction.

If the leading axis is already exactly at the synchronous position before the job is started, the slave has nowhere to traverse, and the instruction has no defined direction of approach. The motion controller is not permitted to silently collapse the slave onto the master's exact instantaneous state because the resulting v and a on the slave would be undefined at t = 0. The implementation therefore keeps the instruction in BusyState and never reports Done or Error. This is by design, not a bug in the application code.

This is consistent with the documented behavior published in Synchronized Motion for S7-1500T Technology Object configuration V9 and with the Bosch Rexroth Synchronized Motion reference manual that describes the same precondition in functionally equivalent terms:

"If the leading axis is already in its synchronous position before synchronization, the following axis must also be moved to its synchronous position. In this case, establish the synchronization with an MC_GearIn job."

The Siemens application note 109758886 - Synchronizing axes with MC_GearInPos when the leading axis is already at the synchronous position codifies the same constraint for earlier technology versions (V5/V6).

3. Design Constraint: Use MC_GearIn When the Master Is Already Synchronous

The Siemens reference architecture for engagement at a stationary master is intentionally MC_GearIn, not MC_GearInPos. MC_GearIn sets a synchronous velocity proportional to the master velocity by ratio only and does not require the slave to reach any specific position before engagement. The slave is simply committed to the gear ratio the moment the master starts moving, with no precondition on whether the master coincides with a target position.

For applications that require the slave to arrive at a precise position relative to the master (the typical requirement behind choosing MC_GearInPos), two patterns work reliably:

1. Engage when the master is moving. Drive the master to a known position with a fixed velocity, call MC_GearInPos with the appropriate pre-calculated MasterSyncPos, and accept the standard settling transient.
2. Pre-position the slave manually at standstill, then engage by ratio. Issue an MC_MoveAbsolute to bring the slave onto the desired SlaveSyncPos, then call MC_GearIn to commit the ratio. The slave will track the master from the moment the master starts moving. If a phase-locked start is required, the slave can be offset by the program after MC_GearIn settles with MC_PhasingRelative or MC_PhasingAbsolute.

Pattern 2 is the one recommended by Siemens for standstill-start synchronization and is the only one that is independent of the master's motion state.

4. Prerequisites

Before applying the workaround, verify the following:

• CPU. S7-1515T, S7-1516T, S7-1517T, or S7-1518T with firmware V2.6 or higher. The technology functions require firmware V2.8+ for the full V5 feature set. The example uses 6ES7517-3TP00-0AB0 (S7-1517TF) at firmware V2.9.
• TIA Portal. V16 with S7-1500 Motion Control V6.0 update 1 (or higher), or V17/V18/V19/V20 with Technology Object configuration V9. The cited Siemens TIA V20 - MC_GearInPos start gearing with specified synchronous positions reference is the definitive English-language description of the V9 state machine.
• Technology objects. Master and each slave configured as Position axis with Drive = SINAMICS S120 via PROFINET IRT, or as Virtual axis for bench simulation. The commissioning engineer must confirm that the slave TO is configured with Synchronization monitoring set to Enable monitoring functions if overspeed protection is required.
• Homing. All axes must be homed (Axis.Homed == TRUE) before any gear job is issued. MC_GearIn will refuse if either side is un-homed.
• Drives. SINAMICS S120 with telegram 105 or 106 selected on every axis; p920 (DO list) must include the relevant DO. For S120 firmware V5.x (tested on V5.2 SP3 HF4) the standard PROFIdrive position control word is sufficient.
• PLC clock and OB1 cycle. Cyclic OB1 at 1 ms to 4 ms is recommended; MC_GearIn is deterministic down to 1 ms and does not impose additional load above MC_GearInPos.

5. Step-by-Step Workaround Implementation

The pattern below replaces the failing MC_GearInPos call with a robust standstill-synchronization sequence. Codesys-style and SCL examples are provided.

5.1 Decide engagement strategy up front

1. Detect whether the master is stationary. Use ABS(Master.ActVelocity) < 1e-3 (units of UserUnits/s) as the standstill predicate.
2. If the master is moving, branch to the MC_GearInPos path (the standard synchronized engagement).
3. If the master is stationary at (or very near) the configured MasterSyncPos, branch to the standstill path described below.

5.2 Pre-position the slave with MC_MoveAbsolute

Bring the slave to the required engagement position before any gear job is started. Position the slave first so Master.SetPointPosition == Slave.SetPointPosition when the gear job is issued.

5.3 Issue MC_GearIn to bind the ratio

MC_GearIn binds the slave's velocity to (RatioNumerator / RatioDenominator) * Master.ActVelocity. With the master at zero velocity, the slave is committed to the gear relationship without traversing any distance. When the master starts moving, the slave follows at the gear ratio immediately.

5.4 Optional: phase correction with MC_PhasingAbsolute

If the application requires the slave to lead or lag the master by a fixed phase angle, issue MC_PhasingAbsolute after MC_GearIn completes. Phase correction can run while the master is stationary; the slave will hold position via its internal position controller.

5.5 SCL sample implementation

// FB: "fbGearEngageAtStandstill" (SCL, S7-1500T, TIA V16/V20)
// Inputs:
//   MasterSyncPos : LREAL -- target master position at engagement
//   SlaveSyncPos  : LREAL -- target slave position at engagement (equal to MasterSyncPos for 1:1)
//   GearNum       : DINT   -- RatioNumerator
//   GearDen       : DINT   -- RatioDenominator
// State machine: IDLE -> PRE_POS -> GEAR -> PHASE -> DONE

FUNCTION_BLOCK fbGearEngageAtStandstill
VAR
    bExecute       : BOOL;                 // rising edge starts the sequence
    bAbort         : BOOL;
    bDone          : BOOL;
    bError         : BOOL;
    iErrId         : WORD;

    // internal state
    eState         : DINT := 0;            // 0=IDLE,1=PRE_POS,2=GEAR,3=PHASE,4=DONE

    // MC blocks
    fbMoveAbs      : MC_MoveAbsolute;
    fbGearIn       : MC_GearIn;
    fbPhaseAbs     : MC_PhasingAbsolute;

    fDist          : LREAL;                // distance to pre-position slave
    rTol           : LREAL := 1.0E-3;      // position tolerance (UserUnits)
    fMasterStandVel: LREAL := 1.0E-3;      // |velocity| considered as standstill
    bRisingEdge    : BOOL;
    bOldExecute    : BOOL;
END_VAR

METHOD fbExecute : BOOL
    // rising-edge capture
    bRisingEdge := bExecute AND NOT bOldExecute;
    bOldExecute := bExecute;

    IF bAbort THEN
        fbMoveAbs.Abort    := TRUE;
        fbGearIn.Abort     := TRUE;
        fbPhaseAbs.Abort   := TRUE;
        eState := 0;
        bDone  := FALSE;
        bError := FALSE;
        iErrId := 0;
        RETURN;
    END_IF;

    CASE eState OF

    //-- IDLE: wait for rising edge on bExecute ------------------------------
    0:
        bDone := FALSE;
        bError := FALSE;
        IF bRisingEdge THEN
            // Compute slave pre-position delta
            fDist := SlaveSyncPos - AxisSlave.ActPos;
            IF ABS(fDist) <= rTol THEN
                // already in position -> skip move
                eState := 2;
            ELSIF ABS(AxisMaster.ActVelocity) > fMasterStandVel THEN
                // master is moving -> caller should use MC_GearInPos instead
                iErrId := 16#8001; // local error: master moving
                bError := TRUE;
                eState := 0;
            ELSE
                // dispatch MC_MoveAbsolute
                fbMoveAbs.Position    := SlaveSyncPos;
                fbMoveAbs.Velocity     := AxisSlave.Config.VelocityLimit * 0.5;
                fbMoveAbs.Acceleration := AxisSlave.Config.AccelerationLimit * 0.5;
                fbMoveAbs.Deceleration := AxisSlave.Config.DecelerationLimit * 0.5;
                fbMoveAbs.Jerk         := AxisSlave.Config.JerkLimit * 0.5;
                fbMoveAbs.Direction    := mcPOSITIVE_DIR;
                fbMoveAbs.Execute      := TRUE;
                eState := 1;
            END_IF;
        END_IF;

    //-- PRE_POS: move slave to sync position --------------------------------
    1:
        fbMoveAbs();
        IF fbMoveAbs.Done THEN
            fbMoveAbs.Execute := FALSE;
            eState := 2;
        ELSIF fbMoveAbs.Error THEN
            iErrId := fbMoveAbs.ErrorID;
            bError := TRUE;
            eState := 0;
        END_IF;

    //-- GEAR: bind slave to master by ratio ---------------------------------
    2:
        fbGearIn.Master            := AxisMaster;
        fbGearIn.Slave             := AxisSlave;
        fbGearIn.RatioNumerator    := GearNum;
        fbGearIn.RatioDenominator  := GearDen;
        fbGearIn.Acceleration      := AxisSlave.Config.AccelerationLimit;
        fbGearIn.Deceleration      := AxisSlave.Config.DecelerationLimit;
        fbGearIn.Jerk              := AxisSlave.Config.JerkLimit;
        fbGearIn.Execute           := TRUE;
        eState := 3;

    //-- PHASE: optional phase correction ------------------------------------
    3:
        fbGearIn();
        IF fbGearIn.Done THEN
            fbGearIn.Execute := FALSE;
            // If no phase change required, go directly to DONE
            fbPhaseAbs.Execute   := FALSE; // unused in this branch
            eState := 4;
        ELSIF fbGearIn.Error THEN
            iErrId := fbGearIn.ErrorID;
            bError := TRUE;
            eState := 0;
        END_IF;

    //-- DONE -----------------------------------------------------------------
    4:
        bDone := TRUE;
        IF NOT bExecute THEN
            eState := 0;
        END_IF;
    END_CASE;
END_METHOD
END_FUNCTION_BLOCK

5.6 Re-engagement after a PLC STOP -> RUN

Because MC_GearIn never enters a BusyState when the master is stationary, the issue resolves itself: the slave is already pre-positioned, the new MC_GearIn call engages the ratio in a single scan, Done rises within the same OB1 cycle. Add the following guards in fbGearEngageAtStandstill to be re-entrant:

• Detect the warm restart via a retained bOldEngaged flag in the instance DB (set to TRUE when gear is committed).
• On the first OB1 cycle after warm restart, if bOldEngaged is TRUE, skip MC_MoveAbsolute and go straight to MC_GearIn.
• Reset bOldEngaged to FALSE whenever the operator commands a full disengage.

6. MC_GearIn Parameter Reference

7. Verification

Verification should be executed on the live hardware bench as well as in PLCSIM. The procedure below applies to both:

1. Static state check. In TIA Portal open the AxisTrace on Master.SetPointVelocity, Slave.SetPointVelocity, MC_GearIn.Busy, and MC_GearIn.Done. Trigger on a rising edge of Execute. Confirm:
   • Master.SetPointVelocity = 0 throughout
   • Slave.SetPointVelocity = 0 throughout
   • Busy -> Done within one OB1 cycle
2. Master-motion response. Issue MC_MoveVelocity on the master at 100 RPM (UserUnits/s equivalent). Trace the slave velocity. Confirm Slave.SetPointVelocity = Ratio * Master.SetPointVelocity within the slave Acceleration limit.
3. Round-trip positioning. Issue MC_MoveAbsolute on the master to MasterSyncPos + 720 deg (one mechanical revolution) and observe the slave. Confirm the slave traverses the same 720 deg following the same mod-720 wrap behavior.
4. STOP/RUN re-engagement. Trigger a STOP -> RUN transition (or simulate with MC_Reset -> warm restart on the simulation). Confirm the sequence re-engages without intervention.
5. Continuous sync monitoring. Enable the TO-level Synchronous operation monitoring for both slaves. Threshold defaults are Position = 1 deg, Velocity = 50 RPM, Acceleration = 50 rad/s^2. Tighten as needed.

8. State Machine Reference (LAD/FBD view)

The successful path through the workaround is captured in the following transition logic. Use it as a guide to implement the same flow in ladder logic if SCL is not preferred.

9. Edge Cases and Multi-Slave Configurations

9.1 Two slaves, one master

The described case is the dual-slave variant. Both slaves are gated by the same MasterSyncPos and have the same SlaveSyncPos as the master for 1:1 coupling. With the workaround, instantiate fbGearEngageAtStandstill twice (once per slave). The master remains a single proxy; the function block must be re-entrant so both instances dispatch their own MC_MoveAbsolute and MC_GearIn in the same OB1.

9.2 Virtual master with no real axis

A virtual master is configured as a TO position axis with virtual = TRUE. The same BusyState hang is observed. The pre-position still works because the slave's TO is real, but confirm the virtual master has its Simulation property enabled in the TO configuration under Hardware.

9.3 Combined MC_CamIn engagement at standstill

Siemens FAQ 109758886 also covers camming engagement at a standstill. The general guideline is the same: if the master is at the synchronous position before cam engagement, pre-position the slave with MC_MoveAbsolute and engage with MC_CamIn while the master is stationary. The MC_CamIn instruction has the same slave must reach SlaveSyncPos precondition as MC_GearInPos.

9.4 Switching to MC_GearInPos after initial movement

If phase-accurate engagement is required and the master is initially stationary, the canonical Siemens sequence is:

1. MC_MoveVelocity on the master at a constant, deterministic velocity.
2. When the master crosses a defined enable position (e.g., 90 deg before the target sync point), call MC_GearInPos with the appropriate pre-distance.
3. Wait for Done; both axes are synchronized at the configured positions.

This pattern is demonstrated in the V9 documentation linked above.

9.5 Cross-vendor reference: Beckhoff and AutomationDirect

The same precondition exists outside the Siemens ecosystem. The Beckhoff TF5055 TwinCAT 3 NC Flying Saw MC_GearInPos documentation describes an equivalent behavior for the flying-saw semantic, including the requirement that the leading axis be moving at the time of engagement for the slave to compute a unique approach. AutomationDirect's ProductivityOpen and XMC user manual defines MC_GearInPos with SyncProfile and SyncDirection inputs in the same Siemens-aligned semantic. The Bosch Rexroth Synchronized Motion manual likewise specifies that the leading axis must traverse into the engagement window so that the slave can compute a unique direction.

Cross-vendor consistency confirms the BusyState hang is a documented precondition rather than a Siemens-only defect.

10. Glossary and Symbols

• UserUnits. Engineering unit defined on the TO; can be degrees, mm, or any integer / floating-point scaling.
• Master / Slave. Leading / following axis nomenclature per PLCopen Motion Control Part 1.
• Sync window. The interval around MasterSyncPos inside which the master must arrive for MC_GearInPos to begin closing the sync loop.
• Virtual axis. A TO without hardware drive; moves generated as commands only.
• Leading axis proxy. A TO configured as Leading axis via Lead value source; cannot be moved by MC_Move* directly, only by external MC_GearIn or MC_CamIn slave.

11. Summary

The MC_GearInPos instruction's BusyState at master standstill on S7-1500T is the documented consequence of a precondition: the leading axis must move into the synchronous position from a defined offset so the slave can compute a unique approach direction. Once the master is already at MasterSyncPos at the rising edge of Execute, the instruction cannot decide a direction and remains in BusyState indefinitely. The Siemens-recommended remedy is to pre-position the slave with MC_MoveAbsolute and engage with MC_GearIn when the master is stationary, or alternatively to ensure the master is moving at the moment MC_GearInPos is called. The pattern is portable, verifiable, and supported across Technology Object configurations V5, V6, and V9.

12. Frequently Asked Questions