Logging S7-1500 Process Data to CSV and SQL: TIA Portal Guide

Overview

Siemens S7-1500 CPUs include a native DataLog instruction set in TIA Portal that writes structured records to comma-separated value (CSV) files on the SIMATIC Memory Card (SMC). For higher-level historians or relational databases (Microsoft SQL Server, MySQL, PostgreSQL, MariaDB, Oracle), the on-board CSV can be moved off the PLC over the integrated web server, via OPC UA Historical Access, or pushed directly with an ODBC/CSV bridge application running on a PC or edge gateway.

This reference covers the complete engineering workflow: enabling the DataLog function block family (DataLogCreate, DataLogOpen, DataLogWrite, DataLogClose, DataLogDelete, DataLogNewFile), configuring the SIMATIC memory card, exposing the files through the CPU web server, and forwarding the records to an external SQL database. The procedures are valid for S7-1500, S7-1500F, ET 200SP CPU, and the software controller S7-1500S starting with TIA Portal V14 SP1 and CPU firmware V2.0. Subsequent features (such as DataLogNewFile for runtime file rotation) require firmware V2.5 or later.

Prerequisites and Supported Hardware

Confirm the SIMATIC Memory Card is inserted and formatted. If the PLC has been running without a card, perform a memory reset and insert the card before powering up so the S7-1500 can claim the card as boot medium. For projects that require program persistence on card removal, configure the CPU in Card operation mode (CPU properties > Card operation).

Architecture: CSV-on-Card vs. External SQL

Two distinct topologies apply. Engineers should pick the one that matches the historian, retention policy, and network boundary.

Most plants deploy both. The on-card CSV acts as a forensic buffer; the external SQL sink provides queryable, time-indexed history for SCADA, analytics, and regulatory reporting.

Step 1: Configure the SIMATIC Memory Card

1. Open the device view of the S7-1500 CPU in TIA Portal.
2. Select Properties > General > Memory and confirm the card type matches the inserted SMC.
3. Enable the file-system browser access rights under Web server > User management (covered in Step 4).
4. Download the project to the CPU. The DataLog instructions will only execute when the CPU is in RUN and the SMC is present and write-enabled.

Step 2: Create the DataLog in TIA Portal

1. In the project tree, expand Instructions > Extended instructions > Recipe and DataLogging > DataLogging.
2. Drag the DataLogCreate instruction into a new function block (e.g., FB_Datalogger).
3. Declare an instance DB; TIA Portal will create a DataLog reference DB automatically on first download.
4. Wire the inputs as shown in the table below.

On the first rising edge of REQ, the CPU creates a CSV file under /DataLogs/<NAME>.csv on the SMC and returns STATUS = 0. Repeat the call after a power cycle to re-open the same log via DataLogOpen with the matching ID.

Step 3: Program the DataLog Instructions

A typical OB1 cycle (or a time-of-day OB, e.g., OB10, OB30..OB38) chains the instructions as follows:

// FB_Datalogger — instance DB: iDB_DataLog
// 1) Create on first call
IF bFirstRun THEN
  DataLogCreate(REQ := bFirstRun,
    ID := 1,
    NAME := 'BatchLog_2024',
    HEADER := 'Timestamp;Temp_C;Pressure_bar;Flow_lpm',
    RECORDS := 500000,
    DATA := iDB_ProcessData.ProcessData,
    TIMESTAMP := TRUE,
    FORMAT := 16#01,
    STATUS => wCreateStatus);
  bFirstRun := FALSE;
END_IF;

// 2) Write one record per cycle (1 s OB1 or 100 ms OB35)
DataLogWrite(REQ := bWriteTrig,
  ID := 1,
  DATA := iDB_ProcessData.ProcessData,
  STATUS => wWriteStatus);

// 3) Optional: rotate file daily
IF (dtNow > dtNextRollover) THEN
  DataLogNewFile(REQ := TRUE,
    ID := 1,
    NAME := CONCAT('BatchLog_', STRING_FROM_DT(dtNow)),
    STATUS => wNewStatus);
END_IF;

The DATA parameter on DataLogWrite must point to a data area whose byte length matches the original DataLogCreate declaration. Mismatches return STATUS = 16#80C0 (record length error). The maximum data block size for a single record is 512 bytes; bundle small tags into a global DB to keep the layout contiguous and avoid fragmentation faults.

Step 4: Activate the Web Server for CSV Retrieval

1. CPU properties > Web server > check Activate web server on this module.
2. Select Permit access only with HTTPS for production.
3. Under User management, create at least one user with the right Filebrowser — read files. Note: download rights require firmware V2.6+ for HTTPS file access on standard CPUs.
4. Compile and download. Open a browser to https://<CPU-IP> and log in.
5. Navigate to Filebrowser > DataLogs > BatchLog_2024.csv. Right-click → Save target as to download.

Step 5: Push Data to SQL / ODBC Databases

The S7-1500 does not embed an SQL client. To land records into a relational database, choose one of three industrial-grade paths.

5.1 ODBC DataLogger bridge (CSV-flat-file polling)

Many plants have legacy instruments that emit CSV rather than OPC. An ODBC DataLogger plug-in polls the on-card CSV over the web server, transforms each row, and writes it into any ODBC-compliant database (SQL Server, MySQL, PostgreSQL, Oracle, SQLite). Configure the polling interval, the delimiter, and a parameterized INSERT statement. See the TOP Server ODBC DataLogger plug-in reference architecture for an example driver-agnostic bridge.

5.2 OPC UA Historical Access into Ignition, WinCC, iFIX, or PI

1. Enable the S7-1500 OPC UA server (CPU properties > OPC UA > Activate).
2. Create a Historical Access node in the S7-1500 OPC UA address space. The CPU can store up to 10 000 events per HDA node by default (firmware V2.9+).
3. Connect your SCADA / historian. For example, Ignition's OPC-HDA Module reads the HDA nodes and inserts into MySQL/MSSQL using the Store and Forward engine.

5.3 MQTT or REST push from an edge gateway

An industrial edge node (e.g., SIMATIC IOT2050, MIPC, Node-RED on a Click Plus, or any Linux gateway) can curl the CSV from the web server on a schedule, parse it, and POST JSON to an SQL REST endpoint. This is a common pattern for batch evidence where the SQL row is generated only at end-of-batch, not every scan.

Verification and Commissioning

1. Watch the STATUS outputs of every DataLog call in an online watch table. A healthy system shows W#16#0000.
2. Force a DataLogWrite and confirm the SMC file size grows by the configured record length (2 + record bytes).
3. Download the CSV via web server, open in Excel or LibreOffice, and confirm the time-stamp column matches the PLC clock. The default format is YYYY-MM-DD HH:MM:SS.sss in UTC (or local time if the CPU time is set to local).
4. Cycle power and confirm that DataLogOpen reattaches to the same file (STATUS = 0); if it returns 16#80B0, the file does not exist and a fresh DataLogCreate is required.
5. If the SQL path is enabled, confirm the bridge inserts rows by running a SELECT COUNT(*) on the destination table and watching the count increment by the expected polled rows.

Troubleshooting Matrix

Performance and Sizing

DataLog write time scales linearly with record length. A typical 32-byte record on a CPU 1515-2 PN takes ~600 µs to commit. At 100 ms scan, that is well under 1% CPU load. At 1 ms scan with 100-byte records, expect 2-4% CPU load; do not exceed 8 ms scans with large records or scan jitter will dominate.

For ring-buffer behavior, set RECORDS to the desired depth, enable DataLogNewFile on rollover, and archive the closed file to SQL through the bridge. This pattern holds the on-card footprint constant and gives the SQL side a clean, time-bounded batch to ingest.

For high-availability retention, deploy redundant S7-1500R/H CPUs with two SMCs in parallel; the standby CPU also receives DataLog commands if the user program is identical, providing a hot mirror.

Reference: Status Code Summary