Resolving WinCC Channel Diagnosis Error Codes D404 and D405

Overview

WinCC Channel Diagnosis surfaces connection-level faults as numeric error codes prefixed with the letter D (for example, D404, D405). On SIMATIC PCS 7 V7.0 SP1 with WinCC V6.2 SP2 — and on equivalent WinCC configurations targeting S7-300 / S7-400 CPUs such as the CPU 315F and CPU 315-2DP — these codes map directly to internal S7DOS (S7 DOS Layer) status values returned by the S7DOS channel DLL that backs the S7 Protocol Suite. Two codes account for the majority of operator-station (OS) connection failures reported by integrators:

• D404 — The maximum station number / maximum user number has been reached.
• D405 — Service is not supported or syntax error for the function parameters.

Both originate on the OS side after a compilation or runtime start and are typically triggered by a mismatch between what the WinCC project references and what the target AS (Automation Station) can serve. This guide consolidates the diagnostic flow, the official S7DOS error code reference for Panels and WinCC Runtime, and the Siemens FAQ 21915653 on OS compilation with unsupported structure tags. Use it as a field-proven procedure when an OS loses tags, shows D404/D405 in the Channel Diagnosis editor, or fails to come up after a full OS compile.

Where D404 and D405 Appear

Open the WinCC Channel Diagnosis tool from the OS runtime project tree:

1. Start the OS Runtime on the engineering station or the operator station.
2. In the WinCC Explorer, right-click Channel Diagnosis and choose Open.
3. Select the affected S7 Protocol Suite connection (for example, S7-300/400 > TCP/IP).
4. Read the Error column. Codes in the D400 range are S7DOS-level statuses and always indicate an issue between the WinCC channel and the PLC's communication service, not an OS software fault.

For permanent logs, Siemens recommends opening the channel-specific log file. The default location for SCADA RT V11 and equivalent WinCC versions is %ProgramFiles%\Siemens\Automation\SCADA-RT_V11\WinCC\Diagnose as documented in the WinCC Channel Diagnosis manual. Earlier WinCC V6.x deployments write to Siemens\WinCC\Diagnose in the same drive.

Error Code D404: Maximum Station/User Number Reached

D404 is raised when the WinCC channel attempts to register more station or user connections than the S7-300 / S7-400 CPU permits. On the CPU 315F and CPU 315-2DP, the connection resources are limited and shared between:

• PG/OP connections used by STEP 7 / WinCC.
• S7 connections used by other HMI clients or routing partners.
• PUT/GET, BSEND/BRCV, and USEND/URCV communication used by user program blocks.

The official S7DOS code D404 reads: "The maximum station number was reached." In PCS 7 multi-project environments, the message is also surfaced as "The maximum user number has been reached", because WinCC maps the S7DOS resource counter to its user (OS client) registration list. Both phrasings refer to the same CPU-side resource exhaustion.

Resource Limits per S7-300 CPU Family

Error Code D405: Unsupported Service or Syntax Error

D405 indicates that the request the WinCC channel issued against the CPU was rejected because either the service itself is not available on the CPU or the parameter block (request header / data area) does not match the CPU's expected layout. According to the official S7DOS reference, code D405 maps to constant L7_DGS_FKT_PAR_SYNTAX_ERR (decimal value 54277) with the message: "Service is not supported or syntax error for the function parameters."

In PCS 7 V7 / WinCC V6.2 deployments, this most commonly appears when the OS compiler resolves references to structure tags (UDT-based or PLC-DB-derived) that the target CPU does not have a matching data block for, or when the DB has been renamed, deleted, or had its UDT version incremented after the last OS compile. The Siemens support note FAQ 21915653 describes this exact behavior: an OS compiled against structure tags the AS cannot serve will raise D405 on every poll cycle until those tags are removed and the OS is fully recompiled.

S7DOS Error Code Reference (D400–D4xx Subset)

Codes are surfaced as 0xNNNN in the underlying S7DOS API and translated to the human-readable D-code by the WinCC Channel Diagnosis editor. The full table is published in the S7DOS Error Codes documentation and applies to all S7-300/400 WinCC targets.

Root Cause Analysis

The two codes are commonly observed together when an OS project is migrated or hot-patched without a clean recompile. The failure mode is reproducible:

1. The WinCC OS project references structure tags derived from a PCS 7 master data library (APL / standard blocks).
2. The target AS (for example, CPU 315F) has either been compiled with a different block version, has had supporting DBs removed, or never had the corresponding block type installed (third-party or migrated blocks without the matching UDT).
3. WinCC compiles the OS with the tag references; the runtime attempts to subscribe to the missing services every polling cycle.
4. The CPU responds with a negative acknowledgement that the S7DOS layer translates into D405 for unsupported service/syntax and D404 for resource limits once the connection pool saturates.

Decision Matrix

Prerequisites for Resolution

Before starting work on a live system, confirm the following:

• STEP 7 V5.5 SPx (for PCS 7 V7.0 SP1) or higher is installed on the engineering station and can connect to the AS.
• The S7 project for the AS, the WinCC OS project, and any HMI stations are open and synchronized.
• The engineering account has rights to perform a full OS recompile and download (changes will trigger a runtime restart).
• Plant operators are notified that the OS will drop out during the recompile and download cycle.
• A current backup of the WinCC project exists (File > Archive or project copy under Siemens\WinCC\WinCCProjects).

Step-by-Step Resolution Procedure

Step 1 — Capture the Failing Connection State

Open WinCC Channel Diagnosis and capture the connection name, AS number, IP address, rack/slot, and the failing D-code. Export or screenshot the diagnose window; copy the matching *.log from Siemens\WinCC\Diagnose for engineering review. The diagnose folder location for newer SCADA RT versions is documented under Diagnostics with WinCC Channel Diagnosis.

Step 2 — Validate CPU Connection Resources

1. In STEP 7, select the AS in SIMATIC Manager.
2. Open PLC > Module Information > Communication.
3. Inspect Number of Connection Resources: confirm the in-use count matches the configured PG, OP, and S7 connections.
4. If the count is at the CPU maximum and D404 is reported, either reduce the number of OS / HMI clients or add a CP 343-1 to offload Ethernet-based OP connections.

Step 3 — Identify Unsupported Structure Tags (D405 path)

1. In WinCC Explorer, open Tag Management > SIMATIC S7 PROTOCOL SUITE > <Connection>.
2. Sort tags by Type and isolate structure tags (those beginning with the project-specific AS symbol prefix).
3. Cross-reference each structure tag against the corresponding DB number in STEP 7. Any tag pointing at a non-existent DB, or at a DB whose UDT version has changed since the last OS compile, is a candidate.
4. Mark the candidates and prepare them for removal from the OS tag list.

Step 4 — Apply the Siemens-Recommended Fix

Following Siemens FAQ 21915653:

1. Remove the structure tags identified in Step 3 from the WinCC tag management.
2. Save the WinCC project.
3. Execute OS Project Editor > Full Compilation (do not choose delta compile for this recovery case).
4. Wait for the compiler to report success and confirm zero unresolved tag warnings.
5. Download the OS to the target operator station and start Runtime.
6. Re-open Channel Diagnosis and confirm the D-code has cleared.

Step 5 — Restore the Removed Tags Safely

If the removed tags are required for operations:

1. Recreate the missing UDT in STEP 7 on the AS (or import the matching version from the PCS 7 master data library).
2. Re-instantiate the DB and recompile the AS.
3. Re-add the structure tag references in WinCC using Tag Management > Add Structure Tag, making sure the DB number and offset match the AS.
4. Perform another full OS compile and download.

WinCC Channel Diagnosis Log File Inspection

The diagnose logs are the authoritative source when the diagnosis editor is intermittent. They record every state change with timestamp, connection name, and raw S7DOS code:

1. Stop WinCC Runtime.
2. Open the diagnose folder (paths vary by version):
   • WinCC V6.2: %ProgramFiles%\Siemens\WinCC\Diagnose
   • SCADA RT V11 / V13: %ProgramFiles%\Siemens\Automation\SCADA-RT_Vxx\WinCC\Diagnose
3. Open the channel log (for example, S7TCP.log) in a text editor.
4. Search for entries containing D404 or D405.
5. Cross-reference each entry with the channel diagnosis editor to identify the tag / connection that triggers the fault.

PCS7 V7.0 SP1 / WinCC V6.2 SP2 Specific Notes

This version combination predates TIA Portal and uses the SIMATIC Manager as the engineering environment. Important field-validated constraints:

• The OS Project Editor's "Full Compilation" must be used for any tag-list change. Delta compilation does not always regenerate internal tag indices for structure types in WinCC V6.2 SP2.
• The S7 Protocol Suite channel S7-300/400 in WinCC V6.2 SP2 expects one OPC entry per connection; doubling the connection count for redundant OS pairs can exhaust the OP connection count on a CPU 315-2 DP.
• APL blocks shipped with PCS 7 V7.0 SP1 (for example, FB 1869 MOT_SPEED, FB 1889 CTRL_PID) reference UDTs that the OS uses as structure tags. After an APL upgrade, perform Step 4 (full recompile) before restarting the OS.
• Symbolic addressing on CPU 315F must be enabled; D405 can also surface when the OS references absolute addresses while the CPU is set to symbolic-only.

CPU 315F / CPU 315-2 DP Specific Checks

Verification

After the resolution procedure, confirm the system is healthy:

1. Channel Diagnosis: No D4xx errors are displayed; all connections show OK or D400.
2. Tag Monitor: Open a representative structure tag and confirm the value updates within the configured acquisition cycle.
3. OS Runtime: Process screens render without gray placeholder values or quality code Bad.
4. Diagnostic Buffer: The CPU's diagnostic buffer no longer records negative acknowledgements from the OS connection.
5. Redundant OS pair (if applicable): Both servers hold a connection; failover does not raise D404.
6. Log file: Re-check the diagnose log after one hour of runtime; no D404/D405 entries should appear.

Preventive Recommendations

• Adopt a change-management discipline: every AS change that adds, removes, or renames a DB must trigger a full OS recompile before restart.
• Maintain a PCS 7 master data library mirror so the OS and AS share a single source of truth for UDT definitions.
• Avoid referencing structure tags that point at non-standard or third-party DBs; use direct symbolic addresses for those cases.
• Monitor CPU connection-resource utilization during commissioning and document the static allocation per OS.
• Run the diagnose log through a log-rotation policy; long-running plants accumulate thousands of entries that slow the editor.

FAQ