Standard Profinet RT is excellent — and jittery at the microsecond scale, because switched Ethernet queues. Coordinated motion — printing register, electronic gearing, multi-axis interpolation — needs every axis sampling and acting on the same clock tick. That is IRT’s whole job.
What IRT actually changes
Within a sync domain, all participants share a clock (sub-microsecond class) and the bandwidth is scheduled: a reserved time slice per cycle carries IRT frames on precomputed paths, standard traffic uses the remainder. Isochronous mode then couples the drive control loops and even the PLC’s OB6x execution to that clock — setpoint calculation, transmission and application land in fixed phase. The result is deterministic in the literal sense: not “usually fast”, but “always at the same instant”.
The demands follow from the mechanism: IRT-capable switches/devices along every IRT path (the schedule is computed per port), topology fixed in engineering (the planned paths are the schedule — rewiring means recompiling the domain), cycle times and axis counts budgeted in the tool, and the sync master placed deliberately.
Where the line sits
Speed/torque-controlled axes, even many, on RT: fine, routinely. Position control with interpolation across axes, camming/gearing, high-end winders with register: sync domain territory. The honest question is whether axes must agree with each other at sample precision — coordination is the trigger, not axis count.
FAQ
Can IRT and standard devices share the network? Yes — that is the design: reserved phase for IRT, open phase for the rest. The IRT paths need capable hardware; the office printer does not.
What cycle times are realistic? Down to the 250 µs class in engineered domains; most machinery motion lives happily at 1–4 ms. Shorter is a cost, not a trophy.
Zone Otomasyon engineers motion networks from the sync domain up. Servo and motion projects.