When I was using CSI equipment in the past I never took the time to look at Nspectr and AutoStat programs assuming (possibly unfounded) that:

1. Nspectr does just very basic analysis useful mainly to beginners

2. AutoStat does solid analysis based on rules of statistics but has little output value since it operates on invalid data from a pure statistical point of view.

I don't have the RBMware to play with now and would like to ask the panel about their experience in this regard. There is a price associated with these features. Is it worth of money?
I'll appreciate your help. David

This message has been edited. Last edited by: David_G,

David,

I havn't used inspector to any extent, but autostat is a very good tool if you have lots of identical (I really must stress identical) equipment. Variances in mass, speed or load will really throw it off.

Good Luck,

If you have every shred of information available, Nspectr is 'neat' in some regards in that it gives you a lot to think about. I like reading all the rules it uses to come up with its suggestions. I don't think it's just for beginners--if anything I'd say it's dangerous for beginners. Again, if you don't have enough (or the right) information, you get a lot of iffy answers.

I've never used AutoStat. Seems like too much work for what you get out of it. I've also never met a CSI employeee who likes it--other than the salesmen.

I haven't used Nspectr, but I have used Autostat.

Autostat will generate two different types of alarm; Trend alarms and Envelope alarms.

I've only used the Trend alarms function, and after many months of trying to group machines and points, and get sensible numbers, I gave up.

I now only use the warning level (which is calculated individually for each trend parameter, and does not require Autostat) as a trigger, and ignore the "alert" and "fault" levels.

I will be trying to establish envelope alarms, for which Autostat might be of some use.

And yes, they do cost more money (at least in Australia)

Ian

Nspectr can be of some value with minimum configuration. I tell our guys to check it if they have a change in data that they can't figure out. You can have the rules, facts, point diagnostics, reqest for more data of information, etc. It is a good tool to help you think of more things that can cause the same problem. It does have "significant impacting" a lot but it can give you another perspective. Kind of like having someone else look at the data and give you their opinion. I think Art Crawford wrote most of the rule base so I know a lot of thought went into it.
Autostat is a very cumbersome program. About the only thing I use it for regurlarly is to recalculate trend data. Over time I have changed some trend parameters in the database or added a new trend parameter. It will go through all historical data and calculate the trend from the first data. The only trend parameter I know of that it can't recalculate is HFD.

Vendor Warning

I just thought this might be of interest from some marketing research I've seen. From what I've heard, only about 5% of CSI users use Nspectr. Over 90% of DLI's users use our automated diagnostic system. It's also been fairly well established what the main complaints are, but it's not my place to post that in a public forum (the users can do that)

http://www.dliengineering.com

One thing I have noticed with Nspectr is that I often got the message(past tense because I've said I don't trust it, so I don't use it)"Incorrect RPM Values.Validate Diagnosis?" The explanation is that the RPM values are not consistent from point to point. After some experimentation, Using a belt-driven blower for an example,I got the error message to go away by calculating the speed using the sheave ratio that I put in the wizard and using this calculated speed to replace the values for all of the fan points. This was not the correct speed as measured with a tach, so even though I've satisfied Nspectr's doubts, it leaves me with some doubts of my own.

Nspectr is particularly useless for this reason when taking readings on continuously variable speed equipment, such as RTO fans.

I also get another error message if I have to wait a long time between measurement points, such as when I am surveying the droplifters as I discussed in another thread.

As far as I'm concerned, this is just a wasted icon on my screen.

Richard, I did a few tests trying to get that message here as well (since I never saw it before). I plotdata, you can set a mechanism to focus a spectrum and estimate a speed from each new spectrum. You either turn that off, or ask for a peak inside a small and gradually wider percent from the nominal speed that you gave from start. Now, if the spectrum has a readable peak from 1x, then plotdata gives the right speed. If the resolution is low and the peak is flimsy due to other sources, the speed choosen can be way off. - and the warning pops up. I suggest you get at the warnings and check the reasons and adjust until warning is off.

The trick to handle variable speed machines, paper machines, RTOs, gas turbines or jet engine test stands is to use orders as frequency scale instead of Hz or CPM. The diagnostics works just fine for a reasonable speed span. One example: In paper machines, I use the paper weight as a "Class" of the machine and list them as product related machines (but it is the same machine all the time. Diagnostics is made per "Class".) For instance, I have one PM12-42 meaning the PM123 when running 1344 meter/minute making 42 gram/sqmeter paper. From "natural" process variations, I may find it at 1340 to 1362 during a full 870 point route, but with all important info in orders, I avoid the problems and the recommendation from Nspectr is valid.
Nspectr is just as good as any software - Sh-t yields sh-t out. I use it as a fantastic filter and I find the effort to adjust facts has two large benefits: You get to know the machine and your team members in operation, vendors and workshop when getting the facts, and you get to know the machine to the last roll and motor part as the inside of your pocket without getting bleeding eyes looking at all spectra. Plus the big benfit, Nspectr runs it all objectively, disregarding the day of the week. I can focus on checking what it finds and real world corrective actions where the money for my company is.

I am sure the reason just a few users are using it and many show an unhappy feeling is plain nonsystematic planning. Many of the 90 percent DLI users also get odd recommendatiuons, but tend to sigh and just neglect the advice.

You as user of any soft make should focus what can bring long term less repeated tedious work for yourselves. Invest the time to use the tool since you have it there just waiting for you. Put it to work on small obvious cases first so you learn handling it. Place all your concerns here and let us all chew it. That will surely get many more using it, when potential users can see and learn how good it is in daily work. Regards Arne

DavidG--

I implemented Autostat this spring (obviously not that long ago...) and am relatively pleased w/the results I'm getting. Note--Autostat doesn't do either analysis or diagnostics. What it does/can do is generate new AP sets (using band alarms) and/or statistically averaged alarm envelopes based on as much (or as little) historical data as you want. It is cumbersome to implement and I did make some mistakes (messed up my overall trend values in several databases), but I feel that, overall it's been worth it.

I'm in the typical situation of an "in-house" vibe head--lots of equipment to monitor, but little time to do adequate analysis. The statistical envelopes I generated w/Autostat have enabled me (in particularly busy months where I'm fighting for time) to print out a Spectral Analysis Scan Report on some of my routes and then look at / analyze only the points/machines w/the highest alarms.

In comparing w/results from prior surveys on well established routes (where I've looked through all the data for a long time) it's been pretty accurate flagging "problems" (i.e. points where number of "penetrations" throught the spectral envelope exceed certain #'s and amplitudes).

I do not plan on substituting this "method" for regular viewing and analysis of regular route data every month; but, in a "short" month for me, this has helped trim time a lot by avoiding looking at a lot of data that historically typical for that machine (or group of machines).

Again, set-up takes a chunk of time, and I still look pretty closely at EVERYTHING on very critical/complex equipment, but I feel the investment was worth it for me. However, I can see that in different shoes (e.g. a consultant) I might think twice about either spending the time it takes to implement...or not thoroughly looking at all my data all the time!

Hope this helps!

Tony

I can make a statement about DLI - a DLI rep came by and showed me their stuff..... auto diagnosis, auto report and into you E-mail for scheduling; very impressive.

What impressed me was: vibration data I anlayzed while the DLI analyzed - 2 min after I came up with my diagnostics - it rang through and true on the money or if I was wrong, so was it. But it was on!! wink, wink.