Resolving SCOUT V4.1 Warning 16013 on DT Data Type Variables

Problem Overview

Engineers commissioning SIMOTION SCOUT V4.1 with SINAMICS SM150 drives on SIMOTION D445 controllers frequently encounter compiler warning 16013: Data type "DT" is not portably convertible when a global device variable of type DATE_AND_TIME (DT) is added to the project and then read from the add_on source file. The warning is non-fatal — the source generates successfully, the project builds, and the controller goes online — but it indicates a real portability hazard: a DT variable cannot be reliably serialized across the SIMOTION runtime boundary when consumed by a non-SIMOTION HMI such as SIMATIC WinCC V7.x via OPC.

The reported project in this case study contains six D445 stands (N1_A_D445_Stand_1 through N6_A_D445_Stand_5/6) driving SINAMICS SM150 sections, with a custom add_on ST source file at line 138 that surfaces the warning. This reference documents the root cause, the accepted Siemens remediation patterns, the migration to the IEC 61131-3 DTL type where required, and the end-to-end OPC publishing workflow for delivering those global device variables into WinCC.

System Environment and Topology

The reference configuration that produced the warning is summarised in the table below. Values are derived from the project header in SCOUT V4.1 and from the official SIMOTION V4.1 SPx compatibility matrix.

Compiler Warning 16013: Root Cause

Warning 16013 is emitted by the ST (Structured Text) compiler in SCOUT when a variable is declared with the legacy data type DATE_AND_TIME (DT) and that variable is referenced in a context that SCOUT has classified as a portability boundary. Portability boundaries are code constructs that may be regenerated, exchanged with another SIMOTION device, or — most importantly — exported to an OPC namespace where the consumer is a Windows application (WinCC, third-party SCADA, or an OPC bridge).

The exact compiler output from the reported project is:

Information: START of compilation of 'add_on' at 15:10:33
Warning: add_on(138) : 16013 : Data type "DT" is not portably convertible
Information: END of compilation of 'add_on' at 15:10:33
Information: Compilation of add_on: 0 Error(s), 1 Warning(s)

The warning refers to a specific declaration at add_on.st line 138. Typical offending declarations look like the samples below:

// Offending declaration (warning 16013)
VAR_GLOBAL
    g_stTimestamp : DATE_AND_TIME;   // DT - 64-bit, BCD-encoded, non-portable
    g_dtSample    : DT;              // alias form, same warning
END_VAR

Why DT Fails the Portability Check

The DT type is a 64-bit BCD-encoded structure that was specified in IEC 61131-3 first edition. Its byte layout depends on the SIMOTION runtime implementation and is not aligned with the OPC DA standard binary representations used by WinCC. The SCOUT compiler therefore flags any DT value that may be transported outside the SIMOTION process image as not portably convertible. The runtime will still hold the value correctly inside the device, but external tooling that tries to read the symbol will receive an opaque BCD blob.

This is distinct from error 16012 (not convertible at all); 16013 means the value can technically be moved, but it cannot be interpreted by a non-SIMOTION consumer without a custom conversion block.

Data Type Comparison: DT vs DTL vs STRING vs DWORD

The remediation strategy is to substitute DT with a type that is natively representable in OPC. The table below compares the four practical options for storing a timestamp in a SIMOTION global device variable intended for HMI consumption.

Recommendation: For new code in SCOUT V4.1, declare the timestamp as DTL inside the SIMOTION program and expose a derived STRING or DWORD representation as the OPC-visible global device variable. The internal DTL value preserves nanosecond resolution for control loops; the OPC value delivers a clean WinCC tag.

Resolution Path A — Convert DT to STRING

The fastest path when the HMI only needs a human-readable timestamp is to convert the DT to STRING before the OPC export. This eliminates warning 16013 because STRING is a portable type for OPC.

1. Open the add_on source in the SCOUT program editor.
2. Locate line 138 (or the line reported by the compiler). Replace the DT declaration with a STRING buffer.
3. Add a conversion at every write site using the SIMOTION system function DT_TO_STRING or DTL_TO_STRING if you migrate to DTL.

VAR_GLOBAL
    // Replaces the DT that triggered warning 16013
    g_sTimestamp : STRING[19];   // YYYY-MM-DD HH:MM:SS\0
END_VAR

// Conversion example
g_sTimestamp := DT_TO_STRING(g_dtInternalTimestamp);

Resolution Path B — Use DTL Internally, Expose DWORD Seconds

Path B is the preferred pattern when the timestamp participates in control logic (interlocks, sequence timing, motion gating) where nanosecond resolution matters. DTL is the IEC 61131-3 second-edition type and is fully supported by SCOUT V4.1.

VAR_GLOBAL
    g_stTimestamp  : DTL;             // nanosecond resolution, portable
    g_dwUnixTime   : DWORD;           // OPC-visible, 32-bit seconds since epoch
END_VAR

// Update once per scan
g_stTimestamp := CURRENT_DTL;
g_dwUnixTime  := DTL_TO_DWORD(g_stTimestamp);

The g_dwUnixTime tag is the OPC-published symbol. In WinCC, format it with a dynamic text or a C script that converts the DWORD back into a date string using the WinCC standard function FormatDateTime.

Resolution Path C — Restrict DT to SIMOTION-to-SIMOTION Boundaries

If the DT variable will only be consumed by another SIMOTION device on the same project (for example a peer D445 exchanging tags via the _exchangeVars mechanism), warning 16013 is informational rather than critical. SCOUT will still generate the OPC symbol, but downstream SIMOTION devices read it as a DT and convert internally with no loss of fidelity.

To make the intent explicit and silence the warning without changing the wire format, add a comment block and a pragma at the declaration:

VAR_GLOBAL // pragma(off, "16013")  // DT is intentional, used SIMOTION-side only
    g_dtPeerSync : DATE_AND_TIME; // consumed by peer D445 via _exchangeVars
END_VAR

Publishing Global Device Variables to WinCC V7.0 via OPC

Once the DT warning is resolved, the global device variable can be exposed to WinCC. The OPC server in SIMOTION is built into the runtime and surfaces every exported symbol under the SIMOTION device name. WinCC V7.0 acts as an OPC DA client.

High-Level Data Flow

Configuration Steps in SCOUT

1. Open the project, navigate to the affected SIMOTION device (e.g. N1_A_D445_Stand_1) and double-click Symbol browser in the detail view.
2. Confirm you are in offline mode (the symbol browser tab is editable only offline in SCOUT V4.1).
3. Right-click the table and choose Add new symbol. Assign a name (for example g_sTimestamp) and select the corresponding global device variable as the data source.
4. Set the OPC attribute for the symbol to accessible / writable as required.
5. Save and recompile the project (Save and compile shortcut). Verify that warning 16013 no longer appears in the add_on source.
6. Download the project to the D445 (all six stands if the global is shared).

Detailed, version-pinned instructions for creating and exporting global device variables are documented in the official Siemens documentation:

• Use of global device variables in SIMOTION SCOUT (Structured Text)
• Creating global device variables in the symbol browser

Configuration Steps in WinCC V7.0

1. Open the WinCC Explorer on the HMI station.
2. Right-click Tag Management > OPC > OPC Groups and select System Parameters. Add the SIMOTION OPC server as a remote server. The ProgID is Siemens.SIMOTION.OPCServer.1.
3. Configure DCOM on the WinCC station and on the SIMOTION PC (or CX/IBN-PN station) to allow anonymous launch and access for the SIMOTION service account.
4. In the tag management, browse the OPC namespace. The SIMOTION OPC server exposes tags under SIMOTION.<DeviceName>.<SymbolName>, for example SIMOTION.N1_A_D445_Stand_1.g_sTimestamp.
5. Add the tag to a WinCC internal tag group. Recommended update cycle: 1000 ms for status, 250 ms for control interlocks.
6. In the Graphics Designer, bind the tag to an I/O field for display or to a Status display for indication.

Verification and Acceptance Test

Acceptance is a three-stage check. All three must pass before the project is signed off.

1. Trigger a forced refresh in SCOUT (Project > Save and compile all). Confirm 0 Error(s), 0 Warning(s) in the output pane for every stand.
2. Go online to N1_A_D445_Stand_1. Open the symbol browser and confirm the OPC attribute is set and the current value is non-zero.
3. In WinCC, open the diagnostics overview (Tools > Status of Driver Connections) and confirm the OPC channel reports OK.
4. Force a write from WinCC (set the tag to a known string). Verify in SCOUT that the runtime value follows within the cycle window.

Common Pitfalls and Field-Proven Caveats

• STRING length mismatch. SCOUT STRING[n] allocates n+1 bytes. If WinCC allocates a buffer of length n, the trailing null terminator is dropped and the next byte leaks into the next tag. Always size WinCC string tags to n+1.
• Stand-specific recompile. In multi-stand projects, fixing the warning on one stand does not propagate automatically. Use Save and compile all rather than Compile add_on on the stand.
• Pragmas in HF levels prior to HF5. pragma(off, "16013") is not always honoured. Verify on a test stand before relying on it for production sign-off.
• OPC tag polling vs subscription. WinCC V7.0 defaults to subscription (advise loop). On a heavily loaded network this can be starved by PROFINET I/O. Move high-priority tags to a separate group with a 250 ms cycle.
• SM150 regeneration. When the SINAMICS SM150 is auto-recommissioned by the add_on source after a CU replacement, the timestamp variable is reinitialised. Verify the conversion block runs in _initialize so the OPC tag stays valid.
• Multi-language WinCC projects. STRING values are not auto-localised. If the HMI needs regional date formats, perform the conversion on the HMI side (WinCC C script with locale lookup) rather than baking the format into the SIMOTION STRING.

Troubleshooting Matrix

Multi-Stand Rollout Checklist

1. Apply the chosen remediation (A, B, or C above) to the shared library that contains the add_on source.
2. Increment the library version (e.g. from V1.2 to V1.3) so the consuming projects pick up the change.
3. Open each of the six stand projects and accept the library update.
4. Run Save and compile all. Confirm zero warnings matching 16013 in every stand.
5. Download to each stand in turn; verify online symbol presence.
6. In WinCC, replicate the OPC tag configuration across the six device folders.
7. Run the acceptance test per stand before re-enabling production.

Reference: SCOUT V4.1 Compiler Warning 16013 Summary