S7-1200 DataLogWrite Status 0001: Resolving Full Log Detection

1. S7-1200 DataLog System Architecture Overview

The SIMATIC S7-1200 DataLog mechanism stores structured process records on a Siemens SMC (SIMATIC Memory Card) inserted in the CPU. Each DataLog is a binary file written under /DataLog/ on the SD card, indexed by an internal DWORD identifier returned by DataLogCreate. A typical deployment in TIA Portal V15 targets a CPU firmware V4.x class controller (S7-1211C through S7-1215C and S7-1217C), where the DataLog instruction set is implemented as multi-instance-capable FBs inside the Program blocks > System blocks > Extended instructions > Data log library.

Records are appended sequentially, and once the configured RECORDS maximum is reached the system is required to signal a full condition through the STATUS output of DataLogWrite. The full-condition code is the well-known 16-bit value 0001 (W#16#0001). When this code is missing, the most common user-visible symptom is silent overwrite of the oldest record without an error being latched into the application code, which defeats the very purpose of bound logging in regulated or audited processes.

The DataLog family consists of six instructions:

• DataLogCreate – Allocates a new .csv/.bin file and binds it to a DWORD ID.
• DataLogOpen – Re-opens an existing log so DataLogWrite can resume.
• DataLogWrite – Appends a single record (variant).
• DataLogClose – Flushes buffers and releases the file handle.
• DataLogNewFile – Closes the current file and creates a new one with the same name pattern (timestamped) once the old one is full.
• DataLogDelete – Removes a file from the SD card.

All instructions use a single-instance DB (or multi-instance inside an FB) and the standard REQ / BUSY / DONE / ERROR / STATUS execution model that is consistent with all S7-1200 asynchronous system FBs.

2. DataLog Instruction Set Reference (TIA Portal V15)

The instruction set is part of the Extended Instructions palette. Each instruction is added to a code block by dragging from the right-hand task card, after which TIA Portal automatically instantiates the multi-instance DB or lets the engineer wire a separate instance DB. The CALL signature is identical for LAD, FBD, and SCL.

The instruction set and corresponding DB family (default names in parentheses):

All instructions are classified as asynchronous in the S7-1200 system manual because the actual write to the SD card happens in a background task and the FB may require multiple OB1 scans to complete. A rising edge on REQ launches the job, and BUSY stays TRUE until DONE or ERROR is reported.

3. DataLogCreate Parameter Reference

The DataLogCreate block defines the size, format, and identity of the data log. Every parameter below is required to obtain deterministic full-file behavior. TIA Portal V15 exposes these parameters in the block interface and the F1 help contains the authoritative description.

To prevent silent recreation, the application must:

1. Call DataLogCreate once at first-run, gated by a persistent bit (retain tag, DB bit, or check DataLogOpen success first).
2. Store the ID in a retentive tag so it survives power-cycle.
3. Only create a new file if DataLogOpen returns 0007 (file does not exist) or after DataLogNewFile closes the current segment.

4. DataLogWrite Parameter Reference and Status Code Map

DataLogWrite is invoked once per record. The RECORD input is a VARIANT pointing to a STRUCT or DB whose layout must match the data declared at creation time. A mismatch causes status 000A (header does not match).

4.1 DataLogWrite Status Code Map

The complete 16-bit STATUS word returned by DataLogWrite in TIA Portal V15 / CPU firmware V4.x is summarized below. Always cross-check the F1 help of the local TIA Portal installation for the exact firmware you compile against.

5. Root Cause: Why Status 0001 Is Not Returned

The reported symptom — “log silently overwrites the existing records and never reports 0001” — has four field-observed root causes, ranked by frequency in TIA V15 / CPU firmware V4.x deployments.

5.1 Root Cause A — Repeated DataLogCreate Calls

If the OB1 calls DataLogCreate on every cycle (or every scan after a power-up), the call deletes the existing file and creates a new one with zero records. The RECORDS ceiling is therefore never reached, and status 0001 is never produced because the file is “full” only relative to a single OB1 scan, which never contains more than one record write.

Diagnostic: Monitor the DataLogCreate.DONE pulse with a counter. If the counter increments while the log is supposed to be filling, the program is recreating the log.

5.2 Root Cause B — DataLogNewFile in the Wrong Place

DataLogNewFile closes the current log and immediately allocates a new sequenced file. If this FB is triggered every time a full condition is detected but is triggered from a rung that does not confirm 0001, the log is rotated prematurely and never reaches RECORDS.

5.3 Root Cause C — RECORDS Set to Zero or Negative

Although TIA Portal normally validates the input at compile time, a runtime-loaded RECORDS from an HMI tag can pass zero. With RECORDS = 0, the firmware either treats the file as immediately full and never accepts a write (no overwrite), or in early V4.x firmware truncates the existing file. The resulting behavior is platform-dependent and frequently misinterpreted as “overwrite”.

5.4 Root Cause D — Instance-DB Re-Initialization at Restart

If the instance DB for DataLogCreate is not marked non-retain with initial values > retained ID, the firmware recreates the DB on restart, losing the stored ID and forcing the next DataLogWrite to fail with 0002. A fall-back rung in the user program then re-issues DataLogCreate, deleting the file (Root Cause A).

All four causes funnel into the same observable symptom: the log never holds more than 0 – 1 records and 0001 is never produced. The fix is to enforce the lifecycle described in Section 6.

6. Step-by-Step Resolution Procedure

1. Open the TIA Portal V15 project containing the affected S7-1200 station. Verify the CPU is online and that the project on the engineering station matches the running firmware (right-click CPU → Online & diagnostics → Firmware).
2. Locate the DataLogCreate call in the OB1 or the data-log management FB. Use Project tree → Program blocks → search → "DataLogCreate" if it is not in OB1 directly.
3. Read the F1 help for the DataLogCreate block. Confirm the RECORDS, NAME, FORMAT, and TIMESTAMP inputs and note any “Behavior on full” parameter that is specific to the firmware in use.
4. Move DataLogCreate out of the cyclic path. The create call should fire only on first-run, on a user command, or on a detected 0002 / 0007 status from DataLogOpen. Wrap the call in an IF guarded by a retentive "Log_Created" BOOL.
5. Add a retentive DataLogID tag (DWORD, located in a retain-enabled DB) and pass this to every DataLog call. Initialize it with 16#0 — the firmware treats zero as “no valid ID”.
6. Add full-detection logic in the same FB that calls DataLogWrite: IF "DataLogWrite_DB".STATUS = 16#0001 AND NOT "DataLogWrite_DB".BUSY THEN "Log_Full" := TRUE; END_IF;
7. Implement the rotation: when Log_Full is set, call DataLogClose; on its DONE pulse, call DataLogNewFile and assign the new ID back to the retentive tag. Reset Log_Full after the new file is opened.
8. Compile and download the project (Stop CPU → Download → Run). Clear the SD card first if you want a known clean state.
9. Force a fill by writing more than RECORDS from a watch table and confirm that STATUS = 16#0001 is now latched into Log_Full.
10. Verify the rotation by checking the SMC /DataLog/ folder via Web Server → File browser or by removing the SMC and reading it on a PC. The sequenced file should appear with the timestamp appended.

7. Working SCL Sample Code with Full Detection

The following SCL code is a self-contained FB that demonstrates the correct lifecycle. Drop it into Program blocks > Add new block > Function block, declare the variables as shown, and call it from OB1 with a one-second Cyclic_Trigger BOOL from a TON timer.

FUNCTION_BLOCK "DataLogManager"
{ S7_Optimized_Access := 'TRUE' }
VERSION : 0.1
   VAR_INPUT
      Cyclic_Trigger : BOOL;   // 1 Hz pulse
      Record : "typeProcessRecord";  // user record struct
   END_VAR
   VAR_OUTPUT
      Log_Full : BOOL;
      Last_Status : WORD;
   END_VAR
   VAR RETAIN
      ID : DWORD;             // 0 = no valid handle
      Log_Created : BOOL;
   END_VAR
   VAR
      Create_DB   : "DatalogCreate";
      Open_DB     : "DatalogOpen";
      Write_DB    : "DatalogWrite";
      Close_DB    : "DatalogClose";
      NewFile_DB  : "DatalogNewFile";
      Step : INT;             // state machine 0..6
      Rotate : BOOL;
   END_VAR

BEGIN
   // ---- Step 0: try to open existing log ----
   IF Step = 0 AND Cyclic_Trigger THEN
      "DatalogOpen_DB"(REQ := TRUE,
                        MODE := 0,
                        NAME := 'ProcessLog',
                        ID := ID,
                        DONE => Open_DB.DONE,
                        BUSY => Open_DB.BUSY,
                        ERROR => Open_DB.ERROR,
                        STATUS => Open_DB.STATUS);
      IF Open_DB.DONE AND Open_DB.STATUS = 16#0000 THEN
         Step := 2;          // jump to write
      ELSIF Open_DB.DONE AND Open_DB.STATUS = 16#0007 THEN
         Step := 1;          // need to create
      ELSIF Open_DB.DONE AND Open_DB.ERROR THEN
         Last_Status := Open_DB.STATUS;
         Step := 99;         // diagnose
      END_IF;
   END_IF;

   // ---- Step 1: create new log ----
   IF Step = 1 AND NOT Create_DB.BUSY THEN
      "DatalogCreate_DB"(REQ := TRUE,
                          RECORDS := 1000,
                          FORMAT  := 1,
                          TIMESTAMP := 2,
                          NAME    := 'ProcessLog',
                          ID      := ID,
                          DONE    => Create_DB.DONE,
                          BUSY    => Create_DB.BUSY,
                          ERROR   => Create_DB.ERROR,
                          STATUS  => Create_DB.STATUS);
      IF Create_DB.DONE AND Create_DB.STATUS = 16#0000 THEN
         Log_Created := TRUE;
         Step := 2;
      ELSIF Create_DB.DONE AND Create_DB.ERROR THEN
         Last_Status := Create_DB.STATUS;
         Step := 99;
      END_IF;
   END_IF;

   // ---- Step 2: write one record ----
   IF Step = 2 AND Cyclic_Trigger AND NOT Write_DB.BUSY THEN
      "DatalogWrite_DB"(REQ := TRUE,
                         ID := ID,
                         RECORD := Record,
                         DONE => Write_DB.DONE,
                         BUSY => Write_DB.BUSY,
                         ERROR => Write_DB.ERROR,
                         STATUS => Write_DB.STATUS);
      IF Write_DB.DONE THEN
         Last_Status := Write_DB.STATUS;
         IF Write_DB.STATUS = 16#0001 THEN
            Log_Full := TRUE;
            Step := 3;       // rotate
         ELSIF Write_DB.STATUS <> 16#0000 THEN
            Step := 99;      // diagnose
         END_IF;
      END_IF;
   END_IF;

   // ---- Step 3: close + new file ----
   IF Step = 3 AND NOT Close_DB.BUSY THEN
      "DatalogClose_DB"(REQ := TRUE,
                         ID := ID,
                         DONE => Close_DB.DONE,
                         BUSY => Close_DB.BUSY,
                         ERROR => Close_DB.ERROR,
                         STATUS => Close_DB.STATUS);
      IF Close_DB.DONE AND NOT Close_DB.ERROR THEN
         Step := 4;
      ELSIF Close_DB.DONE AND Close_DB.ERROR THEN
         Last_Status := Close_DB.STATUS;
         Step := 99;
      END_IF;
   END_IF;

   IF Step = 4 AND NOT NewFile_DB.BUSY THEN
      "DatalogNewFile_DB"(REQ := TRUE,
                           ID := ID,
                           DONE => NewFile_DB.DONE,
                           BUSY => NewFile_DB.BUSY,
                           ERROR => NewFile_DB.ERROR,
                           STATUS => NewFile_DB.STATUS);
      IF NewFile_DB.DONE AND NOT NewFile_DB.ERROR THEN
         Log_Full := FALSE;
         Step := 2;          // resume writes
      ELSIF NewFile_DB.DONE AND NewFile_DB.ERROR THEN
         Last_Status := NewFile_DB.STATUS;
         Step := 99;
      END_IF;
   END_IF;

   // ---- Step 99: error diagnosis, requires operator intervention ----
   IF Step = 99 THEN
      // Hold last status; operator must clear via HMI reset
   END_IF;
END_FUNCTION_BLOCK

7.1 State Machine Diagram

8. Verification and Commissioning Tests

After the fix is downloaded, perform the following sequence to confirm deterministic behavior:

1. Reset the SD card. Use the Web Server to delete any existing ProcessLog files, or remove the SMC and re-format it with the S7-1200 CPU (online → Functions → Format memory card).
2. Force a low RECORDS value (e.g. RECORDS = 5) so the test runs in seconds rather than hours.
3. Trigger 6 writes from a watch table or test FB. The 6th write must report STATUS = 16#0001 with ERROR = FALSE.
4. Observe the state machine. Step must transition 0 → 1 (create) → 2 (write) → 3 (close) → 4 (new file) → 2 (write resumes).
5. Inspect the SMC via Web Server. The number of files under /DataLog/ should grow by one for each rotation.
6. Cycle power. After restart, Step should remain at 2 because the retentive ID is preserved and the existing log is opened rather than recreated.

9. Troubleshooting Matrix

10. Best Practices for Production Deployments

• Use Siemens SMC only. Article numbers 6ES7954-8LF02-0AA0 (4 MB), 6ES7954-8LE02-0AA0 (12 MB), 6ES7954-8LL02-0AA0 (24 MB) are validated for DataLog. Counterfeit cards are the #1 cause of 0003 errors in the field.
• Pick CSV (FORMAT = 1) unless binary size is critical. CSV files are human-readable and can be analysed in Excel or with the S7-1200 Web Server. Internal binary (FORMAT = 0) is faster but requires the TIA Portal DataLog viewer for analysis.
• Bound the record size. Each record has a fixed 12-byte overhead plus the size of the user struct. A struct larger than 256 bytes causes measurable OB1 jitter.
• Throttle writes to ≥ 100 ms. The SD card wear-leveling expects this. Writes faster than 10 ms will hit 80C0.
• Always use a state machine. Cyclic calls to DataLogCreate are a leading cause of silent data loss. Drive the create open write close new file sequence from a single FB with a Step integer.
• Monitor SMC health with RD_SINFO and the GetSMCInfo user library. Replace cards at 80 % of the rated write cycles.
• Enable the Web Server for diagnostics. Without it, the only way to inspect the SD card is to remove it and read it on a PC, which is impractical in a running plant.
• Log the Last_Status tag to the HMI so operators can see why a log rotation failed.

11. Firmware and TIA Portal Version Notes

The DataLog instruction set has been functionally stable since firmware V4.1. Applications written against V15 will recompile and run unchanged in V16 / V17 provided the S7-1200 CPU is updated in lockstep with the TIA Portal version used to compile. The status code 0001 has had the same meaning — data log full, record rejected — across all these versions, which is the contract the user program can rely on.

12. Diagnostic Procedure Flowchart

The flowchart above is the fastest path to isolate which of the four root causes in Section 5 is active. In production, it is worth running this against any S7-1200 DataLog program during the commissioning FAT.