S7-1500 I-Device vs PUT/GET: PROFINET Data Transfer Compared

This technical reference compares two PROFINET-based mechanisms for moving data between two S7-1500 controllers: the PUT/GET instruction set and the I-Device (Intelligent IO Device) function. The analysis is grounded in a real engineering scenario where the integrator has programming access to only one of the two S7-1500 CPUs, with the second CPU acting as a "black box" device on the same PROFINET subnet. Under that constraint, the selection between PUT/GET and I-Device is no longer a matter of preference; it is a matter of physical access. This document expands the decision criteria, configuration steps, and field caveats so that any engineer facing the same architecture can move from "is it possible?" to a reproducible commissioning procedure in TIA Portal.

1. Architectural Overview: Two PROFINET Roles for an S7-1500

An S7-1500 CPU on PROFINET can fulfil three primary roles:

• IO Controller — the master that plans and exchanges process data with assigned IO Devices on the subnet. S7-1500 CPUs always function as IO Controllers on their PROFINET interface by default.
• IO Device — a slave that exposes a defined set of process data (inputs/outputs) to an IO Controller. An S7-1500 CPU can be configured as an IO Device.
• I-Device — an S7-1500 that acts simultaneously as an IO Device and as an IO Controller for its own lower-level PROFINET subnet. The "I" prefix indicates the device hosts its own automation logic and exposes a controlled subset of that data upstream.

PUT/GET does not rely on the IO role architecture. PUT/GET operates as an application-layer instruction over an existing S7 connection, traversing PROFINET/Industrial Ethernet at the transport layer. The role of the CPU in PROFINET does not constrain PUT/GET; it only constrains the active/passive connection permission flags. This distinction is the key reason PUT/GET works when an I-Device configuration is not possible.

2. Two Communication Mechanisms in Detail

2.1 PUT/GET — Application-Layer DB Access

PUT/GET are two STEP 7 instructions from the Communication palette in TIA Portal:

• PUT — writes a contiguous block of data from a local DB into a remote DB on the partner CPU.
• GET — reads a contiguous block of data from a remote DB into a local DB on the calling CPU.

Both instructions use the S7 protocol over a configured S7 connection in the project tree (Devices & Networks > Networks > S7 connections). Each instruction is triggered by a one-shot REQ bit, runs asynchronously, and sets a DONE, ERROR, and STATUS word when complete. The maximum payload is 462 bytes for a CPU 1500 in firmware V2.x and later; older firmware V1.x CPUs cap at 222 bytes. The transfer can be performed cyclically by a timer or event-driven by a process signal.

Because PUT/GET is a pure instruction, the CPU hosting the data being read or written needs only one configuration change: the Permit access with PUT/GET communication partner option in the CPU properties (Properties > Protection & Security > Connection mechanisms). No DB, tag, or program code must be added on the partner side.

2.2 I-Device — Cyclic Process-Image Exchange

The I-Device function is described in detail in the Siemens application document "I-Device Function in Standard PN Communication". An I-Device exposes a defined transfer area — a contiguous slice of its process image — to an upper-level IO Controller. The transfer area is mapped to submodules in the device description (GSDML), and the upper controller consumes those submodules as if it were talking to a standard distributed IO device (ET 200, drive, valve island, etc.).

The I-Device is, internally, both a controller for its own PN subnet and a device for an external PN controller. It is the standard Siemens approach for cleanly separating two automation projects: the GSD file is the only contract between the device integrator and the controller integrator, as documented in "Properties and advantages of the I-device" in the SIMATIC S7-1200 G2 manual collection. The characteristics of an I-device, including the IO-controller and IO-device dual role, are summarized in "Characteristics of an I-device" using a print-process example.

For a S7-1500-to-S7-1500 link, the project flow is:

1. Engineer A builds the lower-level CPU project and configures the I-Device transfer area in TIA Portal (or exports the GSDML of the I-Device from the project).
2. Engineer B imports the GSDML into the upper-level project and drags the I-Device into the device view of the upper CPU.
3. Engineer B assigns the I-Device's submodules to the upper CPU's process image. The data appears as IB/QB/ID/QD on the upper CPU.

This contract is rigid: there is no mechanism for the upper CPU to read arbitrary DBs from the I-Device. The I-Device decides which areas are exported, and the upper CPU consumes only those areas at the IO scan rate (typically 1 ms to 4 ms, set in the PROFINET properties of the upper controller).

3. Side-by-Side Comparison

4. The Access Constraint: Why PUT/GET Wins in This Scenario

The decisive question in the originating engineering scenario is not "which is faster?" or "which is more elegant?" but "which one does not require me to modify PLC_1?".

For an I-Device, the source CPU (PLC_1) must be configured with the I-Device role, a transfer area must be defined, and a GSDML file must be exported. None of those steps are possible from the upper CPU's project alone. PUT/GET, by contrast, requires only that the PLC_1 be put into a state where it will accept S7 read/write requests from a partner. That state is enabled by a single CPU property:

1. Open PLC_1 in TIA Portal (if read-only access to the project is even available, no code change is needed).
2. Navigate to Properties > Protection & Security > Connection mechanisms.
3. Enable Permit access with PUT/GET communication partner.

If PLC_1 is a "black box" whose project cannot be opened, the same setting must be changed in the online configuration or by the OEM. Once that flag is set, PLC_2 (the integrator's project) can configure an S7 connection to PLC_1 and call GET to pull DB contents from PLC_1, or PUT to write back into PLC_1. No programming change is required inside PLC_1's user program — the S7-1500 CPU's operating system handles the request natively.

The I-Device path is closed in this scenario for three concrete reasons:

1. You cannot make PLC_1 act as an I-Device without configuring it as one in TIA Portal.
2. You cannot generate a GSDML of PLC_1 without opening PLC_1's project.
3. You cannot import a non-existent GSDML on PLC_2 to consume PLC_1 as an I-Device.

Therefore the original poster's tentative conclusion — "PUT/GET seems like the only option" — is correct. I-Device would be architecturally superior (deterministic, project-separated, multi-consumer), but it is not reachable from the integrator's seat.

5. Step-by-Step: PUT/GET Implementation Between Two S7-1500

5.1 Prerequisites

• Two S7-1500 CPUs with PROFINET interface (any firmware V1.5 or higher; the example uses V2.9 typical in 2024 deployments).
• Both CPUs on the same IP subnet (for example 192.168.0.0/24) with unique IP addresses and identical subnet masks.
• PROFINET cable between the two CPU PROFINET ports (X1 or X2 depending on hardware). For S7-1515/1516, X1 is the default PN interface; X2 is optional on most variants.
• PLC_1 has PUT/GET access enabled in CPU properties (see Section 4).
• PLC_2's TIA Portal project has the S7-1500 CPU added with its PROFINET interface configured with the correct IP address.

5.2 Configure the S7 Connection

1. Open PLC_2's project in TIA Portal V17 or later (V19 is current as of the manual baseline; V18 is the LTS release widely deployed).
2. In the project tree, expand Devices & Networks and click Networks.
3. Drag an S7 connection from PLC_2's PROFINET interface to PLC_1's PROFINET interface. TIA Portal will resolve the partner by browsing the subnet or by manual entry.
4. In the connection properties, set the partner IP address (PLC_1's PROFINET IP, e.g. 192.168.0.10).
5. Set the local ID (the connection identifier; default 1, can be changed to any unsigned 16-bit integer except 0x0E and 0x0F which are reserved for diagnostic connections).
6. Confirm the connection partner's TSAP. For an S7-1500 partner, the default TSAP is 03.01 for the first PN interface; the slot-1 rack-0 default. TIA Portal usually fills this in automatically.

5.3 Call GET and PUT in the User Program

From the Instructions task card in TIA Portal, open Communication > S7 Communication and place the GET and PUT blocks into a program block (typically an OB1 cycle or a dedicated FC). The function blocks are PUT (FB 15 under the hood) and GET (FB 14) for S7-1500. The instance DB is created automatically when you drop the block.

Example call for GET (reading 50 bytes from DB100 of PLC_1 starting at byte 0, into DB200 of PLC_2 starting at byte 0):

// GET instance DB: "DB_GET"
"DB_GET"(REQ   := bStartTrigger,        // BOOL — rising edge initiates the read
        ID    := 1,                     // WORD  — connection ID from Section 5.2
        ADDR_1:= P#DB100.DBX0.0 BYTE 50, // ANY   — remote address: DB100, byte 0, 50 bytes
        RD_1  := P#DB200.DBX0.0 BYTE 50, // ANY   — local target:   DB200, byte 0, 50 bytes
        DONE  => bDone,                 // BOOL  — success flag
        BUSY  => bBusy,                 // BOOL  — operation in progress
        ERROR => bError,                // BOOL  — error flag
        STATUS=> wStatus);             // WORD  — error/status code

Example call for PUT (writing 20 bytes from DB300 of PLC_2 to DB150 of PLC_1):

// PUT instance DB: "DB_PUT"
"DB_PUT"(REQ   := bStartTrigger,         // BOOL — rising edge initiates the write
        ID    := 1,                      // WORD  — connection ID
        ADDR_1:= P#DB150.DBX0.0 BYTE 20, // ANY   — remote target: DB150, byte 0, 20 bytes
        SD_1  := P#DB300.DBX0.0 BYTE 20, // ANY   — local source: DB300, byte 0, 20 bytes
        DONE  => bDone,
        BUSY  => bBusy,
        ERROR => bError,
        STATUS=> wStatus);

5.4 Trigger and Verify

1. Toggle the bStartTrigger bit from your HMI, watch table, or a periodic timer (a 100 ms clock is a common choice for non-time-critical data).
2. Monitor the DONE bit to confirm success. DONE = TRUE for one cycle indicates a successful transfer.
3. If ERROR = TRUE, read the STATUS word. Common codes: 0x0001 (communication problem, e.g. wrong IP or PUT/GET not permitted), 0x0005 (resource problem, no free connection), 0x0007 (data length error, exceeds 462 bytes or non-contiguous pointer).
4. Use Online & Diagnostics > Connections on PLC_2 to confirm the S7 connection is established. The state should be "established" with the partner IP visible.

6. Step-by-Step: I-Device Configuration (Reference Implementation)

Included for completeness so that engineers who do have access to both projects can implement I-Device correctly and migrate from PUT/GET later if PLC_1 becomes accessible.

6.1 Configure PLC_1 as an I-Device

1. Open PLC_1's TIA Portal project.
2. Select PLC_1 in the device view and open Properties > PROFINET interface [X1] > Operating mode.
3. Set PN interface mode to IO Device (which enables the I-Device option) and tick I-Device.
4. Under Transfer areas, click Add new and define a transfer area. Specify direction (input or output from the perspective of the upper IO controller), length, and address. For example, an input area of 32 bytes starting at IB 0.
5. Compile the project. Right-click PLC_1 and select Export > GSDML file. TIA Portal will generate a GSDML-V<version>-Siemens-<CPU>.xml file.

6.2 Configure PLC_2 to Consume PLC_1 as I-Device

1. Open PLC_2's TIA Portal project.
2. Install the exported GSDML: Options > Manage general station description files (GSD) > Source path > select the GSDML file.
3. Drag the I-Device from the hardware catalog (under PROFINET IO > I-Devices > <your CPU>) into the device view of PLC_2's PROFINET subnet.
4. Assign the I-Device to PLC_2 (the IO controller for this subnet).
5. Drag the I-Device's submodules into the slots of PLC_2. Each submodule maps to a transfer area; for an input submodule of 32 bytes, the I-Device's input data appears at IB0–IB31 of PLC_2's process image.
6. Set the PROFINET update time: Properties > PROFINET interface > Real-time settings > Update time. 1 ms is typical for high-speed motion; 4 ms is the common default for general automation.
7. Compile and download to PLC_2.

6.3 Data Access in PLC_2

Once configured, the I-Device data is accessible to PLC_2's user program exactly as if it were a remote rack of digital/analog inputs. Use:

iInputBit  := %IB0;     // first byte of the I-Device's input transfer area
iWordValue := %IW2;     // first 16-bit word
rRealValue := %ID4;     // first 32-bit REAL at byte offset 4

No call to GET/PUT is needed; the data is refreshed every PROFINET update cycle. There is also no application latency, no DONE/BUSY handshake, and no STATUS word to interpret.

7. Data Limits, Performance, and Throughput

7.1 PUT/GET Throughput

The S7-1500 PUT/GET instructions are bounded by:

• Maximum payload per call: 462 bytes (firmware V2.0+); 222 bytes (firmware V1.x). For larger transfers, segment into multiple calls or use the Open User Communication blocks (TSEND/TRCV) over ISO-on-TCP or TCP.
• Per-connection parallel calls: PUT/GET operate on a single S7 connection; the connection can service one PUT and one GET in parallel but multiple PUTs to the same connection serialize.
• Throughput limit: A typical S7-1500 PUT/GET call over PROFINET completes in 10–30 ms for a 462-byte payload, dominated by CPU scan and S7 protocol stack processing. Higher rates (sub-10 ms) are achievable but require careful scan time budgeting.

7.2 I-Device Throughput

• Maximum transfer area per I-Device: Up to 1440 bytes input and 1440 bytes output in total across all submodules (S7-1500 limit; CPU-specific limits may apply, e.g. CPU 1511 supports up to 1024 bytes in either direction).
• Submodule granularity: Slots are typically 1, 2, 4, 8, 16, 32, 64, 128, 256, 512 bytes (standard PROFINET submodule sizes).
• Update time: 250 µs to 512 ms; standard values are 1 ms, 2 ms, 4 ms. Faster update times require higher CPU performance and reduce the maximum number of IO devices on the controller.
• Determinism: PROFINET IRT (Isochronous Real-Time) can deliver sub-millisecond bounded latency; S7-1500 supports IRT on X1 from firmware V2.0+.

8. Diagnostic and Error Code Reference

8.1 PUT/GET STATUS Codes

8.2 I-Device Diagnostic Indicators

9. Field-Proven Caveats and Engineering Notes

10. Migration Path: PUT/GET Today, I-Device Tomorrow

Many real projects start with PUT/GET for exactly the reason in this scenario: the integrator has access to only one controller. When PLC_1 later becomes accessible (e.g. the OEM provides source files, or the integrator is granted read access to the original project), the architecture can be migrated:

1. Configure PLC_1 as an I-Device and define transfer areas that match the data ranges currently moved by GET/PUT.
2. Export the GSDML.
3. In PLC_2, install the GSDML and add the I-Device to the PROFINET topology.
4. Re-route the I/O points in PLC_2's user program to read from the process image (%IB/%IW/%ID) instead of the local DB populated by GET.
5. Keep the GET/PUT logic in a "deprecated" state for one or two commissioning cycles, then remove it to free the S7 connection resource.

Migration is essentially a one-time refactor: the data content is the same, only the access mechanism changes. This makes PUT/GET a low-risk starting point for field deployments where PLC_1 ownership is uncertain.

11. Selection Matrix

12. Verification Checklist

1. Confirm the IP addresses of PLC_1 and PLC_2 are in the same subnet (e.g. both 192.168.0.x/24) and the IP on PLC_2 matches the device configuration in TIA Portal.
2. Confirm PLC_1's PROFINET interface has Permit access with PUT/GET communication partner enabled.
3. Download the S7 connection to PLC_2. Confirm in Online & Diagnostics > Connections that the connection state is established.
4. Toggle the REQ bit on the GET/PUT FBs and observe DONE/ERROR.
5. Read the STATUS word and cross-reference against the table in Section 8.1.
6. For I-Device: confirm in the upper controller's Online & Diagnostics > PROFINET > Topology that the I-Device is reachable and all submodules are assigned.
7. Use a watch table in TIA Portal to read the destination DB or input process image to confirm data is updating.