The CPU has almost no I/O of its own. The real sensors and actuators live out on the machine, in distributed I/O like ET 200 stations, and they all talk to the CPU over one Ethernet cable running PROFINET. One IO-controller (the CPU) polls many IO-devices, over and over, every bus cycle. Watch it breathe — then pull a cable.
The CPU on the left is the IO-controller. The three ET 200 stations are IO-devices. On every bus cycle the controller sends each device its outputs and the device returns its inputs — a relentless round-trip you can see as packets on the wire. Hit ✂ Pull station 2 and watch the exchange to it stop and the diagnostics light up.
👀 With RT the packets jitter a little — they share the wire with everything else. Switch to IRT and they lock to a fixed rhythm: IRT reserves a guaranteed time slot each cycle for motion-grade determinism. Pull a station and the diagnostic buffer flags exactly which one dropped — that's how you find a failed device in seconds, not hours.
PROFINET's quirk: devices are identified by a device name, not only an IP. Commissioning is a ritual — load a device's description (its GSDML file), place it in the network view, give it a name, and the controller assigns the IP at startup by that name. Get the name wrong and the device just… isn't there.
🎛️ IO-controller — usually the CPU. Owns the bus, holds the configuration, polls every device cyclically and hosts the diagnostics.
📟 IO-device — an ET 200 station, a drive, a valve island. Described by a GSDML file, addressed by device name, exchanges I/O each cycle.
⏱️ RT (Real-Time) — standard cyclic data on shared Ethernet. Fast enough for the vast majority of machines; update times of a few ms.
🎯 IRT (Isochronous) — a reserved, scheduled slot every cycle for hard determinism. Used for synchronised motion and the tightest control loops.
A brand-new ET 200 station is wired and powered, but the CPU reports it as "not reachable." The IP looks fine. Most likely cause?