Troubleshooting Siemens TP1900 Comfort Slow Recipe File Transfer

Problem Summary

A Siemens SIMATIC TP1900 Comfort panel running WinCC Comfort (TIA Portal) takes 4 to 5 minutes to copy a ~300 KB recipe file from the HMI's internal storage to a remote PC over Ethernet. A scripted trigger fires the copy on a tag change. The panel is dedicated to the recipe operation during the transfer and still serves nine PLC connections on a separate subnet. When the same script is run on a smaller Siemens Comfort panel (e.g. TP700 / TP900 class) on the bench, the same 300 KB file copies in seconds. The narrow performance gap between an identical script on different panels points away from network or scripting logic and toward local storage I/O on the affected panel.

This article documents the field-proven root cause (degraded SD card), the diagnostic path used to confirm it, the verified resolution, and the preventive maintenance procedures that keep a TP1900 Comfort recipe-handling installation performing at the rated ~1-3 second per-recipe throughput.

Affected Hardware and Firmware Envelope

The TP1900 Comfort belongs to the SIMATIC HMI Comfort Panel family (4th-generation Comfort line, 15.6" and 18.5" widescreen variants; "TP" prefix = touch panel, 1900 = 18.5" diagonal). Typical part numbers and characteristics:

Comfort Panels run WinCC Runtime Advanced (Comfort) under Windows Embedded Compact 2013 on x86 hardware. The on-board SD card slot accepts SD/SDHC cards (max 32 GB pre-WinCC V16, larger with WinCC V16+ and firmware updates). The card hosts the runtime project, recipe database, logs, and user data. Recipes by default are written to \Storage Card SD\Recipes\; this path is the default for HmiRuntime.FileSystem in VBS / C scripts using the WinCC file system object.

Reference: Siemens SIMATIC HMI Comfort Panels operating instructions (entry ID 109746413); Comfort Panel system manuals portal.

Observed Symptoms vs. Expected Behavior

The 300 KB payload itself is trivial. A single read of 300 KB from a healthy SD card completes in < 100 ms; the bottleneck is the storage layer, not the 100 Mbit/s Ethernet port.

Root Cause: SD Card Wear and Latency Degradation

The root cause confirmed in the field was a damaged SD card. Recipe creation was the operation most affected because recipes are written as a stream of small records (often 64-512 B per parameter, hundreds of records per recipe) and the file system must update allocation tables and journal metadata on every write. SD cards that have:

1. Exceeded their NAND write-endurance rating (typically 3,000-10,000 P/E cycles per MLC cell, 1,000-3,000 for TLC consumer cards),
2. Lost contact integrity in the card holder (oxidation, mechanical wear, intermittent seating),
3. Sustained brown-out or unexpected power-loss events that corrupt the FAT table,

…will degrade into a state where each block write triggers hundreds of retries at the controller level before the host driver reports success. The host driver then reports a slow but successful transfer. From the WinCC script's perspective, every FileSystem.ReadFile(), CopyFile(), or recipe SaveAs call takes seconds instead of milliseconds.

This is consistent with general-purpose SD card failure modes documented in storage literature. When an SD card's internal wear-leveling metadata is corrupted, the controller repeatedly re-reads, error-corrects, and re-writes blocks, which collapses effective throughput by 1-3 orders of magnitude for the affected file. Reference: Microsoft Q&A on slow copy speeds with degraded media (general symptom pattern).

Why the Other HMI Copied in Seconds

A bench panel used for development is typically powered off cleanly after each test session, sees limited write cycles, and uses a fresh SD card supplied with the engineering kit. It will exhibit nominal throughput. The production TP1900 had been in service for an extended period with continuous recipe churn, accumulating write cycles and wear far beyond a developer panel.

Diagnostic Procedure: Script Profiling with System Alarms

The recommended first step when a Comfort Panel file operation runs slow is to instrument the script with timestamped system alarms. This identifies which call inside the script is the bottleneck.

Step 1 - Add Profiling Tags

Define internal tags to capture elapsed time between script checkpoints:

• t_start (DWord, internal)
• t_step_1, t_step_2, t_step_3 (DWord, internal)
• t_step_4, t_step_5 (DWord, internal)
• t_total_ms (DWord, internal)

Step 2 - Instrument the VBS Script

Example WinCC Comfort VBScript for the trigger event:

' ----- Profile script for recipe copy from HMI to PC -----
Dim t0, t1, t2, t3, t4, t5
t0 = Timer * 1000  ' ms since midnight (approximate resolution ~16 ms)

' ---- Step 1: open source file ----
Dim fso, srcPath, dstPath
Set fso = CreateObject("FileCtl.FileSystem")
srcPath = "\Storage Card SD\Recipes\recipe_001.csv"
dstPath = "\Storage Card SD\Transfer\recipe_001.csv"
t1 = Timer * 1000

' ---- Step 2: ensure destination folder exists ----
If Not fso.FolderExists("\Storage Card SD\Transfer") Then
    fso.CreateFolder "\Storage Card SD\Transfer"
End If
t2 = Timer * 1000

' ---- Step 3: copy file locally first (reads from source, writes to staging) ----
If fso.FileExists(srcPath) Then
    fso.CopyFile srcPath, dstPath, True
End If
t3 = Timer * 1000

' ---- Step 4: raise system alarm to tag ----
SmartTags("t_step_1") = t1 - t0
SmartTags("t_step_2") = t2 - t1
SmartTags("t_step_3") = t3 - t2
SmartTags("t_total_ms") = t3 - t0

' Raise a system alarm with the timing payload
ShowSystemAlarm "PROFILE: open=" & (t1-t0) & "ms mkdir=" & (t2-t1) & "ms copy=" & (t3-t2) & "ms"

Step 3 - Read the Result

If t_step_3 (the CopyFile duration) dominates the total, the bottleneck is the storage I/O and the SD card is the prime suspect. If t_step_1 (the FileExists check) is large, the file system metadata scan is degraded. If all steps are sub-second, the bottleneck lies in the LAN transfer itself (next section).

Diagnostic Procedure: Storage Subsystem Health

If the profile points at the storage layer, run these checks before ordering a replacement card:

1. SMART / health counter: Many industrial SD cards (e.g. Siemens 6AV2 181-2DB03-0AX0, Swissbit S-450, Apacer A1H) expose a health percentage via the SD Card Health tab in ProSave. Reference: ProSave / SD card backup and restore (entry 109482953).
2. Reboot + reseat: Power down, remove the SD card, inspect contacts for oxidation or contamination, reseat firmly.
3. Card reader test on PC: Remove the card and read it on a Windows PC. Run chkdsk e: /r (where e: is the card). Long-running chkdsk /r output that reports relocated sectors is positive evidence of NAND wear.
4. CrystalDiskMark or H2testw: Run a sequential and 4K write test. A healthy 8 GB industrial SD card sustains 8-20 MB/s sequential write and 1-5 MB/s 4K write. Cards below 1 MB/s 4K write are failing.
5. Compare to reference card: Insert a known-good identical card and re-run the script. If performance recovers, the original card is the failure.

Diagnostic Procedure: Network Path

If the storage profile is clean but end-to-end transfer is still slow, the LAN path is suspect. Quick checks:

• ping <PC> -l 1400 -n 100 from a Windows command line should show sub-millisecond RTT and zero loss on a healthy plant LAN.
• Confirm no managed switch is rate-limiting the HMI port (e.g. storm control, ACL).
• Confirm the HMI and PC are on the same subnet/VLAN. Routing hops add RTT variance.
• Verify the HMI's Interface setting in WinCC: PROFINET port X1 is the default; the secondary X2 port is for the separate PLC network in this case. Both ports are 100 Mbit/s full-duplex.
• Capture a Wireshark trace on the PC side during a copy. TCP retransmissions above 1% indicate a layer-2 issue.

Resolution: SD Card Replacement Procedure

The verified resolution for this case was SD card replacement. After swap, the same 300 KB recipe copied in 2-3 seconds end-to-end, with the script unmodified.

Required Tools and Materials

• Replacement SD card (see compatible part numbers below)
• Siemens ProSave tool installed on a Windows engineering PC
• Backup of the current runtime project (PB WinCC Comfort backup file)
• Backup of all recipes (recipe export or SD card image)
• USB-to-SD adapter or laptop SD slot for offline backup

Step-by-Step Procedure

1. Back up the runtime project. In ProSave, connect to the TP1900 Comfort, select Backup > Complete backup, and store the .psb file on the engineering PC. Reference: ProSave backup procedure.
2. Export all recipes. From the runtime HMI, Recipes > Export each dataset to USB or to the network share. Alternatively, take a full image of the old SD card with win32diskimager or dd before removal.
3. Power down the panel. Use the HMI control panel Reboot > Shut down, or disconnect power after a clean shutdown. Do not hot-swap the SD card on Windows Embedded Compact devices.
4. Remove the old SD card. Press to eject. Inspect the contacts and the holder for contamination or mechanical damage.
5. Insert the new SD card. Ensure the card is on the supported list (table below). Power up the panel.
6. Restore the runtime project. ProSave > Restore > Complete restore, selecting the .psb file from step 1.
7. Re-import recipes. Either use Recipes > Import on the runtime, or copy the exported .csv files to \Storage Card SD\Recipes\ via ProSave file browser.
8. Verify the transfer script. Trigger the recipe copy to PC and measure elapsed time.
9. Commission and sign off. Update the maintenance log with the new card S/N, firmware, and recipe set version.

Compatible SD Card Part Numbers

Reference: Siemens SIMATIC HMI approved SD card list (entry 62457098). Consumer-grade SD cards are not recommended for continuous recipe write cycles.

Recipe Path and Storage Layout Conventions

Default paths on Comfort Panels (WinCC Runtime Advanced):

Writing to \Flash\ is not recommended for runtime recipe operations because the internal flash has a smaller write-endurance budget than an industrial SD card.

Performance Tuning for Outbound File Transfer

After confirming a healthy SD card, additional optimizations apply if the script still measures above 1 s for a 300 KB payload:

1. Disable write caching on the destination folder. If you write to a USB-attached network share on the HMI before forwarding, ensure the share does not buffer excessively.
2. Use binary transfer mode. In WinCC, the FileCtl.File object's Read and Write methods with explicit buffer sizes avoid the line-by-line penalty of OpenTextFile.
3. Buffer the whole file. Read 300 KB into a byte array once, then issue a single network Send. Avoid per-record Print # calls over a network file share.
4. Reduce record count. Combine multiple recipe parameters into wider records. 300 B per record × 1000 records is much slower than 30 B × 100 records.
5. Verify the network share mount. Use WScript.Network.MapNetworkDrive or NetUse to mount once at startup rather than per-call. Reference: WinCC Comfort VBScript reference (entry 109755488).

Verification and Acceptance Test

After SD card replacement, perform these checks before signing the change over to operations:

1. Trigger the recipe copy 10 consecutive times. Median elapsed time should be < 5 s for a 300 KB file on a TP1900 Comfort.
2. Monitor t_total_ms in the diagnostic screen. Acceptable range: 500-3000 ms.
3. Check the WinCC alarm buffer for File I/O warnings.
4. Inspect Control Panel > System > Storage for reported free space and health counter.
5. Verify all nine PLC connections remain in Connected state on the X2 port.
6. Power-cycle the panel and confirm recipe persistence across reboot.

Preventive Maintenance Schedule

A panel with frequent recipe writes (e.g. 10+ writes/minute) should be scheduled for proactive card replacement every 2-3 years. A panel with occasional recipe writes (e.g. shift change) can extend to 5-7 years if quarterly health checks remain above 80%.

Related Storage Failure Modes

When SD card replacement does not resolve the slow transfer, investigate these secondary causes:

• File system corruption from brown-out. Run chkdsk on the card via PC and re-test. If corruption recurs, check the panel's UPS / 24 V supply for dips.
• Card holder mechanical failure. If the new card also performs poorly, replace the SD card holder assembly on the panel mainboard.
• Background process contention. Confirm that logging, audit trail, and OPC UA server are not running simultaneously and saturating the SD card write bandwidth.
• Antivirus / file scanner on the PC. If the destination PC is running real-time AV scanning on incoming files, exclude the receive directory.

FAQ