Problem Overview
On a Siemens ET200SP CPU 1510SP-1 PN configured in TIA Portal V16 with a WinCC Unified Comfort Panel, an I/O field bound to a tag of the IEC TIME data type silently overwrites the connected tag with the value T#13H as soon as the operator navigates away from the field, opens a different screen, or touches any other HMI element. The value the operator entered — for example, 5 minutes — is rendered correctly on screen while the field has input focus, but the moment focus is released, the runtime commits a different value to the PLC: thirteen hours. The corruption survives a CPU restart. On the next power-up, the I/O field re-reads the same 13H value from the tag memory and displays it as the current setpoint, even though no operator has touched the panel since the last download.
The defect is a known interaction between the WinCC Unified runtime property InputBehavior.AcceptOnDeactivated (displayed in the engineering as Accept value after exit) and the IEC TIME data type. It is not caused by a TON block misconfiguration, an incorrect scan time, the ET200SP backplane bus, or by the operator entering the value incorrectly. The corruption is generated entirely inside the Unified runtime's tag commit logic. Disabling the offending property restores correct behaviour without changing the PLC program, the variable type, or the HMI tag connection.
Affected System Configuration
| Component | Value |
|---|---|
| PLC CPU | ET200SP CPU 1510SP-1 PN (S7-1500 software controller compatible) |
| CPU firmware | V2.6 or later (any firmware; defect is HMI-side) |
| Engineering | TIA Portal V16, Update 4 or later |
| HMI runtime | WinCC Unified V16, RT Unified (PC) or Panel RT Unified |
| HMI panel | Comfort / Unified Panel (MTP1500, MTP1900, MTP2200, IPC) |
| PLC tag type | IEC TIME (32-bit DINT in milliseconds) |
| HMI tag type | Mirrored from PLC; internally a 32-bit signed integer in ms |
| Block consuming the tag | IEC TON, TP, or TOF at the PT input |
| Property path | I/O field → Properties → Miscellaneous → Reaction to input → Accept value after exit |
The same failure mode has been observed in TIA Portal V17 and V18 with WinCC Unified V17 / V18, although the property path remains identical. Firmware updates of the CPU 1510SP-1 PN do not change the behaviour, because the corruption is generated on the HMI side, not on the PLC side.
Observed Symptoms
The following symptoms are characteristic of this failure mode and differentiate it from a wiring, scaling, or PLC-side conversion error:
- The I/O field shows the correct value (for example,
00:05:00) while the field has input focus. - The moment the operator touches a button, a tab, a navigation button, or a different field anywhere on the screen, the value in the time field jumps to
13:00:00(orT#13Hin the internal tag representation). - Going online with the PLC in TIA Portal reveals that the connected tag is now 46,800,000 ms, i.e. 13 hours exactly.
- A CPU restart followed by a screen reload does not clear the 13H value; the I/O field shows 13H on first display.
- If the operator types a new value, the value is committed correctly while the field has focus, but the value is again replaced by 13H on the next focus change.
- Other HMI tags on the same screen are unaffected. The corruption is specific to
TIMEtags withAcceptOnDeactivatedenabled. - The defect is reproduced on a cold start (power off, power on) and on a warm restart (stop → run).
- The TON block itself is not in fault:
ENOremains TRUE,ETcounts up to 13H, and the output is set after 13 hours, exactly as the corrupted value prescribes.
TIME format corresponds to a 32-bit signed DINT value of 46,800,000 (decimal) or 0x02C9C440 (hex). If the field shows a different value (for example, 12H or 14H) the failure is related to a different bug; check the I/O field's output format string before applying the fix below.Root Cause: InputBehavior.AcceptOnDeactivated
WinCC Unified I/O fields implement a two-stage commit model. While the operator types, the new value lives in a local buffer inside the HMI runtime; it is not yet written to the connected tag. The runtime waits for a commit trigger before copying the buffer value to the tag. Two triggers are available in V16 and later:
- Accept on change — the value is committed every time the field's content changes (on every key press, every spinner step, every list selection).
- Accept on deactivation — the value is committed only when the field loses focus, either by tabbing away, by touching another element, or by navigating to another screen.
The property InputBehavior.AcceptOnDeactivated is enabled by default on every I/O field inserted in TIA Portal V16. For most data types (INT, REAL, STRING, BOOL) the property is harmless: when the field is deactivated, the runtime reads the local buffer, parses it against the configured display format, converts to the tag's data type, and writes the result to the tag.
For TIME tags, however, the parsing logic in WinCC Unified V16 contains a defect: if the buffer contains a partial or non-canonical value (for example, the value the runtime itself wrote to the buffer a few hundred milliseconds earlier during a screen refresh), the parser falls back to a fixed default of 13 hours instead of preserving the value. The result is a self-perpetuating corruption: the runtime writes 13H to the tag, re-reads it, and the next deactivation cycle writes 13H again, even if the operator never touched the field.
Disabling AcceptOnDeactivated forces the runtime to commit the value on every change, so the parser always receives a complete, canonical value (the value the operator just typed or selected), and the 13H fallback is never triggered.
Commit Flow Diagram
Resolution: Disable "Accept Value After Exit"
- Open the TIA Portal project that contains the affected Unified HMI screen.
- In the project tree, expand the HMI device and navigate to Screens → the affected screen (for example, Main).
- Open the screen editor by double-clicking the screen name.
- Click once on the time I/O field to select it. The Properties pane opens on the right side of the editor.
- In the Properties pane, expand the Miscellaneous section.
- Open the Reaction to input subsection.
- Clear the check box Accept value after exit (the localised label of
InputBehavior.AcceptOnDeactivated). - Leave Accept value during input (or Accept on value change) enabled. This is the property that will now trigger the commit.
- Repeat steps 4 through 8 for every other I/O field on the screen that is bound to a
TIME,TIME_OF_DAY,LTIME, orDTLtag. - Compile the HMI project, download it to the panel, and restart the runtime.
InputBehavior.AcceptOnDeactivated is identical across all localizations and is the reliable cross-language identifier for scripting and templates.Verification Procedure
- Download the updated HMI configuration to the panel and perform a panel restart (power cycle or Start → Run → Stop → Start on the Control Panel of the Unified device).
- Go online with the PLC in TIA Portal. Open the watch table that monitors the time tag and force the tag to a known value, for example
DW#16#0000EA60(which is 60,000 ms = 1 minute). - On the panel, open the affected screen. The I/O field should display 00:01:00.
- Touch the field. The runtime picker (hours / minutes / seconds / milliseconds) opens.
- Change the value to 5 minutes using the runtime picker. Confirm.
- Touch a button or another field on the same screen to release focus. The value should remain 00:05:00.
- Navigate to a different screen, then return to the original screen. The value should still be 00:05:00.
- Monitor the watch table while performing steps 4 through 7. The connected tag should track the I/O field value with no unexpected jumps to 13H.
- Power-cycle the PLC only (panel remains powered). On the next scan, the I/O field should display the last-committed value (5 minutes), not 13H.
- Power-cycle the panel only (PLC remains powered). On the next boot, the I/O field should display 5 minutes after the runtime re-reads the tag.
If the value still jumps to 13H after following this procedure, two further checks are required:
- Confirm that no other I/O field on the same screen is bound to the same
TIMEtag. Multiple writers to the same tag are not coalesced by the Unified runtime and can still trigger the parser fallback. - Confirm that the tag is not being written by a script or a job running on a cyclic trigger. Inspect Scripts → Scheduled tasks and Scripts → Global area for any assignment to the tag.
Workaround 1: PLC-Side Conversion in SCL
If the HMI-side fix is not available — for example, because the HMI is delivered to a customer who has already taken the panel into service and cannot be easily upgraded — a robust alternative is to expose a 32-bit integer tag in milliseconds on the HMI and convert it to a TIME tag inside an SCL function block on the PLC. This sidesteps the runtime's TIME parser entirely.
The following SCL snippet, placed in an FB or FC, reads a UDINT value from the HMI (in seconds, for example) and produces a TIME value for the PT input of the TON block:
FUNCTION_BLOCK "fbHmiTimeConv"
VAR_INPUT
iSetpointSec : UDINT; // From HMI, operator enters seconds
iMaxSeconds : UDINT; // 86400 for 24 h, 0 to disable
END_VAR
VAR_OUTPUT
qSetpointTime : TIME; // To TON.PT
qError : BOOL; // Out-of-range flag
END_VAR
BEGIN
// Clamp the operator input to a configurable maximum
IF iMaxSeconds > 0 AND iSetpointSec > iMaxSeconds THEN
iSetpointSec := iMaxSeconds;
qError := TRUE;
ELSIF iSetpointSec > 2147483 THEN // 2,147,483 s ~ 24.8 d, DINT ms limit
iSetpointSec := 2147483;
qError := TRUE;
ELSE
qError := FALSE;
END_IF;
// Convert seconds (UDINT) to milliseconds (UDINT) to TIME (DINT)
qSetpointTime := UDINT_TO_TIME(iSetpointSec * 1000);
END_FUNCTION_BLOCK
On the HMI side, configure the I/O field with data type UDInt, format string 999999 (seconds), and a process value range of 0 to 86,400. The runtime never sees a TIME tag, so the AcceptOnDeactivated bug is bypassed.
The disadvantage of this approach is that the operator no longer sees the convenient hours/minutes/seconds picker; instead, the field shows a raw number. For most operator interfaces this is acceptable because the time value is rarely changed.
Workaround 2: Split H/M/S I/O Fields
An intermediate approach is to use three separate I/O fields on the HMI — one for hours, one for minutes, one for seconds — each bound to a UDINT tag. A small ladder or SCL block on the PLC combines the three values into a single TIME tag using the standard formula:
// Combine three UDINT values into one TIME
qSetpointTime := UDINT_TO_TIME(
(iHours * 3600 + iMinutes * 60 + iSeconds) * 1000
);
This approach preserves the operator's experience (three separate fields, each with a numeric keypad) while routing around the TIME parser entirely. It is recommended for cases where the customer does not allow script modifications and where the HMI does not use the runtime's built-in TIME picker.
Workaround 3: HMI Script-Side Validation
For projects that cannot modify the PLC program, a JavaScript running on the HMI can validate the time field on every value change and reject values that do not match the operator's input. The script is attached to the I/O field's Output event:
export function IOField_1_OnOutput(value) {
// value is the runtime's internal buffer in ms
// Reject the 13H fallback and restore the last good value
if (value === 46800000) {
const lastGood = Tags("LastGoodSetpoint").Read();
return lastGood;
}
Tags("LastGoodSetpoint").Write(value);
return value;
}
The script is a workaround, not a fix. It does not address the root cause and adds runtime overhead. Disable InputBehavior.AcceptOnDeactivated at the next convenient maintenance window.
Why 13 Hours? Decoding the Default Value
Although the fix above resolves the symptom, the value 13H is unusual enough that engineering teams often request an explanation. The 13-hour default is consistent with a defect in the V16 TIME parser, not a meaningful value. The following calculations are useful when documenting the failure in an internal incident report:
| Quantity | Value |
|---|---|
| Observed value | T#13H |
| In seconds | 46,800 s |
| In milliseconds (DINT) | 46,800,000 |
| In hex (32-bit) | 0x02C9C440 |
| As LREAL seconds | 4.6800000 × 10⁴ |
| Maximum TON PT in S7-1500 |
T#24D20H31M23S647MS ≈ 2,147,483,647 ms |
| Percentage of maximum | ≈ 2.18% |
| As a power-of-two boundary | Not on a 2ⁿ boundary; 2²⁵ = 33,554,432; 2²⁶ = 67,108,864 |
The 13H value does not correspond to a system clock, a time-zone offset (UTC+13 is a real time zone — New Zealand with daylight saving — but most plants are in UTC+1 or UTC+0, ruling out a clock-offset theory for the majority of installations), or to a default initialiser. The observed behaviour is consistent with a hard-coded fallback inside the V16 parser when it receives a non-canonical input. The same fallback is observed in V17 and V18 if the parser receives a non-canonical input; the fallback value is unchanged across versions for compatibility reasons. Disabling AcceptOnDeactivated ensures the parser only receives canonical input and the fallback is never reached.
Related I/O Field Properties
Other I/O field properties interact with InputBehavior.AcceptOnDeactivated and should be reviewed when investigating time-tag anomalies:
| Property ID | Engineering label (EN) | Default | Effect on TIME tags |
|---|---|---|---|
InputBehavior.AcceptOnDeactivated |
Accept value after exit | Enabled | Source of the 13H defect. Disable for TIME tags. |
InputBehavior.AcceptOnValueChange |
Accept value during input | Enabled | Should remain enabled. Forces per-keystroke commit. |
OutputFormat.Format |
Output format | 999,999 ms | Use an H:M:S format string such as hh:mm:ss for operator clarity. |
OutputFormat.InputFormat |
Input format | Inherits output | Must match the output format for the parser to accept the value. |
Misc.ClearOnNew |
Clear on new input | Disabled | When enabled, forces the field to clear before the operator types. Useful for TIME fields to prevent stale values. |
Misc.HiddenInput |
Hidden input | Disabled | Should remain disabled for TIME fields. Hidden input has been observed to corrupt TIME parsers in V16. |
Limits.Min / Limits.Max
|
Lower / upper limit | 0 / 100 | Set to 0 ms and 86,400,000 ms (24 h) to bound operator input. |
Mode |
Display mode | Input/output | Use Input/output; Output only will not display the runtime picker. |
For the canonical property reference, see the Siemens documentation for the WinCC Unified I/O field: IO field (RT Unified) - WinCC Unified - docs.tia.siemens.cloud.
Migration From WinCC Comfort / Advanced to WinCC Unified
The Comfort and Advanced runtimes use a single-stage commit model: the value is written to the tag on every change, with no deactivation trigger. Migrating a Comfort project to Unified silently enables AcceptOnDeactivated for every I/O field, and any TIME field that worked correctly under Comfort starts to misbehave under Unified. The recommended migration procedure is:
- Perform the project migration in TIA Portal V16 or later.
- After migration, run a project-wide audit on every I/O field bound to a
TIMEtag. - For every match, clear the Accept value after exit check box.
- Apply a project-wide style template that sets the property default to disabled for new fields inserted in the future.
- Run the full HMI simulation (RT Unified) and verify that all time fields commit on every change.
- Compile, download, and run a one-week shadow test before sign-off.
Style templates in TIA Portal V17 and later allow the project default to be set in the project settings, removing the need to fix every field by hand. Open Project tree → HMI device → Runtime settings → Style, define a new style with InputBehavior.AcceptOnDeactivated = false, and assign it as the default for all new I/O fields.
Commissioning Procedure on a Running Plant
If the fix must be applied to a plant in operation, the following sequence minimises process interruption:
- Identify every screen that contains a
TIMEI/O field. Use the cross-reference editor in TIA Portal (Project tree → HMI device → Cross-reference) to list all I/O fields and filter by tag type. - Schedule a maintenance window long enough to recompile the HMI, download it, and restart the panel.
- Place the PLC in Stop only if a TON is currently timing out with a corrupted setpoint. Otherwise, leave the PLC in Run and accept a one-cycle discontinuity in operator-entered time fields.
- Apply the property change to every I/O field in the cross-reference list. Use the multi-select editor (Shift-click) to change the property on multiple fields simultaneously.
- Recompile only the HMI. A PLC recompile is not required.
- Download the HMI configuration. The runtime will restart automatically; expect a 30-90 second downtime depending on panel size.
- Verify on the panel: enter a 5-minute setpoint, navigate away, and confirm the value persists.
- Update the plant's change log with the engineering change request, the list of modified fields, and the verification results.
Diagnostic Procedure Using Watch Tables
To confirm that the HMI is the source of the corruption, the following watch-table recipe isolates the failure:
- Create a watch table with the time tag and a marker bit
bHeartbeatfrom the PLC's System clock (toggle every cycle). - Force the time tag to a known value, for example 300,000 ms (5 minutes).
- Disable all HMI screens by removing the Visible animation on the time I/O field's parent screen.
- Wait 60 seconds. The watch table should still show 300,000 ms. If it does, the PLC is not corrupting the tag.
- Re-enable the screen. Touch a different field. The watch table should still show 300,000 ms. If it jumps to 46,800,000 ms, the HMI is the source of the corruption.
- Apply the fix and repeat the test. The tag should remain stable.
Engineering Best Practices
- Bind time tags through a named PLC interface (an FB with a defined interface section) rather than directly to DB global variables. This documents the data type and avoids accidental rewrites from multiple screens.
- Set
AcceptOnDeactivated = falseandAcceptOnValueChange = trueas a project template default for every new I/O field. The Siemens Style template mechanism in TIA Portal V17+ can enforce this across an entire HMI project. - Always configure explicit
Limits.MinandLimits.Maxon time fields. A 24-hour upper bound prevents operator typos from generating multi-day setpoints that lock the TON output on indefinitely. - Avoid using the same
TIMEtag on more than one screen. Multiple writers are not coalesced by the Unified runtime and can trigger parser fallbacks even withAcceptOnDeactivateddisabled. - When migrating a project from WinCC Comfort / Advanced to WinCC Unified, audit every I/O field bound to a
TIMEtag. The Comfort and Advanced runtimes do not share theInputBehavior.AcceptOnDeactivatedmodel; the migration is the most common trigger of the defect. - If the HMI runtime is updated to a newer major version (for example, V16 to V19), re-validate the time fields. Although the property is unchanged, the parser internals are version-specific.
- When commissioning a new panel, perform a dedicated time-field regression test: enter a 5-minute setpoint, navigate through every screen, and confirm the value is stable at the end of the cycle.
- Add the property setting to the project's HMI style guide so that the next engineer inherits the correct default.
Quick Reference Card
| Question | Answer |
|---|---|
| Symptom | TON setpoint silently overwritten by T#13H on focus change |
| Affected runtime | WinCC Unified V16, V17, V18 |
| Affected PLC | Any S7-1500 / ET200SP, including CPU 1510SP-1 PN |
| Root cause |
InputBehavior.AcceptOnDeactivated combined with TIME parser fallback |
| Fix | Uncheck Accept value after exit in I/O field's Miscellaneous → Reaction to input section |
| Time to fix | Less than 5 minutes per field |
| Workaround if HMI cannot be modified | Use UDINT tag on HMI and convert to TIME in SCL |
| Effect on PLC program | None |
| Effect on operator workflow | None (operator still uses the runtime picker) |
| Recompile PLC required | No |
| Documentation reference | IO field (RT Unified) - WinCC Unified |
FAQ
Why does my TON setpoint jump to 13 hours on a Siemens Unified HMI?
The Unified runtime's I/O field has the property InputBehavior.AcceptOnDeactivated (Accept value after exit) enabled by default. For TIME tags, the V16 parser falls back to T#13H (46,800,000 ms) when it receives a non-canonical value on deactivation. Disable the property in the I/O field's Miscellaneous → Reaction to input section to resolve the issue.
Does the fix require a CPU 1510SP-1 PN firmware update?
No. The corruption is generated on the HMI side, not the PLC side. No CPU firmware update, no program change, and no recompile of the PLC is required. Only the HMI configuration must be modified, recompiled, and downloaded to the panel.
Will the fix work on TIA Portal V17 and V18?
Yes. The property ID InputBehavior.AcceptOnDeactivated is unchanged in TIA Portal V17 and V18, and the fix is identical. The parser internals have been updated in V19 and the fallback is less likely to trigger, but the same property combination can still produce anomalies on heavily animated screens.
Can I keep the runtime's hours/minutes/seconds picker with the fix?
Yes. Disabling AcceptOnDeactivated does not change the input format or the picker. The operator continues to use the runtime's TIME picker; the value is now committed on every change instead of on focus loss.
What is 13H in milliseconds for an S7-1500 TON block?
13 hours corresponds to 46,800 seconds or 46,800,000 milliseconds. In a 32-bit DINT register this is 0x02C9C440. The maximum TON preset on an S7-1500 is 2,147,483,647 ms (approximately 24 days, 20 hours, 31 minutes, 23 seconds, 647 milliseconds), so 13H is well within range and will not trigger an out-of-range fault.
How do I prevent this defect on future projects?
Apply a project-wide style template in TIA Portal V17+ that sets InputBehavior.AcceptOnDeactivated = false as the default for all new I/O fields, and audit every TIME field on every Comfort-to-Unified migration. Add the setting to the project's HMI style guide and the commissioning checklist.