Resolving MODBUSCP A080 Instance DB Error in PCS7 V7.1

Problem Overview

The A080 diagnostic event generated by the MODBUSCP function block indicates that different instance data blocks (IDBs) were used for the call of MODBUSCP in the warm-restart OB (OB100) and in the cyclic OB (typically OB1 or OB35). The error is reported at the block's ERROR / STATUS outputs and is written to the diagnostic buffer of the CP 343-1 or CP 443-1 communication processor when the CPU goes online with the project.

This condition most commonly occurs in SIMATIC PCS7 V7.1 SP2 projects built with the CFC editor, but it has been observed in STEP7 V5.4 / V5.5 environments as well, particularly after a Download without STOP operation (also called Run-mode download or Configuration in Run, CiR). Because the MODBUSCP block is not designed to accept online reconfiguration of its instance memory, the CPU detects the inconsistency between the initialization context (OB100) and the runtime context (cyclic OB) and raises A080 to protect the integrity of the Modbus/TCP connection.

Affected Components and Versions

Understanding the A080 Error Code

The full Siemens diagnostic text for the A080 status returned by the MODBUSCP block reads:

"Different instance DBs were used for the call of MODBUSCP in OB100 and the cyclic OB."

This message is raised by the block's internal consistency check. The block uses two distinct call sites:

1. OB100 (warm restart): Initializes the block, opens the Modbus/TCP connection, and clears the receive buffer. OB100 executes only on a STOP-to-RUN transition (cold restart, warm restart, or hot restart, depending on CPU type).
2. Cyclic OB (OB1, OB35, OB32): Performs the actual Modbus/TCP transaction — sending requests, receiving responses, evaluating function codes (FC01, FC02, FC03, FC05, FC06, FC15, FC16, FC23), and updating the process image.

Both call sites must reference the same instance DB. If the compiler (CFC) or the programmer (STEP7) generated two different IDBs — for example, because the chart was re-instanced, the chart was deleted and re-inserted, or a Run-mode download split the IDB into a temporary one — the runtime check in MODBUSCP triggers A080 and refuses to bring the connection up.

Root Cause Analysis

There are three primary mechanisms that produce the A080 condition in the field:

1. CFC Regeneration of the Instance DB

When the CFC editor compiles a chart containing the MODBUSCP block, it creates a single instance DB. After the chart is downloaded to the target CPU, the runtime IDB in the CPU's work memory is the reference. If you subsequently:

• Re-open the chart in CFC,
• Modify any parameter on the block (even something cosmetic),
• Recompile, and
• Attempt a Download changes in RUN via CFC's online delta download,

…the CFC compiler may assign a new logical IDB number to the block. The CPU retains the old IDB in its online view, so the next time OB100 fires (after a restart), it sees two different IDBs. Because OB100 already passed without the new IDB, the A080 surfaces.

2. Run-Mode Download Without STOP/RUN

Siemens explicitly documents that the MODBUSCP block is not CiR-capable. Any attempt to download the IDB while the CPU is in RUN, even using STEP7's Download to target system > Entire program to target memory card, leaves the running OB100 instance untouched while the cyclic OB instance is updated. The result is the same inconsistent-IDB condition flagged as A080.

3. STEP7 vs. CFC Handling of Multiple IDBs

CFC has no user-facing mechanism to declare "the same IDB" for two call sites — the editor generates them automatically. In STEP7's LAD/FBD/STL editor, you can manually call MODBUSCP in OB100 and in OB1 using the same multi-instance or the same standalone IDB. The symptom in CFC is therefore more common, but the underlying restriction applies to all editors.

Resolution Procedure

The only sanctioned recovery from a live A080 state is a CPU STOP → RUN transition (a warm or cold restart, depending on CPU type and configuration). Follow the steps below to clear the condition and bring the Modbus/TCP connection online.

Prerequisites

• PG/PC with STEP7 V5.4+ or PCS7 V7.1 SP2 installed and online to the target AS station.
• Read/write access to the project's S7 program and the target CPU's online view.
• Authorization to take the affected CPU briefly to STOP. Coordinate the outage with operations — the Modbus slaves will lose visibility during the restart.
• Documented IP addresses of the CP 343-1 / CP 443-1 and the connected Modbus/TCP devices (default TCP port 502).

Step-by-Step Recovery

1. Verify the project is consistent. In SIMATIC Manager, right-click the S7 program and choose Check Block Consistency. Compile the entire program (or chart) and resolve any warnings about MODBUSCP or the CP's hardware configuration.
2. Stop the CPU. Open the online view of the target station, select the CPU, and toggle the operating mode selector to STOP, or send the STOP command via Target system > Operating mode > STOP.
3. Download the entire program (not a delta). Use Target system > Download > Entire program to target memory card in STEP7, or in CFC use Chart > Download > Chart to target system on the parent chart. This forces a unified IDB write to load memory.
4. Perform a warm restart. Toggle the mode selector from STOP back to RUN, or issue Target system > Operating mode > RUN (warm restart). OB100 will execute, the MODBUSCP block will initialize with the freshly loaded IDB, and the connection will be re-established.
5. Verify the A080 has cleared. Open the CPU's diagnostic buffer (CPU > Diagnostic buffer) and the block's online view. The STATUS output of MODBUSCP should return 16#0000 or a normal operating status; A080 should not appear in the buffer after the restart.

Verification

After the restart, perform the following checks:

• Block STATUS: The STATUS word of the MODBUSCP instance should be 16#0000 (no error) or the active transaction status. A080 = 16#A080 must not recur.
• Connection state: In NetPro, the Modbus/TCP connection to the CP should be in state Established.
• Process data: The configured Modbus registers (holding registers FC03/FC16, input registers FC04, coils FC01/FC05/FC15) should reflect expected values from the slave devices.
• Diagnostic buffer: Look for the entry "MODBUSCP: Connection established to <IP>" after the restart.

Configuring Configuration in Run (CiR) — Why It Is Not Permitted

Configuration in Run allows hot modification of the hardware configuration (adding/removing distributed I/O, changing the AS station count, etc.) without stopping the CPU. The MODBUSCP block is explicitly excluded from CiR-compatible downloads for the following reasons:

• The block maintains a TCP socket state machine on the CP that is initialized exactly once in OB100.
• The block holds the assigned connection ID and the LADDR (logical base address) of the CP; a delta download may not refresh these values safely.
• The block's instance DB contains communication buffers that are sized at first load and cannot be resized online.

Attempting a CiR download on a chart that contains MODBUSCP will either be rejected by CFC's online check or will succeed on the cyclic OB side while leaving OB100 untouched — producing A080 on the next restart anyway.

Best Practices for Avoiding A080

1. Always perform a full STOP/RUN after any change to the MODBUSCP block or its instance DB. Treat MODBUSCP as a "startup-only" block from a download perspective.
2. Avoid modifying the chart online. Make all changes offline, recompile, then download during a planned outage.
3. Single source of truth for IDBs. If you are programming in STEP7 (not CFC), manually place the MODBUSCP call in both OB100 and the cyclic OB and point both to the same standalone instance DB (e.g., DB200). Do not let the compiler generate two separate IDBs.
4. Document the OB100 call site. In PCS7's CFC, OB100 is auto-generated by the chart compiler. Verify in the generated source that the block call uses the same instance name you see online.
5. Reserve sufficient memory. Each MODBUSCP instance consumes ~8 KB work + 9 KB load. On a CPU 315-2 PN/DP (256 KB work), keep the count below 25 instances to leave headroom for the user program.
6. Use distinct connection IDs. The block parameter CON_ID must be unique across the CPU. Maintain a register of assigned IDs to prevent collisions when scaling.
7. Configure watchdog and timeout parameters. Set the block's TIMEOUT (default 3000 ms) and RETRY values to match the network and slave response characteristics. Excessive retries mask transient issues that could appear as A080-adjacent status codes.

Related Status Codes and Their Meanings

Modbus/TCP Background

Modbus/TCP is the encapsulation of the Modbus RTU application protocol over a TCP/IP transport, defined in 1999 by Schneider Automation (now Schneider Electric) and disseminated via the Modbus Organization. It is registered with IANA on TCP port 502 and uses a 7-byte MBAP (Modbus Application) header in place of the RTU address + CRC fields. The transaction identifier in the MBAP header allows the client to multiplex multiple requests on a single TCP socket.

For the MODBUSCP block on the S7 side, the typical data exchange uses the following function codes:

• FC01 Read Coils
• FC02 Read Discrete Inputs
• FC03 Read Holding Registers (most common for process values)
• FC04 Read Input Registers
• FC05 Write Single Coil
• FC06 Write Single Register
• FC15 (0x0F) Write Multiple Coils
• FC16 (0x10) Write Multiple Registers
• FC23 (0x17) Read/Write Multiple Registers

Slave devices return an exception response (function code + 0x80) when an address range is invalid, the requested data length is unsupported, or the function code itself is not implemented. The MODBUSCP block surfaces these exceptions via status codes in the 16#A084 family.

Migration to Newer PCS7 Versions

If you are planning to upgrade the affected AS station from PCS7 V7.1 SP2 to V8.x or V9.x, the MODBUSCP block is superseded by the MODBUS_TCP block in the PCS7 APL (Advanced Process Library) or by the OpenModbus/TCP library from the Siemens Openness / OSS add-on catalog. The newer blocks:

• Support PROFINET-based CP firmware (CP 343-1 PN, CP 443-1 PN) with firmware ≥ V2.x.
• Use the new S7-1500 instruction model when the AS station is migrated to an ET 200SP CPU or a S7-1500 controller.
• Provide more granular status (16-bit extended status word) and integrated diagnostic interrupts.

When migrating, regenerate the charts in CFC, but still perform a full STOP/RUN restart after the first download. The OB100/cyclic-OB IDB consistency rule is enforced by the new blocks as well.

Field-Commissioning Checklist

1. Verify the CP 343-1 / CP 443-1 firmware is at the latest revision supported by your PCS7 version (check the Siemens Industry Online Support SIOS portal for the compatibility matrix).
2. In NetPro, create a Modbus/TCP connection from the AS to the partner (the slave IP). The connection type is "TCP connection" with the partner role set to Server (the S7 side acts as the Modbus client by default for MODBUSCP).
3. Configure the block's LADDR input with the diagnostic address of the CP (visible in HW Config > CP properties > Diagnostics address).
4. Set REMOTE_IP to the slave's IPv4 address and verify TCP port 502 is reachable (ping + telnet <ip> 502 from the PG).
5. Download the program, STOP/RUN restart, and verify A080 is gone before walking away.

Troubleshooting Matrix

FAQ