Editor’s Note: This is the third of a series of tech tips that explain how PROFIBUS diagnostics work and how they can be used to make critical information available to a PLC or DCS. In Part 1 of this series, we showed the basic diagnostic mechanism that PROFIBUS uses. In Part 2, we looked at the coding of the extended Diagnosis. In this tip, we will see the basic alarm mechanism. In the 4th and final tech tip of this series, we will look at the details of alarm setup and coding.
PROFIBUS DPV1 Alarms are a special kind of extended diagnostic. Compared to normal extended diagnostics, Alarms require an additional acknowledgment “handshake” between the master (controller) PLC or DCS and the slave device.
In order for alarms to be operational within a system these conditions must be true:
Many DPV1 slaves allow the master to specify whether the slave will return alarms requiring acknowledgment or diagnostic data with no acknowledgment. This is usually selectable as a parameter during setup of the slave. This parameter is defined in the GSD file of the slave and is selectable from the master’s configuration tool.
The Alarm types that are specified by PROFIBUS and PROFINET International are Diagnostic, Process, Pull, Plug, Status, and Update alarms. In addition to the standard alarms, there are 94 Alarm codes that may be used by device vendors to specify their own alarms. The vendor specified alarms are defined in the GSD file and in the device documentation.
Alarms are reported in a standard diagnostic telegram. (See part 2 of this series) Identifier and Channel related diagnostics remain the same for DPV1 as for standard DPV0. The Vendor Specific part of the diagnostic telegram is replaced by Alarm information. Alarm information returned includes: Alarm Type, Slot Number of the module with the alarm, Alarm Specifier, Add_Ack (acknowledge required), and Sequence Number to show which alarm or alarms from this module is/are being reported.
So why would PROFIBUS and PROFINET International go to such lengths to specify how alarms work? Alarms contain a lot of information about what is going on in your process. Vendors put in some very good features that report all sorts of information. Many devices support corrective/reactive maintenance, some support preventative maintenance and some even support predictive maintenance. However, if the application/control program does not take advantage of the information, alarms and diagnostics are worthless. It is the responsibility of the application engineer to use the information, not “hide” it.
PI and the device vendors give you the “possibility” to know what is going on, the application engineer still needs to take that information and report it from the application program.
We will discuss the details of Alarm encoding/decoding in the next installment of Understanding PROFIBUS Diagnostics.
John Swindall, PROFI Interface Center
