I have a couple of machines that I built in RBMWizard that have some extra measurement points. I would like to deactivate these points as opposed to deleting them so that I can retain the data. I have removed them from the routes so that they are not loaded to the data collector, but the data still shows up in Plotdata and throws my dates off sometimes.

I don't see deactivation as an option in dbutly or Dbase and when I try to do it in RBMWizard, it tells me that I can't change that setting because i have already loaded it into the database.

Any ideas? I will probably just delete the points entirely but would prefer to retain the data if possible.

Danny,
What I do is create a new area in the database then create a machine with the same name as the one with the points I no longer want to use and then move those points to that machine. That way I keep any data I have collected until I'm sure I want to delete them.

Dennis,

Danny, I'm sure you may have already thought of this, but could you just create a new area in your database, then create a machine with the same equipment ID and move the non used points over to it until you need them again?

quote:

I have removed them from the routes so that they are not loaded to the data collector, but the data still shows up in Plotdata and throws my dates off sometimes.

The others guys have good ideas, but I do not understand how you are looking at the data that would make the dates wrong in Plotdata? Is this a new feature in the 5.1 Plotdata?

Danny,
I have the same problem as you do.

Ralph,
What danny means is for example, you take 6 points on an 8 point route in July. When you view these data in plotdata, it will show the latest readings in July. However, if you were to browse one point that's in June, whenever you press forward, all the points will be of during the same June period. It's kinda annoying and really throws you of track.

quote:

Ralph,
What danny means is for example, you take 6 points on an 8 point route in July. When you view these data in plotdata, it will show the latest readings in July. However, if you were to browse one point that's in June, whenever you press forward, all the points will be of during the same June period. It's kinda annoying and really throws you of track.

OH! I see. Thanks wookp.

This has been the case forever, even in MTWin and DOS, the best I can recall. The only way around this, as far as I know, is to use autoplot with the dates you want, say, July 1, 2008 to July 10, 2008. This will show only the points with this date but,if you manually go from a July point to a point that doesn't have a July data, then you are back in the same boat again until you ENTER and it will go back to the last point you looked at before going manually to the wrong date point.

I have never heard of the deactivation option when using manual plot. Autoplot is the only way I can think of now. Moving the points, in Danny's case, is about the only way around this, if this is what Danny is doing, like wookp mentioned.

I might be wrong, but since 1988 when I started using CSI, this has been the case or I never saw another way other than Autoplot.

The programmer could, I am sure, insert an option that would let us manually go from point to point and skip the point without a specified date and not be in Autoplot.

I used to be able to do GWBASIC programming back in the early 1980s when I was running an HP RTA and a basic computer to display the data from the RTA. These programmers can make the software do almost anything they want it to.

If this is not what you are talking about Danny. I'll throw all this in the trash.

When creating the database I usually had lots of extra points in my machines for the baseline survey. After collecting and renaming some things this baseline was then saved and used to create a route style database that is used all the time.
In this database I would usually have some spare machines for the jobs that could possibly prop up as an extra or if I needed to do some special tests that I thought would get in the way of my trends etc.

I must try Ralph's theory out with selecting a date range that sound like it could work. Although I usually find myself going forward and backwards through the current and historical data when doing the analysis.

Hooch

One other option that you can do, is to go in d-base, and move the points that you are not taking to the last points on the machine. That way, when you are going through them on plot data, you will look at the ones that are active first and not have to worry about those. This also preserves the historical data that was taken on these inactive points, but also keeps them available in case you want to reactivate them at a later date.
This is a problem that I too used to have, but I am now using 5.2 and so far, it appears to always default to the last reading, regardless of the date or at least that is what I have seen to this point.

Scott

quote:

This is a problem that I too used to have, but I am now using 5.2 and so far, it appears to always default to the last reading, regardless of the date or at least that is what I have seen to this point.

This sounds great Scott. How does it do it? Some type of options that have to be choosen prior to looking at data?

The only thing about moving points out of a machine, there might be times that a "point" might not be running this month for some reason and that will not be the reason next month and the point is needed to be there. It happens quite often on some speciality machines where a guide roll or paper roll might not be needed during a particulair grade of product, or something along that line. But on a fixed or variable speed motor driving a pump or agitator or something that is always running if any part is running, this removal of the points would not cause a problem.

I am interested in how 5.2 does this seperation. Hope you can give us some details Scott.

Turn the points off in route management. Go to route management and click on the route then go to modify measurement points and put zero's next to the points you want to turn off.

Thanks to all for the tips.

Wook is correct in explaining my problem.

For this instance, I elected to delete the points entirely but for others, the data may be more critical.

Ralph,

I've heard you mention Autoplot before and I'll check it out.

Scott's approach would also be a good one to take

WoW!!!!
Sounds like someone should have used a standard commercial database engine!
Sorry, couldn't resist
In a perfect world, CSI wouldn't have taken the 'propriatary' route and you could be in the field with your 2120's and 2130's, and then dumping that data into Odyssey.
Please don't even think of telling me that RBM ware is a robust 32bit windows software. It isn't and never will be. I am more than willing to admit that the dataPAC's had some worts and the enpac's have never been fully supported (they are still adding BASIC features, like peak hold averaging!).
I firmly believe that many people in the field are not even aware of the major strengths of Odyssey, because in my experience, the sales force (distributors, give me a break!), and the technical support folks don't know them
During my training for Odyssey, after being a MasterTrend user for six years (yes, at least I have used both), I asked the trainer if I change my alarm bands, can I interrogate data previously taken with my new alarm bands? His answer was 'Of course, why not?' I informed him that his major competition could not.
To me, it is a mortal sin to not know your competitors strengths and weaknesses and use them to your advantage in the market place!
I have attached one view to this email and one to the next email.
The first is the hierarchy setup. EVERYTHING is on one page! Don't like it that way, close some of the panes. The point is, it's up to the user, not cast in concrete like it is in a DOS product pretending to be a windows product.
The second page just happens to be the way I like to interrogate a problem, after my alarm report has flagged a machine. Again, EVERYTHING is on the screen and more importantly, every pane on that screen is interactive. Move the cursor in the waterfall plot, and EVERY window updates to that point! Again, as a user, you don't want to look at something, close the pane! It's that simple, but the choice is yours.
Comments?

Thanks for the primer on a totally unrelated topic, Ron. I know you IRD guys have got to take the rare opportunity to point out it's superiority to RBMWare because you are still waiting on the communications to your data collectors to finish.

I fully realize the Oddysey is a real database program and everything and, but I really don't care how easy to use it us because I can't use it.

IF I had a choice, I might use it but I don't.

BTW, Dave Mac beat you to the punch with that one by 24 hrs' Where were you? Trying to find a fault frequency in Oddysey?

This message has been edited. Last edited by: Danny Harvey,

Danny,
It is a darn shame that people in the field really get stuck with what someone else bought. No argument.
But, there is absolutely no delay in uploading and downloading data routes with a PCMCIA card reader for the dataPAC.
Is there something I am missing about fault frequencies? Never had an issue.

I use the method that Viberscott suggested, moving the unused points, to deal with this problem and it has worked well for me.

Ron,

Take for example one drive I cover. It has 4 motors and 4 triple reduction drive trains, all operating a very slightly different speeds, and all in one housing. That's about 100 or more fault frequencies with low speed gearmeshes at about 914, 909, 895, and 888 or so. And it is variable speed. With Rbmware I just tell the Wizard all the tooth combinations and bearings and it created all the fault frequencies for me. And they are automatically adjusted when I input the motor speed once. Can you do that with Odyssey?

(It seems like we have had this exact conversation before, doesn't it?)

I used a card reader with Odyssey with great success for about a year. Dump a full route in a minute, for sure. Then I changed laptops and the card reader wouldn't work anymore so I was back to the cable. 30 minutes to load an empty route and 40 to dump it. Add another data collector and two routes and half of my day at one client was spent watching the data collector and computer communicate. I was getting paid by the hour for that work, but I would rather eat glass and happily don't have to do that work any more. With CSI, they don't even try to make their cards work in card readers, but it only takes about a minute to load a route and 5 to dump it which is about as long a break as I need to take. And it works every time.

I'm sure you could teach me how to fix my problems with Odyssey, but I don't have them anymore because I don't have Odyssey.

Danny,
Sorry to hear you had such poor support while with Odyssey. I have a customer that set up an entire paper machine in Odyssey and with one reference speed input at the very beginning of the 1000 point route, ALL of the frequency items were calculated and saved. The customer had been using Excel until I pointed out this feature.
The card reader issue was not Entek's fault, blame Bill Open Architectrue Gates. That is why from day one, the tech support folks that know what they are doing at Entek recommended the Omni Drive card reader. It is now working on my fourth computer without issues.
I also have a Zonic 8 channel Medallion that worked through a double high PCMCIA DSP plug in. Guess what? My next to last computer has only 1 single high slot. So, I got industrious and found an extender card. Still didn't work. Worked with Zonic and IOTech without success. Got more industrious and found the manufacturer of the card was 30 miles from my office! They were your typical byte head think tank. Realized in a minute what was wrong. In a move to save battery power, laptop manufacturers had changed the voltage output on the communication pin on the PCMCIA slot from 9 volts to 5 volts to 3 volts! The Zonic Medallion DSP was looking for 9 volts. Well, there just so happened to be a pin in the DSP card that had 9 volts on it. The engineer working with me soldered on a jumper and I was back in business.
But you see, IOTechs solution was for me to upgrade to their USB interfaced front end. Price? $10,000! The price I paid for the unit in the first place! That's not an upgrade, that's starting all over.
Again, sorry to hear you don't have Odyseey.

Danny, you'll never get Ron to admit that RBMware is a better system then Odyssey.

Hiya' Ron. Glad to see you're still kickin'.

Nope, won't happen. But I don't want to either. If he is happy with Odyssey and I am with RBMWare, then there really isn't a problem, just some good natured kidding. We do it from time to time and hopefully both learn from each exchange.

Like I told Dave Mac, if I understood database programs, I would probably prefer Odyssey but I don't know nothin' 'bout no databasin' so it is just software to me. I know how to use Rbmware very well and Odyssey not so well. I'm not changing either.

This message has been edited. Last edited by: Danny Harvey,

I haven't upgraded to the latest version of RBMware..uh.I mean Machinery Health Manager, but I've heard it's much like SQL based Odyssey (I'm dreading it).

I really don't think RBMware is a better system either, just easier to use (for now). I know Ron's a genius with Odyssey, so the few times I've used it after watching him makes me feel like a 2 fingered piano player.