Sign up Calendar Latest Topics Donate
 
 
 


Reply
  Author   Comment  
electricpete

Sr. Member
Registered:
Posts: 647
Reply with quote  #1 

We are coming from E-monitor where we have 20+ years history on thousands of machines, and we have developed a unique alert and alarm value (based on velocity overal) for every position on every machine.

Ideally we'd like to implement something very similar to our existing alert/alarm setpoints in AMS.

However, it seems AMS is not well suited to that. We'd need a separate alarm set for each point. And each database only allows 512 alarm sets. We'd need a lot of databases.

It seems that "Dual Upper Delta" style alarm (which gives alert and alarm at specified amount above baseline) might give something close IF we could manually input the baseline value for each point.  Is this something that can be done?

electricpete

Sr. Member
Registered:
Posts: 647
Reply with quote  #2 

I think I found an answer to my specific question of how to adjust baseline values

  • Tools / Stored Data Management / Data Statistics Options …
  • select the machine and position of interest…
  • manual edit (allows to change baseline).

 

But we're still struggling with alarm strategy that would replicate the approach we had in Emonitor though. Note a dual upper delta provides a certain ips above baseline… we'd rather specify a percent above baseline.

MachDiag

Avatar / Picture

Sr. Member / Supporter
Registered:
Posts: 130
Reply with quote  #3 

Quote:
Originally Posted by electricpete
... we'd rather specify a percent above baseline.

You probably want to use a "B" alarm,  Baseline "Br" and "Bs".   Sole use of B alarm, without D and C alarms is usually only done on equipment that has been running somewhat reliably for a period of time. 

 

      

 

   

RustyCas

Avatar / Picture

Admin
Registered:
Posts: 1,809
Reply with quote  #4 
So you have say, 2000 machines, 10 points per machine, 20,000 alert levels, and 20,000 alarm levels. If you have static alert/alarm levels for each point, I'm guessing they all run relatively smoothly, and seldom get replaced or repaired. I doubt you have anything running over 0.3 in/sec.

How is it possible to have 20,000 discrete alert values between 0.02 and 0.3 in/sec? Is it possible to "dump" your alert/alarm values to a file? You could then import to a spreadsheet, sort by alarm level, and you'd be able to group them into 30 groups (0.3/0.01).

Make sense?

__________________
"The trend is your friend"
James.

Sr. Member
Registered:
Posts: 113
Reply with quote  #5 
Hi Rusty,

Have you had a look at the new reporting tab as you can do filtering in that tab then export to excel
MachDiag

Avatar / Picture

Sr. Member / Supporter
Registered:
Posts: 130
Reply with quote  #6 

Quote:
Originally Posted by RustyCas
So you have say, 2000 machines, 10 points per machine, 20,000 alert levels, and 20,000 alarm levels. If you have static alert/alarm levels for each point, I'm guessing they all run relatively smoothly, and seldom get replaced or repaired. I doubt you have anything running over 0.3 in/sec. How is it possible to have 20,000 discrete alert values between 0.02 and 0.3 in/sec? Is it possible to "dump" your alert/alarm values to a file? You could then import to a spreadsheet, sort by alarm level, and you'd be able to group them into 30 groups (0.3/0.01). Make sense?

Here's something I leaned from someone back in the earlier CSI days.  I haven't done this since MasterTrend days, so I could be a little rusty (was the a pun? sorry Rusty). 

If you (or your customer) have a good handle on the facility's reliability program and the equipment is well maintained and running smoothly (or, normally we might say)... consider turning off the static "C" and "D" alarms and just use statistical alarming (the "B" alarm).  Before doing so, there is a relatively simple process to do beforehand that allows it to be effective.  Go into the "Stored Data Management" tab, then the "Data Statistics Options" tab, select a Station, Machine or Measurement Point, then click "Set Baseline Equal to Average" over on the right side.   You really should just do this on a few machines first, so pick Machine.  I think I liked how this was done in MasterTrend, over the Machinery Health Manager software.    

Doing the above step resets the baseline for each parameter band to the average of all the measurement data taken over time.  This alarming option shouldn't be done on machines that don't have enough historical data (say at least five or six sets of data over time), or machines that don't have a clean bill of health.  Try doing this first on just a few machines and see what you think.  Try and pick some machines that always tend to show a long listing in your exception reporting, but after reviewing the data you know (and maybe remember) there's nothing really wrong, and it's acceptable in the end.  

This alarming technique creates exception reports based on an actual change in vibration, reducing the number of machines and measurement points pulled into your exception reporting.  Maybe it's a machine with a gearbox and the load varies each time you take data, or an old HVAC unit with a crappy (flexible) pivoting motor base hanging off the side of the cabinet that always trips the "C" or "D" alarms with of v-belt vibration, or a blower fan with split race bearings.  Whatever the situation might be, if in the end your analysis proves the machine is not in need of any corrective maintenance, statistical alarming techniques might be right for you.             

Now, here's the though part...  Do you go and believe what I just said and run out and implement this on your whole reliability program?  The answer is an obvious NO!  But, maybe just dabble in it a little and create a mini database with a few existing machines and see what you think over time, just remember to turn off the "C" and "D" alarms and consider tightening up your existing "B" alarms a little.  Take data using two routes, one with your normal alarming and one with the statistical alarming.  Run your exception reports for both and see what you think.    

 

    

electricpete

Sr. Member
Registered:
Posts: 647
Reply with quote  #7 
Quote:
So you have say, 2000 machines, 10 points per machine, 20,000 alert levels, and 20,000 alarm levels. If you have static alert/alarm levels for each point, I'm guessing they all run relatively smoothly, and seldom get replaced or repaired. I doubt you have anything running over 0.3 in/sec.

How is it possible to have 20,000 discrete alert values between 0.02 and 0.3 in/sec? Is it possible to "dump" your alert/alarm values to a file? You could then import to a spreadsheet, sort by alarm level, and you'd be able to group them into 30 groups (0.3/0.01).

Good point. Yes, we could do something like that. 
We could have alarm sets with first-level alert at 0.01, 0.02, 0.03, 0.04....0.29, 0.30.
It does not give ability to independently adjust the second-level alarm, which is something we have now.  But maybe we don't need it. Setting the second level alarm at 150% of first-level alert would be good enough. That might be the answer I was looking for... just couldn't break free of my old way of thinking about it.



electricpete

Sr. Member
Registered:
Posts: 647
Reply with quote  #8 

Quote:
Here's something I leaned from someone back in the earlier CSI days.  I haven't done this since MasterTrend days, so I could be a little rusty (was the a pun? sorry Rusty). 

If you (or your customer) have a good handle on the facility's reliability program and the equipment is well maintained and running smoothly (or, normally we might say)... consider turning off the static "C" and "D" alarms and just use statistical alarming (the "B" alarm).  Before doing so, there is a relatively simple process to do beforehand that allows it to be effective.  Go into the "Stored Data Management" tab, then the "Data Statistics Options" tab, select a Station, Machine or Measurement Point, then click "Set Baseline Equal to Average" over on the right side.   You really should just do this on a few machines first, so pick Machine.  I think I liked how this was done in MasterTrend, over the Machinery Health Manager software.    

Doing the above step resets the baseline for each parameter band to the average of all the measurement data taken over time.  This alarming option shouldn't be done on machines that don't have enough historical data (say at least five or six sets of data over time), or machines that don't have a clean bill of health.  Try doing this first on just a few machines and see what you think.  Try and pick some machines that always tend to show a long listing in your exception reporting, but after reviewing the data you know (and maybe remember) there's nothing really wrong, and it's acceptable in the end.  

This alarming technique creates exception reports based on an actual change in vibration, reducing the number of machines and measurement points pulled into your exception reporting.  Maybe it's a machine with a gearbox and the load varies each time you take data, or an old HVAC unit with a crappy (flexible) pivoting motor base hanging off the side of the cabinet that always trips the "C" or "D" alarms with of v-belt vibration, or a blower fan with split race bearings.  Whatever the situation might be, if in the end your analysis proves the machine is not in need of any corrective maintenance, statistical alarming techniques might be right for you.             

Now, here's the though part...  Do you go and believe what I just said and run out and implement this on your whole reliability program?  The answer is an obvious NO!  But, maybe just dabble in it a little and create a mini database with a few existing machines and see what you think over time, just remember to turn off the "C" and "D" alarms and consider tightening up your existing "B" alarms a little.  Take data using two routes, one with your normal alarming and one with the statistical alarming.  Run your exception reports for both and see what you think.    


Thanks for that.  It seems there will be multiple ways to skin this cat.   This steers me a little bit towards using a baseline approach with multiple of baseline.  Then we can update the baseline over time as you say.

electricpete

Sr. Member
Registered:
Posts: 647
Reply with quote  #9 

Quote:
"Good point. Yes, we could do something like that. 
We could have alarm sets with first-level alert at 0.01, 0.02, 0.03, 0.04....0.29, 0.30.
It does not give ability to independently adjust the second-level alarm, which is something we have now.  But maybe we don't need it. Setting the second level alarm at 150% of first-level alert would be good enough. That might be the answer I was looking for... just couldn't break free of my old way of thinking about it."

I've been thinking some more and even if we set all 2nd level alarms at 150% of alert, we still have a problem in the future if we want to add more alarming features (non-sync, subsync etc).  We have 30 alarms set up to cover 0.01 - 0.30" warning, but if we customize one of these alerts, then it applies to all associated machines.  So we have not just one set of 30, but maybe one set of 30 for 3600rpm machines, one set for 1800rpm machines etc.  I don't really know where we're going in the future but I think it'll make it cumbersome to add machine specific alarm customizations.

So I'm going back to an approach where we can use one alarm set to capture all our machines (regardless of warning level) and then it will be easier to customize in the future without creating huge number of alarm sets.

 

Here's what I'm thinking now:

1 - Manually set baseline value for each machine to our target alert value (the alert value from our old database)

2 - Create a dual upper delta alarm set  as follows:

  • set C ~ 0 (use 0.001 since it won't except 0). This will create the Upper Alert at the desired value (whatever we put into baseline, which was our old alert).
  • Set the alarm baseline ratio to 1.5.  This will create a Baseline ratio (Br)  Warning at 1.5 times the baseline…where we'd like our Alarm to be.
  • Parameter D is not needed.  Actually it's a little problematic. I have to set it higher than C. I can set it really like like 1.0 with intention that it's high enough not to distract anyone, but it screws up the plot. Instead I'll probably set it to 0.0011 in which case the alert and fault levels show on top of each other...I guess I can live with that.

Any comments with this approach?

I know I'm not really using the database the way it's supposed to be because baseline is supposed to be something like an average, not an alert value. That worries me I might get into trouble somehow. For one thing I'm worried that my manually-entered baselines (time intensive to transfer from the other database) might get overwritten somehow. 

Also I'm a little unsure of how baseline max deviations Bs works. I don't want it to interfere with my Br alarm. It seems the averages and deviations for Bs get entered or updated in the database automatically.

electricpete

Sr. Member
Registered:
Posts: 647
Reply with quote  #10 
Quote:
Also I'm a little unsure of how baseline max deviations Bs works. I don't want it to interfere with my Br alarm. It seems the averages and deviations for Bs get entered or updated in the database automatically.

Actually I see now that AMS creates an early warning alarm which is the LOWER of either (Baseline Ratio * Baseline) or (Average + MaximumDeviations*StandardDeviation).  So I would need to figure out a way to keep these numbers "Average + MaximumDeviations*StandardDeviation" from getting in the way....setting "Maximum Deviations" as high as the program will let me (25) seems to work pretty well.
James.

Sr. Member
Registered:
Posts: 113
Reply with quote  #11 
Hi Pete

Alert Calculation Process:

1. The software will compare the two numbers below and then use the more restrictive as the
early warning level.
• Baseline Value x Baseline Ratio
• Average + (Maximum Deviation ‘Bs’ x Standard Deviation)

2. If the above calculation is less than 0.5% of the Fault Level, the warning value will be
calculated as follows.
• Fault Alarm Value x Percentage of Fault limit for Baseline override
electricpete

Sr. Member
Registered:
Posts: 647
Reply with quote  #12 
Thanks James, that's pretty consise. You're right that baseline override would mess with my approach (just like the statistical calculation).  I only want the multiplier times baseline. Therefore I have disabled the baseline override (Tools / Database Setup / Global)
Previous Topic | Next Topic
Print
Reply

Quick Navigation:

Easily create a Forum Website with Website Toolbox.