S7-400H GD Communication Restriction Why Global Data Is

S7-400H GD Communication Restriction: Why Global Data Is Unsupported

Global Data (GD) communication is a SIMATIC S7 mechanism that allows cyclic, broadcast-style exchange of small data packets between CPUs over the MPI bus, the K bus, or backplane without any explicit send/receive block programming. It is widely deployed on S7-300 and standard S7-400 installations for low-cost distribution of status words, hand-shake flags, and small recipe headers. The same mechanism is explicitly disabled on S7-400H fault-tolerant CPUs. This technical reference documents the architectural reason for the restriction, quantifies the payload limits that make GD unsuitable for redundancy in the first place, lists the alternative communication services that H-system projects must use instead, and provides a diagnostic checklist that confirms the block at the STEP 7 engineering station.

1. Overview of Global Data Communication in SIMATIC S7

Global Data communication is implemented inside the SIMATIC S7 CPU firmware and exposes itself through STEP 7 as a configuration table rather than as executable code blocks. The engineer assigns each participating CPU to a "GD circle," defines the maximum number of GD packets, and selects which process I/O areas (inputs, outputs, bit memory, timer/counter status, peripheral I/O) participate as senders or receivers. The CPU operating system then broadcasts the configured packets cyclically at a scan rate that the user sets in the GD table editor (typical values: 1, 2, 5, 10, 20, 60, 120 seconds). For each receiver the firmware updates the local process image area at the configured rate.

The protocol is intentionally minimal so it can be implemented entirely in firmware without consuming any application OB or FB execution time. That minimalism, however, is also what disqualifies it from redundant systems. The attributes that define GD communication are:

Further details are documented in the SIMATIC S7-300 CPU 31xC and CPU 31x reference manual on the Siemens Industry Online Support portal. See the SIMATIC S7-300 CPU 31xC and CPU 31x: Technical Specifications entry for the per-CPU GD packet tables and the STEP 7 V5.5 help entry "Global Data Communication" for configuration flow.

2. S7-400H Fault-Tolerant Architecture Constraints

The S7-400H system is a Siemens-redundant PLC platform designed for processes where a single CPU failure must not interrupt production. Two identical H-CPUs run the same user program in lockstep and exchange state information through dedicated synchronization modules and fiber-optic sync cables. The two CPUs share I/O either through a switched DP master or through Y-link coupling, and either CPU may assume the master role at runtime.

The architectural elements that influence the GD support decision are:

3. Root Cause: Why GD Is Unsupported on S7-400H CPUs

The definitive answer is published in the official Siemens manual "SIMATIC Fault-tolerant Systems S7-400H," section 11.4 ("Communication"). See the SIMATIC Fault-tolerant Systems S7-400H system manual. The manual states that GD communication is excluded from the H-system's communication service set, and the reason is twofold:

1. GD requires a 1:1 static sender/receiver relationship identified by unique MPI address. In an H-system the operating system treats the two H-CPUs as a single logical controller for the purpose of external communication. The H-CPU pair owns an H-station address (S7-H station) but the individual CPUs do not present a stable MPI/PROFIBUS identity to outside partners. A third-party CPU configured as a GD receiver cannot bind to either CPU individually because whichever one is currently the master may change at any moment.
2. GD offers no transport acknowledgement. A fault-tolerant design requires explicit confirmation that data reached the peer. GD's best-effort broadcast model cannot satisfy that requirement; data loss during the failover window would go unnoticed.

Several engineering opinions are often circulated on why GD is blocked. The matrix below separates the documented reason from commonly cited but unsupported explanations:

4. GD Packet Size and Transfer Limits

The published per-packet size limits are the first hard constraint that disqualifies GD from any meaningful H-system role. The figures below are taken from the S7-300 and S7-400 CPU reference manuals.

The 22/54-byte payload is sufficient to exchange a hand-shake flag, an operating-mode word, or a 4-word recipe index. It is not sufficient to mirror a single process image partition, a sequence step table, or any meaningful slice of an H-state database. A 32 KB shared data block cannot be distributed via GD; it would require 1458 packets at the S7-400 rate, exceeding the 32-packet CPU limit by two orders of magnitude.

5. MPI Addressing Model on H-Systems vs Standard CPUs

The MPI addressing question is frequently raised because it appears to be the simplest answer to "why GD fails on H." The reality is more subtle and depends on which interface is examined.

Each H-CPU physically owns an MPI address, a PROFIBUS address, and (on later 41x-4H CPUs) an IP address. STEP 7 and TIA Portal accept those addresses when you configure the rack. However, the H-station as a whole presents a logical communication identity to outside partners. S7 connections (PUT/GET, BSEND/BRCV) opened against the H-station are routed by the master CPU and fail over to the reserve CPU automatically when the master becomes unavailable. A GD packet cannot replicate that routing layer because the GD table is a static map compiled at download time with no runtime failover logic.

6. Event-Driven Synchronization and Its Conflict with GD

The H-system uses event-driven synchronization over the fiber-optic sync modules rather than a fixed cyclic sync scan. Synchronization events are triggered by OB 1 entry/exit, OB 35/OB 100, and any change to retentive data areas. When an event fires, the master CPU freezes its user program execution at the next sync point, copies the relevant state to the reserve CPU, waits for the reserve CPU's acknowledge, and only then resumes execution. The whole cycle completes within the configured monitoring time (default 100 ms; typical 30 ms for CPU 414-4H, 20 ms for CPU 417-4H).

GD communication does not participate in this sync model because GD packets are written to the receiver's process image at the GD scan rate, which is decoupled from the OB 1 cycle. Two consequences follow:

1. A GD packet sourced from a non-H CPU and consumed by the H-station could be applied to the master CPU's image but not propagated to the reserve CPU's image at the next sync event. The two CPUs would diverge in that GD-receiver variable until a full re-sync.
2. A GD packet sourced from the H-station and broadcast to non-H partners would be sent from whichever CPU is currently the master; the partner cannot detect a switchover because GD has no status frame.

The official Siemens position is documented in section 11.4 of the SIMATIC Fault-tolerant Systems S7-400H manual and in the related entry Why is GD communication not supported in S7-400H?.

7. Supported Alternatives to GD on S7-400H

The S7-400H platform supports the full S7 connection-based communication suite. The mapping table below is the practical answer for engineers who previously relied on GD in single-CPU projects.

For OPC UA the modern migration path is the SIMATIC S7-1500 generation with its built-in OPC UA server; S7-400H can publish OPC UA through an external CP 443-1 OPC UA server or via the WinCC OPC UA tunnel. See the SIMATIC S7-400H Industrial Ethernet communication manual.

8. Configuration Diagnostics: Confirming GD Is Blocked in STEP 7

If you have inherited an S7-400H project and want to verify that no GD table is in use, run the diagnostic steps below.

STEP 7 V5.5

1. Open the project in SIMATIC Manager.
2. Select the H-CPU (e.g., CPU 414-4H) in the left tree.
3. Right-click and choose Object Properties → tab Communication.
4. Confirm that the Global Data button or sub-tab is absent or greyed out.
5. Open menu Options → Define Global Data. If the menu item is disabled, no GD table can be authored for the project.

TIA Portal V13 and later

1. Open the project in TIA Portal.
2. Open the device configuration of the H-CPU.
3. Inspect the Properties → Communication section. The Global data node is not listed for any 41x-xH device.
4. Right-click the CPU → Compile. The compiler issues diagnostic message "Global data communication is not supported for fault-tolerant CPUs" if any legacy GD table reference is present in the offline block container.

9. Migration Path: Replacing GD with S7 Communication on H-Systems

The following procedure converts an existing S7-300/400 + GD topology to an S7-400H + S7-connection topology with minimal application rewrites.

1. Catalog GD traffic. Export the GD table from the source project (CSV from the GD editor in STEP 7 V5.5). For each row, record: sender CPU, sender DB/M/I/O address, receiver CPU list, scan rate, packet length.
2. Classify each GD row by purpose.
   • Status word (one-bit / one-byte / one-word state): convert to a single PUT/GET or to a USEND if event-driven.
   • Recipe header (multi-word structured DB): convert to BSEND/BRCV with one call per change.
   • Continuous process image slice: convert to PUT/GET at 100 ms – 1 s scan using OB 35 or a cyclic timer OB.
   • Alarm flag: convert to USEND/URCV.
3. Configure the S7 connections. In NetPro (STEP 7 V5.5) or the device editor (TIA Portal), insert one S7 connection per direction per peer. Configure the connection as "fault-tolerant" if the partner is also an H-station. Do not mark the connection as "GD".
4. Implement the FB/FC wrappers. Replace GD-area reads/writes with calls to FB 14 (GET), FB 15 (PUT), FB 12 (BSEND), FB 13 (BRCV), FB 8 (USEND), FB 9 (URCV). Place the calls in OB 1 for cyclic traffic or in the relevant hardware-interrupt OB for event-driven traffic.
5. Validate fail-over behavior. With the H-system online, force the master CPU to STOP via the test panel and observe whether the S7 connection remains active (it should, by virtue of the H-system's automatic partner-rebinding). Confirm that the partner's data buffer contains the latest values within the configured monitoring time.

Minimal S7 PUT/GET template

// Trigger a cyclic PUT from H-CPU to a non-H CPU (S7-300) every 100 ms
CALL FB 15, DB 100 (
  REQ            := "HMI_Ack_Trigger",   // BOOL trigger, e.g. from OB 35 timer pulse
  ID             := W#16#0001,           // connection ID from NetPro
  DONE           := "PutDone",
  ERROR          := "PutError",
  STATUS         := "PutStatus",
  ADDR_1         := P#DB200.DBX 0.0 BYTE 22,  // 22 bytes - same size as a S7-300 GD packet
  SD_1           := P#DB300.DBX 0.0 BYTE 22);

// Evaluate error
IF "PutError" THEN
  // log STATUS to diagnostic buffer; do not retry blindly
END_IF;

10. Programming Best Practices for H-System Data Exchange

• Use the H-station address as the connection endpoint. Never bind S7 connections to the physical MPI/PROFIBUS/IE address of an individual H-CPU; the H firmware re-routes the connection automatically after master switchover.
• Configure connection monitoring explicitly. Set the S7 connection's keep-alive time to 5 s and the partner's timeout to a value larger than the worst-case H master switchover (typically 100 ms) but smaller than the process's safety time.
• Use large-payload blocks (BSEND/BRCV) for recipe or parameter data. A single BSEND of 32 KB eliminates the need to chop the data into multiple GD packets.
• Avoid cyclic GD-style broadcasts. If you need one-to-many distribution on an S7-400H project, use multicast S7 connections or OPC UA publishing from the H-station's CP 443-1.
• Reserve bandwidth for sync. The H-system's sync modules consume a portion of the backplane cycle. Adding heavy communication traffic can delay sync acknowledgements and trigger an OB 70 / OB 72 "Communication fault" event. Monitor OB 70 call counts in the diagnostic buffer of the H-CPU.
• Document the GD migration. Mark every legacy DB that used to be a GD target in the project comments so future engineers do not assume the data is still being broadcast.

11. Troubleshooting Matrix: GD Errors on S7-400H

The matrix below maps the most common symptoms an engineer encounters when trying to deploy GD on an H-system to the documented cause and to the resolution path.

Frequently Asked Questions