SIMOTION D425-2 Multi-Cam Timeout: _enableCamming Task Error Fix

Symptom: A SIMOTION D425-2 DP/PN running SIMOTION SCOUT V4.3 stops with the diagnostic buffer entry "STOP caused by execution system, cause: timeout" the moment two cams are enabled concurrently through the _enableCamming function. With a single cam engaged, the controller runs indefinitely. This is a classic task-system misallocation, not a wiring, cam data, or servo amplifier fault.

Scope: SIMOTION D425-2 DP/PN, SIMOTION D435-2 DP/PN, SIMOTION D445-2 DP/PN on firmware V4.3 / V4.4, executing two _enableCamming calls in a cyclic task of insufficient priority.

1. Problem Description

The reported installation uses one external encoder as the cam master and two SINAMICS servo axes as the cam slaves (LaneFollower_SYNCHRONOUS_OPERATION and LanePosition_SYNCHRONOUS_OPERATION). The application issues two _enableCamming commands inside a single IF block, gated by a DFRedifine trigger:

IF DFRedifine.q THEN
  LFRetValue := _enableCamming(
    followingObject       := LaneFollower_SYNCHRONOUS_OPERATION,
    direction             := POSITIVE,
    masterMode            := ABSOLUTE,
    slaveMode             := ABSOLUTE,
    cammingMode           := NOCYCLIC,
    cam                   := CamLaneFollower,
    synchronizingMode     := ON_MASTER_POSITION,
    syncPositionReference := BE_SYNCHRONOUS_AT_POSITION,
    syncProfileReference  := RELATE_SYNC_PROFILE_TO_LEADING_VALUE,
    syncLengthType        := DIRECT,
    syncLength            := 20,
    syncPositionMasterType := DIRECT,
    syncPositionMaster    := 20,
    mergeMode             := SEQUENTIAL,
    nextCommand           := WHEN_BUFFER_READY);

  LPRetValue := _enableCamming(
    followingObject       := LanePosition_SYNCHRONOUS_OPERATION,
    direction             := POSITIVE,
    masterMode            := ABSOLUTE,
    slaveMode             := ABSOLUTE,
    cammingMode           := NOCYCLIC,
    cam                   := CamLanePosition,
    synchronizingMode     := ON_MASTER_POSITION,
    syncPositionReference := BE_SYNCHRONOUS_AT_POSITION,
    syncProfileReference  := RELATE_SYNC_PROFILE_TO_LEADING_VALUE,
    syncLengthType        := DIRECT,
    syncLength            := 20,
    syncPositionMasterType := DIRECT,
    syncPositionMaster    := 20,
    mergeMode             := SEQUENTIAL,
    nextCommand           := WHEN_BUFFER_READY);

  DeviderEnableCamming := TRUE;
END_IF;

Observed behavior:

• Single _enableCamming execution: no STOP, axes synchronize correctly, cam follows the master encoder.
• Two _enableCamming calls issued in the same scan: the controller intermittently enters STOP state with the cause-of-stop field set to "timeout" in the diagnostic buffer.
• The Alarm tab in SCOUT shows no motion alarm; only the diagnostic buffer shows the execution-system timeout.

This pattern is a strong indicator of task scheduling starvation, not of a defective control unit, cam definition, or PROFIBUS/PROFINET configuration.

2. Affected Platforms and Firmware

3. Root Cause Analysis

The diagnostic-buffer entry "STOP caused by execution system, cause: timeout" is raised by the SIMOTION runtime when the currently active task is not allowed to return to the dispatcher within the configured TaskExecutionTime monitoring window. Two distinct mechanisms trigger it in the reported scenario:

3.1 Wrong task context for the cam-command pair

The program that issues _enableCamming is running in the BackgroundTask. BackgroundTask on SIMOTION D4x5-2 is a low-priority cyclic task with a default IPO/IPO time slice. The two _enableCamming calls each have to allocate command records on the cam-axis state machine, set the synchronizing state, and write to the technology object. With nextCommand = WHEN_BUFFER_READY, the call does not return until the previous command buffer slot is released, which depends on the servo controller's acknowledgement propagation over PROFIdrive / PROFINET. In a low-priority task that is preempted by ServoFastTask, IPOTask, and IPO2Task, the time to fulfil a single _enableCamming can easily exceed the configured watchdog. The runtime then stops the controller with a timeout.

3.2 Task runtime overflow from doubled motion workload

Each _enableCamming call expands the I/O configuration, generates a synchronizing profile (a cubic polynomial in the lead value), and inserts a command into the camming state machine. Two simultaneous calls therefore roughly double the per-cycle technology-packet processing. If the cycle time of BackgroundTask is left at the SCOUT default (often 9 ms or 12 ms on a D425-2 with full technology package), the doubled processing time can be more than 50 % of the cycle, leaving no headroom. The next time slot cannot be opened, and the runtime watchdog fires.

3.3 The "nextCommand = WHEN_BUFFER_READY" trap

When mergeMode = SEQUENTIAL is combined with nextCommand = WHEN_BUFFER_READY, the _enableCamming call has to wait until a buffer slot is free. In a high-priority MotionTask the wait is bounded by the IPO cycle. In BackgroundTask the same wait can block the entire scan if ServoFast pre-empts it, causing the dispatcher's task-completion monitor to trip before the wait resolves.

4. SIMOTION Task System Architecture

SIMOTION D4x5-2 dispatches four cyclic task classes plus a system tick. The order in which the dispatcher evaluates them is fixed and cannot be reordered by the user:

5. The _enableCamming Function: Behavior and Critical Parameters

The _enableCamming function (defined in the SIMOTION technology library Technology Packages > Cam) takes the following axis from the basic state CAMMING_INACTIVE to CAMMING_SYNCHRONIZING and finally to CAMMING_SYNCHRONIZED. The runtime relevant parameters for the reported issue are:

For two concurrent _enableCamming calls the runtime has to allocate two command-buffer slots, two synchronizing-profile state records, and two axis-control contexts. Each allocation goes through the technology-object system service, which is only served during the IPO/IPO2 task. If the calling task is the BackgroundTask, the service call is delayed by ServoFast, Servo, and IPO/IPO2 pre-emption, and the dispatcher watchdog can expire.

6. Diagnostic Procedure

Confirm the fault with the following sequence in SIMOTION SCOUT before changing any code:

1. Open the project online and connect to the D425-2 in RUN/STOP.
2. Navigate to Target system > Diagnostic buffer (or use the diagnostic icon on the toolbar).
3. Look for the entry text "STOP caused by execution system, cause: timeout". Note the timestamp, the task in which the timeout was raised, and the user-program stack pointer.
4. Open Target system > Commissioning > Task configuration and confirm the priority of the task in which the fault occurred.
5. Open Target system > Taskrun time (or read the structure effectiveTaskruntime on the controller) and read the maximum runtime of the last 100 cycles of BackgroundTask. A value close to or greater than the configured cycle time is the second confirmation.
6. With the controller in STOP, open the program containing the _enableCamming calls and look at the assignment list at the top of the editor: the program is bound to the BackgroundTask, the IPO2 task, or a TimerTask. Motion commands bound to BackgroundTask are the prime suspect.

If the diagnostic buffer shows a different cause-of-stop entry (for example user program, system error, or fatal system error), refer to the SIMOTION runtime error list in the SCOUT help (menu Help > Documentation > SIMOTION SCOUT > Diagnostic > Stop responses).

7. Solution: Relocate the Program to a MotionTask

1. In the project navigator, right-click the program unit (PU) that contains the two _enableCamming calls and select Properties > Task assignment.
2. Change the assignment from BackgroundTask to an existing MotionTask that runs at the same cycle as the IPO/IPO2 task. Typical setting: MotionTask_1 with cycle time = IPO cycle (4 ms on a D425-2 with default configuration).
3. If no MotionTask exists, right-click Programs > MotionTasks and add one. Set the cycle time equal to the IPO cycle. For a D425-2 the recommended cycle is 4 ms; for a D435-2/D445-2 with higher dynamics, 2 ms is acceptable.
4. Save the project, download to the target, and run a RAM-to-ROM save.
5. Restart the controller in RUN.
6. Trigger the DFRedifine transition again and verify that both _enableCamming calls return TRUE (retValue = state of command execution, not a simple OK flag).

8. Enable Task-Run-Time Monitoring

To prove that the relocation fixes the issue and to catch any future recurrence, enable the task run-time monitor in SCOUT:

1. Open Target system > Commissioning > Task configuration.
2. Tick Monitoring of task run times for every configured task (BackgroundTask, MotionTask, IPO/IPO2).
3. Download the configuration.
4. Add a watch on the system variable effectiveTaskruntime.maxTime of every task in the symbol browser. The structure is updated once per task cycle.
5. During commissioning, drive the master encoder through a full pass and trigger both _enableCamming calls. Verify that effectiveTaskruntime.maxTime stays below 70 % of the configured task cycle for the task that owns the program unit.

Typical values for the reported scenario on a D425-2 with default technology packages:

9. Reduce Merge-Mode Deadlock Risk

Even with the program relocated to a MotionTask, the combination mergeMode = SEQUENTIAL and nextCommand = WHEN_BUFFER_READY can still block if a single axis receives a second command before the first one has been acknowledged by the technology object. Apply these defensive patterns:

• Use a guard variable like DeviderEnableCamming in the program. Issue the second _enableCamming only after the first axis has reached state CAMMING_SYNCHRONIZED. Read the state from actualState or controlStatus of the cam axis object.
• Use a small command buffer of one slot per axis and never call _enableCamming twice in the same task cycle on the same axis.
• If the two cams must be enabled in the same cycle, call _enableCamming on axis A first, read the technology-packet acceptance flag, then call it on axis B in the next IPO cycle. The two calls will still appear "concurrent" from the application's perspective, but they will not collide on the buffer.
• If you need to change the master or the cam at runtime, use _setCamLeadingValue and _setCammingMode rather than re-issuing _enableCamming for the same axis.

10. Cam Configuration on D4x5-2 vs. D4x5

If the machine was originally built around a D4x5 (no "-2") and the controller has been replaced with a D4x5-2 during the lifecycle of the line, the cam technology object (TO) data may be in the old D4x5 format. Per the official Siemens support note 65767625, the migration must follow this sequence:

1. Open the original SCOUT project.
2. Select Options > Cam technology > Re-import from D4x5.
3. Recompile the project; the cam definition is translated into the D4x5-2 binary format.
4. Verify the cam track configuration under Technology > TO > Cam > Properties > Tracks. Lost or mis-ordered cam points are a common secondary cause of "works with one cam, fails with two" symptoms after a CPU replacement.
5. Check the IPO/IPO2 synchronization of the new CPU. D4x5-2 controllers with PROFINET typically use IPO2 as the second interpolator; the project must reflect this.

11. Verification Checklist

12. Common Side-Faults After the Fix

After the program is moved to a MotionTask, the following can surface and should be checked:

• Wrong cycle alignment: The MotionTask cycle must be a multiple of the IPO cycle. If the IPO cycle is 2 ms and the MotionTask is set to 9 ms, the runtime will round it to 8 ms and the synchronizing profile will be re-sampled on every second cycle. Set MotionTask cycle = 4 * IPO cycle as the safe default.
• Shared variables across the two cams: Reading the same global variable from the two _enableCamming calls in the same task cycle is safe; reading and writing in the same cycle is safe only if the variable is non-Volatile. Use a single source of truth and avoid replica variables.
• Time-out from a different cause: If a STOP with the same text appears again, enable the user-program error handler (_errorFdt or _errorMotion) and read the system variables userData and additionalInfo from the error context. The second-line cause often identifies a different root cause (e.g., a missing PROFIdrive telegram on a SINAMICS drive).
• PROFIdrive telegram mismatch: A D425-2 with two SINAMICS drives must use Standard Telegram 105 or 106 (or Siemens Telegram 3/5) and the isochronous mode must be enabled in both SCOUT and the drive. A single missing or mismatched telegram on a drive is a hidden cause of a "looks like timeout" stop when two axes are engaged simultaneously.

13. Field-Proven Workarounds if a MotionTask Is Unavailable

If the project architecture is frozen and no MotionTask can be added (rare, but seen in upgrade projects with locked task configuration):

1. Stagger the two _enableCamming calls across two BackgroundTask cycles. The first cycle enables axis A; the second cycle enables axis B. Use a state machine with the DeviderEnableCamming flag to gate the second call.
2. Increase the BackgroundTask cycle to at least 20 ms so that two _enableCamming calls can complete within a single cycle without exceeding the runtime watchdog. This is a workaround, not a fix — it only works because the runtime watchdog is sized on the IPO/IPO2 scale and BackgroundTask gets a generous budget by default.
3. Replace _enableCamming with a persistent _setCammingState followed by _camTrackEnable in cases where the cam definition is static for the entire production run. Persistent camming state avoids the per-call command-buffer allocation that drives the timeout.

14. Quick-Reference Parameter Sheet

15. FAQ