How PROFINET Communicates

To diagnose PROFINET, it helps to understand how it actually
communicates — in particular, the fast cyclic exchange that carries the
I/O data and the watchdog mechanism that declares a device failed. Most
PROFINET faults, at heart, are about this cyclic communication being
interrupted, so understanding it tells you what is really going wrong
when a device ‘fails’. This chapter explains the communication in the
practical terms a maintenance technician needs.

Cyclic data: the I/O image on the wire

The heart of PROFINET communication is the cyclic exchange of I/O
data, and understanding it clarifies what the network is doing moment to
moment and what stops when a fault occurs. The controller and each
device exchange their I/O data cyclically — automatically, repeatedly,
at a fast fixed interval: the controller sends the outputs to the device
and the device sends its inputs to the controller, over and over, many
times a second. This cyclic exchange is how the PLC’s I/O image stays in
sync with the real I/O out on the machine: the inputs the program reads
and the outputs it sets are kept current by this constant exchange. So
the cyclic data is the continuous, automatic heartbeat of the network,
keeping the controller and devices in sync. When this exchange is
interrupted — the data stops flowing — the device’s I/O is no longer
updated, which is the essence of a device ‘failing’ on the network.
Understanding cyclic data — the constant automatic exchange of the I/O
image — clarifies the network’s core activity and what a fault
interrupts. It reinforces that PROFINET’s core is the fast cyclic
exchange of I/O data between controller and devices, keeping the I/O
image current, so that a fault interrupting this exchange is what
‘failing’ means. Understanding cyclic data as the I/O image on the wire
— the constant, automatic, fast exchange that keeps the controller and
devices in sync — is central to understanding PROFINET, because this
heartbeat is what the network fundamentally does, and its interruption
is what most faults come down to, so that grasping the cyclic exchange
tells you what is really happening when a device stops communicating and
why keeping that exchange flowing is the network’s essential job.

Update time and the watchdog

Two related concepts — the update time and the watchdog — govern when
a device is considered healthy or failed, and understanding them
explains the classic PROFINET failure precisely. Each device has an
update time: the interval at which its cyclic data is exchanged (for
example, every 2 milliseconds, or every few milliseconds — configurable
per device). Alongside this is a watchdog: a tolerance for missed
updates, typically a small number of update intervals. As long as the
cyclic data arrives within the watchdog time, the device is healthy. But
if updates stop arriving — if the controller misses several in a row,
exceeding the watchdog — the device is declared failed: the network
concludes that communication with it has been lost. So the watchdog is
what turns a brief interruption into a declared failure: miss updates
beyond the watchdog time, and the device ‘fails’. This is the mechanism
behind the classic PROFINET fault — a device going from OK to failed
because its updates stopped long enough to trip the watchdog.
Understanding update time and watchdog — the interval of exchange and
the tolerance for missed updates — explains exactly how and when a
device is declared failed. It reinforces that each device has an update
time and a watchdog, and that missing updates beyond the watchdog
declares the device failed, which is the classic PROFINET failure.
Understanding the update time and the watchdog — the cyclic interval and
the tolerance that, when exceeded by missed updates, declares a device
failed — explains the precise mechanism of the most common PROFINET
fault, so that when you see a device ‘failed’, you understand it means
the cyclic updates stopped arriving long enough to trip the watchdog,
which directs your diagnosis to why the updates stopped: almost always
something interrupting the cyclic communication, most often
physical.

Acyclic messages: parameters and diagnostics

Alongside the cyclic data, PROFINET carries acyclic messages for
occasional needs, and understanding these — particularly that
diagnostics travel this way — completes the communication picture. Not
everything needs to be exchanged every cycle: some information is needed
only occasionally — writing configuration parameters to a device at
startup, reading a detailed diagnosis, retrieving a record. These travel
as acyclic messages: sent on demand rather than every cycle. Importantly
for troubleshooting, diagnostic information is conveyed this way: when a
device has a fault to report, it makes that diagnosis available, and the
controller or your tool reads it acyclically. So the network carries two
kinds of traffic: the constant cyclic I/O data, and the occasional
acyclic messages for parameters and diagnostics. This matters because it
means the network itself carries the diagnostic information you use to
troubleshoot — the faults a device reports come to you over the same
network, via acyclic messages. Understanding acyclic messages — the
on-demand traffic for parameters and diagnostics — completes the picture
and explains how diagnostics reach you. It reinforces that alongside
cyclic I/O data, PROFINET carries acyclic messages for parameters and
diagnostics, which is how a device’s fault information reaches the
controller and your tool. Understanding acyclic messages — the on-demand
traffic carrying parameters and, crucially, diagnostics — completes your
picture of PROFINET communication, so that you understand both the
constant cyclic exchange (whose interruption is most faults) and the
acyclic messages (which carry the diagnostic information you read to
troubleshoot), which is why the network can report its own faults to
you: the diagnostics travel as acyclic messages over the same network
that carries the I/O data.

Real-time classes: RT and IRT

A refinement of PROFINET communication worth understanding is that
there are different real-time classes — chiefly RT and IRT — because it
explains why some networks have special timing hardware and
requirements. Standard real-time (RT) is the common case: cyclic data
exchanged in real time over ordinary Ethernet switches, sufficient for
most applications. Isochronous real-time (IRT) is a higher class for the
most timing-critical applications (like coordinated motion control),
which requires special hardware and precise scheduling to achieve very
tight, deterministic timing. Most maintenance situations involve RT, but
you may encounter IRT on high-performance motion systems, where the
timing requirements and the special hardware matter. Understanding the
real-time classes — RT for the common case, IRT for the most demanding —
explains why some networks have special timing requirements and
hardware. Understanding the real-time classes — RT for standard
real-time communication over ordinary switches, and IRT for the most
timing-critical applications needing special hardware and scheduling —
explains why some PROFINET networks have special timing hardware and
stricter requirements, so that when you encounter a high-performance
motion system with special timing configuration, you recognize it as IRT
and understand its extra demands, while knowing that most maintenance
situations involve the more common RT class that runs over ordinary
Ethernet switches, which distinguishes the everyday case from the
specialized one.

Scenario: the device that failed on a watchdog

A scenario shows understanding the watchdog explaining a puzzling
failure. A device kept ‘failing’ briefly and returning, and the
technician was puzzled — the device seemed fine, yet the network
declared it failed. Understanding the watchdog explained it: the
device’s cyclic updates were being interrupted just long enough, now and
then, to exceed its watchdog and trigger a declared failure, after which
the updates resumed and the device returned. So the device was not
itself broken; its communication was being interrupted. This
understanding redirected the diagnosis from the device to what was
interrupting its updates — which turned out to be a marginal connection
dropping the link briefly. Understanding that a watchdog turns a brief
communication interruption into a declared failure led the technician to
look for the interruption rather than a broken device. This scenario
shows watchdog understanding explaining an intermittent failure and
redirecting the diagnosis. Understanding the update-time-and-watchdog
mechanism let the technician see that the ‘failure’ was interrupted
communication, not a broken device, directing the diagnosis to the
interruption. It reinforces that understanding the watchdog explains why
brief communication interruptions cause declared failures, redirecting
diagnosis to the interruption’s cause. The scenario reinforces the value
of understanding the communication mechanism: knowing that a watchdog
declares a device failed when updates are interrupted led the technician
to correctly seek what was interrupting the communication (a marginal
connection) rather than suspecting the device itself, which is how
understanding the cyclic exchange and watchdog directs the diagnosis of
the classic PROFINET failure to its real cause.

Shared device and multiple controllers

A more advanced configuration worth understanding is the shared
device — where more than one controller communicates with one device —
because it explains some otherwise puzzling situations. Normally one
controller owns a device, but PROFINET allows a shared device, where
different controllers access different parts (modules) of one device.
This is used in some larger or safety-related systems. For
troubleshooting, the relevance is that a device’s communication may
involve more than one controller, so a problem could relate to one of
the controllers or its part of the device, which is more complex than
the simple one-controller case. You likely will not meet this often, but
recognizing that a shared device involves multiple controllers helps you
make sense of a configuration that would otherwise be confusing.
Understanding the shared-device concept — multiple controllers sharing
one device — explains a more complex configuration you may occasionally
meet. Understanding shared device and multiple controllers — the
configuration where more than one controller accesses different parts of
one device — explains an advanced situation you may occasionally
encounter, so that when a device’s communication involves more than one
controller, you recognize the shared-device configuration and understand
that a problem could relate to a particular controller or its part of
the device, which is more complex than the simple one-controller case
but comprehensible once you know that PROFINET permits sharing a device
among controllers, helping you make sense of an otherwise puzzling
configuration.

Communication understanding as a diagnostic lens

To close, it helps to see how understanding PROFINET’s communication
serves as a diagnostic lens through which the faults make sense, because
this framing shows why the communication concepts matter for every
fault. The core concepts — cyclic data as the constant heartbeat, the
update time and watchdog governing health, acyclic messages carrying
diagnostics — form a lens: through it, a ‘failed device’ is seen as
interrupted cyclic communication tripping the watchdog, a diagnosis is
seen as an acyclic message the network sends you, and a
stable-then-dropping device is seen as a watchdog problem. Every
PROFINET fault, viewed through this lens, becomes comprehensible in
terms of the communication. So understanding the communication is not
academic; it is the lens that makes the faults make sense and directs
the diagnosis. Seeing communication understanding as a diagnostic lens —
through which faults become comprehensible — shows why the concepts
matter for every fault. Understanding communication as a diagnostic lens
— the cyclic heartbeat, the update time and watchdog, and the acyclic
diagnostics forming a framework through which every fault becomes
comprehensible — shows why the communication concepts matter for every
fault, so that you view a failed device as interrupted cyclic
communication, a diagnosis as an acyclic message, and a dropping device
as a watchdog problem, which turns the communication understanding into
a practical lens that makes PROFINET faults make sense and directs your
diagnosis to what is really happening in the communication, the deeper
value of understanding how the network communicates.