Profinet offers two grades of real-time communication, and the difference between them is about how tightly the timing is controlled. Real-Time, or RT, sends prioritised Ethernet frames that jump ahead of ordinary traffic but still travel over standard switches, which is fast enough for most process and factory I/O. Isochronous Real-Time, or IRT, goes much further, scheduling communication into reserved hardware time slots so that data arrives with sub-microsecond jitter, which is what coordinated motion control needs. IRT requires special switches and hardware, while RT can run on more ordinary networks. Knowing which class a segment uses tells a monitoring integrator whether they can tap it easily or not.
Profinet IRT vs RT in one line: Profinet RT (Real-Time) sends prioritised Ethernet frames that take precedence over normal traffic and run over standard switches, which suits most cyclic I/O. Profinet IRT (Isochronous Real-Time) reserves hardware-scheduled time slots so frames arrive with sub-microsecond jitter, as coordinated motion control demands, but it requires special IRT-capable switches and hardware rather than ordinary networking equipment.
Profinet RT achieves real-time behaviour without abandoning standard Ethernet. It marks its cyclic process-data frames with a high priority so that switches forward them ahead of best-effort traffic like web pages or file transfers. Those frames also skip some of the overhead of the general-purpose TCP/IP stack, being handled more directly, which shaves latency. The result is deterministic-enough communication for the vast majority of automation tasks: reading sensors, writing to actuators, exchanging status with remote I/O, all cycling on a regular schedule.
Because RT rides on prioritisation rather than strict scheduling, its timing is good but not perfectly rigid. Frames still share the network with each other and with lower-priority traffic, so there is some variability, or jitter, in exactly when a given frame arrives. For process control and most factory I/O this variability is comfortably small compared with the response times the equipment needs, so RT is entirely adequate and is the class most Profinet devices use day to day.
The great practical advantage of RT is that it works over ordinary managed switches that support the relevant priority handling, without exotic hardware. An engineer can build an RT network from widely available industrial switches, which keeps cost and complexity down. This ordinariness is also what makes RT relatively easy to observe from the outside, since the frames are travelling over normal Ethernet infrastructure that can be mirrored or tapped.
Isochronous Real-Time exists because some applications cannot tolerate even the small jitter that RT allows. Coordinating several motion axes so they move in precise lockstep, for example in a printing line or a synchronised handling machine, requires each device to send and receive at almost exactly the same instant every cycle. IRT delivers that by dividing each communication cycle into reserved time slots and scheduling the isochronous traffic into those slots in advance, so the timing-critical frames are effectively guaranteed a clear path at a known moment.
This scheduling is enforced in hardware rather than left to software priority. IRT relies on switches with special IRT-capable silicon that understands the reserved slots and forwards the scheduled frames deterministically, keeping jitter down into the sub-microsecond range. The whole segment shares a synchronised time base and a planned communication schedule, so the network behaves almost like a distributed clockwork mechanism. That is the level of precision motion control needs, and it is well beyond what prioritisation alone can provide.
The cost of that precision is dedicated hardware and more engineering. An IRT segment needs the special switches and devices that support it, and the communication schedule has to be planned as part of network design rather than left to chance. Because the time slots are reserved, an IRT network also allocates part of each cycle to the isochronous traffic and part to ordinary traffic, so the two coexist in a carefully partitioned way. IRT is therefore reserved for the parts of a machine that genuinely need it, with RT handling everything else.
For a monitoring integrator, the RT-versus-IRT distinction has a very practical consequence: how easily you can observe the traffic. RT frames travel over ordinary Ethernet on standard managed switches, so they can often be mirrored to a monitoring port or read through a gateway without disturbing the control network. That makes it comparatively straightforward to pull cyclic process values from an RT segment up into a cloud SCADA system, where they can be historised, dashboarded and alarmed alongside data from other sources.
IRT segments are a different matter. Their traffic depends on the reserved time-slot schedule and the special hardware that enforces it, so casually mirroring or inserting a device into an IRT path risks disturbing the very determinism the segment exists to provide. Motion-control data on an IRT network is usually best accessed indirectly, by reading the relevant values from the controller that already participates in the IRT schedule, rather than by tapping the isochronous wire directly. The controller then exposes the meaningful values through a normal interface that a gateway can read.
In practice this means a well-planned monitoring architecture treats the two classes differently. Merobix and similar cloud platforms typically ingest RT-level process and status data through a gateway or the controller, which is where the useful operational values live anyway, while leaving the tightly scheduled IRT motion traffic to the machine's own hardware. Knowing that a segment is IRT tells the integrator not to expect to sniff it like ordinary Ethernet, and to reach its data through the controller instead, keeping both the monitoring reliable and the motion control undisturbed.
No, it is just tighter in timing. IRT provides sub-microsecond jitter for applications like coordinated motion that genuinely need it, but it requires special switches and careful schedule planning. For the vast majority of process and factory I/O, RT's prioritised frames on standard switches are entirely adequate and much simpler.
RT runs over standard managed Ethernet switches that support frame prioritisation, so it does not require the special hardware that IRT does. That is one of its main advantages, keeping networks affordable and making the traffic relatively easy to observe on ordinary infrastructure.
It is risky, because IRT depends on reserved hardware time slots and inserting or mirroring devices can disturb its determinism. The safer approach is to read the values of interest from the controller that already participates in the IRT schedule, which then exposes them through a normal interface a monitoring gateway can read.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.