S7-1200 IWLAN Setup: I-Device and PUT/GET for AGV Networks

1. Overview: S7-1200 Peer-to-Peer Architectures for AGV Applications

Automated Guided Vehicles (AGVs) typically use a two-controller architecture: a stationary "master" controller that aggregates environmental sensor data (LiDAR, RFID, line-track photoeyes, zone beacons) and a "vehicle" or "slave" controller mounted on the AGV chassis that handles motor control, steering, and safety I/O. The two controllers must exchange orders, setpoints, and status frames over a wireless link — most commonly an Industrial Wireless LAN (IWLAN) backbone built on the SCALANCE W product family.

For the S7-1200 platform, three PROFINET/Ethernet-based methods can carry peer-to-peer traffic between two CPUs:

• PUT/GET – asymmetric, single-sided configuration, up to 160 bytes per call. Available on all S7-1200 CPUs; remote access must be explicitly enabled in TIA Portal from firmware V4.0 onwards.
• PROFINET I-Device – the vehicle CPU is configured as an I-Device (intelligent device) and the master acts as IO-Controller. Symmetric configuration, up to 1440 bytes of process data, and the I-Device transfer areas are mapped like distributed I/O on the controller side.
• Open User Communication (OUC) – connection-oriented via TSEND_C / TRCV_C (or TCON, TSEND, TRCV) over TCP, UDP, or ISO-on-TCP. Fully flexible payload size; requires structured DB programming and is the most portable across firmware versions.

The choice of method depends on payload size, latency budget, deterministic I/O behaviour, and whether the AGV PLC needs to expose its data to the master as if it were a remote I/O station (I-Device) or as a true peer (PUT/GET / OUC).

2. Prerequisites: Hardware, Firmware, and Software

Confirm the following before starting the configuration:

Verify firmware version in TIA Portal under Online > Accessible devices or via the CPU display: Diagnostics > General > Firmware version. The I-Device role is supported in CPU firmware V4.0 and above; PUT/GET to a remote partner (across a router) was added in V4.0 with the "Permit access with PUT/GET communication from remote partner" option.

3. Communication Method Comparison

4. IWLAN Network Architecture with SCALANCE W

A typical AGV deployment uses SCALANCE W access points mounted at ceiling height in a grid that fully covers the AGV's travel path. The vehicle-mounted SCALANCE W client (in client mode) associates to the strongest AP and "roams" between cells as the vehicle moves. The PROFINET traffic between the two S7-1200 CPUs travels through this wireless bridge exactly as if it were wired copper.

Key settings on the SCALANCE W devices (configured via Web-Based Management or TIA Portal topology):

• SSID: AGV_BACKBONE (broadcast disabled for security; pre-shared key WPA2/AES-CCMP).
• Channel: fixed 5 GHz channel, e.g. channel 52 (DFS-clear in EU), or use iREF for automatic channel selection.
• DTIM interval: 1 beacon (low latency for control frames).
• iPCF (industrial Point Coordination Function): enabled on both AP and client — gives <1 ms deterministic handover and 0 ms handoff time when crossing cell boundaries. Required for PROFINET RT traffic on moving vehicles.
• Max client roam time: <50 ms. SCALANCE W1788 supports <30 ms with iPCF-master.
• RSTP disabled on the wireless side; use iPRP for parallel radio redundancy if dual-radio SCALANCE W788 is used.

Refer to the SCALANCE W700/W1700 Configuration Manual (Entry ID 90880063) for the full parameter set, country-specific DFS tables, and iPCF cell planning rules.

5. I-Device Method — Step-by-Step Configuration

The I-Device approach is the recommended method when the master must read the AGV's drive state, battery state, safety diagnostics, and write setpoints (target speed, target steering, job ID) with PROFINET RT semantics. Detailed application example: "I-Device Function in Standard PN Communication" (Entry ID 109478798).

5.1 Configure the Vehicle (I-Device) CPU

1. Open the vehicle PLC project in TIA Portal. Select the CPU, then in the inspector go to Properties > PROFINET interface > Operating mode.
2. Set the interface role to "I-Device" (not "IO-Device"). Tick "IO-Controller" if the vehicle also has local distributed I/O to control (typical for an AGV chassis with SINAMICS V90 or SIMATIC ET 200 I/O).
3. Under Real time settings, set the send clock to 1 ms and the update time to 1×R (1 ms) for RT. If you need isochronous mode, set the same values on the master.
4. Under Transfer areas, click Add new and create:
   • Slot 0: Input area (AGV → Master), 64 bytes, starting at IB 100. Name: iDev_Inputs_to_Master.
   • Slot 1: Output area (Master → AGV), 32 bytes, starting at QB 100. Name: iDev_Outputs_from_Master.
5. Assign a unique PROFINET device name (e.g. agv-vehicle-01) and IP address (e.g. 192.168.10.51/24). The vehicle will be identified by this name on the master's PROFINET topology.
6. Compile and download to the vehicle CPU.

5.2 Configure the Master (IO-Controller) CPU

1. In the master project, open Devices & networks and add the vehicle PLC as a device. Use the GSD file or the partner project reference.
2. Drag the I-Device from the catalog into the network view. The connection is established automatically as an RT IO link.
3. Assign the master's PROFINET interface IP (e.g. 192.168.10.1/24).
4. Open the device view of the master and click on the I-Device slots — you will see the transfer areas you defined on the vehicle CPU now appear as inputs and outputs in the master's I/O map. The starting addresses are negotiated automatically; you can override them (e.g. map to IB 200 / QB 200 in the master).
5. Compile the master project and download.

5.3 Verify the I-Device Link

From the master PLC, open a watch table and add the I-Device input address. If the link is up, the first byte (IB 200) will show the PROFINET IO status. The PROFINET diagnostics can also be read in Online & diagnostics > PROFINET diagnostics. The PNIO_SEND / PNIO_RECV blocks are not used on the S7-1200 — those are S7-300/400 legacy blocks. S7-1200 I-Device data is consumed directly via process image or via DPRD_DAT / DPWR_DAT instructions if the addresses are outside the process image.

6. PUT/GET Method — Step-by-Step Configuration

PUT/GET is the simplest method for small payloads and is fully supported on the S7-1200. The full procedure is documented in the S7-1200 System Manual and in the application example "Open User Communication with S7-1200" (Entry ID 109747710).

6.1 Enable PUT/GET Access

1. On the master CPU, open Properties > Communication > Access to the CPU.
2. Tick "Permit access with PUT/GET communication from remote partner". This option is required because the vehicle PLC is on a different IP subnet reached through the SCALANCE W AP (a router). Without this, the master rejects remote PUT/GET calls.
3. Compile and download.

6.2 Create DBs and Call PUT/GET on the Master

1. Create DB 100 (master send data) and DB 200 (master receive data) in the master PLC. Each holds the data to be exchanged (max 160 bytes per call, 160-byte boundary alignment recommended).
2. Call PUT in OB1: PUT(REQ := M10.0, ID := 1, ADDR_1 := P#DB200.DBX0.0 BYTE 100, RD_1 := P#DB100.DBX0.0 BYTE 100) — this writes master DB 100 → vehicle DB 200.
3. Call GET in OB1: GET(REQ := M10.1, ID := 2, ADDR_1 := P#DB300.DBX0.0 BYTE 100, RD_1 := P#DB200.DBX0.0 BYTE 100) — this reads vehicle DB 300 → master DB 200.
4. The ID parameter is a free connection ID (1..255). The ADDR_1 pointer is the remote partner's DB address; this is what is configured on the calling side only — nothing must be configured on the vehicle PLC itself.

6.3 No Configuration on the Vehicle PLC

This is a unique property of PUT/GET: the receiving CPU has zero knowledge of the connection. It does not need its own PUT/GET call, does not need a connection resource reservation, and does not need a configured partner. It just answers PUT/GET requests from authorized IP addresses. The vehicle CPU must, however, have its protection level set such that it will accept remote PUT/GET access (set to "Full access incl. fail-safe" or use a separate user with communication rights).

7. Open User Communication (TSEND_C / TRCV_C)

For larger or variable-length payloads (such as diagnostic logs, or an order list), OUC is the most flexible method. TIA Portal V15.1+ provides a wizard:

1. Drag TSEND_C into OB1 from Instructions > Communication > Open User Communication.
2. The wizard prompts for the connection type — choose TCP for AGV telemetry, UDP for one-way broadcast, or ISO-on-TCP for S7-compatible large payloads.
3. Enter the partner IP (e.g. 192.168.10.51), the partner port (e.g. 2000), and the local port (e.g. 2001).
4. The wizard auto-generates the connection DB (DB 502) and a length / error status DB. Enable CONT for active connection establishment; the master can be the active side and the vehicle the passive side.
5. Repeat for TRCV_C on the master to receive responses from the vehicle.

For broadcast telegrams (e.g. fleet-wide "all-stop" command), use UDP. A single TSEND_C with an ADHOC send length can address up to 1472 bytes per packet on a 1500-byte MTU wireless network. Lower MTU on 5 GHz is recommended to 1300 to avoid fragmentation during roaming.

8. Data Mapping and Tag Allocation

Define a clear data contract between the two PLCs. A typical AGV payload looks like this:

For PUT/GET, the entire 100-byte payload fits in a single call. For I-Device, define two transfer areas (input and output) with the master offset starting at 0. For OUC, define a UDT that mirrors the above and serialise it into a DB of length LEN.

9. Diagnostics and Verification

Use the following diagnostic points to verify the link is healthy:

• Watch table — create a watch table on the master with the input process image, force a known pattern, and verify it lands in the vehicle's DB. The PROFINET status byte (bit 0 = "IO-Controller in RUN") tells you the cyclic link is up.
• CPU diagnostic buffer — under Online & diagnostics > Diagnostic buffer, look for events with ID 0x001E (connection established) or 0x001F (connection lost). Connection loss on IWLAN during handover is normal and should clear within 50 ms.
• SCALANCE W Web-Based Management — check the W client's Information > WLAN > Clients page for RSSI, link quality, and association time. RSSI < -75 dBm triggers a roam attempt; -80 dBm is the typical cutover threshold.
• PROFINET diagnostics — Online & diagnostics > PROFINET diagnostics > Port statistics: discard count, CRC error count, late collision count. A healthy link has zero discards and zero CRC errors.
• PROFINET alarms — channel-diagnostic alarms from the I-Device carry the diagnosis in plain text. A common alarm is "station failure" if the I-Device loses its connection to the master.

10. Troubleshooting Matrix: Common Faults and Corrections

11. Field Commissioning Checklist

1. Flash both CPUs to identical or compatible firmware; back up the project to a TIA Portal archive.
2. Verify PROFINET device names and IP addresses on each CPU display before powering the SCALANCE W radios.
3. Use a wired connection for first commissioning: laptop on the master PROFINET port, S7-1200 directly to the master PROFINET port. Verify the I-Device link is stable for 30 minutes before introducing the wireless link.
4. Connect the SCALANCE W AP, assign it an IP in the management VLAN, set the SSID and iPCF channel plan, and confirm a wired client can associate.
5. Install the SCALANCE W client on the AGV, associate, and confirm the vehicle's PROFINET device name is still visible from the master.
6. Run the AGV through the entire cell at slow speed. Capture RSSI logs from the SCALANCE W client and confirm no roams exceed 50 ms.
7. Introduce PROFINET update time. Start at 8 ms, then drop to 4 ms and 2 ms as the cell plan stabilises.
8. Inject a fault — pull power on the AGV — and verify the master's diagnostic buffer records the loss-of-station alarm with the correct timestamp.
9. Document the cell map, channel assignments, RSSI thresholds, and PROFINET cycle times for the maintenance crew.

12. FAQ