Modbus TCP is the lingua franca of “everything else” — meters, HVAC, third-party skids, building systems. The S7-1500 speaks it natively in both directions; the architecture questions are yours.
Client side (S7 polls devices)
MB_CLIENT instances manage TCP connections plus transactions. The patterns that survive production: one client instance per target device (clean connection state, independent failure), a job table per device rather than free-form calls, explicit DISCONNECT/reconnect handling with backoff (devices reboot; your blocks must shrug), and per-device health bits surfaced to the HMI — “meter 7 offline” as an alarm beats silent stale data everywhere.
Budget connections: CPU connection resources are finite and shared with HMI/OPC UA/PG traffic — thirty Modbus devices means deliberate resource math, or an IoT gateway aggregating below the PLC.
Server side (S7 serves others)
MB_SERVER maps holding registers onto a DB you define — which makes the content a design act: build a dedicated, documented interface DB (like the OPC UA story — stable contract, internal freedom behind it), never point external writers at live control data without a validation layer between. Multiple server instances on distinct ports/connections serve multiple clients cleanly.
Coexistence: Modbus TCP rides the same ports as everything Ethernet — keep it on the plant-facing interface, let Profinet own the machine I/O side, and the two never fight.
FAQ
Performance vs Profinet? Different classes: Modbus TCP is comfortable acyclic data in the tens-of-milliseconds-and-up world; it is not an I/O bus and should not audition as one.
Unit ID on TCP? Mostly vestigial except through gateways to serial — set what the gateway manual demands, otherwise conventionally 1.
Zone Otomasyon wires the “everything else” into S7 systems with contracts, not spaghetti. Systems integration.