Looking for some tips from you guys on how to improve the Efficiency of our analysis.

Any suggestions would be helpful

Develop meaningful alarms and let the software do much of the work. Something I've always wished I had time to do.

Good/Cheap/Fast - Please pick two.

I'm not sure on what you mean by efficieny in this case. Can you clarify?

If you are trying to improve your speed in performing an analysis of the data? Waylon's suggestion of developing/improving your alarms is good. This allows you to focus on the machines that are having problems.

Are you trying to improve the quality of your analysis and recommendations?

More questions than answers, but hopefully we can focus the discussion on what you're truly interested in.

Steve

Well Steve, it seems you've put your finger right on it. Cheap/Good/Fast

Our program is set for considerable expansion this year and beyond, and I am anticiapting needing to get through data faster.

Waylons answer is the obvious one, but his comment is an all too relevant one. We have been considering as a group to designate a block of time for alarm development.

Of course as the person responsible for the equipment, I don't want to give away anything in the quality of analysis, but it seems you really can't have both...

I guess a better way to frame the question is this:
When you finish a cycle of analysis and send out reports, what gives you confidence that you haven't missed something you should have caught?

I've spoken to several people who have their systems set up on overall/magnitude alarms only. If you don't already do it, then ensure you set up meaningful spectral alarms as well, then you will have the confidence that you haven't missed anything. It isn't unusual for a single peak to grow without affecting the overall level. I recently added a retrospective spectral alarm to a pump where I'd already successfully called a bad bearing. If I'd had the spectral alarm in place at the time, I would have detected the bearing four months earlier.

It doesn't necessarily make your analysis quicker, because you find yourself looking at extra data, but it certainly gives you extra confidence. At the end of the day the alarms are only there to let you know that something has changed.

I did hear of one guy who was instructed to reduce his time/costs at a certain plant. He chose to use an ultrasonic "gun" on every bearing and only collect data from the suspect ones. I can see what he's trying to achieve, and if all they want is to catch dodgy bearings it may work, but he's going to miss all the other problems (imbalance, misalignment, etc).

Use the high frequency tool in your analyzer, weather it is enveloping or peakvue or whatever. Most people don't use it, and they are missing out....

Waylon is correct; just do it. I have a fair number setup w/4 levels. When it hits RED trouble is around the corner. But your data acquisition techs and system integrity all have to maintain the highest of standards or you get garbage in.

As much as possible, without sacrificing "cross-training" let the same people run the same routes. If you look at a piece of equipment on a regular basis, you really do develop a feel for the equipment. If you feel or hear something out of the ordinary it will get your attention immediately, often before you collect any data.

If your software allows it, develop a good set of note codes that are standardized across all your databases. If possible, when you sit down to do analysis, print the note codes from the most recent survey.

Set all machines up as "variable speed" and input the actual speed in the field. This will save you time doing analysis as you don't have to 'locate' the 1x peak when doing analysis. And you will find many load-related problems that won't show up - or that are confusing - in the vibration data.

As Steve mentioned, we use enveloping combined with velocity and acceleration. We tried with bend alarms but end up with a lot of false alarms, so we use more historical trends. It is important that analyst is familiar with machines and have direct access to history of machines through discussion with operators, maintenance guys and CMMS system. Also recently we start using SKF's @ptitude, "decision support system" so I don't have to look data, just challenge alarms. Right now we are in stage of connecting process data, vibration and oil analysis data through @ptitude.

I can say we have established effective diagnostic system; good reporting system, but this is not enough.

Our problem is "after diagnostics".

Operation is driven force, maintenance crew is so limited, and management not educated to understand priorities and support condition-based maintenance. Managing emergency WO, and big backlogs is till huge challenge.
Problem with operator driven production is that "young process engineers" don't get even basic knowledge of maintenance through their education, but are managing maintenance.
Good luck.
Dragan

Thanks guys, I think I'll be pushing to invest some considerable time into meaningful alarm development, we haven't done any enveloping, we just have band and overall.

HI Martin.
I have been working in vibration analysis since the beginning of the program, 5 years ago and soon I realize that without any more manpower the Pdm was heading in a dead end alley. I survey the whole plan ± 300 equipments. We quickly had to improve collect, analysis and reporting. First, after 3 years of data, we remove all non-useful collection points and we perfected Fmax, definition, alarm and route schedule. It still wasn't enough so we developed interconnectivity of Pdm software with CMMS to reduce reporting time. Finally, we included lub. People to Pdm by providing ultrasound with lub. route on simple slow speed machine as conveyor pulley. We have been able to keep high standard Pdm without adding personnel. Good computerized equipment file readily available to the analyst help a lot as well.

Good luck, Marcel