WinCC V7.4 Tag Logging Action for Processing Silently Drops

1. Problem Summary

In SIMATIC WinCC V7.4 (the pre-TIA classic SCADA line, distinct from WinCC Runtime Professional in the TIA Portal), a tag logging entry configured with Processing = Action and a user-defined Action for processing C-function silently reverts to an empty cell the next time the project is opened in WinCC Explorer. While the project is loaded, the action executes correctly, the logged value is modified, and the runtime data appears in the tag logging database as expected. The configuration loss only manifests after WinCC Explorer is closed and the project is reloaded; at that point the column value is empty and the action no longer runs.

No compiler error, no compiler warning, and no editor validation message is raised in either the Global Script C editor (where the function lives) or the Tag Logging editor (where it is referenced). The defect is a length-validation gap in the Tag Logging configuration write path: the in-memory column control accepts the long name, but the persistence layer rejects it on the next read cycle, leaving the cell blank on reopen.

2. Affected Versions and Scope

The defect is independent of whether the logging tag uses a cyclic acquisition, an event-driven acquisition, or a command-triggered acquisition. It is also independent of the storage location of the logged values (SQL Server native archive, Sybase SQL Anywhere archive, or the legacy file archive). It is, however, scoped to project functions in the project functions group; standard functions added to individual graphics pictures are stored in a different persistence path and are not subject to the same length budget.

3. Root Cause Analysis

3.1 WinCC configuration persistence model

Tag logging configuration in WinCC V7.4 is persisted in the project database CC_Logging.mdf (or the equivalent .mdf / .ldf pair on the engineering station) inside the project's database directory. Each logging tag's processing action is stored as a row in the configuration tables with the function name in a fixed-width column. The persistence layer's write path serialises the name string into this fixed-width field. The read path deserialises the same field on project open and rebuilds the editor's in-memory model.

The 30-character effective limit is a function of the column width assigned to the ActionForProcessing field in the schema used by V7.4. Names up to 30 characters round-trip without loss. Names at exactly 31 characters or longer are accepted by the in-memory editor control (a standard Windows edit control that has no project-specific length cap wired into it), but the write path silently truncates or drops the over-budget value because the column is not auto-extended. The defect becomes visible only on the next project open when the read path returns an empty string.

3.2 C function naming rules in WinCC

WinCC's C scripting engine (the WinCC Global Script C compiler) follows the ISO C / ANSI C identifier rules, with a WinCC-specific length cap. The de-facto limit is 31 significant characters, which is consistent with the C89/C99 standard's minimum requirement for external identifier significance. The WinCC C compiler accepts project function names up to and including 31 characters and compiles them into the project's C-script runtime DLL. The Global Script editor's Compile All step does not flag names of 31-32 characters as warnings; the script is considered valid.

Where the breakdown occurs is at the boundary between the C compiler (which validates syntax and identifier shape) and the configuration consumers (Tag Logging, Alarm Logging, Scheduler, Global Script actions) that reference the C function by name. Each consumer has its own column width, its own write path, and its own read path; the C compiler does not cross-validate the name against the length budget of every consumer. Tag Logging's column is the narrowest in the V7.4 line, hence it is the consumer that fails first.

3.3 The editor validation gap

The Tag Logging editor's column-edit control is a standard grid cell. It accepts the full 31-character (or longer) string from the keyboard and visually displays it. Pressing Enter commits the value to the in-memory model and the action runs at runtime because the runtime read path consults the in-memory model. The persistence write, however, is deferred and is triggered when WinCC Explorer commits the configuration - typically on project save, project close, or when the editor's Apply / OK handler runs.

Because the visual feedback (the cell shows the long name) and the build feedback (the C function compiles) are both positive, the engineer has no indication that the configuration is being silently dropped. The first time the defect surfaces is on the next project open, which can be hours, days, or weeks later. This is the field signature of the bug: the action ran on the project that was open when the function name was typed, but it does not run on the next project that is opened after WinCC Explorer was closed.

4. Reproduction Procedure

1. Open WinCC Explorer on a project that uses the Tag Logging module.
2. Expand Global Script → C functions and confirm the project functions group is present (right-click → New Function if not).
3. Create a new C function in the project functions group with a 31-character name, for example:

   /* 31-character function name */
   void LogProcessing_Action_V7_Four(void)
   {
       /* body: read setpoint tag, return scaled value */
       return;
   }

4. Compile the function. Confirm Compile → OK with zero warnings or errors.
5. Open Tag Logging in the navigation tree. Select or create a logging tag (process tag, raw data tag, or compressed tag).
6. In the row for the selected logging tag, set the Processing column to Action using the dropdown.
7. In the Action for processing column on the same row, type the full 31-character function name (LogProcessing_Action_V7_Four) and press Enter.
8. Start WinCC Runtime (Activate in the toolbar) and trigger the logging event. Verify the logged value is modified by the action in the tag logging archive.
9. Deactivate Runtime, close WinCC Explorer completely.
10. Reopen the project in WinCC Explorer and inspect the same row: the Action for processing cell is empty.

If steps 1-10 are followed exactly, the cell is empty at step 10. If the function name is shortened to 30 characters or fewer, the cell round-trips correctly across project close and reopen.

5. Diagnostic Checklist

Use the following checks to confirm the defect is the 30-character cap and not a different configuration issue (corrupt database, missing function reference, wrong project state):

To inspect the persisted configuration directly, attach CC_Logging.mdf in SQL Server Management Studio (the project must be closed and the WinCC SQL service stopped first) and query the configuration table for the affected tag. The relevant column is the action-name string in the tag's processing row; an empty or truncated value confirms the persistence write dropped the name.

6. Workarounds

The defect has no software fix in V7.4 base through V7.4 Update 5; the engineer-side resolution is to keep all C function names referenced by Tag Logging at or below 30 characters. The following strategies are listed in order of preference.

6.1 Primary workaround: shorten the function name to 30 characters or fewer

Rename the C function in the Global Script editor and update every reference (Tag Logging, Alarm Logging, Scheduler, picture scripts, other C functions). A 30-character function name leaves a thin margin for safe re-use across the project. Example rename pattern (replace long descriptive names with prefix-coded short names):

/* Before: 38 characters */
void LogProcessing_Action_ForTagFlow1234(void)

/* After: 24 characters */
void lp_Flow1234(void)

When renaming, search the project for all references using the WinCC cross-reference tool (Tools → Cross Reference) or by exporting the project source and grepping for the old name. Update every reference before compiling to avoid dangling references.

6.2 Secondary workaround: dispatch through a thin wrapper function

Keep the long, descriptive C function name in the Global Script project functions, and create a 30-character-or-shorter wrapper function that calls the descriptive function. Point the Tag Logging Action for processing at the wrapper. The wrapper is the only consumer constrained by the length budget.

/* Descriptive function (any length) */
void LogProcessing_Action_ForTagFlow1234_Detailed(void)
{
    /* full pre-processing logic */
    return;
}

/* Wrapper (25 characters, well under the 30-char budget) */
void lp_Flow1234(void)
{
    LogProcessing_Action_ForTagFlow1234_Detailed();
    return;
}

This pattern is the cleanest engineering solution because it preserves the descriptive naming for code review while satisfying the consumer's length budget. It also gives a single point of insertion for any future migration when a WinCC version is adopted that does not have the 30-character cap.

6.3 Migration-safe workaround: encode long names as 30-character tokens

For large projects with many long function names, generate a mapping table from descriptive names to 30-character tokens. Use a prefix convention that identifies the module, the tag, and a sequential index. Document the mapping in a project-side README inside the WinCC project folder so that future maintainers can resolve tokens back to descriptive names.

/* Token convention: lp_<TagID3>_<Seq3> (10 chars + body = 30 max) */
void lp_FLW_001(void); /* -> LogProcessing_FlowSensor_001_PressureScale */
void lp_FLW_002(void); /* -> LogProcessing_FlowSensor_002_TempCompensate */

6.4 Bulk-rename script (VBScript)

For projects with many over-budget function names, the rename can be automated with a WinCC-side VBScript that walks the project functions group, identifies names > 30 characters, and proposes a short token. Run from the Global Script C editor's command line or as a maintenance script under WinCC ScriptControl:

' Inspect C function names; print over-budget entries
Dim fso, folder, f, nameLen
Set fso = CreateObject("Scripting.FileSystemObject")
Set folder = fso.GetFolder("<project>\\library\\CFunctions\\ProjectFunctions")
For Each f In folder.Files
    nameLen = Len(f.Name) - Len(".c")
    If nameLen > 30 Then
        WScript.Echo "OVER BUDGET: " & f.Name & " (" & nameLen & " chars)"
    End If
Next

Use the script output as the input to the rename / wrapper strategy of choice. Do not run rename scripts against an open project; close WinCC Explorer before modifying the C function source files.

7. Verification

1. After applying the workaround, open WinCC Explorer on the project.
2. Confirm every C function referenced by Tag Logging is ≤ 30 characters. The diagnostic checklist in section 5 should now show all rows passing the "name length ≤ 30" check.
3. Compile the Global Script C project. Confirm zero errors and zero warnings.
4. In Tag Logging, populate the Action for processing column for each affected tag.
5. Activate Runtime and trigger the logging event. Verify the action modifies the logged value.
6. Deactivate Runtime and close WinCC Explorer completely.
7. Reopen the project. Verify the Action for processing cell is still populated for every tag.
8. Repeat the close → reopen cycle two additional times to rule out intermittent persistence failures.
9. Inspect CC_Logging.mdf directly via SQL Server Management Studio and confirm the persisted name matches the in-editor value.

8. Long-Term Resolution Path

Because the defect is in the WinCC V7.4 base product, the long-term fixes are:

1. Service Request to Siemens Technical Support. Open a Service Request via the Siemens Industry Online Support portal and attach the affected project (or a sanitised reproduction project). Reference the symptom: "Tag Logging Action for processing column empties on project reopen when the referenced C-function name exceeds 30 characters." Siemens may release a hotfix or include the fix in a later V7.4 SP / Update, or escalate to a V7.5 behaviour change.
2. Project migration to V7.5 or later. SIMATIC WinCC V7.5 and subsequent V7.x SP lines have extended the relevant column width. Migration to a version with the fix is the durable resolution. Plan the migration with the standard V7.x migration guide and re-test all tag logging actions after migration.
3. Migration to TIA Portal / WinCC Runtime Professional. For new projects, the TIA Portal-based WinCC Runtime Professional data logging model uses a different configuration model that does not exhibit this column-width issue. The TIA Portal model is the strategic target for greenfield projects.

9. Project Function Name Best Practices

To avoid this class of defect and its analogues in other WinCC consumers, adopt the following conventions for C function names in WinCC projects:

10. Tag Logging Action for Processing - Configuration Reference

The Action for processing property is one of two pre-processing modes in Tag Logging; the other is Formula (an inline expression). Both are configured per logging tag in the Tag Logging editor's grid view. The complete configuration model is documented in the WinCC V7.4 information system under Tag Logging → Logging Tags → Processing. Conceptually, the data logging configuration in WinCC Runtime Professional (the TIA Portal successor) is the modern reference for the same conceptual model.

11. Cross-Module Validation Gap - Other Affected Areas

The 30-character cap is Tag Logging's specific column width. Other WinCC configuration consumers have their own length caps, all of which can fail with the same silent-drop pattern. Treat the 30-character rule as the tightest constraint in the project, but be aware of the adjacent consumers:

Adopting a single project-wide convention of ≤ 24 characters for any C function referenced by a configuration consumer eliminates the entire class of silent-drop defects.

12. Troubleshooting Matrix