So many machines. So little time. What’s the best approach?
Vibration analysts are often faced with scores—perhaps hundreds—of machines, many of which exhibit vibration frequencies that are very hard (if not impossible) to identify. Some machines can absorb countless hours of an analyst’s time before he/she can confidently identify all the discernible peaks in their FFT signatures. The danger is that an analyst could waste precious analyzing time trying to identify the source of a vibration that will never cause a problem, and possibly miss the rise of another, more lethal vibration. What does an efficient analyst do?
Approach your machines with a plan
An efficient analyst will first identify the frequencies that are most likely to originate from defects that have already been identified as typical failure modes for the machine of interest.
IMPORTANT HINT: Gearmesh and its sidebands won’t be an indication of a failure mode for most electric motors.
Although optional, next rank the failure modes according to speed of degradation (i.e., the ones that will cause most rapid failure). This will not only help prioritize the work, but should be the basis for most data-collection schedules. If you’re not monitoring often enough to catch the most likely failure modes in time for a scheduled repair, you’re playing analyst roulette—and sooner or later you will encounter the chamber with the bullet in it.
ANOTHER IMPORTANT HINT: Only when the fault frequencies that should be monitored are identified can an analyst determine the proper monitoring setups to use. Adequate resolution and range must be provided to capture the frequencies of interest!
After identifying the frequencies that are expected to be involved in machine degradation and failure, the analyst should set alarm bands around them. Historical data should be mined to determine comfortable alarm amplitude levels that will alert the analyst to a “potential” failure in time to prevent it from becoming an “actual” failure. As new data comes in, the efficient analyst uses it to “tweak” the alarm levels. The goal is for alarm levels to be as relaxed as possible (no false positives), while still protecting the machine users from unplanned failure.
(Click to enlarge.)
But what if there’s no historical data to begin with? In this case, alarm-band amplitudes—and in some cases, the band ranges themselves—should be sought from more mature programs. Many analysts in the U.S. begin their programs using alarm bands and amplitudes suggested by Technical Associates of Charlotte and its “Proven Method.” Another possible starting point could be the standards that many large corporations have developed for their equipment. An online search may yield these types of standards for both acceptance and operations. Whatever the source of a program’s “starting point,” historical vibration data is the best way to optimize alarms. This process of optimization may never be completely finished, but comfortable levels can be reached relatively early in a program’s life.
As an efficient analyst, you want to begin by building enough “cushion” into your alarm levels to protect your users. With data coming in, you can tighten levels as the accumulated historical data warrants. When you feel protected by your alarms, run a simple alarm status report (like that in the figure above) on the entire route. If no alarm levels are exceeded, there’s no need to spend analysis time on machines in the route. If alarm levels are exceeded, however, you need only to analyze the machines in alarm condition.
Keep these points in mind: The efficient vibration analyst DOES NOT monitor equipment more often than necessary, nor waste precious time analyzing good machines or harmless peaks in FFT signatures or time waveforms. The efficient vibration analyst DOES approach his/her machines in a well thought-out, planned manner that considers the specific failure modes of whatever equipment is to be evaluated. MT
Mike Fitch is a Vibration Application Engineer for LUDECA. Telephone: (305) 591-8935; email: firstname.lastname@example.org.