PROFINET devices support a diagnostic hierarchy which cannot only notify the user of an issue on a device but also can isolate the location of the issue within the device. This is a priceless benefit as it gives you the ability to find the error quickly. It could be a device-wide issue, a problem with a network port, a module fault, or a channel within a module for instance. Not only are you informed where the alarm occurred in the device, but you are also given some error information about the type of the alarm and an error code. Examples could be a diagnostic alarm like a wire break, process alarm such as an over temperature in a running process, or a network alarm where a port got unplugged from the device.
Every PROFINET device has to be modeled in a standard way, and this is described in the device GSD (General Station Description) file, which is imported prior to device configuration into the PROFINET engineering tool. A list of supported diagnostics and standard PROFINET errors, including manufacturer specific errors are included in the GSD file. Some modules might have diagnostic settings which are changeable by the user during configuration, allowing a custom tailoring of the settings for your application.
Once your system starts up, in the event the diagnostic condition occurs in a device, an alarm is sent to the PROFINET controller as well as being stored locally in the device. The user can then react to it in the user application if needed. The diagnostic information can also be read out with a tool by maintenance directly using read/write record services.
Part of the PROFINET application layer diagnostics come in the form of standard data records which are always present in the device. PROFINET data records can be read from a configuration tool or IO supervisor/controller at any time using a read record service. These records can contain diagnostic information, IO information, parameter sets, device information and more.
To explain this: a common issue is a configuration fault. The user did not setup the device with the proper configuration and it does not match the real configuration in the device. An example would be if the user configured the wrong device such as a variable frequency drive (VFD) instead of a valve and attempted to start it with the IO controller. The IO device would detect that the startup data was not matching its real identity and the device at startup would signal a configuration fault to the IO controller. The error could be read out using “Application Log Data”.
Another example would be if the user configured the correct device, but didn’t configure all of the modules properly also signaling a fault for the incorrect modules. The engineer could verify this by comparing in the engineering tool or by reading device diagnostics the “Module Diff Block” which would show a difference. And finally, there are many other diagnostic and information records available to provide information on the latest diagnostic error, log data, identification and maintenance (I&M0) information such as part number, serial number, firmware revision, input and output data status, and more. A few records even can be written to, for example, the user could add further identification information, like installation date, whom to call if there is a problem with the device, location, etc.
In conclusion, PROFINET has the most collective and comprehensive diagnostics suite available of any Industrial Ethernet protocol and its focus is to be simple. This helps make it easy to manage your network, implement diagnostics in your applications, and keep downtime to a minimum. And PROFINET supports diagnostics not only at the application layers but also on the network which is a unique feature of the technology.
To learn more and see how simple it is firsthand, attend one of our hands-on PROFINET Certified Network Engineer classes (North America) or here (internationally) in the near future.