Resolving Modbus TCP A092 Error on S7-300 with ModScan32

Problem Overview

When commissioning a Siemens SIMATIC S7-300 PLC as a Modbus TCP participant against a Modbus master simulator such as Win-Tech ModScan32, the application program compiles cleanly and the CP (typically a CP343-1 or CP343-1 Lean/Advanced) reports an established link, yet no data exchange occurs. The only diagnostic indication is a recurring status word bit pattern that decodes as error code A092. Because A092 is reported by the Modbus runtime rather than by the standard SIMATIC diagnostic buffer, it is frequently misread as a transport-layer fault (TCP, ISO-on-TCP, or CP firmware) when the actual fault is an application-layer addressing mismatch between the S7-300 program and the Modbus master polling map.

This article isolates the root cause of the A092 condition, walks through the corrected wiring of the Modbus function blocks on the S7-300, validates the DB222 instance parameterization, and configures ModScan32 (licensed build) for verification. The procedure applies to the legacy SIMATIC Modbus/TCP blocks distributed with the S7-300 CP product family: FB106 (MB_CPLI), FC10 (MB_HOLD), AG_CNTRL, and the standard instance DB (DB222 in the default example project). Field engineers integrating the S7-300 against third-party SCADA, Ignition, or a custom .NET/PC master will follow the same diagnostic path.

Decoding Error A092: Modbus Exception Code 2

The A092 status is generated when the Modbus client block receives an exception response from the partner with Modbus exception code 0x02 (ILLEGAL DATA ADDRESS). According to the Modbus Application Protocol Specification V1.1b3, exception code 2 is returned by a server when the request references a register coil or holding register that does not exist in the server's address space, or when the requested quantity plus starting address exceeds the implemented address range.

The exception frame is encapsulated as follows on the wire (PDU):

Function Code | Exception Code
   0x80 + FC   |   0x02
Example (FC03 poll failure):  83 02

For the S7-300 CP343-1 the Modbus runtime translates the received 0x02 into status word bit pattern 0xA092, which the application sees in the STATUS output of FB106 / FC10. A092 can also be re-cast as decimal 41042 or, when viewed as individual flags, the following bits are set:

The implication is unambiguous: the S7-300 is receiving a reply from the partner, the reply is a valid Modbus PDU, but the partner (ModScan32 in this case, when configured to simulate a server) is rejecting the request because the S7-300 client is asking for an address the simulator has not been configured to serve.

Root Cause Analysis: Three Failure Modes

Field experience with the S7-300 Modbus blocks yields three reproducible root causes for the A092 symptom. Any one is sufficient; in real commissioning work all three are often present.

Cause 1 - DB222 Modbus Map Mismatch

The default SIMATIC Modbus TCP example project configures DB222 with a Modbus address space that starts at offset 40001 (Holding Register 1) and extends for a fixed quantity, typically 100 words. The Modbus client's parameter block in DB222 contains the start address of the PLC data area (e.g., DB222.DBD0 = 400001), the quantity of registers, and the function code mask (read holding registers 03, read input registers 04, write single register 06, write multiple registers 16). If ModScan32 is configured to poll address 400101 (i.e., the 101st holding register) and the DB only exports 100 registers, the simulator will return exception code 2 and the S7-300 client will surface it as A092.

Cause 2 - FC Number Collision with AG_CNTRL

The Modbus blocks use an internal helper function that the application program must call repeatedly to drive the CP. In the Siemens example project this function is FC10. However, the user program may already declare its own FC10 in the symbol table, causing STEP 7 to silently substitute one symbol for the other when AG_CNTRL resolves its call target. If AG_CNTRL ends up calling the user's FC10 instead of the Modbus library FC10, the CP never receives a Modbus request and the connection sits idle; on the next master poll, the S7-300 side never responds, but the S7-300 client may itself be polling another node and seeing A092-style exceptions back. The recommended remediation is to rewire AG_CNTRL to a free FC number such as FC100 by editing its source in a separate, offline copy of the project.

Cause 3 - ModScan32 Trial Version Limitation

Win-Tech's ModScan32 was historically shipped as a 30-day trial that permitted only Modbus RTU/ASCII serial polling. The trial build rejects Modbus TCP client connections silently; the application starts, accepts the TCP connect, but never issues a request frame. The S7-300 therefore sees no exception, but also no successful response, and the application interprets the missing reply as a timeout. According to Prosoft Technology's published KB article on Modscan32 trial limitations, this is a licensing check rather than a protocol fault.

Step-by-Step Resolution

The remediation proceeds in five ordered steps. Each step is independently verifiable and may be skipped only after confirming the previous step is already satisfied.

Step 1 - Inventory the Modbus Library Blocks

1. Open the S7 project in STEP 7 V5.5 or TIA Portal (with the legacy S7-300 CP block library imported).
2. Navigate to the Blocks container and confirm the presence of: FB106 (MB_CPLI), FC10 (MB_HOLD), FC100 (AG_CNTRL after rewiring), DB222 (Modbus data instance), and UDTs if used.
3. Verify that no user-defined FC10 exists in the symbol table. If a user FC10 is present, right-click > Rename and move it to FC11 or similar; the symbol table update must propagate to all call sites.

Step 2 - Rewire AG_CNTRL to FC100

Open a separate, offline copy of the project (File > Save As with a suffix such as _AGCNTRL_REWIRE). In that copy:

1. Open the AG_CNTRL source. The block is implemented as a wrapper that calls a Modbus-internal FC. Locate the call statement (e.g., CALL FC 10).
2. Change the FC number from 10 to 100. Recompile and download to the offline PLC only - never to the running production CPU.
3. Verify that the FC10 instance DB and the FC100 instance DB are both present and correctly populated. In the symbol table, map AG_CNTRL to FC100.
4. Re-download to the target PLC and observe the diagnostic buffer. Successful rewiring eliminates the symptom; failed rewiring produces W#16#8081 (resource problem) or W#16#80A1 (FC parameter assignment error).

Step 3 - Validate DB222 Instance Configuration

Open DB222 in STEP 7 and verify the following parameters against the S7-300 CP Modbus manual reference data. The exact layout depends on the Modbus block version; the canonical fields are:

The most common field engineer error is leaving MB_MODE = 1 (client) while the system architect intended server behaviour. A092 only manifests when the S7-300 is the Modbus client; if it is configured as a server, A092 should not appear, and the symptom is therefore a configuration/state inconsistency between DB222 and the runtime state. Realigning MB_MODE to 0 (server) typically eliminates A092.

Step 4 - Configure ModScan32

1. Launch ModScan32 (licensed version). The trial build will not transmit Modbus TCP frames reliably.
2. From the Connection menu, select Connect. In the dialog, set:
   - Port: TCP/IP
   - Remote IP: the S7-300 CP IP (e.g., 192.168.0.20)
   - Remote Port: 502 (or the port configured in HW Config for the Modbus connection)
   - Slave ID: 255 for Modbus TCP (TCP does not use a slave address; the field is ignored by most stacks but must be a valid byte)
3. Set Address = 400001, Length = 100, Device ID = 255, Function = 03 (Read Holding Registers).
4. Confirm polling starts. The status bar at the bottom should read "Connected" and the register table should populate within one poll cycle.

Step 5 - Verify the TCP Connection in the CP

Open the S7-300 online diagnostics (PLCSIM or real CPU):

1. Right-click the CP343-1 in the project tree > Diagnostics > Connection Diagnostics.
2. Confirm the Modbus TCP connection shows state = Established and ID = the configured connection ID.
3. Open DB222 online and observe the STATUS word. It should now read W#16#0000 (no error).

CP343-1 Hardware Configuration Reference

The CP343-1 Lean (6GK7343-1CX10-0XE0), CP343-1 (6GK7343-1EX30-0XE0), and CP343-1 Advanced (6GK7343-1GX30-0XE0) all support the Modbus/TCP protocol option, which must be enabled by a license key on the older firmware and is included by default on the -EX30 / -GX30 variants from firmware V2.0 onwards. The configuration path in HW Config is:

1. Properties > CP343-1 > Modbus/TCP tab.
2. Enable the Modbus/TCP option and assign a connection resource (local ID 1..16).
3. Configure the partner IP, partner port (502 default), and the local port (any, 502 conventional).
4. Set the keep-alive timer to 30s (recommended for SCADA masters).

On the firmware side, A092 is reported by the Modbus block version 4.0 (FB106 V4.0) and later. Earlier V3.x blocks used different status encodings (e.g., 8081, 80A1). When upgrading a working V3.x project, expect to remap STATUS handling logic.

Connection Topology and Data Flow

The S7-300 Modbus TCP architecture is layered as follows. The application calls FB106 (MB_CPLI) cyclically from OB1; FB106 internally calls FC10 (MB_HOLD) which performs the actual data marshalling; FC10 then calls the CP's Modbus function via AG_CNTRL. The CP maintains the TCP socket to the partner. AG_CNTRL is the link between the user program and the CP's firmware mailbox. If AG_CNTRL is misrouted, the CP never receives a request and the master sees only timeouts.

Modbus Address Map Validation

When A092 persists after Steps 1-5, the next investigation is the master polling range versus the S7-300 address map. ModScan32 supports four function codes; the table below summarizes which S7-300 area each function code maps to and the resulting Modbus address space:

If the master polls FC04 against an area the S7-300 has not pre-mapped as input registers, or polls beyond MB_DATA_LEN, the simulator returns 0x02. To debug, set ModScan32 to poll address 1 with length 1 (i.e., the smallest possible valid request) and confirm the S7-300 replies. Incrementally extend the length until the failure re-occurs; the breakpoint is the configured boundary.

Connection Stability and Timeout Tuning

Beyond A092, intermittent disconnect events are a common Modbus TCP issue. The CP343-1 keep-alive default is 30 seconds, which can mask short network outages. If the master is sensitive to brief disconnects, lower the keep-alive to 10 seconds and the master's read timeout to 1 second. The companion issue is the Modbus block's MB_TIMEOUT (default 2s). A value below 500ms produces spurious A092 reads because the master has not yet had time to reply. Recommended field values:

Troubleshooting Matrix

Comparison: ModScan32 vs Ignition vs Vendor Masters

Field engineers often start with ModScan32 but quickly move to a SCADA master once commissioning is complete. Each tool surfaces A092 differently:

According to Prosoft Technology's published knowledge base, Modscan32 trial versions from www.win-tech.com historically did not allow Modbus TCP/IP client connections without a license; this is the most common cause of "no data, no error" symptoms during initial setup. Always verify the ModScan32 build by clicking Help > About and confirming the TCP/IP Client option is enabled.

Verification Checklist

1. DB222 STATUS word reads W#16#0000 after a poll cycle.
2. ModScan32 status bar reads "Connected".
3. ModScan32 register table updates at the configured poll interval.
4. CP343-1 connection diagnostics show state = Established.
5. S7-300 diagnostic buffer shows no new error entries.
6. Write test: change a register in DB222, confirm ModScan32 reflects the change within one poll.
7. Disconnect test: pull the Ethernet cable; observe that the S7-300 sets status bit 7 within keep-alive timeout; reconnect; confirm STATUS returns to 0 within one poll.

Common Field Pitfalls

• Mixing MB_MODE between projects. Copying DB222 from a client project into a server project flips the role silently. Always confirm MB_MODE matches the architecture.
• Port conflict with WinCC flexible / TIA HMI. The HMI panel may also bind to TCP/502. Move the S7-300 to TCP/503 or the HMI to another port.
• Firewall on the engineering PG. Windows Firewall blocks outbound TCP/502 by default on Windows 10+. Add a rule for STEP 7 and ModScan32.
• PLC time-of-day not synchronized. Out-of-range timestamps in the CP log may mask the actual Modbus fault. Synchronize via NTP or SFC.
• MB_DATA_PTR pointing to a DB that is not loaded. Download the DB with initial values, otherwise AG_CNTRL returns W#16#8081.

Frequently Asked Questions