WinCC TDC PMC V6.2: Resolving Authorization and Multi-CPU Errors

Problem Overview

When commissioning a PCS7 V7.0 station that communicates with a SIMATIC TDC rack, two recurring faults block process data exchange between WinCC and the TDC CPUs. The first fault is a startup authorization error raised by the WinCC channel TDC PMC TCP/IP V6.2 even though the Automation License Manager does not list a missing license record. The runtime dialog displays V6.0 No authorization found or limited authorization expired! and the channel refuses to bind to the Ethernet interface. The second fault surfaces once the licensing issue is cleared: the driver dialog reports all configured connections OK, but tag values from individual TDC CPUs return intermittently instead of simultaneously, as if the runtime is polling only one CPU at a time.

This document records the field-proven resolution for both faults, the ordering data (MLFB numbers) and authorization strings required to clear the missing authorization, the WinCC-side configuration of the Device name field for a CP51M1 Ethernet module, and the LI block (Local Interface) port-allocation strategy that is required to keep five TDC CPUs polling in parallel.

Reference Hardware and Software Context

The following configuration is the basis for the corrections documented here:

• Engineering station: PCS7 V7.0, WinCC V6.2 runtime.
• TDC rack with five CPUs (CPU555 or CPU544/545 family).
• CP51M1 Ethernet module installed on the TDC rack for TDC ↔ WinCC TCP/IP coupling.
• Single Industrial Ethernet (IE) card on the WinCC server.
• WinCC channel driver: TDC PMC TCP/IP version 6.2, DLL PMC_TDC.dll.
• Authorization library: ADDONAUT.DLL shipped with the channel package.
• Function blocks: standard PCS7 system charts with @LI / LI block, AR_Send, AR_Recv, AT_Send, AT_Recv per CPU.

The PMC blocks reside in the system chart of every TDC CPU and are linked to the Ethernet CP through the LI block. Each CPU therefore exposes its image data to the WinCC server through the CP51M1.

Root Cause 1: Authorization Failure Despite ALM Showing All Licenses

The PMC TCP/IP V6.2 channel DLL is hard-coded with copy protection. The channel does not activate unless a Siemens authorization string matching SIK/SIMATIC TDC PMC TCP/IP is present on the hard disk. The Automation License Manager does not always flag this authorization as a missing record, in particular when the original authorization has been deleted, transferred to a different host, or never installed in the first place.

The channel readme states the protection mechanics explicitly:

This channel-DLL is provided with a copy protection. Therefore the software will only run if the authorization SIK/SIMATIC TDC PMC TCP/IP (A9TDCT60) or the appropriate emergency authorization (14 days authorization; X9TDCT60) has been installed on the hard disk drive of the relevant PC. You need the new file ADDONAUT.DLL for the authorization check.

The corresponding diagnostic log is:

...\WinCC\Diagnose\TDC PMC TCP_01.LOG

When the authorization is missing, expired, or keyed against a different machine, the channel start sequence writes a deny entry to the log file and raises the runtime error V6.0 No authorization found or limited authorization expired!. The error string remains V6.0 even on a 6.2 channel build because the message originates from the protected DLL and was not refreshed for the 6.2 recompile.

For projects still based on a WinCC Unified runtime platform, the parallel troubleshooting concepts are documented in the official Siemens WinCC Unified connection troubleshooting manual. The procedure follows the same pattern: confirm the channel is online, validate the authorization, then verify the connection endpoint.

Solution 1: Install the Correct SIK Authorization

Select the licensing path that matches what is already present on the PC before placing the order.

Procedure to install the authorization:

1. Close WinCC Explorer and stop the WinCC runtime on the server.
2. Open Automation License Manager and confirm the host ID of the PC (HostID on local drive and the Industrial Ethernet adapter).
3. Order the matching MLFB from Siemens IT4Industry. Provide the HostID so the license can be keyed to the target PC. The V6.0 base license (2XV9450-1WC43-0KX0) plus the V6.2 upgrade (2XV9450-1WC43-0KX2) is required only when migrating a V6.0 install to V6.2; a greenfield PCS7 V7.0 install should be ordered directly with the full V6.2 entitlement.
4. Receive the package containing the .wibu container file. Transfer it to the target machine over a USB stick or any disk-on-hand path that preserves the license file unchanged.
5. Run Automation License Manager → menu Authorize → Import Authorizations. Point to the transferred file and confirm the HostID.
6. Restart the WinCC server. Verify the license row displays valid with a green check.
7. Activate WinCC and recheck the channel diagnostics.

Verification 1: Authorization Active

1. After WinCC restart, open the channel diagnostics from the WinCC Explorer. The channel TDC PMC TCP/IP must report an active state.
2. Inspect the log file ...\WinCC\Diagnose\TDC PMC TCP_01.LOG. A successful authorization check writes an entry similar to Authorization OK, A9TDCT60. Any failure produces a line starting with Authorization: missing or Authorization: expired.
3. The runtime dialog V6.0 No authorization found or limited authorization expired! must not appear during channel activation.

Root Cause 2: Intermittent Tag Update With Five CPUs and a Single CP51M1

Once the licensing fault is cleared, the channel diagnostics report all configured connections OK but tag values from the five TDC CPUs are not refreshed in parallel. Symptoms observed in the user interface:

• Each tag prefix (one per CPU) updates correctly, but only one prefix updates at any given moment.
• Cycle time of CPU1, CPU2, ... CPU5 appears to rotate. The same physical point repeatedly reads old values, then refreshes while another prefix refreshes.
• No TCP socket error is reported; only one Ethernet session per CP51M1 is sustained by the WinCC server.

The PMC TCP/IP driver opens a single WinCC-side TCP connection per channel unit. Every LI block (system chart of each CPU) exports its AR_Send / AR_Recv pair to the same channel unit through a local port number configured in the AR connector of the LI block. When the local port number and the channel name are identical across all five CPUs, the driver treats the five AR endpoints as parallel accesses to the same TDC port and serializes them, polling one CPU at a time. The same identifier collision also prevents more than one outstanding query at any moment, which the operator experiences as intermittent values.

Solution 2: Differentiate LI Block Ports or Use a Shared LI

The PCS7 V7.0 sample project D7-TDC-WINCC ships with the engineering installation and documents the canonical approach. Two valid configurations are supported:

Option A: Single Shared LI Block Across All CPUs

Route all AR/AT traffic between WinCC and TDC through one LI block instance using sub-channels. The PMC blocks on each CPU reference the shared LI by name. The driver opens one socket that multiplexes to all five TDC CPUs through that channel, eliminating the per-CPU port collision. The WinCC side is configured with one PMC TCP/IP channel unit and five connection entries pointing at the same local port, distinguished by their remote target (rack/slot/CPU identifier on the CP51M1).

Option B: One LI Per CPU With Unique Channel Names

Keep one LI block in each CPU system chart. On every LI block, assign a unique string to the AR connector's Channel Name parameter (for example CPU1_LI, CPU2_LI, ... CPU5_LI). Internally, each channel name is mapped by the driver to a separate TCP session on the CP51M1, restoring parallel polling.

Configuration steps for Option B:

1. Open the PCS7 system chart of CPU1 and locate the LI function block.
2. Edit the AR_Send and AR_Recv connectors: set Channel Name to CPU1_LI and assign a free Local Port.
3. Repeat for CPU2 ... CPU5, giving each one a unique Channel Name. Keep the local port consistent only if WinCC targets a unique channel unit per CPU; otherwise the unique channel name segregates traffic automatically.
4. In WinCC Explorer, open the TDC PMC TCP/IP channel and create one Connection per TDC CPU. Each connection's parameter dialog identifies the remote TDC port plus the channel name (CPU1_LI, CPU2_LI, ...).
5. Confirm in TDC PMC TCP_01.LOG that five independent TCP sessions are listed under Connection state.

Configuration Reference: PMC System Parameters

The Device name field on the PMC parameter tab of TCP/IP Unit 1 must contain the network interface identifier that WinCC uses to reach the CP51M1. This identifier must match the access point defined in the Windows Set PG/PC interface dialog, otherwise the channel fails to bind to the correct adapter and the runtime reports the connection as established against the wrong NIC.

Procedure to confirm the exact string:

1. Open Windows Control Panel → Network and Sharing Center → Change adapter settings.
2. Right-click the IE card used for TDC communication and select Properties.
3. Note the connection name (for example Local Area Connection 2). The same identifier must be entered in the Set PG/PC interface for the WinCC access point.
4. Open WinCC Explorer → Tools → System Parameter → TCP/IP → PMC parameter tab → Device name. Type the identical connection name.
5. Restart the channel to force re-binding.

The Device name string is case-sensitive. Example entry:

Local Area Connection 2

If the PC uses a server-class NIC, confirm the slot binding order in the BIOS; slot reassignment after a firmware update can change the apparent connection name and silently break the channel.

Diagnostic Files and Useful Logs

Open the sample project and study the LI block wiring. The bundled example illustrates two-CPU data coupling; the same pattern scales to five CPUs by replicating the AR/AT and LI per CPU with unique channel names (Option B above).

Alternative Path: S7 Protocol Suite Driver

When the PMC TCP/IP V6.2 driver is unsuitable (license unavailable, mixed TDC/PROFIBUS topology, evaluation machine), the WinCC S7 protocol suite driver can establish a separate channel for SIMATIC TDC. The S7 driver avoids ADRIMP and PROBIBridge access routing, supports standard PUT/GET to the TDC CP51M1, and uses the standard WinCC S7 connection dialog.

Operational differences from the PMC TCP/IP driver:

• The S7 driver honors a single connection entry per CPU, so per-CPU differentiation is automatic.
• Tag addressing uses standard S7 syntax (DB, byte, bit) bridged through the CP51M1; the PMC channel uses the AR/AT binary telegram.
• The S7 path does not require the SIMATIC TDC PMC TCP/IP authorization; only the standard WinCC S7 option license is needed.

The selection between drivers depends on the function blocks already deployed in the TDC program. A greenfield program can use either; an existing program written against the PMC AR/AT blocks must stay on the PMC TCP/IP driver to avoid dual engineering of the data interface.

Verification 2: Multi-CPU Polling

1. In WinCC Explorer, open Tools → Status of driver connections. All five CPU connections must show OK and Established.
2. Configure a WinCC trend view with one tag per CPU (different prefixes) using a short acquisition cycle, e.g. 500 ms.
3. Confirm that the trend of each tag updates synchronously on its own clock; no tags show stepwise rotation between CPUs.
4. Examine the Windows resource monitor or PRTG counters for the IE card; the WinCC server must hold five open TCP sessions to the CP51M1, one per CPU on its assigned port.

If only one session is open, the channel name parameter on the LI blocks has reverted to a single value. Reapply Option B from Solution 2.

Channel Restart Sequence After Any Configuration Change

Apply after every edit of the LI block, Device Name, or local port assignment:

1. Deactivate the WinCC runtime.
2. Stop the WinCC channel TDC PMC TCP/IP service in WinCC Explorer.
3. Delete the file TDC PMC TCP_01.LOG so the next start produces a clean trace.
4. Reactivate the WinCC runtime.
5. Reopen the channel diagnostics and confirm the authorization result, channel name bindings, and per-CPU session state.

Preventive Maintenance Notes

• Keep a local backup of the .wibu authorizations on a secured share; transferring them to a replacement PC requires re-authorization by Siemens, so archive the package separately from the runtime machine.
• Document the channel name of every LI block in the PCS7 project header. Naming drift between engineering and runtime is the most common repeat-cause of intermittent polling after a PCS7 master data upgrade.
• Snapshot TDC PMC TCP_01.LOG in the WinCC backup routine. Log growth itself does not degrade the runtime, but historical traces accelerate root-cause analysis when extending the system with additional CPUs.
• Repeat the channel restart sequence after any BIOS/firmware update on the WinCC server or any firmware update on the CP51M1; the Ethernet adapter binding is the most fragile link in the chain.
• Validate the automation license status during every preventive maintenance round. A 14-day emergency authorization (X9TDCT60) is silent: when it expires the channel only fails on restart.