I wanted to get a thread going regarding tips for general machine diagnostics. There is a lot of readily available diagnostic information which, if mapped and monitored, can have a dramatic effect on the time and effort required to diagnose a problem. Here are some of my favorites.
Generic Module Diagnostics
At the top of the I/O Mapping for most modules there is a handful of general datapoints. These include:
- ModuleOk
- SerialNumber
- ModuleID
By default, every module added to your project will be supervised by the hardware watchdog in Automation Runtime. This means that if a module is removed from the running machine or is missing at startup, the controller will immediately reboot into Service mode. Perhaps the most frequently given advice by B&R engineers is to turn this feature off and use the ModuleOk datapoint instead. (Module Supervision can be disabled in the Configuration for each module). If a module’s ModuleOk datapoint ever goes false, you can instead set an alarm and have your code react to the problem in a controlled fashion. This is also useful if you want to start testing out parts of your machine without all of the hardware installed.
The SerialNumber and ModuleID datapoints can provide additional information for your alarms or be used in your HMI. If a particular module is consistently throwing errors, these datapoints also give you enough data to effectively log which exact module is the culprit. (Note that this information is provided in the System Diagnostics Manager as well).
Power Supply Modules
Power supply modules (e.g. X20PS2100) have specialized datapoints that can help you locate power supply problems.
- StatusInput01: This boolean will go true if the bus power supply drops too low (< 4.7V)
- StatusInput02: This boolean will go true if the I/O power supply drops too low (< 20.4V)
If you suspect power issues on your machine, these datapoints should be monitored so that you can set alarm or create a log entry for frequent voltage drops.
Additionally, exact voltage and current can be monitored with the SupplyVoltage and SupplyCurrent datapoints. These datapoints must be enabled via the module’s Configuration.
Digital Outputs
Digital Outputs are accompanied by a StatusDigitalOutput datapoint. This input will go true if the output is turned on, but the module detects a wiring problem. If this ever occurs, the output should be turned off and an alarm should be set to notify the operator.
Analog Inputs
Analog Inputs are accompanied by a StatusInput input datapoint. This input is a USINT value where each bit represents different diagnostic information such as invalid value or open circuit. See the documentation for your specific module to learn more.
Powerlink Bus
The Powerlink Master has I/O datapoints which can help you to diagnose communication problems.
- CycleOk: This boolean will be true as long as cyclic communication is happening
- SyncOk: This boolean will be true as long as the communication is synchronized correctly
- FailedCycleCount: This is a counter which will increment every time there is a failed bus cycle
- CycleIdleTime: The unoccupied time during a Powerlink cycle (should be > 15% of the cycle time)
A single failed Powerlink cycle should not stop your machine and is not necessarily something to be concerned about. However if communication is consistently failing, or communication faults in certain situations, monitoring these datapoints and logging any changes can help you find the cause of communication problems.
X2X Bus
As with Powerlink, the X2X Master also has diagnostic I/O datapoints:
- SyncErrorCount: The number of failed synchronous frames
- AsyncErrorCount: The number of failed asynchronous frames
- ModuleLostWhileOperational: Increments anytime a module stops communicating (the loss of a module should correspond with that module’s ModuleOk datapoint going false)
As with the Powerlink datapoints, a single failed X2X cycle is not a reason to worry too much. However, these datapoints can be monitored to help diagnose persistent communication faults.
How to Monitor These Datapoints
Mapping the above datapoints to process variables allows you to use them in your project. One way to do this is by tying them into your existing alarm system (e.g. MpAlarmX). For example, if a module is removed while the machine is running, an alarm can be displayed on the screen. This will require the machine operator to fix the problem and acknowledge the alarm.
Another way to use this data is by creating custom log books in the Automation Runtime Logger. Custom log entries have many advantages.
- Viewing I/O diagnostic entries in-line with other logger entries will help you figure out what was going on when the issue(s) occurred (i.e. if a communication fault happens whenever a certain motor turns on).
- An export of the Logger (and therefore a System Dump) will contain all of this information
- You may want to keep a record of this data, but any changes don’t necessarily need to interrupt the machine operator with an alarm
You can add custom entries to the Logger using the official ArEventLog library or the UserLog library. The UserLog library is an unoffical logging library created by my colleague Tyler which makes creating custom Logger entries very easy.
If anyone has any additional tips or clarifications, please add them below. I’d also like to thank whoever presented on this topic at AutomationCon in 2013 for creating the presentation I referenced when writing this post.