Always Report Changes to Machine Information fields
Similar to last week's Best Practice article, this week focuses on ensuring accurate information is fed into our algorithms and analysts so they can return the most accurate diagnostics. Rather than data from the hardware, this time let’s consider the machine information fields.
Near the top of the machine page, there is a section titled “Machine information”. It includes information such as the motor type, horsepower, nameplate RPM, the drive configuration, the number and types of bearings for each component, pictures, and more. Each field informs the algorithms and analysts of vital information. With that in mind, it could be considered preferable for a field to be blank as opposed to containing incorrect information.
Even if everyone involved in the machine setup process does their job correctly and the machine information is 100% complete and 100% accurate, the data could later become inaccurate following maintenance and repairs. Perhaps a motor didn’t have a variable frequency drive when it was built in the Augury platform, but one is later installed. If the motor continues to be supplied with 60 hz line frequency at all times, we likely wouldn’t question whether or not one had been installed. But the presence of a VFD could generate differences in the electrically related vibration signatures. Not knowing this change was made, our analyst could send an alert supposing there is an electrical fault developing in the motor.
When replacing a motor, as long as the frame, horsepower, and rpm are a match, the motor will likely fit physically and be sized correctly for the electrical supply circuit. However, there may be other differences which would yield the motor unsuitable for the application such as the rating of the windings. The new motor could also contain different bearings with different part numbers and different bearing defect frequencies. If the picture of the motor and motor nameplate in the Augury platform is not updated our customer success and analyst teams reviewing such information may make a mistake in their diagnostic results or consultation relying on it.
The last example I’ll share is possibly the most likely to cause errors. If changes are made to the motor rpm field in the machine information section it is vital that it is logged as an observation. Simply stating, “we noticed the motor rpm was listed as 1785 rpm but this is actually a 2 pole motor so we changed it to 3570 rpm to match the nameplate” is all that is necessary. This is so important. Our algorithms use the motor rpm in the machine information in conjunction with the magnetic data to calculate the actual motor rpm at any given time as well as the harmonic vibration trends related to it. In this situation, it’s likely the dominant vibration on the motor is and was occurring at 3570 cpm and the vibration at 1785 cpm was always quite low. Since the machine information incorrectly showed the motor rpm as 1785, the 1x velocity rms trend would have had a very low value and the 2x velocity rms trend would have had a higher value. Now that the information is corrected, our algorithms would recognize 3550 as the 1x and plot it onto the 1x velocity rms trend. Except now the value would be much higher than all the prior values on that trend, so to the algorithms it would look like a large, anomalous increase in vibration and they would likely trigger a detection. Without the context of the change our analysts may even mistake it for a true machine health change and send out an updated alert to the customer.
It’s not only Augury which can be fooled by this missing context or incorrect information. Many of you are analysts yourself, reviewing detections or data sets on your own or you rely on the accuracy of the data inside the platform for other purposes. Clearly, it is important that we all ensure we are logging these changes to machine information to get the context to the people who need it. Because an accurate diagnosis is a good diagnosis.