What Is a PROFINET Alarm Frame?

Back to Blog

Acyclic, Acknowledged, and Event-Driven

Cyclic IO frames carry the same process image every update whether or not anything changed. An alarm frame is the opposite: it is sent once, when a specific event happens, and the controller acknowledges it. This acknowledgement matters because it makes alarms reliable - the device knows the controller received the event and does not simply hope a status bit was noticed. Alarms travel on the dedicated alarm CR inside the application relation, so they never compete with real-time IO for the cyclic budget.

Because alarms are edge-based, each condition produces a pair over its lifetime: an appearing alarm when it starts and a disappearing alarm when it clears. That lets the controller maintain an accurate live picture of what is currently faulted rather than a latch that never resets. It also means a lost alarm would leave the controller's view stale, which is exactly why the frame is acknowledged rather than fire-and-forget.

The Alarm Types You Will Actually See

The most common alarm is the diagnosis alarm, which announces that a channel or module diagnosis has appeared or disappeared - a wire break, a short, an overtemperature - and carries the same structured slot, subslot, and channel detail as the underlying diagnosis. Then there are the maintenance and hot-swap alarms: a pull alarm when a module is removed, a plug alarm when one is inserted, and a return-of-submodule alarm when a previously failed submodule comes back and rejoins the exchange.

There are also process alarms a device can raise for application events, and PROFINET reserves alarm handling for the parameterization-end and application-ready signals during startup. In practice, the diagnosis and pull/plug alarms are what you watch during troubleshooting: they tell you both what failed and whether someone physically changed the hardware, which is often the missing context. These alarms are one layer of the broader PROFINET diagnostics capability a device guarantees by its class.

Two Alarm Priorities, One Alarm Channel

The alarm machinery inside the application relation and its communication relations provides two priority levels. High priority is intended for process alarms - application events where the controller program should react promptly - while diagnosis, pull, plug, and similar housekeeping notifications travel at low priority. Each priority level is its own ordered, acknowledged channel, so an urgent process event is never queued behind a backlog of maintenance notifications.

For a practitioner the priority split mostly matters when reading captures or device documentation: seeing two alarm flows between the same device and controller is normal, not a fault. The essential properties hold for both - every alarm is delivered once, acknowledged, and ordered within its channel, and neither priority ever contends with the cyclic IO exchange, which continues on its schedule regardless of how much alarm traffic is in flight. Which events a given device raises at which priority is defined by its GSD description and the specification's rules, so the device documentation is the reference when a capture shows an event on a channel you did not expect.

From Alarm Frame to Operator Screen

An alarm frame terminates in the IO controller, but its useful life continues into the application. The controller's alarm handling surfaces the event to the user program - typically as a diagnostic interrupt or status the logic can evaluate - along with the structured detail identifying the station, slot, subslot, and channel involved. That detail comes from the same structures as the channel and module diagnostics model, so an alarm is best understood as the push notification and the diagnosis records as the queryable state behind it.

What the program does next determines whether the field investment pays off. Mapping alarm-derived status into named tags with timestamps means an HMI or supervisory system can tell an operator that a specific analog input channel on a specific remote rack reported a wire break at a specific time - which is a dispatchable work order, not a mystery. Sites that leave alarms unmapped end up with a generic module-fault lamp and a technician walking the rack with a laptop, which is exactly the outcome the protocol's structured detail exists to prevent.

A Field Guide to Reading Alarms During a Fault

The alarm types map onto troubleshooting questions like this:

Alarm	Trigger	What it tells you
Diagnosis appearing	Channel or module fault detected	Exactly which slot, subslot, and channel failed, and why
Diagnosis disappearing	Fault cleared	Whether the problem was transient or is truly resolved
Pull	Module removed	The hardware was physically changed
Plug	Module inserted	A replacement is in place and parameterization follows
Return of submodule	Failed submodule rejoins	IO exchange for that submodule is live again

Sequence and correlation carry most of the diagnostic weight. Repeated appearing and disappearing diagnosis pairs on the same channel point to marginal wiring, a corroded terminal, or a failing sensor rather than a dead one. A pull alarm with no following plug alarm means someone removed hardware and did not finish the job. A burst of alarms from several devices at the same timestamp suggests a shared cause - a power dip or a switch problem - and cross-checking against LLDP neighbor data shows whether the affected devices share a path through the network. The alarm history, read in order, is frequently the whole story.

Frequently Asked Questions