Resolving MC_GearIn and MC_GearOut Block Exit in TIA Portal Motion Control

1. Problem: The Gear Block Never Returns Control to the Program

A common motion-control fault is an MC_GearIn or MC_GearOut block that "hangs" inside an MCC (Motion Control Chart) sequence or a cyclic SCL/LAD/FBD call. The visualization in TIA Portal shows the gear step highlighted in yellow indefinitely, the program flow stops advancing, and the operator HMI freezes on the wait condition. Engineers commonly interpret this as a bug in the FB, when in almost every case it is the expected behaviour of the block waiting for a state-machine transition that has not yet occurred.

The two conditions that produce the hang are:

• The slave axis has not reached the Synchronized state (for MC_GearIn) or the gearing relationship has not been cleared (for MC_GearOut).
• The Delay program execution option of the calling step is set to Wait for completion of the command and the command will not complete until the I/O referenced in the wait condition goes TRUE.

2. PLCopen State Machine and the Synchronized Condition

All SIMATIC motion blocks are built on the PLCopen Motion Control Part 1 state diagram. An axis is always in exactly one of seven states, and every MC_xxx command defines which state transitions it will perform.

When MC_GearIn is called and the slave axis transitions to Synchronized Motion (state 5), the block raises Done = TRUE, drops Busy, and the program flow leaves the block. If the transition never happens — because the slave is held in Standstill by a pending MC_Stop, or because the master axis is not actually moving at the velocity that the gearing algorithm needs to detect — the block sits at Busy = TRUE forever.

3. MC_GearIn Interface and Exit Behaviour

MC_GearIn establishes a synchronous relationship between a virtual or real master axis and a slave axis. The relevant interface bits for diagnosing the exit condition are:

Internally the block proceeds through three sub-phases:

1. Handshake (≈ 1 cycle): Busy rises, Done and Error are FALSE.
2. Ramp to synchronous velocity (10 ms - several seconds, user-defined): Slave is commanded to the master's velocity × ratio. The ramp duration is governed by Acceleration / Deceleration.
3. Locked phase: Phase and velocity match master within tolerance window. Done is set TRUE for one PLC cycle, then Busy drops.

If the master axis never produces a measurable velocity (it is in Standstill, in Homing, or the encoder is faulted), the slave cannot lock and the block remains in phase 2 indefinitely. This is the most common cause of the "yellow highlighted gear step" symptom.

4. MC_GearOut Interface and Exit Behaviour

MC_GearOut terminates the gearing relationship. The slave transitions from Synchronized Motion back to Continuous Motion (if the master is still moving) or to Standstill (if the slave has been commanded to zero velocity). The block sets Done = TRUE for one cycle at the moment the gearing link is removed.

A not-allowed call to MC_GearOut returns Done = FALSE and Error = TRUE with ErrorID = 0x8001 (axis is not in Synchronized Motion). Verify the slave's StatusWord bits 0-3 read 5 (0101b) before calling.

5. The "Delay Program Execution" Parameter

In the MCC editor each command step has a properties dialog. The Delay program execution drop-down controls what the MCC compiler inserts between this step and the next step:

When the user reports "the program leaves from this block", the answer is deterministic: it leaves when the WAITFOR condition becomes TRUE. For MC_GearIn, that condition is Done = TRUE OR Error = TRUE. Therefore the program cannot leave the gear step until the slave has either locked onto the master or returned an error code. Engineers who need the program to leave earlier must switch to Do not wait and monitor the axis state through the technology object's StatusWord in their own code.

6. Reading the Yellow Step in MCC Charts

The yellow highlight in the MCC editor marks the currently active step — the one whose condition is open. It is not a fault indicator. The colour simply tells you which step is consuming CPU time. A gear step that stays yellow for several seconds during a 200 mm/s ramp is normal; a gear step that stays yellow indefinitely indicates that the wait condition has not been satisfied.

Right-click the yellow step and select Open Instance DB to see the live values of Busy, Done, Error, and ErrorID. The same values are also available in the technology object's Diagnostics folder under Status and error bits.

7. Decoding the I/O Wait (i0.2 / i0.4)

The original report shows the yellow step as Wait with condition i4_HomeMac, and a second symbol i2_HomeCutter appears yellow in the watch table. The explanation is:

• I0.4 is the physical input mapped to the symbol i4_HomeMac. The MCC WAIT step polls this input every cycle.
• I0.2 is the physical input mapped to the symbol i2_HomeCutter. It is yellow in the watch table because the watch table is monitoring it, not because any step is waiting on it.

To find where a symbol is used, use the cross-reference tool (References > Cross-references in the project tree) or right-click the symbol and choose Go to > Usage. If the compiler accepts a deliberate typo of the symbol name and reports no error, the symbol has zero usages and the wait is hung on an input that is never being checked by code other than the WAIT step itself.

Standard SIMATIC I/O Addressing

8. Watch Table Diagnostics Procedure

Use a TIA Portal watch table to confirm the live state of every signal involved in the gear sequence.

1. Open Project tree > PLC_1 > Watch and force tables > Add new watch table.
2. Add the following tags (substitute your project names):

   
   "Axis_Master".StatusWord
   "Axis_Slave".StatusWord
   "Axis_Slave".MotionStatus.Synchronized
   "Instance_DB_GearIn".Busy
   "Instance_DB_GearIn".Done
   "Instance_DB_GearIn".Error
   "Instance_DB_GearIn".ErrorID
   "Instance_DB_GearOut".Busy
   "Instance_DB_GearOut".Done
   "Instance_DB_GearOut".Error
   "i4_HomeMac"      // physical input I0.4
   "i2_HomeCutter"   // physical input I0.2
   

3. Click Monitor all (the spectacles icon) to display live values.
4. Trigger the gear-on sequence. Observe:
   • Master StatusWord should reach 4 (Continuous Motion) or 5 (Synchronized).
   • Slave StatusWord should reach 5 (Synchronized) when Done goes TRUE.
   • i4_HomeMac should follow the physical input. If it stays FALSE, the wait will never be released.
5. If the slave StatusWord never reaches 5, MC_GearIn has not been issued, or the master is not moving. Cross-check with the cross-reference tool.

9. Common Root Causes and ErrorID Matrix

The above codes match the SIMATIC S7-1500 Motion Control error list published in the S7-1500 Motion Control Function Manual. Always cross-check with the documentation shipped with your firmware version, because some codes are added or renamed between TIA Portal releases.

10. Step-by-Step Resolution Procedure

Use this procedure when a gear step remains yellow beyond the expected ramp time.

1. Confirm the wait semantics. Open the MCC step, read the Delay program execution drop-down, and note whether the program will wait for Done or merely for Busy.
2. Read the slave StatusWord. If the value is 1 (Standstill), MC_GearIn has not been accepted — typically ErrorID = 0x8021 or 0x8001. If the value is 4 (Continuous Motion) but stays there, the ramp is failing to complete.
3. Read the master StatusWord. A master stuck at 1 (Standstill) cannot produce the velocity a slave needs to lock. Drive the master with MC_MoveVelocity first.
4. Verify the physical input the WAIT step is monitoring. Force the input in the watch table only if the machine is in a safe state. If the symbol is never used elsewhere, the WAIT is locked on a condition that the program never updates.
5. Check the cross-references of the wait symbol. If only the WAIT step references the symbol, add a status bit to the technology object that the program will set when the prerequisite is satisfied.
6. Reduce the ramp duration. Increase Acceleration / Deceleration on the MC_GearIn instance so the slave locks within the operator-acceptable cycle time. Typical starting values: 100 mm/s² or 10 rad/s² scaled to your unit system.
7. Change the Delay option to "Do not wait". If the program flow is more important than the synchronization guarantee, restructure the MCC so the gear command is issued and the program continues; verify synchronicity by polling StatusWord = 5 in the next step.
8. Recompile and re-download. After any change to the MC block parameters, perform a full download to the CPU and reset all axes with MC_Reset before the next test run.

11. Verification: Confirming the Block Exits

After applying the fix, verify with the following four checks:

1. Visual: The yellow step turns green for one cycle as Done = TRUE, then advances to the next step in the MCC.
2. Status word: In the watch table, the slave StatusWord reads 5 (0x0005 — bits 0 and 2 set) for at least one PLC cycle after Done = TRUE.
3. Velocity match: The slave's actual velocity is within 1 % of master velocity × ratio. Use the technology object's trace to record both velocities simultaneously and confirm the lock window is held for ≥ 100 ms.
4. Symmetry: Calling MC_GearOut brings the slave back to Standstill within the configured deceleration, and the second gear step cycles without leaving an error code in the instance DB.

12. Field-Proven Caveats and Edge Cases

• Master at zero velocity: Even if the master StatusWord = 4, a master commanded to velocity 0.0 does not produce a lock. Add a minimum velocity floor of > 1 × 10⁻⁶ user units in the technology object, or ensure the master is commanded to a non-zero velocity before MC_GearIn is issued.
• Direction reversal: When the master changes direction, the slave will track automatically, but Done does not retrigger. The synchronization relationship remains valid until MC_GearOut is called or an error occurs.
• Hot-restart behaviour: After a CPU restart, all gearing relationships are dropped. The slave reverts to Standstill. Any gear step that runs on cold start must re-establish the lock with a fresh MC_GearIn call.
• S7-1200 vs S7-1500: S7-1200 supports a subset of MC_GearIn features. Some acceleration parameters are read-only on S7-1200; verify against the SIMATIC S7-1200 Motion Control Function Manual.
• External encoder as master: When the master is a real encoder (TO_ExternalEncoder), ensure the encoder is configured and operational before the gear command, or the slave will never see a velocity and the block will hang.
• Camming precedence: If MC_CamIn is active on the same slave, MC_GearIn is rejected. The slave can only follow one master relationship at a time.

13. Related References

• SIMATIC S7-1500 Motion Control Function Manual (edition 2023-12). Siemens Support 109769281
• TIA Portal V18 Motion Control Help (in-product documentation, index term "MC_GearIn").
• PLCopen Motion Control Part 1 (Technical Specification, version 2.0). PLCopen Motion Control working group
• SIMATIC S7-1500 Technology Objects Diagnostics Manual. Siemens Support 109751049

Frequently Asked Questions