Every PROFINET network has two types of participants, and confusing their roles is the fastest way to misconfigure a machine. The I/O-Controller is the brain — it programs the data exchange, sets the update rate, and owns the application logic. The I/O-Device is the hands — it responds to the controller's data requests, reports its input status, and executes output commands on schedule. This article maps these roles to real hardware, explains how the data exchange works, and clarifies where each function lives in a modern machine architecture.
What is a PROFINET I/O-Controller?
The I/O-Controller is the PROFINET equivalent of a master device. It is always a PLC, PAC, or industrial PC running an automation application — typically programmed in IEC 61131-3 languages. The controller initiates all cyclic data exchange: during startup, it sends connect requests to each configured I/O-Device, negotiates the update rate (send clock), and establishes the application relationship (AR). Once the AR is active, the controller writes output data to each device and reads input data from each device on a fixed isochronous cycle, typically 1–8 ms for motion applications or 8–32 ms for process I/O. A single PROFINET controller can manage up to 256 I/O-Devices on one subnet. The controller also handles acyclic services: parameter assignment at startup, alarm acknowledgment, diagnostic record reads, and device identification via I&M (Identification & Maintenance) data.
What is a PROFINET I/O-Device?
An I/O-Device is the PROFINET equivalent of a slave. It responds to the controller's data exchange requests but never initiates cyclic communication on its own. The most common I/O-Devices are distributed I/O blocks (Siemens ET 200SP, ET 200AL), variable frequency drives, servo drives, valve terminals, HMI panels, and field instruments with integrated PROFINET interfaces. Each I/O-Device has a GSDML file (General Station Description Markup Language) that declares its capabilities — number of I/O modules, supported data types, update rate constraints, and alarm behavior. The engineering tool reads this file to configure the device in the network topology. In the network, every I/O-Device is identified by a unique device name (not an IP address — PROFINET uses DCP, the Discovery and Configuration Protocol, to assign names and IP addresses separately from data exchange).
How does the controller-to-device data exchange actually work?
PROFINET cyclic data exchange runs on a provider-consumer model over standard Ethernet. The controller sends an output frame containing the process data for all configured devices on its send clock. Each device extracts its own output data from the frame based on its position in the telegram structure. The device then responds with its input data in a separate frame. This exchange bypasses TCP/IP entirely — PROFINET RT (Real-Time) frames travel directly on the Ethernet layer (EtherType 0x8892), skipping the IP and TCP/UDP stack for deterministic latency. For high-performance motion control, PROFINET IRT (Isochronous Real-Time) adds hardware-based time slicing at the switch level, reserving bandwidth for cyclic data and reducing jitter below 1 μs. A standard RT device like the Siemens SINAMICS G115D distributed drive operates as a PROFINET I/O-Device on the RT channel, exchanging speed setpoint (controller→device) and actual speed/current/temperature (device→controller) every 2–8 ms.
Can a single device be both I/O-Controller and I/O-Device?
Yes — this is the PROFINET concept of a supervisor or a shared device. Some higher-end controllers support "I-Device" functionality, where a PLC acting as controller for its own local I/O also presents itself as a device to a higher-level controller. This is common in line-integrated machines: a robot controller manages its own axes locally (as I/O-Controller for its servo drives) but exposes a simplified data interface — "start weld," "fault status," "cycle count" — upward to a line controller, which treats the robot controller as one of many I/O-Devices. A shared device, less common but available in PROFINET V2.3 and later, allows two controllers to access different modules within a single physical I/O block — for example, a safety controller reading the F-modules while a standard controller reads the standard I/O on the same ET 200SP station.
When does the distinction affect your hardware choice?
The I/O-Controller vs I/O-Device distinction is not academic — it determines which hardware you buy and how you configure it. A standard VFD with a PROFINET interface is always an I/O-Device; it cannot be the controller. If you need coordinated multi-axis motion with electronic gearing, all servo drives are I/O-Devices under one motion controller. If you need peer-to-peer data exchange between two PLCs, PROFINET offers I-Device and controller-to-controller communication (C2C), but these are configured differently from the standard cyclic I/O exchange. The engineering cost of getting this wrong is significant: attempting to configure a drive as a controller, or assigning overlapping I/O addresses because the device/controller relationship was not mapped before the hardware order, is a common cause of commissioning delays.
Browse our industrial communication catalog for PROFINET-capable controllers and devices, and see the VFD selection for drives with integrated PROFINET interfaces including the SINAMICS G115D family.
