PROFINET Isochronous Mode and Ti/To
For coordinated motion, it is not enough for data to arrive fast - every axis must sample its position and drive its output at the same instant, cycle after cycle. Isochronous mode gives PROFINET that lockstep, and Ti and To are the timing points that make it happen. This page explains isochronous operation and what the Ti and To offsets actually do.
PROFINET Isochronous Mode in one line: PROFINET isochronous mode synchronizes the application, network, and I/O to one common clock so every device samples inputs and applies outputs at the same instant each cycle. Ti is the input capture offset before the cycle start, fixing when all devices latch their inputs; To is the output offset after cycle start, fixing when they apply outputs. This lockstep is what coordinated motion control needs.
Why Fast Is Not the Same as Synchronized
Real-time PROFINET already delivers data quickly and deterministically, but quick delivery alone does not coordinate distributed axes. If each drive samples its encoder and updates its output on its own internal timing, the axes drift relative to each other even when every frame is on time. Coordinated motion - a gantry, a flying shear, an electronic cam - needs every axis to capture its feedback and act on its command at the same physical moment, not merely within the same cycle.
Isochronous mode provides that. It builds on the hardware-scheduled timing of the isochronous variant of PROFINET, where a shared clock disciplines every device, and adds application-level synchronization so the control program, the network transfer, and the I/O all run in lockstep. This is the distinguishing step beyond ordinary real-time, and it is why the RT versus IRT distinction matters: isochronous operation depends on the scheduled, clock-synchronized transport that IRT provides.
What Ti and To Actually Do
Ti and To are the two timing offsets that pin sampling and actuation to the network cycle. Ti (input time) is an offset before the start of the cycle at which every device latches its inputs. Because all devices use the same Ti relative to the common clock, they all capture their feedback at the identical instant, so the controller receives a consistent snapshot of the whole machine as it was at one moment. Ti is set early enough that the captured data is ready to transmit at cycle start.
To (output time) is an offset after the start of the cycle at which every device applies its outputs. Again, because all devices share the same To relative to the clock, they all act at the same instant, so commanded moves happen simultaneously rather than smeared across the cycle. The controller runs its motion calculation in between, using the synchronized inputs to produce the next synchronized outputs. Tuning Ti and To is part of motion commissioning; the values must allow enough time for capture, transfer, computation, and application within one cycle.
A Symbolic Timing Budget
The whole isochronous arrangement can be written as one budget against the cycle length T. Inputs are latched at Ti ahead of a cycle boundary, the input data crosses the network in its scheduled window, the motion application computes for some window Tapp, the results cross back, and outputs are applied at To after a subsequent boundary. For lockstep to hold, capture, inbound transfer, computation, outbound transfer, and output application must all fit within the cycle structure the engineering tool lays out; if any element grows, something else must shrink or the cycle must lengthen.
Writing it out makes the erosion factors visible. A longer line of devices adds forwarding delay to the transfer windows; a heavier motion calculation eats the application window; a shorter cycle shrinks everything at once. The engineering tool computes the minimum feasible Ti and To from the actual topology, and the practical discipline is to leave headroom rather than configuring at the computed limits, because a budget with no slack turns every small disturbance into missed cycles. How the cycle itself is chosen is covered under the update time and reduction ratio.
Hardware and Topology Prerequisites
Isochronous operation is not a checkbox on an ordinary network. Every device in the synchronized path, including every switch the traffic crosses, must support the scheduled, clock-synchronized transport - in PROFINET terms, hardware of the appropriate class, since devices built only for unsynchronized real-time cannot participate. The distinctions between device capability levels are laid out under the PROFINET conformance classes.
Topology is configured, not discovered. The engineering tool must know the exact wiring - which port connects to which neighbor - because the transmission schedule is computed from it, and a field change as small as moving a cable to a different switch port invalidates the plan until the project is updated. Mixed traffic still works: the schedule reserves a window in each cycle for the synchronized frames and leaves the remainder open for standard real-time and TCP/IP traffic, so ordinary I/O and diagnostics can share the wire with a motion axis group.
Commissioning Checks That Catch Sync Problems
A short sequence of checks separates a healthy isochronous network from one that will limp along:
- Confirm every device and switch in the synchronized path supports the required class and firmware level per its documentation.
- Verify the downloaded topology matches the physical wiring port for port before enabling the motion application.
- Check that exactly one sync master is active and every participating device reports a synchronized state rather than free-running.
- Soak-run the network under full production traffic while watching the missed-cycle and sync-loss diagnostic counters.
- Trend axis-following error during a repeatable coordinated move; a periodic beat in the error usually points at a timing problem, not a servo tuning problem.
When the counters climb or the axes beat, the causes are usually physical: a marginal cable, a port swap relative to the planned topology, or a device silently dropping out of sync and rejoining. The systematic path through those symptoms is the same one used for diagnosing PROFINET jitter and dropped cycles, worked from the physical layer upward.
Frequently Asked Questions
What do Ti and To mean in PROFINET isochronous mode?
Ti is the input capture offset before cycle start - the instant every device latches its inputs, identical across the network because they share a clock. To is the output application offset after cycle start - the instant every device applies its outputs. Together they make all axes sample feedback and act simultaneously, which is what coordinated motion requires.
Does isochronous mode need IRT?
Yes. Isochronous operation relies on the hardware-scheduled, clock-synchronized transport that PROFINET IRT provides. Ordinary real-time (RT) delivers data quickly but does not give every device a common clock, so it cannot guarantee that distributed axes sample and act at the same instant. Isochronous mode builds application synchronization on top of IRT timing.
Why is synchronized timing needed for motion control?
Coordinated motion such as a gantry or flying shear needs every axis to capture feedback and apply commands at the same physical moment. If each drive uses its own timing, the axes drift relative to each other even with on-time frames. Isochronous mode locks sampling and actuation to a common clock so the motion stays precisely coordinated.
Can standard RT devices share a network with isochronous devices?
Yes. The computed schedule reserves part of each cycle for the synchronized traffic and leaves the rest open, so standard real-time devices and even TCP/IP traffic coexist on the same wire. Only the devices participating in the synchronized application, and the switches between them, must meet the isochronous hardware requirements.
What symptoms suggest Ti or To is set wrong?
Sync alarms and missed-cycle counters that increment under load, axes that track well individually but disagree with each other on coordinated moves, and following error with a repeating beat pattern. Because the engineering tool derives feasible Ti and To from the declared topology, these symptoms often trace back to a physical network that no longer matches the declared one rather than to the numbers themselves.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.