Troubleshooting SIMOTION MCC Chart Monitor Not Updating Live Status

When a SIMOTION Motion Control Chart (MCC) is downloaded to a target device and the operator opens the chart in the SIMOTION SCOUT or TIA Portal workbench, pressing the Monitor toolbar button should overlay current variable values, transitions, and active program branches onto the chart in real time. If nothing changes, no values appear, or the chart returns to a static offline view, the symptom is almost always caused by one of four root causes: (1) the chart program is not actually executing on the controller, (2) the Permit Program Status attribute is not set on the MCC unit, (3) the scan is too fast to be perceived without a deliberate hold or wait step, or (4) the engineering station is not in a consistent online state with the SIMOTION runtime. This reference walks through each cause, the diagnostic checks that confirm it, and the corrective action that restores live status indication.

1. SIMOTION MCC Execution Model Overview

SIMOTION separates configuration, programming, and execution layers. The MCC editor produces MCC source units compiled by SCOUT into mappable task objects. At runtime, a SIMOTION task (MotionTask, BackgroundTask, IPO_Task, IPO_2_Task, Servo_Task, or a user-defined cyclic task) is bound to the MCC unit, and that task is what actually drives the chart's state machine. Understanding this is essential because monitoring reflects the task's last visible state, not the editor's view of the source.

Reference: SIMOTION MCC Programming Manual (Siemens Support, PDF) describes the central role of the MCC as a flow-chart-style language compiled and dispatched by the SIMOTION runtime, with online monitoring provided through the engineering interface.

2. Problem Statement: Monitor Button Does Nothing

Symptom summary, as reported in the field:

• The user clicks Monitor (or the equivalent toolbar icon in SCOUT: Target system > Monitor or the glasses icon) on an MCC chart that has been downloaded to a SIMOTION target.
• The chart does not enter the online/active state. Variable overlays do not appear, transition conditions show no current value, and active command blocks do not highlight.
• No error dialog appears; the editor simply remains visually static.
• The same chart can be downloaded successfully and the target reports RUN, but the MCC program itself either does not appear to be running or appears to run too fast to observe.

3. Root Cause Matrix

Use this matrix to triage the symptom before changing any code or attributes.

4. Root Cause R1 — Permit Program Status Is Not Set

The most common reason an MCC chart refuses to show live status is the Permit Program Status attribute being disabled at the unit level. This is a per-unit compilation switch; when it is off, the runtime deliberately suppresses the program-status data structures that SCOUT requires to render overlays. The chart will still execute, but the engineering channel cannot ask the controller "which block is active right now?" because the supporting symbols are not emitted.

4.1 Where to find the option

1. In the SCOUT project navigator, expand the SIMOTION device and then Programs.
2. Right-click the affected MCC unit (for example, MyMccUnit) and choose Properties.
3. Open the Compilation tab (older SCOUT releases: General tab).
4. Check Permit Program Status.
5. Click OK, recompile the unit (Target system > Compile or right-click → Compile), and download to the target.

4.2 Why it is not the default

Program status adds runtime overhead: it forces the compiler to keep additional metadata describing each block, branch, and transition so that the controller can report the current "cursor" back to SCOUT. On tightly tuned machines this overhead is sometimes undesirable, so Siemens leaves the option at the developer's discretion. When monitoring is required, enable it; when commissioning is finished and the machine is in production, you may turn it off again.

5. Root Cause R2 — MCC Unit Not Running

A chart that is downloaded but not bound to a running task is silent. The Task Configuration editor (reached via Target system > Configure Task in SCOUT) is the single source of truth: every executable unit, including MCC, ST, and LAD/FBD sources, must be assigned to a task, and that task must be started.

5.1 Verify the binding

1. Open Task Configuration from the project navigator.
2. Locate the task you expect to drive the chart — typically a MotionTask_ with a configured cycle time of 1–32 ms for motion sequences, or BackgroundTask for non-time-critical sequences.
3. Confirm the MCC unit name is listed under that task's Programs.
4. Confirm the task itself is in RUN state. In online mode, the task icon shows a green play triangle; a paused task shows a yellow pause icon.

5.2 Force the task to RUN

If the task is in STOP:

1. Right-click the task and choose Start Task, or use the toolbar Run/Stop selector.
2. If it returns to STOP immediately, check the System log for alarms — a faulty axis reference or a missing technology object can abort the task on entry.
3. Confirm the assigned technology object (axis, cam, output cam, temperature controller, etc.) exists, is configured, and is not in error state.

6. Root Cause R3 — Online Connection Issues

Monitoring requires a live engineering channel to the SIMOTION device. The channel is established when you click Connect to target system (or Online > Connect to target system). If the channel is not up, the Monitor button will either be disabled or will produce no overlay.

6.1 Quick checks

1. Open Online > Accessible Nodes. The target's PROFINET name and IP address should appear in the list. If they do not, the engineering station cannot reach the controller.
2. Verify IP/subnet: the SIMOTION device and the engineering PC must be on the same IP subnet, or the routing must be set up correctly via a switch/router that is accessible to both.
3. Verify the right target is selected: Online > Target System > ... should show the device you're trying to monitor.
4. If the device is reachable but not in your project, add it via Online > Accessible Nodes > [device] > Online & diagnostics or Download to target system (after a careful comparison to avoid overwriting running code).

6.2 Address the SIMOTION device in TIA Portal

If you are working inside TIA Portal with the SIMOTION option, the device is selected from the project tree. Right-click the SIMOTION device and choose Go online. If TIA Portal reports a certificate or PG/PC interface problem, set the PG/PC interface to the correct Ethernet adapter under Start > Control Panel > Set PG/PC interface and select S7ONLINE (STEP7) → <your network card> (Windows) or the corresponding Set PG/PC interface in the TIA Portal options.

7. Root Cause R4 — Chart Runs Too Fast To See

SIMOTION tasks are scheduled at high priority. Servo_Task can run at 250 µs to 1 ms, IPO_Task at 1–4 ms, and even a MotionTask at 4–32 ms is faster than the human eye can comfortably resolve. If the MCC unit contains only motion commands and a few Boolean transitions, the chart may transition through several states between two paint events of the SCOUT UI.

7.1 The "4 ms scan" problem

A typical MotionTask with a 4 ms cycle will execute the entire MCC chart roughly 250 times per second. Without an explicit wait in the chart, the editor will never see the cursor in a single block long enough to render. A watch table may show values changing, but the chart will appear frozen because the editor's polling rate is also gated by the same task cycle and the rendering pipeline.

7.2 Insert observation points

To make a fast chart observable, add a deliberate pause or synchronization point:

1. Add a Wait for ... command (for example, Wait for <Boolean variable> or Wait time 1.0s) between sub-flows. This causes the chart to dwell on the waiting block until the condition is true or the timer expires, giving SCOUT time to render the active state.
2. Use Set output blocks to pulse a digital output at every branch transition, and probe that output on a scope. This is a more deterministic way to validate the chart flow without relying on visual feedback.
3. For motion sequences, structure the chart so each motion block ends with an implicit End of motion transition. SIMOTION will hold the chart state at the block until the motion completes, which usually means the chart can be observed on a single-axis or low-axes sequence.

7.3 Single-step mode

For detailed debugging, switch the task to Single-step mode via the task toolbar. The chart will execute one block at a time on user request, allowing you to inspect every transition. This is the equivalent of the LAD/FBD single-step in STEP 7 and is the most reliable way to correlate chart state with variable values.

8. Root Cause R5 — Compilation and Firmware Constraints

Program status is also affected by how the MCC unit was compiled and by the SIMOTION runtime version on the target.

8.1 Compiler version mismatches

If the SCOUT build that compiled the project is newer than the SIMOTION firmware running on the controller, certain symbols (including program-status structures) may be present in the build but not understood by the older RT kernel. Symptoms include: the chart downloads and runs, but SCOUT reports a Compatibility warning at compile time, and the monitor overlay returns no data. Update the target firmware to match the SCOUT build, or compile against the older target firmware using the Target device selection in the project properties.

8.2 Optimization and dead-code elimination

The MCC compiler may, in some configurations, recognize unreachable code and omit it from the build. If the chart contains only commands that the compiler considers "no-ops" (such as a sequence of Set variable to its current value), the active-block cursor can be reported as "none". Enable Compile with debug information in the project options to force the compiler to retain all blocks for status purposes.

9. Root Cause R6 — Access Rights and Concurrent Engineering

SIMOTION supports a single engineering seat holding exclusive write access, and a configurable number of read-only monitoring seats. If another engineer has the project open in exclusive mode, your Monitor action may be refused silently.

1. Check the bottom status bar of SCOUT: if it shows a yellow lock icon with another station name, you are not the exclusive owner.
2. Coordinate with the other engineer to release the exclusive lock, or ask them to switch to monitoring mode.
3. If you are the only engineer and the lock persists, restart SCOUT and reconnect; stale locks occasionally survive a project crash.

10. Step-by-Step Diagnostic Procedure

Use this sequence in order. It is the fastest path from a static chart to a live overlay in the field.

1. Confirm online state. Open Online > Accessible Nodes and verify the target is reachable. If not, fix the network first.
2. Go online with the project. Right-click the SIMOTION device in the project tree and choose Go online. The status indicator should turn green.
3. Open the MCC unit's properties. Confirm Permit Program Status is checked. If not, check it, recompile, and download.
4. Open the Task Configuration. Confirm the MCC unit is assigned to a running task. Start the task if it is stopped.
5. Open the MCC chart and click Monitor. The chart should now show overlays. If it does not, continue.
6. Add a temporary Wait step. Insert a 1-second Wait time near the start of the chart, recompile, and download. The chart should dwell on the wait block; that confirms execution.
7. Open a watch table on the same variables. Confirm values are updating on the target. If they are, but the chart overlay is still empty, escalate to single-step mode.
8. Switch the task to single-step. Step through the chart manually and confirm each block transitions correctly.
9. Check system log and alarms. If the task aborts on entry, the system log will show the alarm code. Resolve the axis, cam, or technology-object issue first.
10. Verify firmware compatibility. Cross-check the firmware version on the target with the SCOUT build that compiled the project.

11. Verification Checklist

After each corrective step, confirm the chart is alive by looking for the following visual indicators in SCOUT:

12. Comparison: MCC Monitor vs Watch Table vs Trace

Use the right tool for the right question. Each one answers a different debugging need.

13. Best-Practice Recommendations

• Enable Permit Program Status on every MCC unit used during commissioning, and turn it off before final production build to save a small amount of cycle time.
• Structure charts with explicit wait or synchronization points around motion blocks; this is good engineering practice and makes monitoring meaningful.
• Keep the firmware version of SCOUT and the target aligned. Mismatches are a frequent source of subtle monitoring failures.
• Document the task binding in the project header so every engineer knows which task drives which chart.
• Use a single engineering seat in exclusive mode during commissioning to avoid silent refusals of monitoring requests.
• For fast cycles (<4 ms) prefer trace and single-step over visual monitoring; visual monitoring is most useful on 8 ms and slower tasks.

14. Frequently Asked Questions