Resolving Siemens S7-400H Modbus TCP Error 16#2522 Licensing

Resolving Siemens S7-400H Modbus TCP Error 16#2522: FB 909 Licensing Failure on S7-400H

Problem Overview

A redundant S7-400H (CPU 417-4H / CPU 414-4H / CPU 416-4H) reports the following diagnostic-buffer entry while running the Modbus TCP library (MODBUS TCP PN-CPU or the legacy "MODBUS TCP" blocks):

Event 30009 : Event ID 16#2522
Area length error when reading M area, bit access, access address: 60000
FB Number : 909
Module Address : 9140
Request OB : Programming error OB (OB121)
Priority Level : 1
Internal error, incoming event
Coding: 16#2522 0179 8E03 EA60 038D 23B4

The PLC stops raising this entry on every cycle of FB 909 ("MB_RED_CLIENT" / "MB_RED_CLI" depending on STEP 7 version). A second diagnostic event is typically appended shortly after the same cycle:

Event 30013 : Event ID 16#A090
No valid license found for MODBUS TCP block

The two events together identify a license failure on the Modbus TCP runtime blocks, not a user program fault. The program code is correct; the CPU is simply rejecting the call because no Automation License Manager (ALM) license key for the Modbus TCP package is present on the storage card or local hard drive.

Root Cause Analysis

Event ID 16#2522 Decoding

In the S7-400 / S7-400H diagnostic buffer, the event-ID half-word 16#2522 is interpreted as:

Field	Value	Meaning
Event class	16#25	Synchronous error – programming / access error
Event number	16#22	"Area length error when reading" sub-type (read access)
Direction	READ	CPU attempted to read from an out-of-range or unlicensed memory area
Area	M (Merkers / flags)	M area is the scan target
Access	BIT	Bit-level access (1 bit at offset 60000)
Address	60000 (decimal)	Bit offset inside the FB's instance / marker DB region

The CPU raises this synchronous error because the licensing routine inside the Modbus TCP runtime block (FB 909) tried to read its license token out of the CPU's internal marker / DB region (bit address 60000). When the ALM key is absent or has not been transferred to the CPU, the read returns a length error, which the CPU reports as 16#2522 and routes to OB 121.

Why FB 909?

On S7-400 / S7-400H with the SIMATIC Modbus TCP library, the standard FBs are:

FB / FC	Symbolic name	Function
FB 906	MB_CPCLI / MB_CLIENT_CP	Modbus TCP client via CP 443-1 (legacy)
FB 907	MB_CPSRV / MB_SERVER_CP	Modbus TCP server via CP 443-1 (legacy)
FB 908	MB_RED_SRV	Modbus TCP server, redundant variant for S7-400H
FB 909	MB_RED_CLI / MB_RED_CLIENT	Modbus TCP client, redundant variant for S7-400H – this is the FB generating 16#2522
FB 910 / FC 910	MB_GET / MB_PUT helper	Data-handling helpers

FB 909 ("MB_RED_CLI") is the Modbus TCP client FB explicitly written for the S7-400H, providing synchronized connection handling on both H-CPUs (RACK 0 / RACK 1) with master/standby switchover. Internally, FB 909 calls FC 909 / FC 910 license-check routines that probe the ALM for the "Modbus TCP" license bucket. The bit at M 60000.0 is part of the licensing fingerprint the block uses; it sits inside the instance data block of FB 909 plus an offset, which is why the diagnostic buffer always reports the same access address regardless of your actual M-area configuration.

Related Diagnostic Event 16#A090

Event class 16#A0 is an asynchronous module-level error. 16#A090 with text "No valid license found for Modbus TCP block" is generated by the licensing component embedded in FB 909 when the license key check fails. Event A090 is often logged within a few seconds of 16#2522 and confirms the licensing root cause.

Why the User Program Looks "Correct"

The PLC programmer's intuition is that the event must come from a typo in the FB's parameters – for example, an MB_DATA_PTR pointing past the end of a DB, or a length that overflows the bit area. In this case, the parameters are innocent. The licensing stub is triggered before any user-configured I/O is processed, so the same diagnostic fingerprint appears whether you connect to one Modbus device or ten.

Resolution Procedure

The fix is to install the SIMATIC "Modbus TCP" license on both H-CPUs of the S7-400H rack.

Prerequisites

• STEP 7 V5.5 SPx (or STEP 7 Professional in TIA Portal if the project has been migrated).
• Automation License Manager (ALM) V6.0 or later installed on the engineering station.
• The original license USB stick / CoA certificate for the Modbus TCP package (Siemens order number 6AV6 671-1GE00-0AX0 for the legacy "Modbus TCP" library, or the equivalent TIA Portal bound license).
• Online access to the H-station via TCP/IP (ISO-on-TCP) or MPI/Profibus to both CPUs.
• S7-400H CPUs of firmware V4.0 or higher (older V3.x CPUs do not support FB 909 and use FB 906 / FB 907 only – which need a different license migration path).

Step-by-Step

1. Confirm the diagnostic events. Open SIMATIC Manager > Online > Accessible Nodes, connect to the H-station, and read the diagnostic buffer of both CPUs (RACK 0 and RACK 1). Confirm that both events are present: 16#2522 on OB 121 from FB 909, and 16#A090 from the licensing module.
2. Check installed licenses on the engineering station. Launch Automation License Manager. Under "My Computer / Local Drive" or the assigned network dongle, verify that a license titled "SIMATIC Modbus TCP" appears and is not expired. If the license is on a USB stick and the stick is not plugged in, ALM will show "License not found" and the CPU runtime will receive the same negative reply that produces 16#2522.
3. Transfer the license to the H-station storage card / hard drive. Right-click the "SIMATIC Modbus TCP" license in ALM and select Transfer > Transfer License. Two targets are required for an S7-400H:
   • CPU 0 (RACK 0) – transfer via the online path used in step 1.
   • CPU 1 (RACK 1) – repeat the transfer while connected to the standby CPU. Both H-CPUs must hold a copy of the key so that a link-switch / rack-failure does not disable the Modbus communication.
   ALM writes the license key as a hidden file *.LIC on the memory card or the internal flash of the CPU.
4. For rack-resident licenses (no MMC): On older CPUs without an MMC, the license is loaded into the CPU's internal flash via the menu PLC > Authorize / License. Some CPU variants also require a one-time Copy to Internal Flash after RAM power-on so the key survives a power-down.
5. Cold-restart or warm-restart both CPUs in the correct H-sequence:
   • Place the standby CPU first (H-CPU Switchover from SIMATIC Manager).
   • Issue stop → run (warm restart) on the now-standby CPU so the new license is read during start-up.
   • Repeat for the partner CPU.
   A full re-link-up of the H-system is not required; only the user-program start sequence must re-run.
6. Clear the diagnostic buffer on both CPUs (PLC > Clear Diagnostic Buffer) so the stale 16#2522 / 16#A090 entries do not pollute future maintenance logs.
7. Force a single Modbus poll by setting the REQ input of FB 909 to TRUE. The DONE output should pulse TRUE on completion and ERROR must remain FALSE.

Verification

After licensing, perform the following four checks. Each one is intended to fail in a predictable way if the license has not been re-loaded correctly.

Verification 1 – Diagnostic Buffer Clean Read

1. Online > Accessible Nodes > CPU 0 > PLC > Diagnostic/Setting > Diagnostic Buffer.
2. Confirm there are no new entries containing 16#2522 or 16#A090 after the restart.
3. Repeat for CPU 1.

Verification 2 – OB 121 Has Not Been Called

Open Monitor/Modify on the OB 121 error counter or the system status word. If OB 121 is empty (a single BE at end), the licensing routine no longer triggers a programming error. Some customers keep a thin OB 121 ("fehler_OB121") that increments a tag — that counter must remain at 0 after the fix.

Verification 3 – Modbus TCP Communication Live

1. In the FB 909 instance DB, watch the MB_RED_CLI.STATUS, MB_RED_CLI.CONNECT_STATUS, and the connection table for the partner CP.
2. A successful poll returns STATUS = 16#0000 and the application data areas (e.g. MB_DATA_PTR from holding registers) cycle at the configured POLL_CYCLE.
3. Wireshark capture on the Ethernet cable to the CP 443-1 should show a Modbus/TCP frame (MBAP header 0x0000 0000 0006 0103 0000 000A for FC 03, read 10 holding registers) and the device's response with the correct exception code (none = 0x00).

Verification 4 – H-System Link-Up

PLC > H-System Information on both CPUs. The "Status of both H-CPUs" indicator must show "Run" on both RACKs, and the redundant link must be "OK". A license mismatch between the two CPUs occasionally produces a "Link-down / license unequal" status – this is the symptom that one CPU holds the license and the other does not, and is fixed by repeating step 3 for the missing CPU.

Preventive Hardening

Wrap OB 121 and OB 122

Even though OB 121 is the recipient of 16#2522 in this failure mode, OB 122 (I/O access error) should also be installed. Replace the default empty OBs with a handler that sets a marker you can later alarm on. This guarantees that a future license drift surfaces in the HMI rather than as a CPU stop.

// OB 121 sample (STL/SCL variant)
CALL  FC 120  // FC_OB121_HANDLER
   OB121_ERROR_INFO := OB121_FLT
   OB_NUM_IN          := 121
   ERR_FLAG_LICENCE   := M_LICENCE_ERR       // latch
   ERR_FLAG_PROGRAM   := M_PROG_ERR
   ERR_FLAG_IO        := M_IO_ERR
   CYCLE_COUNT        := CNT_OB121

Use a License-Watchdog FB

Add an FB that runs every minute and checks the STATUS of FB 909 together with a periodic read of the ALM "Modbus TCP" license string from the CPU's online diagnostics. On a negative result, set a pre-warning tag and surface it to the HMI / SCADA. This catches a key being deleted by anti-virus sweeps on the engineering station or a maintenance engineer removing the USB stick.

Mirror the License Between H-CPUs

STEP 7 V5.5 does not automatically duplicate runtime licenses on the partner CPU. Add this rule to the project's lifecycle document: "After any license change, transfer the license to both H-CPUs before resuming production." A simple offline script in the Automation License Manager can call the TransferLicense API to both CPUs and write a log entry.

Set Diagnostic Buffer Archiving

Long buffer retention is essential for the kind of intermittent licensing errors seen on Modbus TCP blocks. Configure the diagnostic buffer to log to a CSV on the engineering station via PLC > Save Diagnostic Buffer or via the OPC-UA push interface on newer H-CPU firmware.

Cross-Platform Reference

The same licensing principle applies on other Siemens platforms, but the FB numbers and license paths differ. The table below is useful when porting a Modbus TCP integration from S7-400H to a newer or older controller.

Platform	Modbus TCP FB	Library	License?	Diagnostic fingerprint
S7-300 / S7-400	FB 906 / FB 907	MODBUS TCP	Yes – "SIMATIC Modbus TCP"	16#A090 + OB 121 / 16#2522
S7-400H	FB 908 / FB 909	MODBUS TCP (redundant)	Yes – same license key	16#A090 + OB 121 / 16#2522
S7-1200 / S7-1500	MB_CLIENT / MB_SERVER (instruction block)	Built-in TIA instruction	No separate license on most firmwares (firmware ≥ V2 on 1500 includes Modbus TCP)	No licensing error – errors come from TCP layer only
ET 200SP CPU	MB_CLIENT / MB_SERVER	Built-in TIA instruction	No separate license	No licensing error
CP 343-1 / CP 443-1 (legacy)	FB 900 / FB 901 / FB 906 / FB 907	MODBUS TCP	Yes – "Modbus TCP for CP"	16#A090 with CP-specific error LED on the CP module

If you are migrating an S7-400H Modbus TCP project to an S7-1500H, the licensing constraint disappears but the redundancy semantics are different – the S7-1500 uses a system IP and program-state synchronization rather than the FB 908 / 909 master/standby handshake.

Troubleshooting Matrix

Symptom	Likely cause	Fix
16#2522 + 16#A090 every cycle of FB 909	License missing on this H-CPU	Transfer Modbus TCP key via ALM
16#2522 only on CPU 1, not CPU 0	License only transferred to CPU 0	Repeat transfer to CPU 1
16#2522 on CPU 1 only, after link-switch	License lost during H-link restart	Re-authorize CPU 1 and run a warm restart
16#A090 but no 16#2522	License present on one CPU, missing on the other; FB instance only running on the licensed CPU	Transfer license to both CPUs
16#2522 still present after transfer	License file corrupt or MMC write-protected	Re-export license, disable write protection, re-transfer
16#2522 + 16#A090 + SF LED on CPU + CP "IF" LED	CP 443-1 firmware mismatch with Modbus library	Update CP firmware to V3.x or higher and re-load library
16#2522 + OB 121 only at start-up, then clears	License probe runs once per cycle until FB 909 first calls the licensing routine; not an error after warm restart	Monitor – no action needed if no further events
No 16#2522, but FB 909 ERROR = 16#0007	Modbus exception code from the partner device	Check device address and register map
No 16#2522, FB 909 ERROR = 16#80C8	Connection timeout on the partner CP	Check network, CP partner address, keep-alive

Edge Cases & Field Notes

• Dongle vs. hard-disk licensing. If the Modbus TCP license is hosted on a USB dongle attached to the engineering station, the key is checked at programming time, not at runtime. The CPU runtime always expects a copy on its storage card / hard drive. A common misconfiguration is to assume that because the dongle is plugged in, the CPU is licensed – it is not.
• Encryption changes in STEP 7 V5.5 SP2. Some V5.5 SP2 builds re-encrypt the *.LIC file format. License keys issued for V5.4 must be re-exported via the updated ALM to work on V5.5 SP2 H-CPUs.
• License export to a WinCC station. The "Modbus TCP" license has nothing to do with WinCC – if WinCC is connecting to the S7-400H, it uses a separate OPC-DA / OPC-UA license. Do not transfer the Modbus TCP key to a WinCC runtime only – that does not authorize the PLC blocks.
• Migrated project on TIA Portal. If the project has been migrated to TIA Portal, FB 909 is replaced by the TIA instruction block MB_RED_CLIENT. The licensing still exists (Siemens offers TIA-Portal-bound keys), and a missing key produces equivalent status outputs in the instance DB plus diagnostic buffer events 16#4580 "License missing for block" rather than 16#2522. Treat the new fingerprint as the TIA analogue of the legacy event.
• H-CPU cold restart vs. link-up restart. A full cold restart of the H-system wipes the internal volatile copy of the license if the storage card has been reformatted. Always use a warm restart when re-licensing, and verify with the diagnostic buffer that the key is still present after the restart.
• Anti-virus on the engineering station. Some endpoint-protection products flag the *.LIC files as suspicious and quarantine them. Restore from quarantine and add an exception; otherwise, every license transfer to the PLC will produce a 0-byte key and the PLC will respond with 16#2522.

Operational Procedure Summary (Quick Reference)

1. Read the diagnostic buffer; expect 16#2522 on OB 121 from FB 909 + 16#A090 "No valid license found".
2. Open ALM; confirm the "SIMATIC Modbus TCP" license is present.
3. Transfer the license to CPU 0 (RACK 0).
4. Transfer the license to CPU 1 (RACK 1).
5. Warm restart both H-CPUs (standby first, then primary).
6. Clear the diagnostic buffer on both CPUs.
7. Trigger one FB 909 poll; verify STATUS = 16#0000.
8. Capture a Wireshark trace on the Modbus/TCP cable to confirm a real response.

Standards & Documentation Anchors

The following Siemens manuals are authoritative for the licensing procedure and the Modbus TCP block library used on S7-400H. Always cross-check the firmware-specific chapter before transferring a license.

• SIMATIC S7-400H Fault-tolerant Systems, System Manual (Siemens order number 6ES7498-8AA05-8AN0) – chapter on "Run-time license for option packages".
• SIMATIC Modbus TCP for S7-300/400, Function Manual (entry ID 109754141) – describes FB 906 / FB 907 / FB 908 / FB 909 and the licensing requirement.
• Automation License Manager, Operating Manual (entry ID 109769836) – describes license transfer to S7-400 / S7-400H.
• Modbus Application Protocol Specification V1.1b3 (Modbus Organization) – for the on-the-wire format referenced in the Wireshark verification step.

FAQ