WinCC Professional: Resolving Recipe DateTime Tag Binding Errors

1. Problem Description

When configuring a recipe in WinCC Professional (RT Professional / WinCC Runtime Professional), an attempt to bind an internal HMI tag of data type DateTime to a recipe element of data type Date / Time causes the element to display the binding in red. The tag is rejected at configuration time and cannot be used as a recipe value source or destination. The same rejection occurs regardless of whether the tag is internal, PLC-linked, or Modbus TCP-mapped.

The configuration error is reproducible in TIA Portal V15, V16, V17, and remains documented as a hard limitation in the official TIA Portal V20 help: Creating Recipe Elements and Data Records (RT Professional) explicitly states:

This restriction is not a defect — it is the expected behaviour of the recipe system. Engineers who are unaware of the underlying architecture typically interpret the red binding as a bug, which is the central motivation for this troubleshooting reference.

2. Root Cause: WinCC Professional Recipe Architecture

WinCC Professional inherits its recipe subsystem from the WinCC V7.x "User Archive" concept. The recipe database tables, the change-tracking mechanism, and the schema definition for elements all derive from the same User Archive foundation that shipped with WinCC V7. The Type > Recipe > Element > Data Record hierarchy in the TIA Portal recipe editor is a thin configuration layer on top of the User Archive back end.

Within that back end, the column type DateTime is reserved exclusively for system-maintained timestamps, in particular the Last Change column and the audit/trail columns of every archive row. The same reserved usage exists in WinCC V7: opening any User Archive column editor reveals that DateTime columns are pinned to system fields and cannot be edited as user data.

Because the recipe system exposes a single element abstraction (one column = one element), binding a process tag of data type DateTime to a user element would collide with the system DateTime columns. The TIA Portal configuration layer therefore refuses the binding at design time. The same restriction is enforced for all tag data types when the recipe element column is of type Date / Time:

The constraint is symmetric: you cannot write a DateTime tag to any recipe element, and you cannot read one back through tag communication. The only legitimate access path to a DateTime value within the recipe subsystem is via scripts (VBS / VBA / ANSI C) that read the system-maintained timestamp column directly.

3. Diagnostic Symptoms and Error Indicators

The failure presents in three distinct places during the project lifecycle. Capture all three to confirm the root cause before applying a workaround.

1. TIA Portal configuration (design time): The recipe element row in the TIA Portal recipe editor shows a red field next to the tag selection. Hovering over the red marker displays the tooltip "Invalid data type for this recipe element" (localized wording varies).
2. Compile / consistency check: The project compiles without a hard error, but a warning is emitted in the output window: "Recipe element 'X' references a tag of incompatible data type. Tag binding will be ignored at runtime."
3. RT Professional runtime: Reading the recipe back via HMIRuntime.Tags(...).Read in VBS returns the last good value (or zero) and the date element stays at its default. Writing the recipe from the runtime does not propagate to the Date / Time column.

If the symptom stops at the design-time red marker and the project never compiles, you are looking at configuration-only failure. If the warning appears in the compile log, runtime values will silently fail.

4. Preconditions and Platform Considerations

The behaviour diverges between the two runtime families in the TIA Portal HMI/SCADA portfolio. Confirm the runtime before assuming the limitation applies.

The asymmetry explains a frequently reported confusion: engineers accustomed to Comfort Panel recipes see a Date_And_Time S7-1500 tag binding succeed on a TP700/TP1500, and assume the same will work on a WinCC Professional RT. It will not.

For RT Professional running on a PC node with no PLC (for example, a Modbus TCP-only architecture), the recommended engineering workflow is:

1. Define recipe elements using only the supported data types listed above.
2. Use a String element to carry ISO 8601-formatted timestamps (yyyy-MM-dd HH:mm:ss or yyyyMMddHHmmss).
3. Use a DInt or LReal element to carry epoch seconds if arithmetic is required.
4. Translate to/from DateTime in scripts at the boundary.

5. Solution A: Use a String Element as a DateTime Carrier

The supported path. Configure the recipe element as String with a defined length, and write ISO 8601 strings to it from a script bound to a button or faceplate event.

5.1 Configuration in TIA Portal

1. Open the recipe in the project tree.
2. Add a new element named, for example, BatchStartTime.
3. Set Data type = String.
4. Set Data record length = 19 (matches yyyy-MM-dd HH:mm:ss including the T separator if you prefer yyyy-MM-ddTHH:mm:ss = 19 chars, or use plain yyyy-MM-dd HH:mm:ss = 19 chars).
5. Leave the tag binding empty; the element will be populated by script.

5.2 VBA / VBS Populate From Internal DateTime Tag

' VBS / VBA: write a DateTime tag value to a String recipe element
Sub WriteBatchStartTime
    Dim sFmt
    sFmt = "yyyy-MM-dd HH:mm:ss"
    Dim sValue
    sValue = FormatDateTime(HMIRuntime.Tags("InternalDateTime").Read, vbGeneralDate)
    ' Normalize to the configured format
    sValue = Year(Now) & "-" & Right("0" & Month(Now), 2) & "-" & Right("0" & Day(Now), 2) & " " & _
             Right("0" & Hour(Now), 2) & ":" & Right("0" & Minute(Now), 2) & ":" & Right("0" & Second(Now), 2)
    ' Push into the recipe data record (recipe name "Batch", element "BatchStartTime")
    HMIRuntime.DataSet.Set "Batch", "BatchStartTime", sValue
End Sub

5.3 VBA / VBS Read Back Into a DateTime Tag

' VBS / VBA: read a String recipe element and parse into a DateTime
Sub ReadBatchStartTime
    Dim sValue
    sValue = HMIRuntime.DataSet.Get("Batch", "BatchStartTime")
    If Len(sValue) >= 19 Then
        Dim dValue
        dValue = CDate(Mid(sValue, 1, 10) & " " & Mid(sValue, 12, 8))
        ' Note: there is no public WinCC API to write a DateTime tag value directly.
        ' Round-trip via the configured display element or a derived String tag.
        HMIRuntime.Tags("BatchStartTimeDisplay").Write sValue
    End If
End Sub

6. Solution B: Use a Numeric Element (DInt or LReal) for Epoch Arithmetic

When the application must add hours, minutes, or seconds to a stored timestamp (for example, to compute an end-of-batch time from a start time), the most robust carrier is Unix epoch seconds as a 32-bit DInt or 64-bit LReal. This avoids string parsing and survives DST / timezone changes that confuse wall-clock arithmetic.

6.1 Configure the Recipe Element

6.2 VBA Example — Compute End From Start Plus N Hours/Minutes

' VBS: add hours and minutes to an epoch DInt and store as another recipe element
Sub ComputeBatchEnd
    Const SECS_PER_HOUR  : Const SECS_PER_MIN  : Dim iStart, iAddH, iAddM, iEnd
    SECS_PER_HOUR = 3600
    SECS_PER_MIN  = 60
    iStart = CLng(HMIRuntime.DataSet.Get("Batch", "BatchStartEpoch"))
    iAddH  = CLng(HMIRuntime.Tags("BatchDurationHours").Read)
    iAddM  = CLng(HMIRuntime.Tags("BatchDurationMinutes").Read)
    iEnd   = iStart + (iAddH * SECS_PER_HOUR) + (iAddM * SECS_PER_MIN)
    ' Guard against the 2038 boundary
    If iEnd > 2147483647 Then
        HMIRuntime.Trace "Batch end overflows 32-bit epoch. Switch to LReal element."
    End If
    HMIRuntime.DataSet.Set "Batch", "BatchEndEpoch", iEnd
End Sub

This pattern resolves the symptom described in the field report where "13 hours + 18 hours returned 31 hours." That error came from wall-clock arithmetic performed on the hour component only. By moving the arithmetic to epoch seconds, the wrap-around happens at the mod-86400 boundary in a single explicit step, not implicitly on the hour field.

7. Solution C: ANSI C Time Arithmetic With a Properly Linked time.h

RT Professional supports ANSI C scripts and exposes a subset of the standard C runtime. Importing a full time.h from a Debian installation will compile, but only after the project is told where the WinCC C runtime headers and libraries live. The official procedure is documented in Siemens Support entry 22279366 — How to incorporate your own header files in C scripts.

7.1 Procedure (per Siemens Support entry 22279366)

1. Place the custom header (for example, my_time.h) in a project-local folder (recommended: \<project>\CustomHeaders).
2. Open the script editor for the C function. From the menu, choose Options > Settings for C scripts > Include paths.
3. Add the absolute path to the folder containing my_time.h.
4. Restart the C compiler service (the TIA Portal caches include paths until restart).
5. Use a #include "my_time.h" directive — the quote form triggers the project search path before the system path.

7.2 ANSI C: Compute End Time From Start Plus Hours/Minutes

/* ANSI C function callable from a WinCC button event */
#include "apdefap.h"
#include "my_time.h"

void ComputeEndFromStart(const char* szStartIso, int addHours, int addMinutes, char* szOut, size_t cbOut)
{
    struct tm tStart;
    int yr, mo, dy, hh, mi, ss;
    if (sscanf(szStartIso, "%d-%d-%d %d:%d:%d", &yr, &mo, &dy, &hh, &mi, &ss) != 6) {
        strncpy(szOut, "PARSE_ERROR", cbOut);
        return;
    }
    memset(&tStart, 0, sizeof(tStart));
    tStart.tm_year = yr - 1900;
    tStart.tm_mon  = mo - 1;
    tStart.tm_mday = dy;
    tStart.tm_hour = hh;
    tStart.tm_min  = mi;
    tStart.tm_sec  = ss;
    tStart.tm_isdst = -1;   /* let mktime decide */

    /* mktime normalises overflow: 13+18 = 31 hour becomes day+1 07:00 */
    tStart.tm_hour += addHours;
    tStart.tm_min  += addMinutes;
    (void)mktime(&tStart);

    strftime(szOut, cbOut, "%Y-%m-%d %H:%M:%S", &tStart);
}

The mktime call performs the field normalisation that the user's broken script missed. With tm_isdst = -1, the runtime also resolves daylight-saving transitions correctly, which addresses the separate "recorded time is 2 hours later than real" symptom reported in the source thread.

8. Why the 2-Hour Offset Happens (DST / Time Zone)

The field report includes a related bug filed under a separate thread: "Recipe data are wrong, recorded time is 2 hours later than real." A 2-hour delta almost always points to a DST / standard-time transition, or to a system clock running in a non-local time zone. Verify in this order:

1. Confirm the WinCC Runtime PC clock and time zone: Control Panel > Date and Time > Change time zone… in TIA Portal project under Runtime settings > Time settings or on the engineering station.
2. Confirm the PLC time (if any) and its synchronisation source. The S7-1500 Date_And_Time is in local time unless explicitly converted.
3. Check whether the recipe writes use FormatDateTime(..., vbGeneralDate) against an internal DateTime tag that was originally populated in UTC. If yes, convert at the boundary.
4. Check whether the PC and PLC observed DST on the same calendar date. Inconsistent DST rules (rare, but seen in legacy Windows installations) can produce a 1-hour or 2-hour delta.

9. Verification and Commissioning Tests

After implementing the workaround, run the following checks to confirm the recipe is functional end to end.

1. Design-time compile: Rebuild the project. The warning "Recipe element references a tag of incompatible data type" must be gone.
2. Tag binding inspection: Open the recipe element. The cell that was red must now be empty (script-driven) or green (valid String tag).
3. Round-trip test — write: Trigger the populate script. Use HMIRuntime.Trace to log the value before and after the DataSet.Set call. Confirm the value matches the configured format and length.
4. Round-trip test — read: Reload the data record into the runtime. The String element must echo the same value written in step 3. If the LReal epoch path is used, confirm integer seconds since 1970-01-01.
5. Arithmetic test: Set BatchStartTime = 2025-03-30 02:00:00 in a region observing DST start at 02:00. After running ComputeEndFromStart with addHours = 18, the result must be 2025-03-31 00:00:00 in local time (the lost hour is correctly absorbed by mktime with tm_isdst = -1).
6. Bound check (32-bit epoch): If a DInt element is used, set BatchStartEpoch = 2080-01-01 00:00:00 and run the arithmetic. The result must overflow the warning trace, not silently wrap. Migrate to LReal if the application horizon passes 2038-01-19.

10. Field Engineering Recommendations

• Pick one carrier and stick to it. Mixing String and DInt elements in the same recipe for the same logical timestamp leads to divergent values after a single edit cycle.
• Document the format in the element comment. Right-click the recipe element in TIA Portal and add a comment that names the format (e.g., "ISO 8601 local, 19 chars") and the timezone ("UTC" or "Europe/Berlin").
• Prefer LReal over DInt for new projects. The 2038 problem is a known footgun. Use LReal for epoch with sub-second resolution.
• Keep DateTime tag usage out of the recipe editor. Use DateTime tags at the tag layer for display and alarm timestamping; never bind them to a recipe element column.
• Centralise the conversion in one script library. Put the FormatDateTime, mktime, and strftime calls in a project-global script module so the format is consistent across all recipes.
• Audit at commissioning. Cross-check the recipe write time against the engineering station's local clock and against a known-good reference (NTP-synchronised PC). A consistent offset indicates a time-zone bug; a drifting offset indicates a script bug.

11. Troubleshooting Matrix

12. FAQ