S7-300 I-Device PROFINET Setup for CPU-to-CPU Data Exchange

Connecting multiple S7-300 CPUs over PROFINET for peer-to-peer data exchange is a common requirement in distributed control architectures. This reference documents a production-tested configuration for one IO controller plus three S7-315-2 PN/DP stations that must each exchange 240 bytes bidirectionally, while remaining extensible to additional IO controllers and cross-project integration. It covers the I-Device mechanism in both STEP 7 V5.6 and TIA Portal, transfer-area sizing, firmware prerequisites, and the PUT/GET fallback path for projects that already rely on S7 connections.

Topology and Use Case Overview

The reference topology is a flat PROFINET network in which one CPU acts as the PROFINET IO controller and three S7-315-2 PN/DP stations act as I-Devices. The controller does not own the I-Devices' programs; it only consumes the I-Devices' configured transfer areas as IO data. From the controller's point of view, each I-Device is a modular PROFINET device with one or more slots whose contents are mapped into the controller's process image.

Per the engineering requirement, each I-Device provides 240 bytes of input data (consumed by the controller) and accepts 240 bytes of output data (provided by the controller). The total data exchanged between the controller and any single I-Device is therefore 480 bytes per update cycle. The controller originates data destined for the three I-Devices; each I-Device's user program also provides its own 240-byte block to the controller. This pattern keeps coupling strictly cyclic (PROFINET real-time) and avoids any per-call programming on the wire.

Method Selection: I-Device, PUT/GET, or Direct Data Exchange

Three different mechanisms can move data between S7-300 CPUs on PROFINET. Choosing the right one depends on firmware levels, project boundaries, and data size.

For 240 bytes bidirectional data with strict real-time expectations, the I-Device mechanism is the recommended path. PUT/GET and BSEND/BRCV are valid alternatives if the S7-300 firmware does not support I-Device, if the data is acyclic, or if a S7 connection already exists for other reasons. PUT/GET example wiring and S7-connection configuration are documented in Siemens Support article 82212115.

Prerequisites: Hardware, Firmware, and Software

Confirm the following before you begin configuration. Mismatched firmware is the single most common cause of "the I-Device option is greyed out" complaints.

• IO controller CPU: S7-315-2 PN/DP (order numbers 6ES7315-2EH14-0AB0 or 6ES7315-2EH13-0AB0), PROFINET interface enabled.
• I-Device CPUs: S7-315-2 PN/DP, firmware V3.2 or higher. The I-Device role is exposed in HW Config under the PN interface properties only when the firmware supports it. CPU 6ES7315-2EH08-0AB0 (older FW 2.x) does not support I-Device and must be replaced or used as a PUT/GET peer.
• STEP 7 V5.6 / V5.7 with the latest Service Pack, or TIA Portal V16 or higher for an integrated workflow.
• GSD files for the I-Devices if a separate project is involved (export from the I-Device project, import into the controller project). The exported GSD carries the I-Device's transfer-area description as device/submodule slots.
• PROFINET topology: All four CPUs in the same subnet (e.g. 192.168.0.x/24), with switch port assignments and device names assigned before commissioning.

S7-300 I-Device Transfer Area Limits

The I-Device transfer area is the data region the CPU exposes to the higher-level IO controller. It is composed of one or more transfer slots, each with a length, an address in the I-Device's process image, and a direction (input or output relative to the controller).

For three I-Devices, the controller consumes 3 x 240 = 720 input bytes and provides 3 x 240 = 720 output bytes. With four slots total (two per I-Device), the project uses 12 IO slots in the controller's device view (one device slot plus two data slots per I-Device).

STEP 7 V5.6 Configuration: Master as IO Controller

With the master CPU selected, the project must define the three I-Devices as PROFINET IO devices. In an integrated STEP 7 V5.6 project (master and I-Devices in the same project), use the following sequence.

1. Open the master CPU in HW Config and double-click the PN-IO interface (X2) to open Properties.
2. On the PROFINET IO tab, confirm the controller role and assign a unique PROFINET device name (e.g. plc-master) and IP address (e.g. 192.168.0.10/24).
3. Right-click the PN-IO port of the master and select Insert PROFINET IO System. The PROFINET IO system appears in the right-hand pane of HW Config.
4. From the project tree, drag each of the three S7-315-2 PN/DP stations from the SIMATIC 300 station list into the PROFINET IO system. STEP 7 creates a PROFINET IO device for each station.
5. For each dragged station, double-click the IO device and configure its device name (plc-slave1, plc-slave2, plc-slave3) and IP address (192.168.0.11/24, 192.168.0.12/24, 192.168.0.13/24).
6. For each I-Device, the slots that the controller will see are the transfer areas defined in the I-Device's HW Config. The controller's view of each I-Device is read-only at this stage: the controller simply maps the slot data into its own process image.
7. Compile and download the master station. Use the Accessible Nodes function to verify the four devices are online and reachable.

STEP 7 V5.6 Configuration: I-Devices (Slaves)

Each I-Device CPU must have its transfer area defined in its own HW Config. From the I-Device's point of view, the transfer area is a real I/O area that is exchanged with the higher-level controller.

1. Open the I-Device CPU (slave) in HW Config.
2. Double-click the PN-IO interface, switch to the Operating Mode tab, and enable I-Device. STEP 7 exposes the Transfer Area configuration under the interface once this option is enabled.
3. Click New to add a transfer area. Configure the first area as follows:
   • Type: Input (data flowing from I-Device to controller)
   • Length: 240 bytes
   • Start address (in I-Device process image): e.g. IB 100
   • Slot number (controller view): 1
4. Add a second transfer area for the output direction (data from controller to I-Device):
   • Type: Output
   • Length: 240 bytes
   • Start address (in I-Device process image): e.g. QB 100
   • Slot number (controller view): 2
5. Repeat for the second and third I-Devices, using the same slot-numbering convention (1 and 2) so the controller's view is identical across all three I-Devices. The actual IP and device name are the only differences.
6. Compile and download each I-Device separately.

Mapping on the Master (IO Controller) Side

After the three I-Devices are inserted, the master HW Config shows each I-Device in slot 0 of the PROFINET IO system, with submodule slot 1 (input) and slot 2 (output). The master CPU's process image receives the following mapping by default:

Choose start addresses that do not overlap with the master's local I/O and that respect the S7-300 process-image partitioning. If the master uses OB1 with full process image and a process-image size of 1024 bytes input / 1024 bytes output, the cumulative 720 input / 720 output bytes fit comfortably.

TIA Portal Configuration Workflow (Alternative)

When the project uses TIA Portal V16 or higher, the workflow mirrors STEP 7 V5.6 but exposes additional diagnostics. The same I-Device role is configured under Properties > PROFINET interface [X2] > Operating mode > I-Device.

1. Add the four S7-300 stations to the project. For each I-Device, open the device view, select the PN interface, and on the Operating mode tab enable I-Device and define the transfer areas exactly as in STEP 7 V5.6 (240 B input, slot 1; 240 B output, slot 2).
2. On the controller station, open Devices & Networks, drag a PROFINET connection from the controller's PN port to the first I-Device's PN port. Repeat for I-Devices 2 and 3.
3. TIA Portal automatically creates the IO device entry and assigns the controller as the IO controller. Verify the device name and IP of each I-Device in the device properties.
4. In the controller's device view, open Device overview; the slots 1 and 2 of each I-Device appear with the configured 240-byte lengths. Adjust the master's process-image start address to the desired range (e.g. IB 100 / QB 100 for slave 1, then increment by 240 for the next I-Device).
5. Compile the project. Use Go online > Accessible nodes to download each station individually, then perform an assignment of PROFINET device name via Online & diagnostics > Assign PROFINET device name.

TIA Portal's PROFINET diagnostics surface includes per-slot health, send-clock, and refresh-time information directly under Online & diagnostics > PROFINET diagnostics, which simplifies verification compared with STEP 7 V5.6.

Cross-Project I-Device Integration via GSD

When the I-Devices are engineered in a separate project (different team, different maintenance boundary), STEP 7 V5.6 / TIA Portal can export the I-Device as a GSD-based PROFINET device.

1. In the I-Device project, open the I-Device's PN interface, switch to Operating mode > I-Device, and click Export. STEP 7 generates a GSD file that describes the I-Device as a modular PROFINET device with the configured transfer slots.
2. In the controller project, install the GSD file via Options > Install GSD file in STEP 7 V5.6, or Options > Manage general station description files (GSD) in TIA Portal.
3. Insert the I-Device from the hardware catalog under the appropriate PROFINET IO family. The slot structure (slot 0 device, slot 1 input submodule, slot 2 output submodule) is preserved from the export.
4. Assign the device name and IP as in the integrated case. The runtime behavior is identical to the integrated case, but configuration changes on the I-Device side require re-exporting the GSD and re-installing it on the controller side.

Supporting Multiple IO Controllers per I-Device

The original question asked whether two IO controllers can share the same I-Device. The answer is yes, with the right slot allocation:

• Slot partitioning: Assign disjoint transfer-slot ranges to each IO controller. For example, the first IO controller owns slots 1 and 2 (240 B each), the second IO controller owns slots 3 and 4 (240 B each).
• IP and device name: Each IO controller reaches the I-Device over the same PROFINET network; the device name is the same (the I-Device has one PROFINET identity), but each AR is independent.
• Update time: Each IO controller configures its own send clock; the I-Device multiplexes the ARs. Watch for combined cycle time exceeding the configured update time on either AR.
• CPU limit: Confirm the I-Device CPU supports the number of ARs you intend to use. The S7-315-2 PN/DP supports multiple ARs; the exact maximum is documented in the CPU's data sheet and is typically 4 to 8 depending on firmware.

From the user-program point of view on the I-Device, the multiple ARs remain transparent: the input data from controller A and controller B both land in the I-Device's process image at the configured start addresses. The user program reads those bytes and acts on them, without any awareness of the ARs.

PUT/GET Alternative: S7 Connection for Acyclic or Small Data

If the S7-300 firmware does not support I-Device, or if the data is acyclic and small, the classic S7-connection path with PUT and GET is the fallback. The configuration is described in detail in Siemens Support article 82212115, but the salient points for the 240-byte case are:

• Connection count: S7-315-2 PN/DP supports up to 16 S7 connections. Three masters-to-slave links would consume three of those, leaving margin for HMI and PG connections.
• Block choice: With 240 bytes per direction, PUT and GET (FB15 and FB14 in the STEP 7 V5.x standard library) hit their per-call ceiling of 160 bytes on the S7-300. The 240-byte payload must be split across two PUT/GET calls (for example 160 + 80) or migrated to BSEND/BRCV (FB12/FB13), which supports payloads up to 32768 bytes per call.
• Configuration path: Open NetPro on the master, right-click the master's PN interface, and insert an S7 connection. Specify the partner IP, the partner's connection resource (one of the 16 S7 connection IDs on the slave), and leave it as an S7 connection (not ISO-on-TCP-only). Compile and download both stations; the S7 connection establishes on the first communication attempt.

PUT/GET is acyclic and event-driven; it is not deterministic. For a 1 ms update, stick with the I-Device mechanism. For status data, operator-setpoints, or non-time-critical exchanges, PUT/GET is easier to retrofit because it does not require slot and process-image planning.

Direct Data Exchange (PROFIBUS) as a Last-Resort Pattern

If a parallel PROFIBUS network is available on the S7-315-2 PN/DP (the second interface on this CPU is PROFIBUS DP master or slave), a direct data exchange (DX) configuration is possible. The conceptual flow is described in the TIA Portal direct data exchange example, which walks through linking a master and two slaves with PROFIBUS connections. For a 240-byte payload, however, the PROFINET I-Device path is preferred: it removes the need for an additional PROFIBUS cable plant, the configuration is graphical and integrated, and the same CPU can act as both IO controller and IO device without any second network.

Commissioning, Download, and Verification

Follow this verification sequence after the configuration and download of all four stations.

1. Device-name assignment: For each CPU, use Accessible nodes in STEP 7 / TIA Portal and assign the configured PROFINET device name. A station that keeps its default name will not join the IO system.
2. IP verification: Ping each IP from the PG. ARP and ICMP must succeed before PROFINET ARs can be established.
3. IO controller online diagnostics: Open the online view of the master HW Config. Each I-Device should appear with a green check in PROFINET IO > Diagnostics. Station status should be "OK" with no submodule fault.
4. I-Device diagnostics: On each slave, open Online & diagnostics and check the PROFINET diagnostics. The transfer slots should report their input/output lengths and current data update state.
5. End-to-end data check: On the master, force a pattern into QB 100 (slave 1, output slot). On slave 1, monitor IB 100 in a VAT or watch table. The pattern should appear within one configured update time (typically 1 ms). Reverse the check for the input slot by writing a pattern in the slave's VAT to its input transfer area and reading IB 100 on the master.
6. Live cycle counter: Insert a 32-bit counter in the I-Device's first input byte. The master should see it incrementing at the configured send-clock rate. This catches AR-drop and re-AR issues that a static test misses.

Diagnostics and Online Tools

• Master online view (STEP 7 V5.6): PLC > PROFINET IO > Diagnostics shows per-station status, per-slot status, and AR state.
• Master online view (TIA Portal): Online & diagnostics > PROFINET diagnostics shows the same data with a clickable topology tree.
• I-Device online view: Online & diagnostics > PROFINET diagnostics > Transfer areas lists each transfer area's IO data length, current quality code, and last update time.
• Diagnostic buffer (I-Device): The CPU's diagnostic buffer records PROFINET AR establishment, AR loss, and station-fault events. Always read the buffer in chronological order (newest first) when an AR keeps dropping.
• Wireshark with PROFINET dissector: For cyclic-data debugging at the frame level, attach Wireshark to a mirror port on the switch. The PROFINET RT frames carry the IO data, slot identifiers, and AR UUIDs, which makes it easy to identify the source of a misconfigured slot.

Troubleshooting Matrix

Common Engineering Pitfalls

• Confusing direction in the I-Device HW Config. The "Input" transfer area on the I-Device is data sent from the I-Device to the controller. The "Output" transfer area on the I-Device is data received from the controller. Many engineers swap these two on the first try.
• Re-using the same start address for input and output. Each direction has its own address range; using QB 100 for both directions will corrupt the IO update on the first write.
• Exceeding the 244-byte slot limit. The PROFINET spec for S7-300 I-Devices limits a single slot to 244 bytes. Use multiple slots if a single direction exceeds that.
• Forgetting the process-image partition on the master. The S7-300 only updates the process-image range configured in OB1. If the IO data falls outside, the master program must use direct PI access (Pxx/PQB/PQW/PQD) or extend the partition.
• Compiling the master before the I-Device has its transfer area. STEP 7 V5.6 cannot resolve the I-Device's slot structure if the I-Device project is not yet compiled. Compile all I-Devices first, then the master.

Performance and Update-Time Considerations

With 240 bytes per I-Device, three I-Devices, and 1 ms send clock, the I-Device path easily meets any reasonable application requirement. The PROFINET RT frame payload limit is well above 720 bytes input + 720 bytes output. The S7-300 PN interface is rated for these payloads without contention as long as the send clock matches across all stations. Mismatched send clocks do not break the AR but can cause data jitter if the controller's update time is shorter than the slowest I-Device's configured send clock. Lock the send clock to a single value across all four stations when in doubt.

Summary

For the original 4-CPU requirement, configure the three S7-315-2 PN/DP stations as PROFINET I-Devices (firmware V3.2 or higher), with a 240-byte input transfer area and a 240-byte output transfer area per station, slots 1 and 2 in the controller's view. Use STEP 7 V5.6 (or TIA Portal V16+) for an integrated project, or export each I-Device as a GSD for a cross-project setup. The I-Device path provides deterministic, cyclic, real-time data exchange without per-call user code, and it scales to a second IO controller by allocating disjoint transfer-slot ranges. PUT/GET remains the fallback for older firmware or acyclic needs, but its 160-byte per-call ceiling forces a split for the 240-byte payload or a switch to BSEND/BRCV.