Preventing machinery faults and downtime is a recent topic of discussion in the automation business. A lot of interesting information is offered, mostly anecdotal, that is offered as “helpful tips” for the aspiring automation programmer. But its generally very loose, as anecdotal information usually is, and not quite as helpful for specific situations.
Better automation diagnostics should be the result of 2 major sources of input; intelligent design and discovery.
On the design side we can narrow diagnostics to a few topics that we know something about.
- Conditions that can be measured, logged and used for predictive maintenance
- Conditions that will lead to a fault condition over time
- Fault conditions that are software recoverable
- Fault conditions that require operator intervention
- Fault conditions that trigger an emergency stop condition
For the purpose of this post, I will focus on the first item and pick up on the others in the future. A couple of important comments on “discovery” follow.
In terms of conditions that can be measured and used for predictive maintenance, this could apply to any condition for which there is a dynamic sensor. If you are measuring air pressure at the manifold of a group of pneumatic actuators, trending this value is extremely important since pressure predicts the speed of the motion. When monitoring the current of an electric motor, ac or dc, the current value over time is associated with torque. If the current is trending up over time, there is a mechanical wear or alignment problem that should be looked into. The same behavior can be applied to certain processes like grinding. The motion of the grinding fixture may be a position loop, but the actual process of grinding is a PID loop around a current setpoint of the motor driving the grinding wheel.
On the discovery side, we have to be a little less specific. Each new automation project leads to the creation of a unique piece of equipment that embodies a new arrangement of parts and programming. This inevitably leads to operating behaviors that could not have been predicted until the system is commissioned. This is the knowledge that we don’t have and cannot have until some run time is accumulated. Stuff that we know, that we don’t know, if you get my meaning.
And there is a corollary that is also important to consider; the number of possible fault conditions in a complex system increases with the number of components. So the number of fault conditions that could be considered is more or less infinite. Which means you do not want to be programming this project forever unless you think it will lead to job security. Which it won’t. So you have to come up with some definitions early in the project to attempt to define areas of concern and limitations that will be applied to the development of fault and diagnostic code.
The proof of the importance of the discovery phase is that many of the more experienced automation integrators include a commissioning phase either in their own shop or under very controlled circumstance on the client’s production floor in order to get as much as 90 days worth of operational experience with the new piece of automation. From this the integrator can bring the experience of running the actual machine into the programming, improving the code and making a more robust platform.
Real world experience is the key.