Read Part 1: Right Goals | Read Part 2: Right People and Right Leadership | Read Part 3: Right Goals and Right Follow-Up and Review
Part 4 of this series focuses on the importance of selecting the right tools for your goals and collecting the right data at the right time.
With any job, you need the right tools. In the case of vibration analysis and other condition monitoring (CM) technologies, it is important that the goals of the program are well understood (right goals) and the tools match the skill levels of the people who will use them (right people). Sadly, most people purchase the tools before understanding their goals and the technology. Many programs end up being limited or defined by the capabilities, or lack thereof, of the system that was purchased.
There are many different uses or applications for vibration analysis and just as many different tools on the market. So, the best place to start is by understanding your goals. Vibration analysis can be used for troubleshooting, acceptance testing, structural analysis or resonance testing, process monitoring, simple alarming, etc. Each of these applications requires tools with different capabilities.
A common goal of vibration analysis is to enable condition-based maintenance, so that is the goal for the purpose of this article, along with the features to look for in a tool. Condition monitoring is a process of taking the same data on the same machines day after day, month after month and year after year, and looking for changes. Imagine you are in the hospital and a nurse wakes you up to take your blood pressure. Now, imagine you are late for a doctor’s appointment. You burst into the waiting room and the nurse calls you back right away, sits you down and takes your blood pressure. Are the readings going to be the same? Does the difference mean there is something wrong with your heart? The answer to both questions is “no.”
One aspect of “right data” is repeatable measurements. The machine must be running at the same speed and load each time it is tested for trends to be meaningful. From a personnel or right people point of view, it means the person collecting the data is doing it the same way every time, which implies data collection is a standard procedure, which further implies it is a low skilled job. From a right tools point of view, it means the data collection unit doesn’t need a big screen and a million features, it simply needs to be able to take a preloaded standard test. A simple, robust data collector with fewer buttons and features might be more than adequate to meet the need and more suitable for a lower skilled employee.
Wireless sensors and systems are becoming more popular due to reduced sensor costs, better wireless communications, unlimited data storage and ease of installation. An important question to ask is: Is the sensor smart enough to know when to take a good reading? To save battery power, most wireless sensors “wake up” at a predetermined time, take a reading and then go back to sleep. If your machine is variable speed or load, what are the chances it will be in the right condition when the sensor happens to wake up?
Because they are battery powered, wireless sensors might be limited in the data they can collect. It takes more processing power and memory to take higher quality data. Transmitting larger amounts of data also lessens battery life. In order to keep prices down and maximize battery life, most wireless sensors on the market today are limited in the data they can collect, compared to what is routinely collected with portable systems.
Right data means that the data being collected is adequate to detect the defects you are trying to find. “Right understanding” refers to understanding how the asset fails and what indicators it gives when it enters a failure mode. These are the indictors you are trying to measure, therefore, right data and right understanding are directly linked. For example, a root mean square (RMS) overall reading is probably not an adequate indicator if your goal is condition-based maintenance. Likewise, a sensor that only measures up to 2,000 Hz is not adequate to detect a defect in a gearbox that generates vibration at a frequency of 7,000 Hz.
You need to know what you want to measure and you need to make sure you are measuring it accurately.
Condition monitoring is based on trending repeatable data and looking for changes. If you have good software, it should be able to detect these changes for you. When people are shopping for a system, they tend to focus on the data collectors, even though most of the full featured data collectors on the market can easily take the standard tests required for condition monitoring. It is more important to focus on the software and its alarm or diagnostic capabilities. Consider how good the software is at turning data into an alarm, an alarm into a diagnosis and a diagnosis into a report with actionable recommendations.
A benefit of wireless sensors is they can test the machine more frequently, perhaps every hour instead of once a month. For example, if you have 1,000 machines with an average of six sensors on each machine, each collecting five different measurements once per hour, that’s 30,000 unique graphs to analyze each hour. Who is going to analyze all this data? If, as previously noted, you are not even certain that all of the data is good data, then you are really in trouble! Assuming your system is intelligent and collects good repeatable data (which is NOT the case for most of the wireless sensors on the market today), you will still need very good software with intelligent alarms or diagnostic features to let you know which machines have problems.
Most vibration analysts today do not have alarms set on most of the equipment in their database because most of the main vibration software programs have archaic alarm features that do not work so well. Too many false positives cause users to ignore the alarms and too many false negatives (machines that fail without triggering alarms) cause users to not trust the alarms. There is also a big difference between an alarm (this piece of data is in the “red”) and a diagnosis, such as “moderate free end motor bearing wear.” For wireless systems and the Industrial Internet of Things (IIoT) to be successful with vibration monitoring, data needs to be right data and improvements need to be made in automated diagnostics (i.e., right analysis and right reporting).
Here is something to try if you already have a system to see if you are using it correctly, or if you are buying a system, use it as the best approach. First, ask for a field engineer, not a salesperson, to demo the system for you. Set the individual up in a conference room with a grinder or desk fan on a table. Next, ask the field engineer to configure the grinder or fan in the software as if it was a real machine in the plant, taking all of the data types one would normally measure. Set up more than one test point and more than one measurement axis to make it more realistic.
Then, ask the field engineer to load a route (the machine test configuration defined in the software) into the data collector and test the machine. Based on this data, ask the field engineer to build alarms or baselines in the software, utilizing all of its alarm features on each data type. Next, put a piece of duct tape on the fan or add a screw or some gum to the grinder rotor to create an unbalance (be careful!). Test the machine again and upload the data to the software. Here is the key point: See if the software tells you the machine is out of balance or in alarm, but not by looking at the data manually, rather via an automated report. If it doesn’t, then look at the data manually to verify there was a change. It could be the fan was out of balance and the duct tape balanced it. If so, move the tape and try it again. The goal here is to see if the alarms or diagnostics work, not to see if you can manually view the difference in the graphs.
If the new data looks different, but the software does not say it is in alarm or out of balance, then tweak the alarm until it does. This is what you want to be able to do with the actual machines in your plant. When and if you get the software to say it is in alarm, add some more tape, test it again and see if the software says it is a higher severity level. When and if you get that to work, take the tape off and put a coin under one of the feet of the machine to simulate a different fault. Test it again and see if the software says it is in alarm. If not, tweak the alarm until it does. When you are happy with the results, return the machine to its original state and test it again. The software should say it is healthy. When you add duct tape again, it should say it’s out of balance, in alarm, etc.
Next, run the machine at a slightly different speed, if possible, to see how the software handles it, or tell the software the machine is running at a slightly different speed than it actually is. Even AC induction motors that are not on variable frequency drives (VFDs) can vary in speed by a few percent from test to test. This is a huge issue because most of the fault indicators are related (or not) to the motor shaft speed. Therefore, the software needs to know or be able to determine the motor speed if it is going to be able to give a correct diagnosis. A slight variation in running speed should not trigger an alarm, nor should it cause the alarms to not function correctly.
At each of these steps, write a report. How hard is it to turn the data or your analysis into a report? How easy is it to edit or add comments to the report? Is the last report available and visible when you are analyzing newer data? Can you easily add a note that says, “the machine has been repaired” and see it in the machine history? Can you easily see the history of what has happened, such as no fault, moderate unbalance, serious unbalance, foundation looseness, or no fault? Can you easily make this report available to someone else, preferably without printing reams of paper?
The bottom line is this: If it takes all day or if the field engineer cannot make the software come up with the right answer when testing a simple machine sitting on a table with known problems, then it isn’t going to work in your plant with real machines. Again, you already know what the problem is, so the point isn’t to manually analyze the data and come up with the fault. The point is to automate the process and fine-tune the alarms until you feel you can rely on them.
There are hundreds of different vibration monitoring systems on the market and even more sensors. All of the hype around the IIoT is attracting new companies into the wireless sensor market and big data companies are promising advanced analytics. When assessing which tools to use, it is important to understand your goals and the equipment you are monitoring. It is also important to understand the people who will be employing these tools, along with their level of education and training. Right tools facilitates and supports the 10 components of a successful program.
Right data is about being sure the tools are configured and utilized correctly in order to get high quality data that accurately measures the specific fault indicators you are looking for. There are a lot of technical details that come into play when determining if an instrument, like a data collector or sensor, is actually measuring what you want it to measure. These details are related to both the limitations of the equipment itself and to how it is configured and used. It is a good idea to get an unbiased opinion before making a big purchase, not just to rate the equipment, but to make sure the equipment is appropriate for the users and the application.
Why would someone pay $1,500 for a camera when there are other cameras available for $100? Because they are not the same. That said, the $100 camera might be perfect for what you need it for and the $1,500 camera will still take rotten photos if you don’t use it correctly.
Right tools and right data are only a part of the puzzle. In order to have a successful program, you need to have all 10 components in place: Right goals, right people, right leadership, right tools, right understanding, right data collection, right analysis, right reporting, right follow-up and review, and right processes and procedures.
