SIMOTION Trace 8-Signal Limit: Workarounds and Task Profiler Configuration

The SIMOTION TRACE function in SCOUT engineering is limited to a maximum of 8 signal tracks per trace recorder instance. Engineers troubleshooting motion control systems frequently encounter this hard ceiling when diagnosing axis behavior, task scheduling, or I/O timing problems that involve more than eight discrete variables. This reference documents the architectural reason for the limit, explains the purpose of the Task Profiler, and provides two production-tested workarounds that extend the effective trace surface to 32, 64, or theoretically up to 256 signals without requiring external recording hardware.

SIMOTION Trace Function Architecture

The SIMOTION trace subsystem captures process variables, system variables, and I/O points at the servo/IPO/task clock rate and stores them in a circular buffer on the controller. Each trace recorder instance on a SIMOTION C, P, or D controller can monitor up to eight independent signals simultaneously. This is a fixed limit in the trace subsystem of the SIMOTION runtime and is not configurable through SCOUT TIA-style parameter changes.

Key architectural facts that frame the 8-signal limit:

• Each trace recorder writes to its own buffer; multiple recorders can coexist only when the controller is in Test mode (German: Testmodus).
• Process mode (production runtime) permits a single trace recorder with the standard 8-track ceiling.
• Trace data is captured at servo or IPO tick resolution, with trace depth (samples) traded off against the number of recorders.
• Binary signals can be packed into a 32-bit DWORD or 64-bit QWORD, and the trace subsystem will display each bit of the packed variable as a separate track.

The 8-Signal Limit Explained

The constraint is enforced inside the SIMOTION runtime's trace buffer descriptor. Each recorder reserves eight trace slots, and the recording engine hard-codes the slot count. The SCOUT HMI exposes this through the recorder configuration dialog: the signal list cannot be extended beyond eight entries regardless of controller firmware version, technology package, or project configuration.

If your diagnostic objective involves more than eight non-binary signals (for example, axis position, axis velocity, following error, torque, and multiple analog I/O points), you must either combine variables into packed structures or move to Test mode and instantiate additional recorders.

Task Profiler: Purpose and Configuration

The Task Profiler is a SIMOTION diagnostic tool used to analyze task traces. It does not record user process variables; instead, it visualizes how CPU time is distributed across the SIMOTION task system (BackgroundTask, IPO, IPO_2, Servo, Servo_2, etc.). The profiler reads a task trace buffer that you create through the device diagnostics of the SIMOTION CPU.

When to use Task Profiler

• Determining whether a task is exceeding its slice time budget (for example, IPO task overshoot under load).
• Identifying priority inversion or starvation between Servo, IPO, and BackgroundTask.
• Verifying that motion interpolation runs at the configured servo cycle (typically 1 ms, 2 ms, or 4 ms depending on SIMOTION hardware class).
• Diagnosing cyclic timeouts that surface as technology object alarms or axis stop reactions.

Creating a task trace

1. In SCOUT, connect to the target SIMOTION device.
2. Open Project Navigator > [Device] > Diagnostics.
3. Select Task Trace and click Create. Choose the tasks to include (Servo, IPO, BackgroundTask, and any user-defined tasks).
4. Define the trace depth (number of samples) and the trigger condition (immediate, variable edge, or alarm-triggered).
5. Start the recorder, reproduce the condition, and stop the recording.
6. Open the trace in the Task Profiler view to read the per-task execution histograms and timeline.

Workaround 1: Bit-Packing Binary Signals into DWORD or QWORD

If the variables you need to trace are all binary (BOOL), pack them into a 32-bit DWORD or 64-bit LWORD/QWORD in the SIMOTION program. The trace recorder can then be configured to display each bit of the packed variable as an independent track, effectively multiplying the 8-track limit by 32 (or 64).

Implementation in SIMOTION ST

// Pack 32 boolean flags into a single DWORD for trace
VAR_GLOBAL
    bFlag01 : BOOL; bFlag02 : BOOL; bFlag03 : BOOL; bFlag04 : BOOL;
    bFlag05 : BOOL; bFlag06 : BOOL; bFlag07 : BOOL; bFlag08 : BOOL;
    bFlag09 : BOOL; bFlag10 : BOOL; bFlag11 : BOOL; bFlag12 : BOOL;
    bFlag13 : BOOL; bFlag14 : BOOL; bFlag15 : BOOL; bFlag16 : BOOL;
    bFlag17 : BOOL; bFlag18 : BOOL; bFlag19 : BOOL; bFlag20 : BOOL;
    bFlag21 : BOOL; bFlag22 : BOOL; bFlag23 : BOOL; bFlag24 : BOOL;
    bFlag25 : BOOL; bFlag26 : BOOL; bFlag27 : BOOL; bFlag28 : BOOL;
    bFlag29 : BOOL; bFlag30 : BOOL; bFlag31 : BOOL; bFlag32 : BOOL;
    dwPacked : DWORD;
END_VAR

// Pack using bitwise OR inside a fast task
PROGRAM PackFlags
    dwPacked.0  := bFlag01;
    dwPacked.1  := bFlag02;
    dwPacked.2  := bFlag03;
    dwPacked.3  := bFlag04;
    dwPacked.4  := bFlag05;
    dwPacked.5  := bFlag06;
    dwPacked.6  := bFlag07;
    dwPacked.7  := bFlag08;
    dwPacked.8  := bFlag09;
    dwPacked.9  := bFlag10;
    dwPacked.10 := bFlag11;
    dwPacked.11 := bFlag12;
    dwPacked.12 := bFlag13;
    dwPacked.13 := bFlag14;
    dwPacked.14 := bFlag15;
    dwPacked.15 := bFlag16;
    dwPacked.16 := bFlag17;
    dwPacked.17 := bFlag18;
    dwPacked.18 := bFlag19;
    dwPacked.19 := bFlag20;
    dwPacked.20 := bFlag21;
    dwPacked.21 := bFlag22;
    dwPacked.22 := bFlag23;
    dwPacked.23 := bFlag24;
    dwPacked.24 := bFlag25;
    dwPacked.25 := bFlag26;
    dwPacked.26 := bFlag27;
    dwPacked.27 := bFlag28;
    dwPacked.28 := bFlag29;
    dwPacked.29 := bFlag30;
    dwPacked.30 := bFlag31;
    dwPacked.31 := bFlag32;
END_PROGRAM

Trace configuration for the packed variable

1. In SCOUT, add dwPacked as a single signal to your trace recorder.
2. In the trace display, right-click the signal and choose Display as Bit Tracks.
3. SCOUT renders each of the 32 bits as a separate logical track in the chart, yielding 32 visible tracks from one slot.
4. With all 8 slots filled with packed words, you achieve up to 256 binary tracks in a single recorder, comfortably exceeding most field diagnostics.

The same technique extends to LWORD (64-bit) for 64 tracks per slot. Field experience suggests SCOUT reliably renders up to 32 bits per packed variable; the 64-bit path is documented but should be validated on your specific SCOUT version and SIMOTION firmware combination before relying on it in production.

Workaround 2: Enabling Test Mode for Multiple Trace Recorders

When you need to monitor more than eight non-binary signals (analog values, axis variables, real-typed process values), bit-packing is not applicable. The second workaround is to switch the SIMOTION CPU into Test mode, which permits multiple simultaneous trace recorder instances.

How to enable Test mode

1. Connect SCOUT to the target device online.
2. Right-click the SIMOTION device in the project navigator and select Operating Mode > Test Mode.
3. Confirm the prompt warning about increased resource consumption.
4. The CPU status indicator in SCOUT changes from RUN to RUN (Test). Functionally, the control program continues to run without restriction; only the diagnostic subsystem is enhanced.

Instantiating additional recorders

1. Open the TRACE editor under device diagnostics.
2. Create the first recorder (8 signals).
3. Create a second recorder instance — this is only available in Test mode.
4. Configure each recorder with its own 8-signal set and independent trigger.
5. For a third recorder, repeat the process. The total count is constrained by available RAM and CPU load, not by a hard-coded ceiling in Test mode.

The combined track count becomes 8 × N where N is the number of active recorders. Three recorders deliver 24 tracks, four deliver 32, and so on. This is the only supported method to exceed 8 tracks when the signals are real-valued.

Test Mode Resource Implications

Test mode is functionally equivalent to Process mode for the user program — there are no functional restrictions against production operation. However, the diagnostic subsystems (trace, Task Profiler, watch tables, force tables) consume additional system resources:

Memory and CPU Stop Conditions

Excessive diagnostic load on a SIMOTION controller can drive the CPU into a stop state or trigger an internal software error. The runtime monitors its own resource utilization and protects itself by halting when thresholds are crossed.

Observed failure modes

• CPU STOP from RAM exhaustion: when the trace buffer allocation, combined with project code and data, exceeds the installed memory on the SIMOTION platform (for example, SIMOTION D4x5 with 64 MB versus D4x5-2 with larger RAM).
• Internal software error (SF, BF): triggered when the diagnostic subsystem cannot allocate buffer space or when task execution time exceeds the watchdog limit due to trace data extraction overhead.
• Task timeout and axis stop reaction: when the servo task slice time is exceeded, the motion subsystem may command a stop reaction (STOP 1, STOP 2) depending on configuration.

Mitigation checklist

1. Check available RAM and RAM disk in the device diagnostics before enabling Test mode on a production controller.
2. Reduce trace depth (number of samples) before increasing recorder count.
3. Prefer bit-packing to multiple recorders when the signals are binary.
4. Schedule trace recording for known events using trigger conditions rather than continuous capture.
5. Stop recorders as soon as data is captured; do not leave multiple recorders running indefinitely.
6. When working with limited memory (D410, D425), consider exporting the trace to a CF card or external storage via the file system interface.

Best Practices for SIMOTION Trace Recording

Engineers working on SIMOTION diagnostics should treat the trace recorder as a precision instrument: configure it tightly, capture narrowly, and reset promptly.

Pre-recording

• Define the diagnostic question before configuring the trace. Eight tracks force you to be selective.
• Prefer system variables (axis.actualPosition, axis.actualVelocity, axis.followingError) for motion diagnostics over derived project variables.
• For binary state machines, pre-pack into DWORD to free slots for analog signals.

During recording

• Use edge triggers on a known causal variable to capture only the relevant time window.
• Annotate external events (operator input, E-stop press) into a single boolean for post-capture correlation.

Post-recording

• Export the trace to CSV or a SCOUT archive immediately to free controller RAM disk.
• Stop the recorder; do not let it idle.
• Return the controller to Process mode if Test mode was used.

Diagnostic Workflow Matrix

Trace vs. Task Profiler: Choosing the Right Tool

The trace function and the Task Profiler address orthogonal questions, and confusion between them wastes engineering time.

• Trace answers: What value did this variable take at time T?
• Task Profiler answers: How was CPU time distributed across tasks at time T?

If you suspect a task scheduling problem (servicing lateness, timeouts), open the Task Profiler. If you need the actual trajectory of an axis or a digital signal, open the trace. The two tools can run side by side in Test mode without conflict, though each consumes additional RAM.

References to Foundational Tracing Concepts

The general concept of a software tracer — capturing execution context with low overhead — is shared across many real-time and operating-system environments. For engineers interested in how tracing is implemented in another highly optimized real-time context, the Linux kernel function tracer (ftrace documentation) describes similar trade-offs between trace depth, number of events, and runtime overhead. The SIMOTION trace subsystem makes analogous engineering choices at the motion-control layer.

Field Notes and Common Pitfalls

Three recurring issues appear during commissioning:

1. Assuming Test mode and Process mode are functionally identical: they are equivalent for the user program, but resource consumption differs. Test mode is not a free diagnostic environment.
2. Leaving recorders running after data capture: the trace buffer continues to consume RAM disk and CPU time. Always stop recorders explicitly.
3. Forgetting to remove Test mode before production handover: if the controller ships in Test mode, the system reserves diagnostic memory permanently and may behave differently under high load.

FAQ