Resolving Siemens Multi Panel LogTag Failures in WinCC Flexible

Problem Description: LogTag Intermittent Failure on Siemens Multi Panel

A SIMATIC Multi Panel (MP277, MP377, Comfort Panel, or Mobile Panel) configured with a CSV datalog in WinCC flexible / TIA Portal WinCC drops entries when the application uses the LogTag function together with a Cyclic acquisition mode on the logged tags. The symptom reported in the field is reproducible:

• Tags declared with Acquisition mode: Cyclic, 1 s and a one-second trigger pulse from the PLC (M100.0) attached to LogTag.
• First power-up: the datalog file is created on the SD card and rows are appended correctly.
• Power-off, power-on without deleting the log folder: the file is no longer appended; LogTag is not visible in the data record.
• Delete the log folder on the SD card, then power cycle: logging resumes until the next restart.

The behavior is independent of PLC scan time, tag class, or number of variables. It is a configuration conflict between two valid runtime features in WinCC — the polling/cyclic acquisition model and the event-driven LogTag model. Running both at once corrupts the trigger semantics of the datalog buffer.

Siemens HMI Datalogging Architecture Overview

Every Siemens Comfort / Multi Panel runs a datalogging engine inside the WinCC flexible runtime. The runtime reads tag values from the PLC over the configured bus (PROFINET, PROFIBUS, MPI, or EtherNet/IP) and stores them in a circular buffer per datalog. The buffer is then flushed to a file on the storage medium (internal flash, multi-media card, or USB) at a flush threshold or on operator action.

The relevant constraint for the LogTag failure is the acquisition mode field of the HMI tag. WinCC distinguishes three acquisition strategies, and the choice of strategy must match the trigger strategy in the datalog function call.

Acquisition Modes: Cyclic vs. On Demand vs. On Change

Open HMI tags → select tag → Properties → Acquisition mode. The dropdown exposes the following options that govern how the runtime samples the PLC address.

For event-driven logging the only mode that delivers deterministic one-record-per-event semantics is On demand. Cyclic and On change both populate the buffer independently of the LogTag trigger, so the resulting CSV can contain:

• extra rows from the cyclic poll that fired between two events,
• missing rows because the poll timer and the trigger pulse did not coincide,
• duplicate rows on power-up while the runtime re-fills the ring buffer from retained memory.

This is exactly the symptom observed: "It logs if I clear the log's folder and power up the machine again. But when I turn off the machine and restart it the logging stops working." The runtime re-hydrates the cyclic buffer at boot, the LogTag call is no longer recognized as a new event, and the file is not flushed.

Root Cause: Why Cyclic Acquisition Breaks Single-Shot LogTag

Three independent mechanisms combine to break the configuration.

1. Buffer ownership collision. The datalog ring buffer is owned by the cyclic acquisition task. The LogTag call appends a single snapshot but cannot force a flush because the cyclic task is still filling rows ahead of it. On power-down, the unwritten rows in the buffer are lost, and the next boot re-acquires the same values from the PLC, so the file appears unchanged.
2. Trigger pulse width. A one-second pulse from M100.0 may be sampled zero, one, or two times by a 1 s cyclic acquisition depending on jitter between the PLC scan and the HMI poll. The first LogTag at the rising edge is lost because the cyclic snapshot already wrote the row, and the second LogTag at the falling edge is dropped because the value is identical to the previous sample.
3. SD card file locking. With a circular log, WinCC opens the CSV in append-and-rotate mode. If the cyclic task has the file handle when LogTag requests a flush, the write is queued but not committed before the next scan. After power-loss, the queued write is discarded and the file pointer is reset, so the next LogTag appends to the old file as if it were new — producing the "works once, fails forever" pattern.

None of these mechanisms are bugs. They are the documented behavior of the cyclic / event-mixed model. The fix is to remove the conflict, not to retune it.

The Correct Configuration: On Demand + LogTag

Configure every tag that participates in the per-cycle record with Acquisition mode: On demand. The runtime no longer polls the PLC. Instead, the LogTag function pulls a single snapshot of each tag at the exact moment the function executes and writes one row per call.

1. In the project tree, open Historical data → Data logs and create a new datalog (or edit the existing one).
2. Set Storage location to Storage card — SD/MMC card and File format to CSV (Comma Separated Values).
3. Set Log mode to Circular log if the file must roll over, or Sequential log if you need an append-only audit trail.
4. Add the four variables as columns. For each column, confirm that the linked HMI tag has Acquisition mode = On demand.
5. Place an invisible switch (or use a function attached to the value-change event of M100.0) on any screen.
6. On the Events tab of the switch, configure Change value → ON to call the function LogTag, with parameter Log name set to the datalog name and Tag name set to the HMI tag that should be the snapshot source (or leave Tag name empty to log all columns in one call).

PLC-HMI Tag Interface and Trigger Design

For a one-shot per machine cycle, the cleanest trigger is a single boolean bit that is set by the PLC when the cycle is complete and cleared by the HMI after the record has been written. The recommended handshake is shown below.

In the HMI project, attach two scheduled tasks to the same function list:

1. On rising edge of CycleDone: LogTag("CycleLog", "").
2. On falling edge of CycleDone: SetBit("LogAck") so the PLC can handshake the next cycle.

For TIA Portal / WinCC Professional, the equivalent is to use a Tag trigger in the datalog properties and select On change — of any tag — CycleDone. The runtime will then call the snapshot automatically on every rising edge of CycleDone without an explicit LogTag function call.

Storage, File Format, and SD Card Considerations

Power-loss safety depends on the flush strategy. With On demand acquisition, every LogTag call commits the row to the file immediately, so a power-down loses at most the row currently in transit. With Cyclic acquisition, the loss window equals the poll interval times the flush threshold — which on a 1 s cycle can be 10–30 s of records.

Function Reference: LogTag vs. StartLogging/StopLogging

The choice of function must match the acquisition mode of the participating tags. The table below summarizes the only valid combinations.

Diagnostics: Verifying LogTag Execution on the Panel

If LogTag still does not produce a row after switching to On demand, use the following diagnostics before changing the wiring or the PLC logic.

1. Open the Diagnostics view on the panel: Start Center → System → Diagnostics → Datalog. Confirm that the datalog shows Active and that the storage path is reachable.
2. Insert a temporary internal tag DebugLogCount of type Int. Configure an additional function on the same rising edge: IncreaseTag("DebugLogCount"). If the value increments on every cycle, the trigger is reaching the runtime.
3. Add a text list on a screen bound to DebugLogCount so the operator can read the count without ProTool/ProSave.
4. On the SD card, list the file. With Circular log the file is /Logs/<LogName>_0.csv. The header row must contain the exact names of the four variables; if the column order changes between restarts, the project and the SD card file are out of sync — delete the file before next boot.
5. Export the diagnostic buffer through Start Center → Options → Transfer → Backup. The backup contains the datalog files in their committed state, which is the fastest way to confirm whether the runtime wrote the row at all.

Edge Cases and Field-Proven Caveats

• File name collision after firmware update. A firmware change (for example from WinCC flexible 2008 SP5 to TIA Portal V17) renames the runtime and the datalog file may be written under a new path. The old file is left on the SD card and the runtime does not append to it. Always clear /Logs/ after a firmware update.
• Locale change. If the panel region is set to a comma-decimal locale (Germany, Spain, France), the CSV column separator becomes a semicolon, which breaks Excel macros expecting a comma. Lock the separator in the project or use the RDB format and export to CSV from the runtime.
• Trigger pulse shorter than 250 ms. The HMI tag update task runs at 250 ms on most Comfort Panels. A PLC pulse shorter than 250 ms may be missed entirely. Stretch the pulse to at least 500 ms in the PLC logic.
• Multi-variable log with mixed modes. If three of the four tags are On demand and one is left Cyclic, the cyclic tag's value is always one cycle ahead of the others in the row. This produces values that are inconsistent at the moment of the trigger. Switch every tag in the log to On demand.
• Power-up race with PLC boot. If the HMI boots faster than the PLC, the first LogTag call may read zero values. Gate the trigger with a "PLC ready" tag that the PLC sets after its own warm-up is complete.
• SD card wear on Comfort Panels. The internal flash is rated for ~100 000 write cycles. Cyclic logging at 1 s fills the cycle budget in ~28 h. With On demand, the write count is bounded by the cycle count, so the panel can run for years.

Verification Procedure

1. Rebuild the project with all four tags set to On demand. Compile and download.
2. With the panel online, navigate to the screen that contains the trigger switch. Toggle the switch to ON for at least 1 s.
3. Navigate to Start Center → System → Datalog and confirm that the file size has grown by one record.
4. Power-cycle the machine three times. Each time, toggle the trigger once and confirm that exactly one row is appended per cycle.
5. Remove the SD card and open the CSV in Excel. Confirm the four variables, the timestamp, and the absence of duplicate rows.
6. Run the line for one full production shift. Compare the row count in the CSV to the PLC cycle counter. They must match within ±1 row.

Summary

Siemens Multi Panel datalogging supports both continuous and event-driven recording, but the two modes must not be mixed on the same tag. Cyclic acquisition assumes that the runtime owns the buffer; On demand acquisition assumes that the function call owns the buffer. Mixing them produces the intermittent LogTag failure that prompted this article. The fix is a one-line configuration change — set the acquisition mode to On demand for every tag in the datalog, drive the LogTag function from a discrete PLC bit that is at least 500 ms wide, and gate the trigger with a PLC-ready handshake. With these constraints satisfied, one record per machine cycle is reliable across cold boots, warm reboots, and SD card swaps.

FAQ