Resolving Siemens FB 905 Modbus TCP Error Codes A083 and 8304

1. Problem Overview

Siemens S7-300/S7-400 CPUs communicating through the standard Modbus TCP library (FB 905 in the "Modbus/TCP for S7-300/400" package) periodically report the internal status codes W#16#A083 and W#16#8304 on a CP443-1 Ethernet interface. The communication then recovers within roughly 10 seconds without operator action. Because both controllers are continuously powered and the cycle is irregular (2-14 days between faults in the field data shown below), the root cause is not power cycling but a combination of client-side telegram handling and partner-side response timing.

Observed fault cycle (24-hour clock, identical fault / recovery pairings captured on site):

The 8-9 second fault window matches the Siemens default TCP reconnection cycle, which confirms that the socket is torn down and rebuilt by the Modbus TCP block, not by the partner. The 2-14 day spacing matches the partner's sporadic background task (file flush, recipe load, scan-time spike) rather than a deterministic cycle in the S7 program.

2. Error Code A083 — Definition and Root Cause

W#16#A083 is the FB 905 STATUS word returned in the STATUS output of the block when the application program sets the ENQ (REQ) trigger while a previous telegram is still being processed. The exact meaning documented in the FB 905 F1 help is: "Job still active — a new request was triggered before the previous one reached DONE = TRUE or ERROR = TRUE."

In the affected application the cycle OB (typically OB1 or OB35) raises ENQ every 200 ms without testing the DONE flag first. While the link is healthy and the partner replies in under 5 ms, the FB 905 finishes the previous transaction before the next trigger and A083 is rarely observed. When the partner side stalls for more than the configured MONITOR time, however, the in-flight transaction is still pending, the next ENQ is raised, and the block posts A083 once or twice before the connection is dropped with 8304.

The block monitors the ENQ / REQ input on every call. If a rising edge is detected while an internal state machine is anywhere other than IDLE, the request is rejected with STATUS = A083 and no new telegram is sent. This protects the block from overlapping requests but does not protect the user program from generating them.

3. Error Code 8304 — Definition and Root Cause

W#16#8304 is the STATUS code returned when FB 905 cannot establish or has lost the TCP connection to the Modbus partner. The 8304 code is reported at the end of the MONITOR-timeout window once the block decides to abort the in-flight telegram and recycle the connection. In the symptom list above, 8304 follows a short burst of A083 codes, confirming the causal chain:

1. Partner response is delayed (1.5 s in the captured Wireshark trace).
2. FB 905's MONITOR timer expires and the block internally terminates the TCP connection.
3. The application raises ENQ again while the block is still cleaning up the previous transaction — STATUS becomes A083.
4. The block finishes disconnecting, opens a new passive connection, and reports STATUS = 8304 while the new socket is not yet established.
5. Within 8-9 seconds the TCP handshake completes, the new transaction succeeds, and STATUS returns to 0.

8304 is therefore not an error in itself — it is the diagnostic footprint of a forced reconnect. The underlying trigger is the partner taking longer than MONITOR to answer. The exception codes that the partner may return inside the Modbus PDU (e.g., 0x06 Slave Device Busy, 0x0B Gateway Target Device Failed to Respond) are a separate issue and are documented in the Schneider Electric EcoStruxure Modbus TCP/IP exception code reference and the AutomationDirect Modbus error code reference.

4. CP443-1 Diagnostic Buffer Event IDs

The CP443-1 diagnostic buffer, read through STEP 7 → PLC → Module Information → Diagnostic Buffer, recorded three matching events every time 8304 appeared. The event class 16#F9C1 is the standard Siemens ISO-on-TCP / TCP connection-diagnostics class:

The triplet 261A → 260D → 2622 is the standard Siemens fingerprint for "Modbus block closed the socket and is about to re-establish it." It is not, by itself, a fault caused by the CP443-1 hardware; it is a normal recovery sequence. To separate a local cause from a partner-originated abort, look at the connected-events log:

• If the events are tagged "External error, incoming event" with the same timestamp and the same connection ID, the abort is initiated locally by FB 905 after the MONITOR timeout.
• If the same triplet is preceded by 16#F9C1:261B (RST received from partner) or 16#F9C1:2621 (partner-initiated close), the partner is the one dropping the link first.
• If a fourth event of class 16#F9C1:2630 (connection establishment OK) follows within a few seconds, the new socket is healthy and the cycle is just FB 905's normal reconnect sequence.

In the captured incident the events were always tagged as "External error, incoming event" on connection 1 with identical timestamps, which confirms the CP443-1 is being told to close the socket by FB 905, not by the partner.

5. The MONITOR Parameter and Connection Recovery

FB 905 monitors every outstanding telegram and waits up to MONITOR × 100 ms for a response. The Siemens default for the Modbus/TCP block library is typically MONITOR = 50 (i.e., 5 seconds), although this is an input on the function-block instance DB and can be set per project. The block's exact behavior at MONITOR expiry is:

1. The in-flight Modbus PDU is discarded.
2. The CP's control block is told to abort the TCP connection (event 16#F9C1:2622).
3. The CP443-1 issues the active close (event 16#F9C1:261A).
4. The TCP socket returns to CLOSED and event 16#F9C1:260D is logged.
5. FB 905 returns STATUS = 8304 to the application.
6. On the next ENQ (with DONE = TRUE), the block triggers a new passive open and the cycle repeats.

In the Wireshark capture from this site, normal transactions sit at roughly 1-2 ms between query and response, but a single pair showed a 1.5-second gap with no reply at all. That is the trigger event for MONITOR expiry and the subsequent 8304. The recommended first response is to confirm with the partner vendor why one transaction in tens of thousands is taking longer than 1.5 s.

6. Wireshark Capture Procedure

Wireshark is the only practical way to confirm which side is delaying the response. Use a managed switch with port mirroring (SPAN) or a tap on the Ethernet segment between the CP443-1 and the partner. Capture with the filter:

Recommended capture window: 5 minutes before to 5 minutes after a logged 8304. Because the faults are 2-14 days apart, leave a continuous capture running on a small industrial PC and rotate the file with a ring buffer of 5 × 200 MB. Save a pcap file (not a text export) for later offline analysis.

Interpretation rules:

Save the pcap next to the diagnostic buffer export from the CP443-1 and align the timestamps. The single exchange with the 1.5 s gap in the capture from this site is the smoking gun — the partner stops responding for 1.5 s and the CP443-1 (driven by FB 905's MONITOR) terminates the connection.

7. Programmatic Fix: Wait for DONE/ERROR Before Next ENQ

The application code in the affected system raises ENQ unconditionally every 200 ms in OB1. The standard Siemens example project guards the trigger on both DONE and ERROR. The exact pattern from the FB 905 example in the Modbus/TCP library is:

// Pseudo-STL snippet, matches the FB 905 example in the Modbus/TCP library
      U     M      100.0      // operator enable
      U     DB905.DBX   0.1   // DONE bit (block output)
      O
      U     DB905.DBX   0.2   // ERROR bit (block output)
      =     M      101.0      // "previous job finished" flag

      U     M      100.0
      U     M      101.0
      S     DB905.DBX   8.0   // ENQ trigger
      UN    M      101.0
      R     DB905.DBX   8.0

Three important refinements:

1. Clear ENQ as soon as DONE or ERROR rises, otherwise FB 905 can interpret a still-set ENQ at the start of a new cycle as a new job and you will continue to see A083 even when the link is healthy.
2. Use OB35 (e.g., 100 ms) instead of OB1 to give the block an extra few milliseconds to settle between cycles, especially if DONE is signalled only on the next call.
3. Cross-reference DB905.DBX 8.0 (ENQ) in STEP 7 to confirm no HMI or second OB is also writing the trigger; a duplicate ENQ source is the most common reason A083 persists after the fix.

After the change, A083 should disappear on a healthy link within one OB cycle. If A083 still occurs, the trigger source is wrong (a second OB or an HMI job is also writing ENQ) — check the cross-reference for DB905.DBX 8.0.

8. Network and Partner-Side Checks

Even with a clean client, 8304 will return if the partner stalls. Run the following checklist in order:

1. Partner CPU / scan load. A 1.5 s response gap is almost always a partner-side scan-load spike, a buffer-flush task, or a watchdog on the partner PLC. Ask the partner vendor for the scan-time histogram during the fault window.
2. Switch path. Confirm that the CP443-1 and the partner sit on the same VLAN, that the managed switch has no spanning-tree blocking events, and that no IGMP/MLD snooping pruning is removing the multicast group used by the partner's discovery protocol (some partners default to UDP discovery before TCP).
3. TCP keep-alive. CP443-1 supports a configurable keep-alive timer in Properties → Ethernet → Keep-Alive. Default is 30 s; reduce to 10 s only as a last resort because aggressive keep-alives can also trigger 8304 if the partner's TCP stack is slow to reply to keep-alive probes.
4. Firewall / NAT. Industrial firewalls in front of the partner may close the TCP session after an idle period. The Modbus/TCP "IDLE" trigger is the absence of application traffic, not the absence of TCP keep-alives, so the firewall can drop the socket while FB 905 still considers it open. Configure the firewall to allow the connection to remain open for at least 5 × MONITOR.
5. Duplicate IP / ARP storms. A duplicate IP on the segment will produce exactly this pattern: most transactions succeed, a small number stall, then a 8304 cycle. Run arp -a from a maintenance laptop and verify the MAC behind the partner IP is the expected vendor OUI.
6. Function code 0x08 diagnostic sub-codes. Use Modbus function code 0x08 (diagnostic sub-functions 0x0000-0x000A) to validate round-trip time and slave presence. The Beijer Electronics Modbus TCP/UDP reference documents the supported sub-codes. Sub-code 0x000A (Clear Counters) and 0x000C (Return Bus Message Count) are particularly useful for proving whether the slave is even seeing the request.

9. Step-by-Step Troubleshooting Workflow

1. Capture state. Export the current CP443-1 diagnostic buffer and save the FB 905 instance DB. Record the firmware version of the CP443-1 (read with STEP 7 → PLC → Module Information → Identification) and the S7-CPU firmware.
2. Patch the client program. Implement the DONE/ERROR guarded ENQ pattern from Section 7 and reload the program. This removes A083 from the running system on a healthy link.
3. Start a Wireshark capture on the SPAN port of the managed switch with the filter shown in Section 6. Use a ring buffer so a long-running capture does not fill the disk.
4. Wait for the next fault (typically 1-14 days). When STATUS = 8304 appears, stop the capture, save the pcap, and align the timestamps with the CP443-1 diagnostic buffer.
5. Diagnose the side. In the pcap, identify the last query that has no response. If the FIN comes from the CP443-1 side after MONITOR ms, the partner is too slow. If a RST or FIN comes from the partner side first, the partner application is closing the link.
6. Engage the partner vendor with the pcap and the diagnostic buffer excerpt. Request scan-time data and a list of long-running tasks (file system flush, log rotation, recipe download) that overlap the fault window.
7. Tune MONITOR. If the partner scan-time histogram shows occasional 1-2 s spikes that cannot be removed, increase MONITOR so FB 905 tolerates them. Re-test for 14 days; the fault rate should drop by an order of magnitude.
8. Long-term monitor. Add a counter that increments on every STATUS = 8304 and a separate counter for STATUS = A083. Trend both in WinCC / HMI; A083 should fall to zero after the program patch, and 8304 should fall after the MONITOR tuning.

10. Verification and Long-Term Stability

Verification has two layers.

Immediate (within one hour of the change): Use STEP 7 → Monitor/Modify on the FB 905 instance DB. Watch the STATUS word: a healthy link returns STATUS = 0 (or 0x0000 with DONE pulsing). STATUS = A083 must not appear during continuous observation for 30 minutes.

Long-term (30 days): Trend the two counters added in step 8 of Section 9. The expected pass criteria for a properly tuned system are:

After the trigger patch and MONITOR tuning in the affected site, both A083 and 8304 dropped to zero over a 30-day observation window and the DONE_NDR counter matched the ENQ counter within 0.01 %.

11. Frequently Asked Questions