Opinions on Nspectr

I have to admit that I have a fairly negative attitude towards Nspectr or any other software program that looks at data and provides an analysis. Mad Since I've never used it, I suppose it's not fair of me to make a judgement. Confused My main objection is that these programs look at the data and apply the typical vibration rules that you find in all the books. How many of us can say that every problem we've encountered looks and acts like it's supposed to? Roll Eyes Another example of "smart technology" is the balancing program I have. Mad I went out to do a balance job last week, and after going through the process of the initial run, and adding trial weights, the program tells me there's a problem and it can't make the calculations. It did't tell me what the problem was, just that there is one. Well, try telling your customer that! Thanks to some good old human thinking and applying some non-typical rules, I got the vibration down from 40+ mils to 6 mils dispite the resonant condition. Big Grin(I know, I know, that's still not good enough! I'm working on it. Razzer) My opinion is that you can't replace a properly trained analyst with a computer! What's your opinion?
Original Post
Basically the same! The CSI requires a qualified analyst to do the analysis and call the shot IMHO. I'm looking at a 13 y/o program in a plant now run from CSI and it is 13 years of nothing or worse than that. I'm now re-vamping it.

Aug 7 this year will make 38 for me. I've used HP, Ono Sokki, Nicholet, Bently, et... and have software of Entek for SKF and the whole bunch plus my own software.

Recently I was in GA for a client doing PdM surveys using RTA's and on-site analysis and doing the trending thing. Finished the formal report, listed and labeled problems and provided a maintenance work scope and time line for scheduling. I had just gotten a ME-42 (machine evaluator w/artificial intelligence based on ISO 10816-1). I didn't use the ME-42 for this but took it into the field after the formal report and ran it through its paces. The 'evaluation mode' found all the faults and listed them in plain english spot on to my surprise and back to the computer and downloaded in seconds. I bought the thing and think every field engineer that has anything to do with rotating equipment needs one. If you own a calculator you can justify one of these. I'm hoping it gets expanded and built upon for PdM.

But yes; I'm kinda with you, I don't have confidence in the CSI at all or not at this point.
Rusty, sadly enough, no. I did not help design the firmware for Rotalign. If I was smart enough to do something like that, I wouldn't have to sell my 4-wheelers Frowner in order to afford buying a boat.

Sam, it's good to know that there's some software out there that does work for accurately diagnosing machine problems. In time, perhaps I'll learn to trust it. One more paradigm to overcome. Sam, you're fortunate to have the opportunity to work with various analysis equipment. I've used CSI excusively since I started 10 years ago. For the most part, I like CSI, but it took quite a while to get comfortable with it. There's still a lot about RBMware I need to learn.

I don't use nspector either for the very same reasons. I just don't trust either the programming or my ability to input all the data exactly as required to get accurate answers.


I really like the way the Rex Omega spacer couplings look when the bolts come out of one half of one side of the coupling. The stamped steel piece that is molded into the orange element is quite a sight when spinning at 1790 rpm (viewed from a distance).


Maybe your subtle humor is too subtle for some. I get it. Smiler Frowner Big Grin Wink
Years ago I tried usinf Nspectr because I had 64 gearboxes that were identical. I set it up and it kept saying they all had bearing problems. I extracted these machines out of my database and sent them to CSI to configure Nspectr, and low and behold they got the same results. So I was not to impressed with it after this experience, and have not tried it since.
Yes I have used Nspctr for many years and it do have a tendency to over react and give locked coupling as an answer. I have once had a case where it did find a coupling in a place where I had no idea and no drawing to indicate there was a coupling so I did think it was dreaming but it was written in the report and customer didn´t look for it either until the machine quirked up and stopped. Sure there was indications of it but I am only a poor human.
Thing with software is that it looks at ALL data, same way year out and in, all days of the week, humans don´t do that.
And enter true data otherwise you get shit in and shit out rule activated.
So as long as you feed the silicon mind with all the info you have to your best knowledge and use it as screening tool for large amount of data to indicate what machines humans should concentrate on, it is doing it´s thing, indicating what to concentrate on as "decision support tool" not a decision maker as you try to use it. Silicon can just as in implants only help to enhance and concentrate your view to what it think is essential, pun intended, at least so far.
I used also SKF, DLI and lately the Russian Dream out of S:t Petersburg, I like the latest best so far it makes sure I don´t miss anything. It has happened we both missed in special cases but then my ears also did that so the "Expert" is only silicon and I am only human, together we make a hell of a team and he is more persistant than I ever be. Also I like the one I made myself but that should be obvious :-)Off the soapbox again. Olov
Hi Don,

I have had similar experiences with nspectr, it takes a lot of time to set up and produces questionable results.

It has been my experience that inexperienced analysts that rely on it will make a lot of bad calls, and experienced analysts don't trust it.
I've never really used Nspecter... just played with it some, but it seemed to say that "everything" was a possibility. When I was with the power company, I thought that everything was induction motors, bolted and grouted in place, and ran at one speed (except for boiler feed pumps). When I went out on my own, I realized that I'd only seen maybe 10% (5%?) of the equipment types out there. There are just so many different types of equipment, with every imagineable mounting configuration..... (I really had no idea what I was getting into...)

My regular customers include: steel mills, peanut butter plant, snack bag plant, lime plant, hardwood flooring mill, rubber roofing membrane plant, trace metal recovery plant, convention center, and a wire mill.... and at one time or other I've done plants that make fish food, aluminum beverage cans, aluminum foil, MDF, and the list goes on.

I don't have a single plant that makes power, petrochemicals, plastics, or paper.... things we usually think of when we think PdM. My point is, there is a HUGE variety of equipment out there, and unless you are in a narrowly defined field (plant), there is no way an expert system is going to be efficient at diagnosing problems on such a diverse population of equipment.

Besides, as most "seasoned" analysts here will tell you, when you walk away from the machine, you're usually about 80% done with the analysis anyway.

Case in point. Up on a rooftop today, and I could feel the vibration from a big baghouse fan as soon as I hit the deck. Nearly 3 in/sec at 1x.... was shaking the world. Obviously (very obviously) imbalance... Nspectre and everyone on this board would know that right away. A quick visual revealed everything was tight, no cracked welds.... but the rubber expansion joint on the inlet of the fan was missing. Poked my little pocket strobe through the opening, tuned it, and sure enough... there is was, wrapped 1/2 way around the inside of the wheel. Snapped a few pics with my Canon A400 and had a picture of it to take down and show the maintenance super.

There are some things that software is never going to be able to do.... namely, tell you how to fix something.

(Danny, if Ludeca ever gets rid of that stupid smiley face, I'll think about buying a Rotalign. The only thing that could be worse was if 'Barney' popped up when you're in spec... or maybe a flower... a kitten... a fluffy, white cloud, perhaps?)
My favorite subject.

I agree with most of the comments too. However, there are somethings that I have learned to consider as I have used P4Pro, Checkmate, tried to use nspector, and have been involved in building 3 automated diagnostic software systems using specialized neural nets and boolean rules and some other methods. Currently working on 2 more systems as well.

Most current rules or inference engine systems do not work well. Reason being the rules are are of the canned nature and the sofware developer did not have the foresight to allow the end user to develop his own. Sure some things are common and could be relied on somewhat, but we all know that it is just not that simple. My old friend John Mitchell and I have belabored the issue. John say's the rules should be locked and not be able to be edited. I say that is the exact reason why these systems have not been successful. How many have complained just like here that they made wrong calls.

If one took the time to develop his own rules for a fault and it missed who does he blame?

It takes discipline and many hours to sit down and calculate the specific frequency locations for all that may be present. Then what are valid alarm levels? Some frequencies may overlap and require other data input to differentiate the faults. What about data resolution, if too course then you cannot discriminate discrete frequencies. What is the manufacturer really doing with the data processing? You know they all claim proprietary data rights. Do the applications utilize phase data and other possible operation related data?

Looks bleak, not really. It's in the methodology.

How well do you think one would work if you sat down and determined the data resolution required to capture discrete data related to all faults while considering all other faults. Set your data acquisition resolution and data types to the appropriate resolution and type. Then condition indicators are developed (narrow bands, demod spectrum with band extraction applied, cepstrum, crest factors, phase, motor current, flows, pressures, etc.) These values are then available to the user to develop his own rules and his own desired response to these faults. This data is also processed in parallel via special neural nets (same one the Navy acutally uses for automated sonar diagnostics). The neural net overcomes the pitfalls of the rules and vice versa. Voting logic could be used in a second tier neural net to compare both sub-sytem outputs prior to notification of a fault which is e-mailed to responsible individuals who view the actual data and make the final decision. The system may process data in near real time or from static databases. The rules can be modified as time goes on to refine them. The neural nets are trained as new data is collected that may modify the diagnostic response. If online systems are used then you could detect transients if data collection rates were adequate.

What you wind up with is a high speed intelligent data filter that is an enourmous tool for the analyst. They can process vast amounts of data unbelievably fast. The Neural nets can detect hidden patterns, overlaping faults are shown with a degree of probability (bayesian), will detect unknown faults and identify them as such.

Some of the major companies out there have developed similar systems that process up to 1500 data points every couple of seconds. (can't tell you who non-disclosure and confidentialty agreements) Their quality requirements were no missed faults and only one false alarm per machine week. This come out to one false alarm in 7.56 million opportunities. They met the criteria and deployed the system in 2000.

The system with the neural nets was developed in 1998 and could pull in 30-40 MB of data per second and would do all the processing above to the tune of 50 points per second. The data was analyzed manually and found that the outputs were accurate in the high 90's percentile.

This is not your Daddy's Oldmobile for darn sure, nor is it a tool for a novice.

The problem is the big boys back then had their heads in the sand. The old we didn't invent it so it can't work. Look at what they are starting to do now. They still don't understand how to do it. Also the data interface issue in gaining access to the data via a third party application. So far we have been able to gain access to Prism4, Vibrometers system, Entek Odyssey and several others.

I'll be glad to share what I can and I also have the only functional prototype of the Neural net based system. Now you know pretty much what I have been doing for the last 13 years of my life.

This technology will work but not in its present form! My $5.00 worth.

Interesting Spencer,
I have always been thinking of how you could effectively train those neurals. In humans we here say that regardless of background you have a 3 year apprentice time to do before you have trained your personal neurals enough, and they fortunately never finish training. So my problems is to see how you squeeze those basic 3 years training in to the silicon in a shorter time. Olov
Duncan is correct.

Because neural nets are learning systems which require time and data to train they are like an infant in that they are born with a certain amount of intelligence but know basically nothing until educated and trained. (By the way archived data works well in training NN's. I also developed an artificial data trainer.) I guess you could say it has a learning capacity. Like you sai it may take some time to train, but maybe not as much as you might think.

Rules based systems are knowledge systems which operate based on some rule or set of rules. The rules require one to program in known fault parameters. They are good at linear faults but are not well suited for detecting overlapping faults, hidden patterns or unrecognized faults.

This is why the both of them were utilized.

Sensor validation, data persistance and rolling averages may incorporated as well.

In the case of my company's expert system, what is required to be programmed in is the physical properties of the machine components, i. e. the physical parameters of a bearing's elements, the number of teeth in gearbox gears, the number of slots in an AC motor, etc. The expert system also weighs the effects of combination of faults on the safe operating life of the machine components.
Rusty Cas posted:
(Danny, if Ludeca ever gets rid of that stupid smiley face, I'll think about buying a Rotalign. The only thing that could be worse was if 'Barney' popped up when you're in spec... or maybe a flower... a kitten... a fluffy, white cloud, perhaps?)
Smiley face gone. Ludeca has "Easy Laser" Now


Add Reply

Likes (1)