WinCC V7.5 SP1 Text Archive Tag Shows Float in TableControl: Fix

Problem Statement: Text Archive Tags Render as Floating Point Values in TableControl

In WinCC V7.5 SP1 Tag Logging, configuring an archive tag with the data type "Text tag (8-bit character set)" or "Text tag (16-bit character set)" and binding it to an internal Text tag for change-driven archiving produces the expected rows in the SQL backend. When the same archive tag is displayed inside a WinCC TableControl (OnlineTableControl or ArchiveControl) on a process screen, the value cell is rendered as a floating point decimal (e.g., 1.0715083E+09, 4.2E+09, or arbitrary values that change with the text payload) instead of the original ASCII or Unicode string. The timestamp column renders correctly, the row appears when the source tag changes, and successive text changes produce different floating point values rather than the literal string content.

Observed environment (from the source report):

• SIMATIC WinCC V7.5 SP1 (Update 4 confirmed in follow-up)
• Windows Server 2016 Standard (also reproduced on Server 2019)
• SIMATIC WinCC/RT Server 7.5 SP1, with WinCC/RT Client 7.5 SP1
• Redundant server pair with multiple WinCC clients
• MS SQL Server 2016 SP2 / 2017 as the WinCC archive database backend

The defect is independent of single-user vs. multi-user project, redundancy configuration (server-server, server-CAS, or single-station), client / server separation, and local vs. remote archive database connection. The defect is reproducible on every client, on the server, and in the WinCC Explorer Tag Logging configuration preview. This confirms the problem is in the archive configuration or the TableControl binding, not in the network or runtime context.

The behavior is also independent of the WinCC service pack level within V7.5. The same root cause exists in V7.4, V7.5, V7.5 SP1, and V7.5 SP2; the symptom becomes more visible after the V7.4 to V7.5 migration because V7.5 introduced additional schema-level validation that does not always re-classify the column after migration. See the WinCC V7.5 SP1 release notes under "Migrated screens" for the related migration behavior.

WinCC Tag Logging: Data Type, Storage, and Projection Stack

SIMATIC WinCC Runtime, when archiving a tag, executes the following projection chain. Each link in the chain holds its own type metadata. A mismatch at any link produces a wrong rendering at the consumer without any error message in the runtime.

1. Source tag: An internal tag of type "Text tag (8-bit character set)" or "Text tag (16-bit character set)" is held in the WinCC tag management. The text payload is a sequence of characters. Maximum length is defined by the configured tag length, default 256 characters in V7.5 SP1, extendable to 512 in the project database.
2. Archive tag: A reference inside the Tag Logging editor that points at the source tag and defines the archive cycle, compression behavior, and crucially the data type. The archive tag's data type must match the source tag's data type exactly. If the source is a Text tag, the archive tag must also be configured as "Text tag". Selecting "Binary tag" or any numeric type here is the single most common cause of the symptoms in this article.
3. SQL backend: WinCC writes the archived value into a compressed value table. The compressed value is a binary payload stored in a column whose physical type is mapped at runtime by the WinCC archive service. For text tags, the payload contains the raw character bytes (UTF-8 for 8-bit, UTF-16 little-endian for 16-bit) packed as binary, not the text string itself. WinCC does not store a textual "value" for text tags; it stores the byte sequence.
4. TableControl column: When the screen designer binds a column of the TableControl to the archive tag, the column has its own "DataFormat" / "Column type" property that controls how the binary payload is interpreted and rendered. If the column's data format is numeric, the text bytes are reinterpreted as an IEEE 754 float and the cell shows a meaningless floating point number. The TableControl is the unique consumer that defers to the column configuration; external consumers (OPC UA HDA, Connectivity Pack, OLE-DB) honor the type metadata returned by the archive service and render the text correctly.

The chain has two places where a "type" can be defined: the archive tag configuration, and the TableControl column configuration. A mismatch in either of them produces the symptom described in the source case.

See the SIMATIC WinCC V7.5 SP1 manual collection for the Tag Logging configuration reference and the SIMATIC HMI WinCC V7.5 product support page for the full documentation set.

Figure 1: WinCC Tag Logging projection chain. The data is stored correctly as text bytes in the SQL backend; the TableControl column configuration is the link that reinterprets the payload as numeric.

Why a Text Value Is Reinterpreted as a Float

WinCC stores text-typed archive values in the same physical compressed value table that holds numeric archive values. The compressed value table has a single column for the value (a VARBINARY or equivalent physical type). The "type" of the value is not stored inside the table; it is held in the Tag Logging configuration metadata and is later reconstituted by the consumer.

When the TableControl asks for "value of archive tag X at time t", the WinCC archive service returns the raw binary payload plus the metadata describing how the payload should be interpreted. The column configuration in the TableControl dictates which metadata field drives the rendering:

• If the column is configured as a numeric column (DataFormat = "Float", "Decimal", or any numeric format), the payload is treated as a 32-bit or 64-bit IEEE 754 floating point number. The raw bytes of the text string are interpreted as if they were the IEEE 754 bit pattern, producing a large, meaningless floating point value. This is exactly what the engineer in the source case observed.
• If the column is configured as a text column (DataFormat = "Text", "String", or "Character"), the payload is decoded as a character array and rendered as the original string. This is the correct setting for a text-typed archive tag.

The floating point value is therefore not a "wrong value" in the database; it is a wrong interpretation by the TableControl of a value that was stored correctly. The same database row will display the literal text string in any consumer that knows to read the bytes as text - a properly configured TableControl, the Online Trend Control with a text column, or a direct MS SQL query that converts the VARBINARY to VARCHAR / NVARCHAR via CAST / CONVERT.

This explains why the value is "different for new text" in the source report. Each different text string has a different byte pattern; each byte pattern reinterpreted as IEEE 754 produces a different floating point value. The mapping is deterministic and one-to-one, so the floating point output is a valid encoding of the original bytes - just the wrong encoding for a text rendering.

Configuration Audit: Internal Tag vs. Archive Tag Data Type

Before touching the screen, verify the archive tag itself. Open WinCC Explorer, expand "Tag Logging", and locate the affected archive. The following checks should pass before the TableControl is touched at all.

If the archive tag's "Data type" is configured as anything other than Text, the symptom is structural. Re-importing the tag with the correct type is the first fix to attempt. Changing the data type of an existing archive tag is not supported at runtime; the archive tag must be re-created or the archive re-imported. Confirm the change by deleting the archive tag, recreating it pointing at the same internal Text tag, and reloading the runtime data on the server.

A common commissioning mistake is to copy a numeric archive tag and re-point it at a text source without changing the archive tag's "Data type". WinCC does not auto-promote or auto-convert the type, so the numeric type sticks and the binary payload is interpreted as numeric downstream. This mistake is silent - the archive works, the timestamps are correct, the row count is correct, and the consumer misinterprets the value. There is no warning in the WinCC event log.

Step-by-Step Resolution: Configure the TableControl Column DataFormat

The corrective action is in the Graphics Designer, on the screen that hosts the TableControl. Perform the following steps on every screen that displays the affected archive tag.

1. Open the screen in Graphics Designer. On the server, navigate to the project folder and open the relevant .pdl file. On a client, the screen is loaded from the server project directory. Avoid editing on a client project while a runtime is in operation; the server copy is authoritative.
2. Select the TableControl on the screen. The control is named "WinCC OnlineTableControl" or a custom-named instance. Double-click to enter configuration mode (alternatively right-click -> "Configure...").
3. Open the column editor. The configuration dialog shows the columns currently bound to archive tags. Locate the column that displays the value of the text archive tag. The "Name" or "Tag" property will reference the affected archive tag.
4. Set the column data format. In the column properties, locate the property group "Columns" and the property that controls the data format. In the V7.5 SP1 WinCC Control, this is the "DataFormat" or "Representation" property. Set it to the value matching the underlying archive tag type:
   • For an 8-bit text archive tag: select "Text" (or "String" depending on the WinCC build language)
   • For a 16-bit text archive tag: select "Text" (the control handles UTF-16 transparently)
5. Set the column type. Some builds expose a separate "Column type" property. Confirm that it is set to "Text" and not "Numeric" or "Date/Time".
6. Confirm the time column format. The time column should remain in Date/Time format; do not change it to text.
7. Save the screen with Ctrl+S or File -> Save. WinCC prompts to regenerate the runtime data; allow the regeneration.
8. Recompile / retransfer. For server projects, the screen change is effective on the next runtime start or on the next screen reload. For client projects, redeploy the screen to the client or rely on the server's automatic screen distribution.
9. Activate runtime and verify. Trigger a change of the internal Text tag and confirm that the TableControl cell now shows the literal string.

The change is a runtime-data modification only. It does not require a WinCC reinstall, a project recompile, or a service restart. The screen file is touched, and the runtime data folder under the project (server: <project>\RT\<computername>\; client: <project>\RT\Client\<computername>\) is regenerated.

For a screen containing multiple TableControls, repeat the procedure for each. A TableControl configured for one archive tag does not affect the columns of another TableControl. Audit every column bound to a text-typed archive tag, project-wide, by opening the screen list in Graphics Designer and walking each .pdl file.

SQL Backend Verification: Inspecting the Compressed Value Tables

To confirm the archive is being written correctly and to differentiate between "the data is wrong" and "the display is wrong", inspect the SQL backend directly. The WinCC archive database is created per project and contains the compressed value tables alongside the configuration tables. See the SIMATIC WinCC V7.5 SP1 Tag Logging manual for the schema reference.

Step A: Locate the archive database

Open SQL Server Management Studio on the server hosting the WinCC archive database. The default archive database name follows the pattern CC_<TAGPREFIX>_<ProjectName>_<Date_Time>_<Random>. The Tag Logging database is the one with the suffix TLG_ (or TLG_Default_ in single-station deployments). In a redundant configuration there are two databases, one for the master and one for the standby server, kept consistent by the WinCC redundancy service. Confirm the database is online and the WinCC archive service is connected.

Step B: List the compressed value tables

The compressed values live in tables whose names contain ARCHIVE_DATA, VALUE, or TLG_. The typical naming for a V7.5 SP1 project is:

[dbo].[TLG_FAST_ARCHIVE_DATA]
[dbo].[TLG_SLOW_ARCHIVE_DATA]
[dbo].[TLG_PROCESS_DATA]

TLG_FAST_ARCHIVE_DATA holds values for the fast archive cycle; TLG_SLOW_ARCHIVE_DATA holds the slow cycle. TLG_PROCESS_DATA holds raw values before compression. For a "On change" archive, the values will appear in the process data table and then propagate to the compressed table on the next compression cycle.

Step C: Confirm the archive tag is configured as Text

Run the following query against the configuration tables to inspect the data type of the archive tag. The exact column names depend on the SQL schema version. For V7.5 SP1 the configuration tables include the archive and tag definitions.

SELECT
    a.ArchiveName,
    t.TagName,
    t.DataType,
    t.Length
FROM dbo.TLG_ARCHIVE AS a
INNER JOIN dbo.TLG_TAG AS t ON t.ArchiveID = a.ArchiveID
WHERE t.TagName LIKE '%YourTextTag%';

The expected value of DataType for a text tag is 7 / 8 (8-bit) or 9 (16-bit) in most V7.5 SP1 schema versions. The mapping is:

If the value is 4 (Float 32) or 5 (Float 64) or any other numeric value, the archive tag has been misconfigured and the symptom is structural, not a display issue. The fix is to delete and recreate the archive tag with the correct data type.

Step D: Read the raw value as text

To confirm that the binary payload is in fact a text string, convert the value column to VARCHAR or NVARCHAR at query time:

SELECT TOP 50
    v.Timestamp,
    CAST(v.Value AS VARCHAR(256)) AS TextValue8Bit
FROM dbo.TLG_FAST_ARCHIVE_DATA AS v
INNER JOIN dbo.TLG_TAG AS t ON v.TagID = t.TagID
WHERE t.TagName = 'YourTextArchiveTag'
ORDER BY v.Timestamp DESC;

For 16-bit text, substitute NVARCHAR:

SELECT TOP 50
    v.Timestamp,
    CAST(v.Value AS NVARCHAR(256)) AS TextValue16Bit
FROM dbo.TLG_FAST_ARCHIVE_DATA AS v
INNER JOIN dbo.TLG_TAG AS t ON v.TagID = t.TagID
WHERE t.TagName = 'YourTextArchiveTag'
ORDER BY v.Timestamp DESC;

If this query returns the expected text, the archive is correct. The TableControl is the only component misinterpreting the value.

Step E: Read the raw bytes as IEEE 754 (to reproduce the floating point symptom)

To reproduce the exact floating point number that the TableControl is showing, force-cast the binary payload as FLOAT:

SELECT TOP 50
    v.Timestamp,
    CAST(CAST(v.Value AS BINARY(8)) AS FLOAT) AS ValueAsFloat64,
    CAST(CAST(v.Value AS BINARY(4)) AS REAL) AS ValueAsFloat32
FROM dbo.TLG_FAST_ARCHIVE_DATA AS v
INNER JOIN dbo.TLG_TAG AS t ON v.TagID = t.TagID
WHERE t.TagName = 'YourTextArchiveTag'
ORDER BY v.Timestamp DESC;

The numbers returned by this query are exactly the values the TableControl is showing when the column is misconfigured as numeric. This is the proof that the symptom is a column configuration problem, not a database corruption.

Redundant Server Pair and Client Distribution Considerations

In a WinCC V7.5 SP1 redundant server pair with multiple clients, the TableControl configuration is held in the project (server project) and distributed to clients during the standard server-client synchronization. The SQL backend, however, is owned by the active master server; the standby server keeps a synchronized copy of the archive database.

The implication for this issue:

• If the screen is corrected only on the master server project, the standby will pick up the change on the next redundancy sync. No manual intervention on the standby is required.
• Clients with a local copy of the project (e.g., a client that runs with a local project rather than a server-projected client) must be updated separately. A "Load Online" operation on the client downloads the latest server project; the screen is refreshed with the new column configuration.
• Both server archives should be inspected during verification. Run the SQL queries in the previous section against both the master and standby archive databases to confirm the data is consistent.
• While the master and standby are swapping roles (failover or planned), the TableControl may briefly show a "No connection" status. This is not the defect in this article; it is the standard WinCC redundancy behavior.

The original report indicated the defect was visible on a redundant pair. The redundancy setup is not the cause; the cause is a single project configuration that is distributed unchanged to both servers and all clients.

Edge Cases and Common Pitfalls

Pitfall 1: Tag length truncated

If the source Text tag is, for example, 32 characters long but the archive tag length is 16, the archive stores the first 16 characters. The TableControl will display 16 characters correctly when the column is fixed. This is a common surprise when migrating from a smaller to a larger string. Re-create the archive tag with the new length and confirm that the source tag length is also appropriate.

Pitfall 2: 8-bit vs. 16-bit mismatch

If the source is a 16-bit text tag but the archive tag is configured as 8-bit (or vice versa), the byte sequence is interpreted with the wrong endianness and character set. The TableControl will render non-ASCII characters or render nothing visible. Confirm both the source and archive data type match (8-bit paired with 8-bit, 16-bit paired with 16-bit).

Pitfall 3: Value out of archive cycle

A value that changes faster than the configured archive cycle may be dropped by the compressor. This does not produce a floating point symptom; it produces a missing row. The defect in this article is not a missing row - the row is present but the value is misinterpreted.

Pitfall 4: Multiple archive tags on the same TableControl

A TableControl can host many columns. A misconfigured column for one archive tag does not affect the others. The fix is per column, not per TableControl. When auditing, walk every column on the screen that is bound to a text-typed archive tag.

Pitfall 5: Online configuration vs. offline configuration

The TableControl column configuration is part of the offline screen. Changes made through the online configuration dialog (right-click -> "Configuration..." in runtime) are runtime-only and do not persist. To make a permanent fix, the offline screen must be modified. The same applies to the column "Online configuration" which only affects the running client.

Pitfall 6: OPC UA Historical Access consumer

External consumers (OPC UA Historical Access on the WinCC server, Connectivity Pack, OLE-DB) reading the same archive tag will display the text correctly because they honor the type metadata returned by the WinCC archive service. The TableControl is the unique consumer that defers to the column configuration, which is why this symptom is visible only in the TableControl and not in OPC UA HDA clients.

Pitfall 7: Project migration from V7.4 to V7.5 SP1

When migrating a project that had a correctly configured V7.4 archive to V7.5 SP1, the column configuration in the TableControl can be reset to a default if the screen was opened in a V7.4 editor and then migrated. Re-validate every TableControl column after a major migration. This is documented in the WinCC V7.5 SP1 release notes under "Migrated screens".

Pitfall 8: Mixed character set in the source

If the source PLC writes ASCII into a tag defined as 16-bit Unicode (or vice versa), the byte count differs from the character count and the CAST-to-NVARCHAR query may show trailing NULs or empty cells. Validate the source PLC's string format matches the WinCC tag declaration. The fix is in the PLC code, not in the WinCC configuration.

Pitfall 9: Runtime data folder not regenerated

After saving the screen in Graphics Designer, WinCC generates the runtime data files in <project>\RT\. If the runtime is already active and the file generation is blocked by a file lock, the new column configuration does not take effect until the runtime is restarted or the file lock is released. Stop and start the WinCC Runtime to force a refresh.

WinCC Version and SQL Server Compatibility

The defect is reproducible across the following versions and configurations. Always pin the runtime to a tested version combination before declaring the issue closed.

For SQL Server Express (the default with a single-user WinCC installation) and SQL Server Standard (used in multi-user / redundant deployments), the underlying schema is the same and the symptom is identical. The choice of SQL Server edition does not affect the symptom or the fix.

Field-Proven Commissioning Verification Checklist

Use this checklist after applying the fix to confirm the issue is resolved and the surrounding functionality is intact.

If all checks pass, the issue is closed. If the SQL backend returns the correct text but the TableControl still shows a float, the column configuration has not been reloaded - close the screen, re-open the project, and re-trigger the runtime data regeneration. In some V7.5 SP1 builds the runtime data is cached and requires a project retransfer to invalidate.

For a long-running project, perform this check after every major WinCC update, every project migration, and every modification of the Tag Logging configuration. The defect is silent and will not show up in the WinCC event log or in the project consistency check.

Frequently Asked Questions