KTP1200 Basic Data Logging Stopped: Troubleshooting and Recovery

KTP1200 Basic Data Logging Stopped: Troubleshooting and Recovery

1. System Overview and Scope

The SIMATIC KTP1200 Basic is a 12.1 inch TFT touch panel from the Siemens Basic HMI family. Catalog numbers in active distribution include 6AV2 123-2MB03-0AX0 (current revision) and 6AV2 123-2MA03-0AX0 (legacy revision). Like every Basic Panel, it supports three independent runtime logging channels - data logging, alarm logging, and event logging - that are configured in TIA Portal under WinCC Basic or WinCC Comfort and that write comma-separated records to an external USB storage medium by default.

The most common field complaint on this panel is that a previously working log installation is found with "no historical data" after a site visit, even though the data log has reached multi-megabyte size on the USB stick and the runtime has been restarted. The data is rarely lost; it has either rotated to a different segment that the trend view is not bound to, halted because of a runtime storage error that the operator never saw, or been written to a USB device that the panel no longer recognizes.

This document walks through the logging architecture, the diagnostic procedure that uses the panel's own alarm system, the root cause matrix that maps a symptom to a fix, and a step-by-step recovery sequence with verification checks.

2. Hardware Identification and Firmware Baseline

Before any logging diagnosis, identify the exact catalog number and the runtime image installed on the panel. The catalog number is on the rear label; the runtime version is visible in the panel's service menu (Control Panel > OP > Information) or online in TIA Portal (HMI device diagnostics > General).

Firmware behavior changes between runtime versions. System alarm numbering, write-cycle defaults, and buffer sizes were revised in V16 and again in V17. When comparing notes against the panel's online help, always cite the runtime version that is actually installed rather than the TIA Portal version used to compile the project.

The single USB host port X61 on the rear is the only data logging destination that the panel supports out of the box. Network paths (UNC) became available on most Basic Panels in V16 and remain available in V17, but require an active Ethernet infrastructure and a configured user with write rights on the share.

3. Logging Architecture Deep Dive

WinCC Basic / Comfort exposes three logging objects in the project tree under the HMI device:

• Data logs - process values acquired at a cycle trigger or change-of-value trigger. The runtime appends a timestamped row per record.
• Alarm logs - discrete alarms raised or cleared by the controller (via tag triggers) or by HMI-side bit triggers. Each row records the alarm state transition and the active text.
• Event logs - operator actions such as login, recipe transfer, audit-relevant changes. Available only if "Audit" is enabled in the runtime settings.

Each log object has its own storage location, segment count, and write cycle. They do not share a buffer, so a fault in one channel does not necessarily stop the other two.

When the runtime boots, it enumerates the configured storage locations, opens the active segment of each log, and begins appending. On every write cycle (default 1 s), the runtime flushes the buffered records to the file. A power loss or USB removal between flushes loses the unflushed records - typically up to one write cycle of data.

3.1 Acquisition Triggers

4. Storage Media Requirements

The KTP1200 Basic enumerates USB mass storage devices formatted with FAT32 and MBR partition tables. exFAT, NTFS, and GUID partition tables are not guaranteed to mount on legacy firmware and may produce silent failures even on V17.

• Use industrial-grade SLC or MLC USB sticks with a sustained write throughput of at least 4 MB/s.
• Avoid consumer-grade "high density" NAND that throttles under sustained write - the panel will simply drop records when the buffer overflows.
• Cap the stick at 32 GB for predictable behavior; larger sticks sometimes trigger long mount-time probes that delay the first write cycle after boot.
• Format as FAT32 with 32 KB clusters; this gives a reasonable balance between throughput and file overhead.

5. File System Layout and CSV Format

When the panel mounts the USB stick, the runtime creates the following directory tree at the root of the first detected mass storage device:

\Storage Card USB\
   \Logs\
      DataLog\
         DataLog_001.csv
         DataLog_002.csv
         ...
      AlarmLog\
         AlarmLog_001.csv
         AlarmLog_002.csv
         ...
      SystemLog\
         SystemLog_001.csv
         ...
      AuditLog\   (only if Audit is enabled)

Each CSV segment has a header row that contains the column titles (tag names, state, etc.) and one record per line. The default timestamp format is "yyyy-MM-dd HH:mm:ss.fff". Records are written in chronological order with no internal index; consumers (Excel, pandas, custom scripts) should rely on the file name suffix to identify the rotation order rather than re-reading the timestamps.

The segment naming convention is fixed: DataLog_NNN.csv, where NNN is a zero-padded ordinal starting at 001. When the runtime rotates to a new segment, it increments the ordinal and resets the file. The runtime never deletes older segments automatically - archiving is the operator's responsibility unless a network share is used.

5.1 File Size and Rotation

The FAT32 file system caps any single file at 4 294 967 295 bytes (4 GB minus 1 byte). The runtime caps the practical size far below that, because the Basic Panel's write buffer is sized for moderate data rates. With a default 1 s write cycle and a typical 16 tag data log, a single segment grows at roughly 30 KB per minute - a 100 MB segment covers approximately 55 hours of continuous logging. Most production installations set the segment size to a date-based rollover (daily or weekly) rather than a size threshold, because date-based rotation maps directly onto operational shifts and external ETL jobs.

6. Failure Symptom Taxonomy

From field experience, the "data has gone missing" symptom on the KTP1200 Basic reduces to one of the following fault classes. The triage question to ask first is always: "is the USB stick still mounted, and is the latest CSV segment timestamp recent?"

1. Segment rotation: the data is intact but lives in DataLog_002.csv; the trend view or alarm view on the panel is bound to DataLog_001.csv. This is the most common root cause when the data log had grown to 14 MB before disappearing.
2. Silent storage fault: the USB stick was ejected, write-protected, or replaced; the runtime logs a system alarm and stops appending. The CSV files on the stick remain readable but stop growing.
3. Full disk: the stick ran out of space because rotation was disabled and no segments were being archived. The runtime stops writing and raises a system alarm.
4. Mount failure: the stick is incompatible (exFAT, NTFS, GUID, defective NAND). The runtime never opens any segment and the Logs directory is empty.
5. Project invalidation: a partial project transfer left the log configuration pointing to a deleted tag or a storage path that no longer resolves.

7. System Alarm Diagnosis

Every logging-related fault on the KTP1200 Basic is reported as a system alarm on the configured system alarm class. By default, system alarms of class "Errors" flash in the system alarm line at the bottom of the active screen and disappear after a few seconds - the default display time is 5 s, the maximum is 255 s. Without a screen object bound to the system alarm buffer, the operator never sees the underlying cause; the panel looks perfectly healthy until somebody notices that the trend view is empty.

7.1 Add a Persistent Alarm View

To capture system alarms for diagnosis, add a dedicated alarm view to a maintenance or service screen:

1. In TIA Portal, open the project and navigate to "Screens" under the HMI device.
2. Insert a new screen (or edit an existing service screen) reserved for diagnostics.
3. Drag an "Alarm view" object from the toolbox onto the screen and size it to fill most of the screen area.
4. In the Alarm view properties, set "Display" to "Buffered" rather than "Pending". Buffered alarms persist beyond the configured acknowledgment timeout and provide a scrollable history.
5. Set the "Filter" property to allow only the alarm class "System, Errors". Optionally also enable "System, Warnings" for early visibility of marginal storage conditions.
6. Compile the project, transfer it to the panel, and trigger a test write by cycling power.

After transfer, the new alarm view will retain a scrollable history of system alarms until the buffer is full or the project is re-transferred. This single change resolves most field cases because the root cause is finally visible.

7.2 System Alarm Reference for Logging

The exact alarm numbers depend on the installed runtime version. Cross-reference the text shown on the panel against the WinCC Basic / Comfort online help for the project revision. The following mapping is representative for V16 and V17:

7.3 Raise the Display Timeout

The pending alarms view shows each entry for the configured "Display duration" in seconds. The maximum is 255 s. If the value is left at the default (5 s), a system alarm that fires during a quick operator task may be missed entirely. In Runtime settings > Alarm buffer, raise the display duration toward 60 - 120 s for production panels. To retain alarms beyond 255 s, use the buffered view as described above.

8. Root Cause Analysis Matrix

The following matrix maps the most common observed symptoms to their most likely cause, a verification step, and a remediation. Use it as a triage table when arriving on site.

9. Step-by-Step Recovery Procedure

Use this procedure when a previously logging KTP1200 Basic suddenly stops recording. The procedure is designed to be safe to run on a live panel without disturbing the process.

Step 1 - Capture system alarms without modifying the project

1. Connect the engineering PC to the panel's Ethernet port (X1) and start TIA Portal with the same project version that is loaded on the panel.
2. Select the HMI device and choose "Online > Go online".
3. Open the "Diagnostics" folder in the project tree.
4. Browse "Runtime alarms" and read the alarm buffer. Note any system alarms whose timestamp coincides with the moment the data went missing.

This step is non-invasive - it does not stop logging, does not require a download, and can be performed while the process is running.

Step 2 - Power down and inspect the USB stick on a PC

1. Inform the operator that the panel will reboot in approximately 30 seconds. HMI-side logging resumes automatically after boot.
2. Power the panel down using the system-standard shutdown sequence.
3. Remove the USB stick. Do not pull it while the panel is running.
4. Insert the USB stick into a Windows PC.
5. Navigate to \Storage Card USB\Logs\.
6. For each log, verify the file timestamps. If the latest write timestamp is before the moment the user noticed the missing data, logging halted - return to the system alarms from Step 1.
7. If timestamps look correct, the issue is most likely on the view side: a trend or table bound to a stale segment name.

Step 3 - Validate storage medium health

1. Open a Windows command prompt as Administrator.
2. Run chkdsk E: /f where E: is the USB stick's drive letter.
3. Confirm the file system is FAT32 with MBR partition table. Right-click the drive in Explorer > Properties > File system.
4. Confirm less than 50 percent of the device is in use. Heavy fragmentation increases write latency and can cause the runtime to skip a cycle.

Step 4 - Adjust the project

1. In TIA Portal, open the HMI device configuration.
2. Navigate to "Runtime settings > Logs".
3. Set "Number of files" to 4 or higher to allow rotation without operator intervention.
4. Set "Trigger for file change" to "Date" with a daily rollover for predictable archiving.
5. Set "Storage location" to a UNC network path such as \\Server\Share\KTP1200\Logs for a permanent solution, or keep USB but increase redundancy and add an alarm view bound to system alarms.
6. Enable "Write buffer" so that a transient USB loss does not lose data.
7. In "Alarm buffer", raise "Number of buffered alarms" toward 1024 (typical maximum for Basic Panels) for a longer diagnostic window.

Step 5 - Re-download and verify

1. Compile the project. Resolve any tag or warning errors - these typically surface as yellow triangles on the HMI device icon.
2. Download to the panel using "Online > Download to device > Software (complete)". A complete transfer re-creates the runtime configuration from scratch and is safer than a delta transfer when logging paths have changed.
3. The runtime will create a fresh log segment on the next mount.
4. Trigger a test data point - write a known value to a tag bound to the data log - and confirm it appears in the new CSV within one write cycle (default 1 s).
5. Verify that the system alarm view (added in Step 1) does not show "Errors" class entries during a 10 minute soak test.

10. Preventive Configuration

For installations where historical data is required to outlive a single USB stick, configure the panel as follows:

• Switch the storage location to a network share. Basic Panels support UNC paths via the "Storage location" parameter in V16 and later; provide credentials through the project if the share is authenticated.
• Configure at least 4 segments per log so that a single corrupted segment does not invalidate the entire history.
• Add an alarm view on the main screen bound to "System, Errors" so the operator sees storage faults the moment they occur rather than discovering them during the next shift handover.
• Set the write cycle to 1 s. Lower values (such as 500 ms) saturate the USB throughput on a busy data log and produce dropped records; higher values (such as 10 s) lose more data on power loss.
• Enable the option "Write log on power fail" if it is available in the runtime. The runtime flushes the buffer to non-volatile storage before shutdown.
• Schedule a monthly task on the engineering PC to archive USB contents to a network share. Even on USB-only installations, a rotating archive prevents data loss when a stick fails.

11. Performance and Throughput Tuning

The Basic Panel's USB stack and the runtime's write buffer together set the upper bound on sustainable logging throughput. With a single data log of 16 tags on a 1 s cycle, the runtime writes roughly 30 KB per minute to the USB stick. This is well within the capability of any industrial-grade USB device. The runtime starts dropping records when the buffer overflows because the storage medium cannot keep up.

Symptoms of buffer overflow:

• System alarm "Buffer overflow during write" appears repeatedly.
• CSV timestamps on the panel's USB jump forward in irregular steps.
• Trend view on the panel shows jagged gaps rather than smooth lines.

Remediation options:

1. Reduce the number of tags in the data log.
2. Switch the acquisition trigger from cyclic to change-of-value where applicable.
3. Increase the write cycle from 1 s to 5 s; this raises the buffer ceiling at the cost of finer time resolution.
4. Replace the USB stick with a higher-throughput industrial part (SLC NAND, USB 3.0 backward-compatible).
5. Move the storage location to a network share to remove the USB throughput ceiling.

12. Migration and Long-Term Archiving

When the panel is upgraded from TIA Portal V13 to V17, recompile and download the full project. Partial conversions can leave logging paths pointing to invalid runtime symbols, which surface at first boot as system alarms in the 900000 range. After a major version upgrade, always perform a complete transfer rather than a delta.

For installations where the data log must be retained for several years (regulatory compliance, batch traceability), a simple and reliable pipeline is:

1. Panel writes CSV segments to a network share with daily rotation.
2. A Windows scheduled task on the share host appends each new segment to a SQL Server table using a small Python or PowerShell script.
3. A separate report queries SQL Server for trend and alarm history without ever reading the panel's USB stick.

This pipeline makes the panel's storage medium a transient cache rather than the source of truth, and makes the "missing historical data" class of complaint impossible.

13. Verification Checklist

Confirm the following after applying the recovery steps. Tick each box before handing the panel back to operations.

• [ ] No "System, Errors" alarms in the buffered alarm view for 24 hours of normal operation.
• [ ] New CSV segment opens at the configured rollover time (midnight if daily, or at the configured time offset).
• [ ] Trend view on the process screen shows current data and historical data extending back to the segment start.
• [ ] USB stick free space remains above 25 percent across one full rotation cycle.
• [ ] WinCC project documentation lists the active log paths and retention policy.
• [ ] A maintenance screen with a buffered alarm view bound to "System, Errors" is visible from the main screen.
• [ ] The write cycle and segment count match the throughput profile of the process.
• [ ] A backup of the current project is stored on the engineering PC and on a network share.

14. Frequently Asked Questions