Resolving SIMOTION _enablecamming syncstate Stuck on Virtual Axes

1. Problem Description

On SIMOTION controllers programmed in SCOUT TIA, a synchronization command issued through the system function _enablecamming on a slave axis whose master is at rest fails to reach the syncstate := YES state when the configuration uses syncprofilereference := RELATE_SYNC_PROFILE_TO_TIME. The technology object data block reports .state := CAMMING almost immediately, but the SlaveSync.syncstate bit remains NO until the master axis actually begins to move. The behavior is reproducible with a virtual axis used as the master and disappears as soon as the master produces a real position change in either direction.

Symptom summary observed in the field:

• Slave axis enters .state = CAMMING immediately after the command is issued.
• SlaveSync.syncstate stays at NO for an indefinite time.
• As soon as the master axis (virtual or real) moves by even a small increment, syncstate transitions to YES.
• The fault appears only on the second (and subsequent) synchronization attempt, after the axis has been desynchronized and re-enabled following a normal stop or fault reset cycle.
• The problem is transient on real masters with continuous motion, but persistent and blocking on virtual masters that stand still between cycles.

2. Affected Versions and Environment

The issue is documented in Siemens Industry Online Support under the contribution linked to Synchronization in SIMOTION - Axes A, B, C with cascading cam/gear. Refer to the SIMOTION Motion Control - Basics and Functions manual section 2.2.5 for the underlying synchronization model.

3. Root Cause Analysis

The synchronization state machine inside the TO_SYNCHRONOUS_OPERATION object decides whether the slave has "caught up" with the master by comparing the slave's projected position against the master value within a configurable tolerance window. Two configuration parameters control this decision and they are the root of the symptom:

3.1 SyncingMotion.masterReversionTolerance

The parameter setconfigdata.SyncingMotion.masterReversionTolerance (engineering units of the master, e.g., degrees or mm) defines the maximum amount of master reversion (i.e., master movement in the negative direction relative to the slave's catch-up expectation) that the synchronization algorithm tolerates before declaring the slave "out of tolerance" and refusing to assert syncstate = YES. The default value supplied by the SCOUT TIA wizard for a TO axis master is typically 40 user units. The user in this case reports the value as 80 in a default project and observed that the symptom appears when the parameter is non-zero.

Mechanically, the sequence is:

1. _enablecamming is issued with a synchronizing profile referenced to TIME (RELATE_SYNC_PROFILE_TO_TIME). The slave begins to ramp up the dynamic values (v, a, jerk) to follow the master value.
2. With a SMOOTH velocity profile and zero master velocity, the slave arrives at the synchronization position reference. The synchronous operation object must now decide whether syncstate may be set.
3. Because the master has not moved, the algorithm interprets the absence of master motion as a reversion event equal to the full magnitude of the master's last known position, which is compared against masterReversionTolerance.
4. If the tolerance is non-zero and the comparison fails (the "reversion" is larger than the tolerance, or the tolerance logic refuses a stationary master in this state), syncstate is held at NO indefinitely.
5. As soon as the master is commanded in the positive direction, the master value advances past the synchronization point, the tolerance check passes, and syncstate latches to YES.

3.2 enableSyncWithinTolerance

Siemens technical support identified the underlying configuration switch as SyncingMotion.enableSyncWithinTolerance. When this property is YES, the synchronous operation object is allowed to assert syncstate = YES even though the slave has not yet crossed the full synchronization window, as long as the slave is within the tolerance band. When it is NO (the legacy default), the slave must reach the end of the synchronization profile and the master must satisfy the reversion criterion before syncstate flips to YES.

With RELATE_SYNC_PROFILE_TO_TIME and a stationary master, the combination of enableSyncWithinTolerance = NO and any non-zero masterReversionTolerance reproduces the reported behavior on virtual axes. On real axes with continuous motion, the master advances quickly enough to satisfy the criterion, which is why the symptom looks like a virtual-axis-only issue.

4. Synchronization Reference Model

To select the correct fix, the engineer must classify the application against the SIMOTION synchronization matrix described in the SIMOTION Motion Control Basics documentation, section 2.2.5 ("Synchronization"). The four key decisions are:

The reported project uses:

• synchronizingMode = SYNCHRONIZE_WHEN_POSITION_REACHED
• synchronizingDirection = SHORTEST_WAY
• syncPositionReference = SYNCHRONIZE_WHEN_POSITION_REACHED
• syncProfileReference = RELATE_SYNC_PROFILE_TO_TIME (time-based profile, dynamic response parameters)
• velocityProfile = SMOOTH (jerk-limited)

For a time-based profile on a stationary master, RELATE_SYNC_PROFILE_TO_TIME forces the slave to traverse the synchronization window using only the configured velocity, acceleration, and jerk. The master contribution to the synchronization criterion is effectively zero, which exposes the tolerance check described in section 3.

5. Diagnostic Procedure

Run the following checks in SCOUT TIA online mode before applying any fix. The goal is to confirm that the symptom matches the documented root cause and not, for example, a wrong cam definition, an inactive following object, or a stuck enable.

5.1 Verify TO Configuration

1. Open the project in SCOUT TIA and connect to the target.
2. Select the Synchronous Operation technology object (e.g., toAxisSync) and go online.
3. Inspect the configuration data block setconfigdata.SyncingMotion on the Configuration tab. Note the current value of masterReversionTolerance and the availability of enableSyncWithinTolerance.
4. Inspect the actual values actdata.SyncingMotion. Confirm state = CAMMING and syncstate = NO.

5.2 Verify the Following Object and Cam

1. Open the cam Str_ACENAB.Cam in the cam editor. Confirm the definition range covers the synchronization window of both master and slave.
2. Confirm the cam is interpolating and that the cam's start value is defined at the master's synchronization position. A cam with a leading undefined segment will cause the synchronous operation object to refuse syncstate = YES independently of the tolerance issue.
3. Verify the master axis is enabled and the following object is linked. In the TO_SYNCHRONOUS_OPERATION properties, Following Object must point to the slave TO and Master to the master TO or to the leader setpoint source.

5.3 Capture the Master Value at the Stuck Moment

Use the trace in SCOUT TIA to record the master setpoint, the master actual value, the slave actual value, the state, and the syncstate bits on a common time base. Set the trigger to the rising edge of the _enablecamming command. The trace will show a flat master value while the slave ramps, then a step in the master value at the moment syncstate flips. This is the diagnostic signature of the tolerance issue.

5.4 Confirm the Symptom Matches

6. Solutions and Workarounds

Three validated remedies are listed below, ordered from least invasive to most invasive. Apply the first that satisfies the application requirement.

6.1 Recommended: Set SyncingMotion.enableSyncWithinTolerance to YES

This is the Siemens technical support recommendation. It enables the synchronous operation object to assert syncstate = YES as soon as the slave is within the synchronization tolerance band, regardless of whether the master has produced a measurable reversion.

Implementation in ST:

After changing the configuration, perform a download to the target and re-initialize the technology object (or, depending on the SIMOTION version, issue a configuration download to apply the new value online). Cycle power or perform a warm restart if the parameter is marked as a restart parameter in the help text.

6.2 Application-level: Set masterReversionTolerance to 0 for camming

If the application does not require reversion tolerance (typical for camming operations where the master is not allowed to reverse during synchronization), zero the parameter:

Apply this immediately before issuing _enablecamming. Apply the appropriate value before _enablegearing (the user reports 40 user units as a workable value for a TO-axis master in their project). Always verify the value with a trace; the exact tolerable magnitude depends on the mechanical backlash, the encoder resolution, and the synchronization velocity.

6.3 Application-level: Application logic that advances the master briefly

As a fallback for projects that cannot be reconfigured, inject a small positive master setpoint just after the _enablecamming command returns. The setpoint must be smaller than the synchronization profile length so that the slave can absorb the motion while ramping. Once syncstate flips to YES, cancel the injected setpoint. This is a workaround, not a fix, and is documented here for completeness because the user reports success with it in tests.

6.4 Combined Procedure for Mixed Cam/Gear Sequences

When the same slave participates in both _enablecamming and _enablegearing within the same program cycle, the parameter must be switched between calls. The validated pattern is:

// Before _enablecamming
toAxisSync.setconfigdata.SyncingMotion.masterReversionTolerance := 0.0;
i32Ret := _enablecamming(followingobject := toAxisSync,
                         direction        := POSITIVE,
                         mastermode       := ABSOLUTE,
                         slavemode        := ABSOLUTE,
                         cammingmode      := CYCLIC,
                         cam              := Str_ACENAB.Cam,
                         synchronizingmode := IMMEDIATELY,
                         syncpositionreference := SYNCHRONIZE_WHEN_POSITION_REACHED,
                         syncprofilereference  := RELATE_SYNC_PROFILE_TO_TIME,
                         velocity         := 50.0,
                         positiveAccel    := 10000.0,
                         negativeAccel    := 10000.0,
                         positiveAccelStartJerk := 50000.0,
                         positiveAccelEndJerk   := 50000.0,
                         negativeAccelStartJerk := 50000.0,
                         negativeAccelEndJerk   := 50000.0,
                         velocityProfile  := SMOOTH,
                         mergemode        := IMMEDIATELY,
                         nextcommand      := IMMEDIATELY,
                         commandid        := CammingCommandId,
                         synchronizingdirection := SHORTEST_WAY);

// Before _enablegearing with a TO axis master
toAxisSync.setconfigdata.SyncingMotion.masterReversionTolerance := 40.0;
i32Ret := _enablegearing(followingobject := toAxisSync, gearingmode := ABSOLUTE, ...);

7. Verification

Apply the following verification matrix to confirm the fix is effective and does not introduce regressions.

Online verification commands (ST, in the watch table of SCOUT TIA):

// Confirm current state
toAxisSync.actdata.SyncingMotion.state;            // expect CAMMING
toAxisSync.actdata.SyncingMotion.syncstate;        // expect YES
toAxisSync.actdata.SyncingMotion.commandId;        // expect CammingCommandId
toAxisSync.actdata.SyncingMotion.difference;       // expect within tolerance

8. Related Parameters and Compatibility Notes

For SIMOTION D controllers running firmware V5.4 and later, the configuration data block can be modified online if the parameter is not classified as a restart parameter. Use the Download to target function (or the Configuration Download for online change) in SCOUT TIA to propagate the new value. For restart parameters, a CPU restart is required.

9. Edge Cases and Field-Proven Caveats

• Virtual axis as master: Most likely to reproduce. The fix is mandatory in test rigs that use a virtual master for offline validation.
• Real axis master with a brief dwell between cycles: Symptom may appear intermittent. Add enableSyncWithinTolerance = YES defensively.
• Cascaded synchronization (axis C cammed to B, B geared to A): Both synchronous objects need the fix, because each one performs its own tolerance check. Apply it on the TO for C-to-B and on the TO for B-to-A.
• Smooth versus trapezoidal velocity profile: With SMOOTH, the slave takes longer to reach the synchronization window, increasing the window during which the symptom can be observed. With TRAPEZOIDAL, the symptom is usually masked by the faster profile completion.
• Time-based vs. distance-based profile: The symptom is specific to RELATE_SYNC_PROFILE_TO_TIME. With RELATE_SYNC_PROFILE_TO_DISTANCE the master value is the primary driver and the tolerance check behaves differently.
• High-ratio gearing: If the synchronization ratio is large, a small master movement corresponds to a large slave movement. The tolerance check must be set so that the slave's tracking error is acceptable; otherwise the symptom recurs with a different root cause (tracking error out of band).

10. Diagnostic Decision Flow

1. Confirm .state = CAMMING and .syncstate = NO.
2. Verify the cam definition covers the synchronization window. If not, fix the cam first.
3. Check masterReversionTolerance. If non-zero, set to 0 and re-test.
4. If the symptom persists, set enableSyncWithinTolerance := YES and re-test.
5. Capture a trace. Confirm the master setpoint is flat at the moment of the symptom.
6. If the master setpoint is changing, the symptom is not the tolerance issue. Investigate the follower enable, the cam interpolation, or the axis enable state.
7. After the fix, run the verification matrix in section 7.

FAQ