Troubleshooting OPC XML DA Error 0x85270206 with SIMATIC S7-300 and CP 343-1 Lean

Intermittent write failures between an OPC XML-DA client, the SIMATIC NET OPC Scout v13, and a SIMATIC S7-300 CPU 315-2 PN/DP behind a CP 343-1 Lean surface in the OPC trace log as HRESULT 0x85270206. The error is non-fatal: a subset of the subscribed values reaches the PLC, while a smaller subset does not, with no deterministic pattern in the failing tags. The root cause is rarely a single broken object; it is the interaction between an inherently best-effort SOAP transport, a tightly resourced CP 343-1 Lean, and an OPC XML-DA configuration that was not engineered for the round-trip latency it actually encounters. This reference decomposes the error code, walks the end-to-end architecture from the enterprise layer through to the S7-300 backplane, and provides a verified diagnostic and remediation procedure for plants that exchange a small set of process variables (typically 5 to 6 tags) through this stack.

1. Problem Definition and Observable Symptoms

The reported failure pattern has the following diagnostic fingerprint:

• Between 5 and 6 process variables are exposed; 1 to 2 occasionally return E_FAIL / 0x85270206 on write.
• The error is reported by SIMATIC NET OPC Scout v13 (the OPC XML-DA client) when the SOAP response from the XML-DA server carries an "Item write error" with the server-side error code 0x85270206.
• Reads on the same items succeed, but the cached read value may diverge from the last successful write, giving the appearance of a "write that did not happen."
• Failures appear more frequently when multiple CP 343-1 Lean units are accessed in parallel from the same XML-DA server instance.
• The CP 343-1 Lean has been bench-tested directly (bypassing the OPC XML-DA stack) and successfully exchanges data with the S7-300, confirming the S7-300 / CP layer itself is healthy.

The error code 0x85270206 is logged in the SIMATIC NET PC station trace. It is documented in the Siemens Industry Online Support entry "Why is the SIMATIC NET OPC server logging error 0x85270206?" as a server-side write error condition originating in the SIMATIC NET OPC XML-DA / S7 channel stack. The exact mapping between the binary code and the underlying fault must be confirmed against that support entry because the high word (facility) identifies the SIMATIC NET OPC XML-DA component while the low word (reason) identifies the specific S7 write-back failure.

2. Reference System Architecture

The failing topology has four logical layers, each with its own boundary that can introduce a SOAP or S7 fault. Engineer the diagnosis by treating each boundary independently.

Key components and catalog numbers used in the reference architecture:

3. Error Code 0x85270206 Decomposition

The HRESULT is a 32-bit value with facility and reason components:

Combined, 0x85270206 is the SIMATIC NET signature for "an XML-DA Write call did not complete successfully because the S7 write request to the CP 343-1 Lean / S7-300 failed or timed out at the controller level." The exact operational meaning for a given SIMATIC NET version (V12, V13, V14, V15, V15.1, V16) is documented in the Siemens Industry Online Support article ID 63098071; consult that entry against the installed SIMATIC NET build for the definitive textual description.

Cross-reference the HRESULT against the OPC XML-DA 1.01 specification error space:

• Server-side write failures are reported by the XML-DA server inside a WriteResponse envelope as an item-level ResultID that is a stringified HRESULT. The XML-DA server may also return a SOAP Fault when it cannot parse the request body, per the OPC UA / OPC XML-DA mapping rules (OPC UA Part 6, §7.4.3 XML Encoding).
• The classic XML-DA "E_NO_WRITE_RIGHT" result corresponds to client permissions, not to an S7 reject, so it is not the same root cause as 0x85270206.

4. Root Cause Categories

Across the reported deployments, the error always falls into one of six categories. Use this matrix to triage before opening a live trace.

5. Step-by-Step Diagnostic Procedure

Run the procedure in order. Each step is non-destructive; stop when the cause is identified.

1. Capture the SIMATIC NET trace. Open "SIMATIC NET Configuration Console" → "OPC Settings" → enable "Verbose tracing" on the S7 channel. Restart the SIMATIC NET PC station service. Reproduce the failure. The trace writes 0x85270206 with the failing item name, the S7 connection handle, and the S7 error code returned by the CPU.
2. Decouple BizTalk. Use OPC Scout v13 directly to issue the same Write against the failing tag. If OPC Scout succeeds while BizTalk fails, the SOAP boundary (IIS, application pool, HTTP timeout) is the fault. If OPC Scout also fails, the S7 boundary is the fault.
3. Validate the CP 343-1 Lean connection budget. In STEP 7 / TIA Portal, open the hardware configuration of the CP 343-1 Lean and inspect "Connection resources." The Lean variant has 4 S7 connections maximum. If the OPC channel and an HMI together already consume 3, only 1 remains for everything else. Move one consumer to a different CP or upgrade to a CP 343-1 (non-Lean) such as 6GK7 343-1EX30-0XE0 with 16 connections.
4. Validate the tag addresses in STEP 7. Open the S7 project, online-connect to the CPU, and use "Monitor/Modify" on the same DB / bit memory offset used by the OPC tag. If the CPU returns SF (system fault) for that address, fix the address in the OPC item definition rather than in the CP.
5. Capture the SOAP envelope. Enable failed-request tracing in IIS for the XML-DA virtual directory, or run a packet capture (Wireshark on port 80/443, decode as HTTP). Confirm that the WriteRequest body contains a valid ItemPath and that the Value data type matches the S7 data type (BOOL ↔ BOOL, INT ↔ INT, REAL ↔ REAL). A 1-byte type mismatch produces a server-side write error that the OPC stack reports as 0x85270206.
6. Check IIS application pool identity. The pool identity must be a domain user (or local user trusted on the PC station) that is a member of "SIMATIC NET" and has DCOM "Local Launch" / "Local Activation" rights on the SIMATIC NET OPC Server. If anonymous authentication is used and the IUSR account has no SIMATIC NET role, the XML-DA server returns 0x85270206 for every write.
7. Stress-test with one CP only. Disconnect 5 of the 6 CP 343-1 Lean units and run BizTalk against the remaining one. If the error disappears, the issue is the aggregate load on the shared S7 connection resources of the PC station, not on any single CP. Solution is to split the PC station into one S7 channel per CP and to apply connection-pool sizing in the SIMATIC NET configuration.

6. SOAP Endpoint and Network Configuration

The XML-DA web service is bound to IIS. The endpoint URL and the HTTP runtime knobs control the upper boundary of the stack.

7. CP 343-1 Lean S7 Connection Tuning

The Lean variant is the most common reason an otherwise-correct OPC stack starts returning 0x85270206. Its resource budget is small, and every consumer is observable.

Configuration knobs to apply on the CP in STEP 7 / TIA Portal:

1. Reduce the S7 connection "Establishment" timeout from 30 s to 10 s. A timeout leaves the slot occupied until it expires, blocking new writes.
2. Enable "Active connection establishment" only for the OPC connection, so other clients (PG, HMI) cannot pre-empt it.
3. Disable "Keep-alive for FETCH/WRIT" if you do not use the partner-side PUT/GET; otherwise an idle partner holds a connection slot.
4. On the OPC channel in the SIMATIC NET Configuration Console, set "Connection resumption" to "Auto-reconnect with 2 s delay, max 3 retries". This converts a transient 0x85270206 into a retry that succeeds.

8. SIMATIC NET OPC Server Configuration

The SIMATIC NET OPC Server is the component that turns an XML-DA Write into an S7 PUT. Misalignment between the XML-DA item definition and the S7 channel item definition is the second most common source of 0x85270206.

Configuration in SIMATIC NET Configuration Console:

1. Open the S7 channel → Properties → "Operating Mode." Set it to "Optimized." Optimized mode reuses a single S7 connection across all items instead of opening one connection per item, which is mandatory on a CP 343-1 Lean.
2. Open the OPC item group → Properties → "Update rate." Set the rate to 1000 ms. Going below 500 ms on a CP 343-1 Lean increases the S7 job rate and the probability of a write collision.
3. In the OPC server, enable "Write access without subscription" only if the BizTalk application expects synchronous writes. With it disabled, writes outside an active subscription are queued and may be silently dropped after the SOAP timeout, surfacing as 0x85270206.
4. Set the S7 protocol "Maximum number of retries" to 3, with a 200 ms back-off. A transient error is then converted to a successful write and 0x85270206 disappears from the trace.

9. OPC Scout v13 Client Behavior

OPC Scout v13 is a generic XML-DA / COM DA client included with SIMATIC NET V13. It is useful for testing but it does not behave like a production client.

• DA 2.05a vs DA 3.0: OPC Scout v13 speaks OPC DA 2.05a against the SIMATIC NET COM DA server and OPC XML-DA 1.01 against the XML-DA server. The two stacks share the underlying S7 channel, so a fault seen in XML-DA is also seen in DA, and vice versa. The COM DA "SyncIO2" interface performs blocking writes; the XML-DA "Write" call is non-blocking. The non-blocking nature is why the same item can show "OK" on the read but "0x85270206" on the write: the read is sampled from the S7 cache, the write is dispatched and the error is delivered asynchronously.
• Group-level deadband: OPC Scout v13 defaults a group deadband of 0%. For BOOL tags this is fine; for analog tags, set the deadband to 1% so the server does not push a Write for every zero-crossing, which can saturate the CP's job rate.
• Item-level MaxAge: In OPC Scout v13 the default is 0 (force fresh). The XML-DA server interprets this as "do not honor any cache." If the BizTalk layer polls the same tag every 200 ms with MaxAge=0, the load on the CP 343-1 Lean increases by a factor of 25 compared to a 5 s update rate.
• Subscription behavior: OPC XML-DA Subscribe returns a subscription handle (ServerSubHandle). OPC Scout v13 issues Subscribe once at connect time and uses it for the entire session. If the subscription expires due to a SOAP-level keep-alive failure, the next write appears to succeed on the client (it is sent) but the server-side subscription has been torn down, and the S7 PUT is not issued. The HRESULT in the trace is 0x85270206.

When the same items succeed in OPC Scout v13 but fail in BizTalk, the BisTalk side is typically issuing a Write outside any active Subscribe and outside the group MaxAge that OPC Scout configured. Lift the BizTalk client to OPC DA 3.0 (or to OPC UA via the SIMATIC NET UA server if licensed) for synchronous write semantics, or use a small wrapper that issues Write inside a Subscribe/Unsubscribe pair.

10. Workarounds and Architectural Alternatives

If 0x85270206 cannot be eliminated with configuration alone, the next options should be evaluated in the order listed. Each is independent of the others.

1. Application-level retry. Wrap every XML-DA Write in a do-while loop with exponential back-off (200 ms, 400 ms, 800 ms) and a maximum of 3 attempts. Drop the result to a side log only after the third failure. This is the simplest fix and is sufficient when the failure rate is below 1%.
2. Reduce write pressure. Coalesce multiple BizTalk messages into a single XML-DA batched Write per cycle. With 5–6 tags this is trivial; with hundreds it is the difference between a healthy and an unstable system on a CP 343-1 Lean.
3. Increase S7 connection budget. Replace the CP 343-1 Lean (6GK7 343-1CX10-0XE0) with a CP 343-1 standard (6GK7 343-1EX30-0XE0) or a CP 343-1 Advanced (6GK7 343-1GX30-0XE0). The standard variant lifts the S7 connection count from 4 to 16, and the Advanced variant adds IT functions and security that the XML-DA stack benefits from indirectly.
4. Move off XML-DA to OPC UA. OPC UA over binary TCP is a session-oriented, acknowledged protocol. The SIMATIC NET OPC UA Server (V14 and later) is delivered with the same SIMATIC NET PC software and exposes the same S7 items as UA nodes. The UA client receives an explicit service-fault for a failed write, which is far easier to diagnose than a SOAP-level item ResultID.
5. Insert a buffering layer. Place a store-and-forward node (for example, an Industrial Edge connector or a WinCC Unified script) between BizTalk and the S7-300. BizTalk writes to a high-availability queue, the buffering node drains the queue against the OPC stack, and a 0x85270206 on the drain side is handled by the node without surfacing to BizTalk.

11. Verification and Long-Term Monitoring

Acceptance test after remediation. All steps must pass before the system is returned to production.

1. Single-tag write burst. Issue 1000 sequential writes of the value 0xAA to the same BOOL tag from BizTalk. Expect 0 failures and 0 occurrences of 0x85270206 in the SIMATIC NET trace.
2. Multi-tag write burst. Issue 1000 sequential writes alternating values across all 5–6 tags. Expect 0 failures.
3. Concurrent write to all 6 CP 343-1 Lean units. Trigger a simultaneous write to every CP from the same BizTalk orchestration. Expect 0 failures and a peak S7 connection usage no greater than the connection budget per CP.
4. Subscription continuity. Run a Subscribe with RequestedSamplingRate=1000 for 24 hours. Expect 0 subscription expirations in the IIS log and 0 SOAP faults.
5. Network fail-over. Pull the LAN cable on the CP 343-1 Lean for 5 seconds, then re-insert. Expect the S7 channel to auto-reconnect within 10 seconds, and a maximum of 1 transient 0x85270206 in the trace corresponding to the outage window.

For long-term monitoring, configure the SIMATIC NET PC station to write the OPC trace to a rotating file with a maximum of 5 x 200 MB files. Build a small script (PowerShell, Python) that greps the file for 0x85270206 and emails a daily count. A count above zero per day is a leading indicator of CP exhaustion or SOAP endpoint degradation.

12. Frequently Asked Questions