Resolving TON V1.0 Not Supported Error on S7-1200 in TIA Portal

Problem: "The TON V1.0 Data Is Not Supported on This CPU or by the Current Library Version"

When programming a Siemens SIMATIC S7-1200 CPU in TIA Portal, an attempt to insert a TON (Timer ON-delay) instruction in a Function Block, Function, Organization Block, or global DB logic block produces the compiler/library diagnostic:

The error typically appears under one of three conditions:

1. A new project is created against a CPU that does not ship the legacy TON instruction set, and the project still references the original S7-1200 template library.
2. An existing project is opened after a TIA Portal upgrade or a CPU firmware upgrade and the cached instruction version is no longer resolvable in the active library.
3. The S7-1200 starter template (the "S7-1200 template project") is imported and one of the in-tree blocks has been inadvertently re-versioned, dragging older TON V1.0 symbols into the new project.

The symptom is non-persistent in the sense that the project compiles again as soon as the offending reference is replaced, but the error returns on the next cold-open of the project because the project file still references an instruction version that the active library cannot resolve.

Root Cause: Instruction Versioning and Library Mismatch

Siemens exposes most standard timer/counter instructions in TIA Portal under versioned identifiers, e.g. TON V1.0, TON V2.0, TP V1.0, TOF V1.0, IEC_Timer V1.0. The "V1.0/V2.0" suffix is a library content version, not a firmware version. Each version is shipped as part of a specific TIA Portal library package and is tied to a minimum CPU firmware release.

The diagnostic "The 'TON V1.0' data is not supported on this CPU or by the current library version" is generated by the TIA Portal compiler when it cannot resolve the referenced instruction version against any of the libraries currently registered in the project's library master. The two independent failure modes are:

The error is independent of the actual logic. A TON with a 1 ms preset in a network where the Enable input is hard-wired to TRUE still produces the diagnostic; the compiler check is performed on type resolution, not on runtime behavior.

Why It Is Intermittent

Several users have reported that the error only appears on a fresh insertion of a TON into a newly created block but disappears when the project is reopened, and vice versa. The cause is that TIA Portal uses two separate caches:

1. Type cache for the active project (resolves instructions against the project's known library versions).
2. Global library cache for the workstation (resolves against installed Siemens libraries and the project template's defaults).

When a TON is dropped from the "Favorites" toolbar, TIA Portal writes a local reference that is bound to the current global library state. When the project is closed and reopened, TIA Portal re-validates the reference against the project type cache. If the cache was built against a library version that has since been removed, replaced, or the active TIA Portal has been updated, the reference dangles and the diagnostic appears.

Conversely, when a TON is dragged in from the project tree of a different project (e.g. a master template), the reference is bound to the source project's library set, which is not always present in the destination project. This is the typical cause of the error after importing or duplicating an S7-1200 template.

Affected CPUs and Firmware Versions

All S7-1200 CPUs from the original FW 1.0 through the current S7-1200 G2 generation (CPU 121x, 122x, 123x, 124x, 125x, 127x) implement the IEC 61131-3 timer instructions. The instruction version identifier exposed in TIA Portal is a function of the TIA Portal release, not the CPU firmware. However, the minimum firmware required to execute a given instruction version does depend on the CPU.

Solution 1 — Replace TON with IEC_TIMER (Recommended)

The IEC_Timer type in TIA Portal is a generic wrapper that is resolved to the correct concrete instruction (TP, TON, TOF, TONR) at compile time. Because it does not hard-code the instruction version, it survives library upgrades and CPU firmware changes far better than a direct TON call.

To migrate a single TON instance:

1. Open the block containing the failing TON in the TIA Portal editor.
2. Delete the failing TON V1.0 instance and its associated instance DB.
3. From the Instructions task card, expand Basic Instructions → Timer operations and drag IEC_Timer into the network.
4. Click the function block header and change its type from IEC_TP_0 to IEC_TON_0 (or whichever subtype matches the original TON behavior).
5. Wire the Enable input to the equivalent of the original IN input. Wire the time-base (e.g. T#1s) to the PT input. Wire Q to the original output coil.
6. Compile the block (Ctrl+B or right-click → Compile).

The resulting block compiles cleanly because the IEC_Timer wrapper is shipped in the current TIA Portal library set and does not require a specific instruction revision to be installed.

Solution 2 — Add TON to the Favorites Bar

TIA Portal maintains a Favorites toolbar whose entries are pre-resolved to the locally installed library set. A TON dragged from Favorites is treated as a self-contained instance with its own private copy of the type description; the resulting reference is bound to the workstation library at insertion time, not to the source template.

1. In the Instructions task card, navigate to Basic Instructions → Timer operations.
2. Right-click TON and select Add to favorites.
3. Drag the TON from the Favorites bar (top of the editor toolbar) into the target network.
4. Compile the block. The instance will reference the active library's TON version, which the compiler can resolve.

This approach is useful when the project must remain a "pure TON" project (e.g. for type-consistency with HMI faceplates that reference the TON instance DB), but it does not protect against future TIA Portal upgrades that remove the specific instruction version.

Solution 3 — Restore the Library Reference

If the error is a "library version not registered" failure (i.e. the TON type is correct for the CPU but the project lost the library that ships the type), the fix is to re-attach the Siemens standard library to the project:

1. In the project tree, right-click the project node and select Properties → Protection & Security → Library version (or the project-wide Library tab in TIA Portal V17+).
2. Verify the active library master contains the entry SIMATIC Standard Library / IEC Timer Functions / TON Vx.x. If absent, click Restore default libraries.
3. If the project was migrated from a newer TIA Portal, in TIA Portal V16 or later open Options → Global libraries → Open library and navigate to the Siemens install path: C:\Program Files\Siemens\Automation\Portal Vxx\Library\SIMATIC Standard Library.
4. Re-compile the project. The compiler should now resolve the TON V1.0 reference.

Solution 4 — Re-Add the S7-1200 Template Correctly

The most common vector for this error is copying a project from the S7-1200 master template supplied with TIA Portal (under File → New → Sample project → S7-1200 template) and then upgrading one of the included blocks. To clean the project:

1. Close all blocks in the editor.
2. In the project tree, expand PLC_x → Program blocks → System blocks and inspect Program resources / Timers. Any timer instance created by the template lives here.
3. Right-click the offending timer and select Reset to factory version. This re-binds the type to the current TIA Portal library.
4. Re-compile the entire project (Project tree → PLC_x → Compile → Software (rebuild all blocks)).

If the template was modified before the upgrade, the reset will lose the modification. In that case, manually re-implement the timer logic in a new block using Solution 1 (IEC_Timer) and delete the old block.

Verification Procedure

After applying any of the four solutions above, perform the following verification before downloading to the PLC:

1. Compiler clean build. Project tree → right-click the PLC → Compile → Software (rebuild all blocks). The "Compile" output window must finish with status Warnings: 0, Errors: 0.
2. Cross-reference audit. Press Ctrl+Shift+F to open the cross-reference list. Filter on TON. Every instance should resolve to a single instance DB. Any item that resolves to a version identifier (e.g. TON_V1_0_DB) indicates a stale reference.
3. Type resolution report. In the project tree, right-click the PLC → Properties → Information → Type resolution (TIA Portal V17+). This report lists every instruction version referenced by the project and confirms that the active library can resolve it. Resolve any entries marked Not found.
4. Online download dry-run. With the PLC connected and STOPPED, attempt to download (Online → Download to device). The dialog should show "No differences in user program" or list only the expected differences. Any error at this stage usually means the compile cleaned the project but a stale instance DB is still on the PLC.
5. Online monitor. Force the Enable input TRUE in the editor and switch to Online → Monitor. Verify that the Q output transitions to TRUE after the preset PT has elapsed, and that ET increments at the configured time base.

Related Diagnostic Messages

When the TON V1.0 error appears, TIA Portal often surfaces additional diagnostics in the same compile run. Knowing them reduces triage time:

How to Identify Which TON Instance Is Failing

The error message names the instruction version ("TON V1.0") but not the specific instance. To locate the offending call:

1. Open the Compile output window after a full project build.
2. Expand the entry under the failing PLC. Each failing call is listed as a sub-entry with the block name and network number.
3. Click the entry — TIA Portal jumps to the network containing the failing TON instance.
4. Hover the TON instance: the tooltip shows the instance DB name and the version of the FB type. Confirm both match the active library.

If the compile output does not list a specific block (which can happen when the failure is a type-resolution issue rather than a call-site issue), use Find and replace (Ctrl+F) with the search term TON and inspect every call site manually.

Edge Case: TON Inside a Multi-Instance FB

When TON is instantiated as a multi-instance (the TON instance is stored in the parent FB's instance DB instead of its own DB), the version binding is more fragile. The compiler can fail to resolve the multi-instance TON if:

• The parent FB was compiled in a different TIA Portal version than the child TON type.
• The parent FB's interface section was modified after the multi-instance TON was added.
• The parent FB was exported and re-imported into a project with a stripped library set.

Fix: open the parent FB, delete the multi-instance TON, re-add it from the active library, and recompile. If the multi-instance is required for HMI faceplate compatibility, re-create it as a single-instance TON in its own DB and update the faceplate tag mapping.

Edge Case: TON Used as an Input to a Custom FB

If a custom FB exposes a TON as an in/out parameter or as a Variant input, the type-resolution check is performed on the custom FB, not the TON itself. The "TON V1.0 data is not supported" diagnostic can therefore point at the custom FB. The fix is the same: re-insert the TON inside the custom FB so that its type binding is refreshed.

Edge Case: TON Inside a Know-How-Protected Block

Know-how-protected blocks (KHP) hide their internal TON type information from the compiler. If the KHP block was compiled against a TON V1.0 instance and the active library no longer ships TON V1.0, the diagnostic surfaces when the KHP block is opened in the editor — not at the call site. The fix is to obtain a re-compiled KHP block from the block author, or to install the Siemens Standard Library version that ships TON V1.0.

Edge Case: Mixed S7-1200 / S7-1500 Project

In a project that contains both an S7-1200 and an S7-1500 PLC, the same TON instruction can be referenced from both controllers. The S7-1500 supports a richer set of instruction versions than the S7-1200, so the compiler can fail to resolve the S7-1500-targeted TON V2.0 against the S7-1200 library. The fix is to compile each PLC separately (right-click the PLC → Compile) and use IEC_Timer in shared library blocks so that the type is resolved at compile time.

Long-Term Best Practices

1. Use IEC_Timer in new code. It is version-agnostic and survives TIA Portal upgrades.
2. Pin the TIA Portal version in source control. Each major TIA Portal release (V16, V17, V18, V19, V20) reorganizes the standard library. Mixing projects across versions is the most common source of the error.
3. Do not modify the S7-1200 master template's timer blocks. Treat them as read-only. If custom logic is required, copy the block, rename it, and apply the modification to the copy.
4. Document the instruction version in the block header comment. When porting a project, the block header comment is the fastest way to confirm whether the block uses TON V1.0, TON V2.0, or IEC_Timer.
5. Re-compile after every TIA Portal upgrade. A clean compile after upgrade confirms that every instruction version still resolves.
6. Maintain a library baseline. Export the Siemens Standard Library version used by each project to a shared network drive. When opening an old project, install the matching library before opening the project.

Troubleshooting Matrix

FAQ