Troubleshooting Retrieving S7-1500 Trace Data Without TIA Portal

Overview: The Trace Data Lock-In Problem

The SIMATIC S7-1500 trace function (and the equivalent trace object on the S7-1200 G2 controller) records cyclic CPU signals against a configurable trigger, sampling tag values, edge counters, and computed expressions into an internal ring buffer. By default, that measurement buffer is exposed only inside the TIA Portal project tree (Project Navigation → Traces → <trace_name> → Measurement) and cannot be opened as a standalone file format (.csv, .csvz, .xml) by any third-party tooling.

Siemens' official documentation states that the trace measurement data is available only within the TIA Portal project and is not available for processing by other tools (see the SIMATIC S7-1200 G2 Tracing and Recording CPU Data entry in the Fail-Safe Modules Manual Collection). This forces every engineer who needs to perform post-mortem diagnostics on a machine that does not have TIA installed to either install the engineering suite or build a side-channel data acquisition path. The remainder of this reference covers the supported, semi-supported, and field-proven workarounds for that scenario, including the constraints, register/parameter settings, and verification steps required for each path.

Prerequisites and Required Firmware

Workarounds below assume an S7-1500 CPU (or ET 200SP CPU, S7-1500 Software Controller) with the minimum firmware levels shown in the table. Trace functionality and the web server page structure have evolved across firmware versions; verify the CPU's firmware before committing to a method.

Method 1: Web Server Memory-Card Storage + Session Scraping

The only Siemens-shipped path that gives you a persistent, *file-system* copy of a trace is the combination of "Save trace to memory card" (configured in the trace object properties under Recording → Storage) plus the CPU's integrated web server. Once both are configured and a recording has completed, the trace is stored in the binary file /card/user/sinumerik/.../trace/ on the SIMATIC memory card and mirrored in the web server's diagnostic pages.

1. Enable the web server in TIA Portal: Properties → CPU → Web server → Activate web server on this module. Set a username/password and the access level to Diagnostics or higher. The minimum access level for trace viewing is Diagnostics; writing trace configurations via the web requires Administration (HMI access level 1+).
2. In the trace configuration, open Properties → Recording → Storage location and select Memory card (CPU storage). Set the maximum number of recordings to retain (1-10) and the recording mode (single, cyclic, or appending).
3. Trigger the recording from a test function or a real process event. After the recording is complete, the trace appears at the bottom of the web server navigation under Diagnostics → Trace.
4. Browse to http://<cpu-ip>/Portal/Portal.mwsl?Pri=diag&trc=1 (or the equivalent /Trace/Trace_1 URL exposed by the firmware). Use a headless browser to capture the rendered DOM. Chromium-based tools (Puppeteer, Playwright, Selenium) handle the JavaScript-rendered chart automatically.
5. Parse the JSON record embedded in the page source. The S7-1500 web server typically renders the trace as a structured object under a key such as window.s7TraceData or a WebSocket subscription; inspect the page in DevTools first to confirm the key, then extract.
6. Write the resulting array to a .csv with one column per signal and a ts_ms time column derived from the trace's sample period.

Verification (Web Server Method)

After the recording has been triggered and the trace is complete:

• Confirm the trace is present via the web UI: Diagnostics → Trace → <trace_name> should show a non-empty chart.
• Confirm the memory card file exists by logging into the CPU via SFTP/FTP (CPU FW 2.6+) or by exporting the trace from the SD card reader in TIA Portal — the binary file should match the SHA-256 hash shown in the web UI's Properties dialog.
• Cross-check the first and last sample values against the live tag values in the HMI to confirm the time base is correct.

Method 2: DataLog File-Based Logging (Closest Native Substitute)

If you control the program (rather than the diagnostic environment), the cleanest alternative to a TIA trace is a DataLog. A DataLog writes a cyclic set of tag values to a .csv-style binary file on the memory card that any PC application can read directly. It does not require the CPU to be online with TIA at all — the file is accessible by removing the memory card or by mounting the card over the web server's file browser (CPU FW 2.6+).

1. Insert a DataLogCreate instruction in the program. The REQ input should pulse on first scan or on a restart event. The NAME parameter is the file name (e.g., 'MOTOR_RAIL_LOG'); ID must be a unique handle per data log.
2. Define the data structure: DataLogCreate accepts an RECORD input of type _DLOG_DATA with up to 254 elements. Each element is a tag name, data type, and a column header string. Use a PLC data type (UDT) for repeatability.
3. Call DataLogWrite on the cyclic task (e.g., the same OB1 cycle the trace would have sampled at). Set WRITE_LEN to the number of records per write, typically 1.
4. Trigger the data log to close on a fault: DataLogClose is called from an error OB, a watchdog trigger, or a manual HMI button.
5. Read the resulting file from the memory card. The file is located at /DataLogs/<NAME>.csv on the SIMATIC memory card and is plain ASCII/UTF-8.

DataLog Parameter Reference

Method 3: Open User Communication (OUC) Streaming via TCP

When the data is required *in real time* on a PC that has no TIA Portal, Open User Communication (OUC) on the S7-1500 side plus a lightweight TCP listener on the PC is the most flexible path. OUC supports TCP, UDP, and ISO-on-TCP. For periodic encoder or signal data, TCP with a fixed receive buffer is the simplest protocol to implement on both ends.

1. Configure the TSEND_C instruction in the program. Set CONNECT to a TCON_Param variant populated with the PC's IP address, remote port (e.g., 2500), and the local connection ID.
2. On the PC, open a TCP listener — for example a Python socket.socket(socket.AF_INET, socket.SOCK_STREAM) bound to 0.0.0.0:2500. Accept the connection and read frames until EOF or a sentinel.
3. Use a pre-agreed framing protocol. A 4-byte little-endian length prefix followed by the payload is robust and easy to parse in any language. The S7-side sender packages the data into a fixed layout: LEN (4 bytes) | TIMESTAMP (8 bytes, ms since CPU start) | SIGNAL_0 (4 bytes) | SIGNAL_1 (4 bytes) | ... | CRC16 (2 bytes).
4. On the S7 side, send the data from a cyclic OB (OB30 at 100 ms is a common choice for fault diagnostics). Be aware of cycle-time impact: each TSEND_C call is non-blocking when CONT=1 and will reuse the same connection for subsequent sends.
5. On the PC, write received frames to a SQLite database or a flat file. SQLite is preferred for fast query over long recordings: CREATE TABLE samples (ts_ms INTEGER, s0 REAL, s1 REAL, ...);

Sample SCL Snippet (OUC Sender)

// S7-1500 SCL: send a fixed-layout frame on a 100 ms cyclic task
#iTSendBusy := FALSE;
IF #tCON.Established THEN
    "dataBlock".frame := #iLengthPrefix + #iTimestamp + "dataBlock".signals;
    TSEND_C(
        REQ := TRUE,
        CONT := TRUE,
        LEN := "dataBlock".frameLength,
        DATA := "dataBlock".frame,
        CONNECT := "dataBlock".connection,
        BUSY => #iTSendBusy,
        DONE => #iTSendDone,
        ERROR => #iTSendError,
        STATUS => #iTSendStatus
    );
END_IF;

Verification (OUC)

• Confirm the TCP socket is open: ss -tnp | grep 2500 on the PC.
• Confirm the S7 connection is established in Online & Diagnostics → Diagnostics → Connection statistics; the TSEND_C.STATUS should report 0x0000.
• Confirm the sample rate matches the cyclic OB period: 100 ms of data should produce exactly 10 samples per second per signal; verify with a one-minute test recording and a histogram of the deltas.

Method 4: OPC UA Subscribe-and-Dump

The S7-1500 OPC UA server (FW 1.7+ ships a Compact server on most CPU variants, FW 2.5+ ships the full server) exposes the same tags that the trace would sample. Any OPC UA client — open62541, Prosys, the open-source asyncua Python library — can subscribe to the tags, store the values in a local database, and emulate the trace's behavior without the trace object at all.

1. Activate the OPC UA server in TIA Portal: Properties → CPU → OPC UA → Activate OPC UA Server. Set the security policy (None is acceptable for a local diagnostic VLAN; Basic128Rsa15 or Basic256Sha256 is required for production).
2. Apply the PLC tag access rights so the required tags are readable. Drag the tags to the OPC UA Server Interface list in the project tree.
3. On the PC, install an OPC UA client. The Python library asyncua is the lowest-friction option; the C# OPC Foundation SDK is the highest-performance option.
4. Subscribe to the tag set with a publishing interval of 100 ms (or the same sample period the trace would have used). Set monitoredItemCount to the number of signals. Store each notification tuple in a local file.
5. At the end of the recording session, dump the file to a .csv. The CSV layout will match the structure used by the trace's Export → CSV menu in TIA Portal, allowing downstream tools that expect a TIA-trace format to read the file with no further conversion.

Method Comparison Matrix

Workaround Matrix for the "Trace Only in TIA" Constraint

Limitations, Edge Cases, and Safety

• Web server session lifetime: TIA Portal logs the web user out after 15 minutes of inactivity by default. Headless browser scripts must keep the session alive (poll a non-mutating endpoint every < 15 min) or re-authenticate before each scrape.
• Memory card wear: Cyclic DataLog writes on a 10 ms task will wear out consumer-grade SD cards in weeks. Specify a Siemens SIMATIC Memory Card (S7-1500 ships 24 MB and up) and use a Write-protected setting if the application is read-only.
• Time stamping consistency: The S7-1500 internal time is the CPU clock; for cross-controller correlation, use the Time synchronization function (NTP) and a 1 ms-resolution time source. Avoid the legacy "Time-of-day" tags from S7-300/400 era code.
• OPC UA security: Never ship a production CPU with the Security Policy: None setting; the field workarounds above are for diagnostic VLANs. Force Basic256Sha256 and an X.509 cert signed by a CA that the PC client trusts.
• Fail-safe interaction: If the trace is configured on a F-CPU (e.g., S7-1516F), the web server is read-only on safety tags and the trace cannot include F-related DBs without an F-authorized user. Plan a separate F-tag access concept before any of the methods above.

Field Commissioning Checklist

1. Confirm CPU firmware is on the supported list for the chosen method (see Prerequisites table).
2. Confirm web server is reachable from the diagnostic laptop: ping <cpu-ip> and curl -k -u user:pwd https://<cpu-ip>/ should return HTTP 200.
3. Trigger a known process event; confirm one full recording cycle completes without a 0x0001 STATUS report on the trace object.
4. Run the export script; confirm the first and last sample match a live reading from the HMI to within one sample period.
5. Document the file naming convention and the retention policy in the project's Functional Specification so a future engineer does not have to repeat this discovery.

FAQ