PROFIBUS DP Diagnostics and Extended Diagnosis

Back to Blog

The Slave Raises a Flag, the Master Reads the Detail

The clever part of DP diagnostics is that it costs almost nothing until something is wrong. During normal cyclic exchange the slave simply reports its I/O. When it has a problem, it sets a diagnostic indication in its response - a signal to the master that a diagnosis is waiting - without yet sending the detail. The master notices the flag and issues a diagnosis request to that slave, which returns the full diagnosis block. This keeps the routine cyclic traffic lean while still delivering rich fault detail on demand, much like PROFINET separates cyclic data from event alarms.

The standard part of the diagnosis block carries defined status bits: station not ready, station not existent, configuration fault, parameter fault, and the like. These tell the master about the health of the relationship itself - whether the slave came up correctly, whether its configuration matches, whether it is even answering. For a great many problems, these standard bits alone point you at the cause: a configuration fault means the module layout does not match, a parameter fault means the parameterization was rejected.

Extended Diagnosis Carries the Device-Specific Fault

Beyond the standard status, the diagnosis block includes an extended diagnosis area, Ext_Diag, where the device vendor encodes fault detail specific to that device: which channel has a wire break, which measurement is out of range, an internal fault code. The meaning of the extended bytes is defined by the device and documented in its manual and GSD file, so reading them usually means consulting that documentation to decode what a particular byte pattern signifies. This is where DP tells you not just that a slave is faulted but which terminal or function is the problem.

There is also a diagnostic overflow indication for when a device has more diagnostic information than fits in one block, so the master knows to fetch more. In practice, engineers map the important diagnosis bits into the PLC so the HMI can show a meaningful fault rather than a bare slave-fault flag, similar to surfacing a watchdog or link fault as an operator message. The decoded result is what a historian or SCADA layer such as Merobix then trends and alarms on; Merobix records the controller's diagnosis tags rather than requesting DP diagnosis blocks itself. Understanding the standard-plus-extended structure is what lets you trace a SCADA fault back to the exact DP diagnosis that raised it.

The Three Ext_Diag Formats

Extended diagnosis is not one undifferentiated blob; the specification structures it into three formats, each with a header identifying its type and length. Identifier-related diagnosis is a bitmap flagging which module slots have something to report - it narrows the search to a module. Channel-related diagnosis goes further: it names the module, the channel, and a coded error type from a standard list - wire break, short circuit, overrange, underrange - which makes it nearly self-describing. Device-related diagnosis is the free-form vendor area, and only the device documentation can decode it.

In practice you read them in that order of preference. A channel-related entry hands you the faulted terminal directly; identifier-related tells you which module to inspect; device-related sends you to the manual. The engineering tool can often translate vendor-specific entries into plain text, but only when the GSD file it holds matches the device firmware on the wire, which is one more reason a GSD file version check belongs in commissioning.

A Walkthrough From Flag to Fix

Suppose the slave at address N raises its diagnostic flag. A repeatable sequence keeps the investigation short:

1. Fetch the diagnosis block through the engineering tool or the controller's diagnosis function.
2. Read the standard bits first - a configuration or parameter fault ends the search immediately, because the problem is the setup, not the hardware.
3. If the standard bits are clean, parse the Ext_Diag headers to find the format: identifier, channel, or device-related.
4. For channel diagnosis, map the module and channel to the wired terminal and inspect that circuit.
5. For device-related bytes, decode against the manual's diagnosis table.
6. After the fix, confirm the diagnostic indication has cleared from the cyclic reply, not just from the tool.

One habit worth adopting: record the raw diagnosis bytes before power-cycling anything. Diagnosis often clears on restart, and a fault that vanishes along with its evidence will be back on the night shift.

Surfacing Diagnosis Without Flooding the Operator

Mapping every diagnosis byte to its own alarm buries operators; mapping only a bare slave-fault bit starves them. A workable middle course is a summary alarm per slave plus a coded diagnosis word the display can decode, with momentary diagnoses latched until acknowledged so a fault that flickers during the night still gets seen. The severity policy is an engineering decision: a channel warning on a spare input does not deserve the same treatment as a configuration fault on a shutdown node.

Bus-wide upsets deserve their own thought. When a segment power dip or a broken termination hits, dozens of slaves flag diagnosis at once, and an alarm list that presents them alphabetically hides the cause. Grouping alarms by physical segment makes the pattern visible - one segment lighting up together points at cable, power, or termination, not at any individual device.

Frequently Asked Questions