Generating SIMOTION D Diagnostic Log Files via IT DIAG

Generating SIMOTION D Diagnostic Log Files via IT DIAG and DIAG Button

SIMOTION controllers generate a rich set of internal diagnostic data that engineering teams must capture when field issues occur. Operators and commissioning engineers routinely need to extract a diagnostic log bundle from a SIMOTION D controller, a SIMOTION C/P controller, or an associated SINAMICS CU320-2 drive controller and forward that bundle to the OEM for offline analysis. This reference documents the supported mechanisms, platform-specific differences, file-system restrictions, and recommended retrieval workflows based on the SIMOTION SCOUT service and diagnostics documentation set.

SIMOTION Platform Overview and Diagnostic Capabilities

SIMOTION is Siemens' modular motion-control platform available in three hardware form factors. Each form factor exposes a different set of diagnostic capture mechanisms, and the workflow for backing up and restoring diagnostic data therefore differs across platforms.

SIMOTION D is the only SIMOTION device that exposes a service selector switch and, on the D4x5-2, a dedicated DIAG button on the front of the unit. These local triggers generate a controlled diagnostic dump without requiring an engineering tool to be connected.

SIMOTION D4x5-2 DIAG Button Operation

The D4x5-2 DP and D4x5-2 PN variants provide a recessed DIAG button on the front panel. Holding the button for a defined interval triggers a system diagnostic capture routine that bundles the active task stack, technology object (TO) trace buffers, system logs, the current project fingerprint, and the Web server diagnostic directory into a compressed archive.

Procedure — Triggering a DIAG Capture on D4x5-2

1. Verify the controller is in a safe operational state. The diagnostic capture is non-destructive for runtime data, but a free CPU is recommended.
2. Insert a suitable pin or SIMOTION DIAG tool into the DIAG button aperture.
3. Press and hold the DIAG button for approximately 3 seconds until the DIAG LED on the front panel changes state (typically from off to solid or slow flash, depending on firmware).
4. Release the button. The capture routine runs in background; allow 30 to 120 seconds depending on project size and trace buffer fill.
5. When the DIAG LED returns to its idle state, the diagnostic ZIP is available in the controller's diagnostic file directory.

Captured Data Set

The DIAG capture ZIP includes:

• System log (system.log) — last 2000 system events with timestamps in UTC
• Task stack snapshot for all active MotionTasks and IPOs
• Technology object trace buffers (TO traces currently in scope)
• Non-volatile diagnostic data (NVDATA) image
• Web server diagnostic directory (/diagnostic) including configuration pages and runtime counters
• Active alarm buffer (ALARM_S state)

Service Selector Switch

SIMOTION D units provide a service selector switch that gates the RUN/STOP/SERVICE modes. The switch positions are:

Position 2 (SERVICE) is the recommended mode when engineering tools are used to perform an explicit diagnostic pull via IT DIAG. Position 0 (RUN) is the typical state when the DIAG button is used during runtime.

IT DIAG — IT Diagnostics Tool

IT DIAG is the web-based diagnostic interface for SIMOTION D and the SINAMICS CU320-2. It runs as an embedded HTTP service on port 80 (HTTP) and 443 (HTTPS, firmware V4.4+) and exposes the diagnostic capture directory.

Accessing IT DIAG

1. Connect a service PC to the SIMOTION D X120 / X130 / X150 PROFINET port or to the X127 service port (D4x5-2 only).
2. Configure the PC with an address in the controller's service subnet. The X127 port default address is 192.168.1.1; the controller default is 192.168.1.2.
3. Open a browser and navigate to http://192.168.1.2 (or the controller's IP if changed).
4. Authenticate with the engineering user credentials. Default user is simotion with password simotion; production systems should change these.
5. Navigate to Diagnostic files in the left-hand menu.

The Diagnostic files page lists all available diagnostic ZIPs by timestamp. Click a file to download the complete diagnostic data set. Each download is logged in the controller's audit log with the requesting IP, user, and timestamp.

SINAMICS CU320-2 Diagnostic Capture

The SINAMICS S120 CU320-2 Control Unit is closely integrated with SIMOTION D — on D4x5 / D4x5-2 the CU320-2 is the drive-side of the combined unit. Diagnostic capture is supported via two paths:

1. STARTER / Startdrive diagnostic buffer — read the fault buffer, alarm buffer, and warning buffer via the engineering tool. This produces an exportable .zip with drive-side data only.
2. SIMOTION DIAG capture — when CU320-2 is paired with a D4x5 / D4x5-2, the SIMOTION DIAG button capture includes a complete drive snapshot in the same ZIP archive.

To read these buffers in Startdrive, navigate to Drive > Diagnostics > Fault/alarm buffer, then click Export. The resulting .bin is decoded via the Startdrive diagnostic viewer or via the SIMOTION SCOUT Drive Diagnostics plug-in.

User-Program Logging — Limitations and Workarounds

A common requirement is to capture application-level events (machine state transitions, recipe changeovers, error counters) into a log file that travels with the diagnostic bundle. SIMOTION's runtime imposes a hard constraint: the user program cannot create arbitrary files on the controller's CF card or on the D4x5-2 internal file system.

Why Custom Files Are Not Permitted

• SIMOTION's non-volatile file system is reserved for firmware, project, and system-managed diagnostic data. The runtime system enforces this in the file-system driver.
• Writing user files to the CF card from within the program risks corrupting the project image if the write overlaps with system metadata blocks.
• Siemens does not expose a stable _FileCreate / _FileWrite API to user code in current SIMOTION runtime versions.

Supported Alternatives for Application Logging

Recommended Pattern — Logging to a Paired IPC

When application-level file logging is essential, the most robust pattern is to pair the SIMOTION controller with a SIMOTION P320 IPC or a third-party IPC and log over PROFINET or TCP. The user program on the SIMOTION side pushes a structured log line to the IPC via a TCP socket connection; the IPC writes the line to disk.

// SIMOTION ST — open a TCP connection to the IPC log service
VAR_GLOBAL
    hSocket : DINT := 0;            // handle
    bLoggingOK : BOOL := FALSE;
END_VAR

IF hSocket = 0 THEN
    hSocket := _openSocket(protocol := TCP, 
                            port := 0, 
                            localIP := '0.0.0.0');
    bLoggingOK := _connect(socket := hSocket, 
                           remoteIP := '192.168.10.50', 
                           remotePort := 9100);
END_IF;

// On each application event:
IF bEdge_Event AND bLoggingOK THEN
    _send(socket := hSocket, 
          buffer := ADR(logLine), 
          length := SIZEOF(logLine));
END_IF;

The IPC side runs a minimal nc -l -k -p 9100 >> /var/log/machine.log or a Python receiver:

# Python receiver on the IPC
import socket
HOST, PORT = '0.0.0.0', 9100
with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
    s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    s.bind((HOST, PORT)); s.listen(8)
    while True:
        conn, _ = s.accept()
        with conn, open('/var/log/machine.log','ab') as f:
            while True:
                data = conn.recv(4096)
                if not data: break
                f.write(data)

SIMOTION Message Handling and ALARM_S

SIMOTION's Message Handling subsystem generates structured event records through _alarm and the ALARM_S / ALARM_D configuration. The strings defined in the message configuration are stored in the alarm buffer and travel with the diagnostic ZIP. Engineers who need a customer-readable event log can do the following:

1. Configure ALARM_S blocks in SCOUT with a numbered message and an associated text parameterized by global variables.
2. Use the message text format string to embed the machine state, recipe ID, and counter values.
3. When the diagnostic ZIP is retrieved, the alarm buffer is decoded by the SCOUT message viewer and can be exported as CSV.

The alarm buffer depth is hardware-dependent but is typically 50 to 200 entries for SIMOTION D, with FIFO overwrite on overflow. If the field engineer is concerned about wrap-around, reduce the IPO and servo task frequency during the test window to leave more time between message bursts, or split message categories across multiple ALARM_S blocks to use separate buffers.

CF Card File System — What Is and Is Not Writable

The CF card on a D4x5 holds the SIMOTION project, firmware, and the diagnostic file directory. The directory layout is fixed by the runtime:

CF:\
├── SIMOTION\
│   ├── FW\
│   ├── PROJECT\
│   └── USER\
├── diagnostic\
│   ├── diag_20240115_103045.zip
│   ├── diag_20240115_143210.zip
│   └── ...
└── log\
    ├── alarm.buf
    └── trace.bin

User code cannot create new top-level directories or files under CF:\. The only writable surface for user code on the runtime side is the persistent data area, accessed via the standard PLC data-block persistence model (_savePersistentData / _loadPersistentData).

Diagnostic Bundle Contents and Naming Convention

Diagnostic ZIPs follow the naming convention diag_<YYYYMMDD>_<HHMMSS>.zip in UTC. The internal structure is:

The meta.json file is critical for triage — it contains the SIMOTION firmware version, the SIMOTION SCOUT project GUID, the device serial number, and the runtime uptime in seconds. Always include the meta.json when forwarding the bundle to the OEM.

Forwarding the Bundle to the OEM

Once the diagnostic ZIP is retrieved, three common methods exist for delivering it to the OEM:

1. Service engineer portable storage — copy the ZIP to a USB stick or laptop and email it through the standard corporate channel. This is the most common field workflow.
2. HMI / SCADA export — write a button on a WinCC Unified or TIA Portal HMI that triggers a script to read the IT DIAG directory and copy the newest ZIP to a network share.
3. SFTP from the engineering PC — use a service PC to connect to the controller's SFTP service (firmware V4.4+ on D4x5-2) and pull the file with a tool such as WinSCP.

Email push from the SIMOTION controller itself is not supported. There is no SMTP client in the SIMOTION runtime, and the controller has no built-in TLS/SSL stack for outbound email in the standard firmware image. Any attempt to add email capability must be done through an external IPC or a separate cellular IoT gateway that sits on the same network and polls the controller's IT DIAG directory.

Commissioning Workflow — Recommended End-to-End Procedure

1. Before commissioning, record the controller's serial number, firmware version, and project GUID. These are in meta.json after the first DIAG capture.
2. During commissioning, perform a baseline DIAG capture to verify the diagnostic chain works end-to-end. Confirm the ZIP appears in IT DIAG and can be downloaded.
3. Train operators on the DIAG button: hold 3 seconds, watch for the LED state change, then notify the service engineer to pull the file.
4. After any fault, before cycling power, trigger a DIAG capture. The alarm buffer is cleared on power cycle, so capture first.
5. Pull the file via IT DIAG within the next service window. ZIP files older than 30 days are auto-purged by the controller in firmware V4.4 and later.
6. Forward the bundle to the OEM, including the meta.json content in the cover email.

Firmware and Version Notes

SIMOTION SCOUT V5.x supports the diagnostic ZIPs from all SIMOTION firmware versions V4.0 and later. Earlier SIMOTION SCOUT versions (V4.x) cannot import meta.json files generated by V5.x firmware; in mixed environments keep the engineering tool aligned with the controller firmware.

Troubleshooting Matrix

Field-Proven Cautions and Edge Cases

• Some early D4x5-2 firmware revisions (V4.2 SP1 and earlier) had a bug where the DIAG capture would silently truncate at 32 MB. Always check the resulting ZIP file size; if it is exactly 32 MB, upgrade the firmware.
• The DIAG button is recessed to prevent accidental activation. Field engineers have been known to use paper clips and break the switch; Siemens sells a dedicated DIAG tool (order number 6FC5348-0AA02-0AA0) that should be preferred.
• The IT DIAG service shares the controller's PROFINET interface bandwidth. Capturing during a high-traffic cycle may slow the diagnostic download significantly. Schedule capture during a maintenance window when possible.
• If the controller is in a Profisafe / Profinet safety configuration, the DIAG capture is still safe — it is a read-only operation against the project. However, the safety signature may change after the capture if any non-volatile data is rewritten, which would require re-acceptance of the safety function.
• The diagnostic ZIP contains the project fingerprint. If the customer has password-protected the project, the OEM receiving the bundle will need the password to open the SCOUT archive. Coordinate this in advance.

Related Documentation References

• SIMOTION SCOUT — Service and Diagnostics manual (entry path: SIMOTION > Engineering > Diagnostics)
• SINAMICS S120 CU320-2 — List Manual, fault and alarm buffer section
• SIMOTION D4x5-2 — Commissioning and Hardware Installation Manual
• IT DIAG configuration in SCOUT project — Programming and Operating Manual