RsView Historical Trend

doug2

Member
Join Date
Dec 2006
Location
California
Posts
181
Is there a way to make the pens on a historical trend indirect tags so that you can associate any I/O point rather than predefined tags to one trend screen?

In WW pens are assigned from a list of all logged tags, by the operator. This is the flexibility that I am trying to simulate.
 
I don't quite understand your problem. In RSView, it is easy to assign a new tag. All you need is some spare unused tags, and the PLC memory address. Assign a tag name, and tell it the PLC memory address. Once the tag is set up, you can use it in a trend chart. A trend chart can use any type of tag as a pen, whether it be a standard defined tag, a derived tag, or a system tag. Tags are THE WAY that RSView accesses PLC memory.

Now the problem could be that you do not have the tags that you want to trend set up to be logged (saved). After all, you must have saved the data before you can view it as a trend. In the RSView Edit Menu, go to "Data Log, then "Data Log Setup",then "Tags in Model", and add the tags for which you want to save historical data.
 
Last edited:
Lancie1 said:
Once the tag is set up, you can use it in a trend chart. A trend chart can use any type of tag as a pen, whether it be a standard defined tag, a derived tag, or a system tag.

I have 50 tags that I want to be able to "choose" from to view on "1" historical trend. The first time I may want to look at tags 1 -8. The second time I may want to look at tag 40 and 22. Or any combonation for that matter. How do you handle this?
 
You would have to add all 50 tags to the "Data Log Setup", so that data is saved for each tag. Remember, each tag is saved on a periodic basis (controlled by your Logic and Control Events time frame. For 50 tags, I suggest saving the data no more often than once every 2 minutes. The more often you save the data, the more memory it will take and the slower the program will respond.

Once you have the data for all 50 tags stored, then it is easy to set up trend charts, as many as you need to look at the data any way you want. You can edit and change them on the fly, but that is not something the average Operator will want to do. I suggest finding a happy medium by putting 5 to 10 data tags on each trend chart.
 
Last edited:
Lancie1 said:
I suggest finding a happy medium by putting 5 to 10 data tags on each trend chart.
This is exactly what we are trying to avoid. I am looking for the flexibility of being able to group and view the data that I am interested in at that specific time. Predefined pens make it cumbersome to find specific data when you have to look through separate trend screens.


Lancie1 said:
I suggest saving the data no more often than once every 2 minutes. The more often you save the data, the more memory it will take and the slower the program will respond.

Does this mean that the resolution on the trends would only be accurate to 2 minutes?

Thanks for the input.
 
Did you use the pre-defined trends package from the library. the thends package have few buttons,it have the options to show all pen, hide slected pen, or show only high lighted pen,
However, the trends must be selected as a histrical and must have the data logger configurated.
 
Does this mean that the resolution on the trends would only be accurate to 2 minutes?
Yes, you have to select some time frame. You can't log every pen on every scan of the PLC. The memory storage requirements would be prohibitive. This is the real world we must live in, with real constraints. If you don't like the physical constraints, then you must learn to get along without trend data.

What in the world is this data that changes so rapidly that once every 1 or 2 minutes is not adequate for historical data? In my experience, once a process is rung out and the bugs found, the data changes very slowly, except for upset conditions. Upset conditions are special cases, and can be handled by collecting real-time data during the event. This data (first-out, runaway temperatures, and so on) can have special memory tags (last 10 points maybe) in the PLC that automatically record the data during the event, so that it can be viewed at any time, independent of RSView.

I suppose you could park an operator in front of a screen and have him collect the RSView data and draw the charts by hand. However for 50 tags, I doubt that you would get any better resolution than an average of 2 minutes per point.

The best method is to select the few most importatnt tags for which you must have data every 30 seconds, then the many more that you can live with only having data every two minutes, and so on. Trying to treat all of the data points with the same importance means that you do not have the necessary understanding of the process, and will run you out of computer memory fast.
 
Last edited:
Its been a couple years (View 6.4), but the lousy run time trend abilities of View is why we stopped using View and went back to wonderware. There was no way to similuate the rather impressive trending abilities of wonderware in View. I had to do the same things, create a furnace temp screen, a water system screen, an atmosphere screen, etc, etc. In wonderware, I have no issues recording 40 or 50 tags every 2 seconds. I dont know if there is a way now that RSView has gone through some upgrades. This, and the lousy recipe and sql abilites of View doomed it in our shop. I really do miss the View - Logix interplay sometimes tho.

matt
 
Lancie1 said:
The memory storage requirements would be prohibitive. This is the real world we must live in, with real constraints. If you don't like the physical constraints, then you must learn to get along without trend data..

It sounds like I must have said something that has you on defense? I know that the memory requirements that you are referring to is the hard drive. The way this is typically delt with in our WW systems is that we log for say 30 days (depending on the customer requirements) then we dump to a backup file.
Getting along without historical trends is not an option. This is the only way to troubleshoot a problem when called in after the fact, that I am aware of anyway.


Lancie1 said:
What in the world is this data that changes so rapidly that once every 1 or 2 minutes is not adequate for historical data? In my experience, once a process is rung out and the bugs found, the data changes very slowly, except for upset conditions. Upset conditions are special cases, and can be handled by collecting real-time data during the event. This data (first-out, runaway temperatures, and so on) can have special memory tags (last 10 points maybe) in the PLC that automatically record the data during the event, so that it can be viewed at any time, independent of RSView...

Pressures and Temperatures that are being controlled within very tight tolerances.
Your suggestion might work in a small system but is not realistic on most of our systems due to the many operator or other outside variables that come into play.

Lancie1 said:
I suppose you could park an operator in front of a screen and have him collect the RSView data and draw the charts by hand. However for 50 tags, I doubt that you would get any better resolution than an average of 2 minutes per point....
I did not think that this would be such a cumbersome exersize. I suppose that I have been spoiled in the WonderWare world.

Lancie1 said:
The best method is to select the few most importatnt tags for which you must have data every 30 seconds, then the many more that you can live with only having data every two minutes, and so on...
I can definately prioritize the data (I never said that this is an issue) but these update time constraints like 2 minutes and 30 seconds are horrible and it seems hard to believe that RSView would be this limited.


Lancie1 said:
Trying to treat all of the data points with the same importance means that you do not have the necessary understanding of the process, and will run you out of computer memory fast.
I am not sure if I should get up and fight back after that slam. lol Lets just say that If you feel that you have mastered all of the many types of processes that we deal with and more importantly you can trouble shoot with out historical data then our engineering staff can definately learn a thing or two from you.
 
I am not sure if I should get up and fight back after that slam. lol Lets just say that If you feel that you have mastered all of the many types of processes that we deal with and more importantly you can trouble shoot with out historical data then our engineering staff can definately learn a thing or two from you.
Please accept my apology. I got a little carried away. I must keep better control of my arrogance. I realize that many plants have many people doing the troubleshooting. However, one-minute data will probably be better than nothing. But the amount of data you can store depends merely on the size of your hard drive, and the time between backing it up and erasing the old data. You can set RSView to collect data every 1 second, if you want.
 
Accepted.

I hoped this was the case. We can purge after a period of time and I can definately prioritize as suggested.

One last question. Do we have to assign a memory tag to the actual pen then write a script to move the actual I/O point in to the pen since it will probably not be the same tag associated with the same pen twice?

Thanks
 
You could certainly do that, make the trends programmable for different tags. It seems easier to me to create a large variety of trend charts with different combinations of tags, then call the one needed at the time. Remember that all trend charts, whether set up manually or by program, can still only pull the data from the historical data log files, so only what has been saved is available to view.

Because it is a record of what happened in the past, you had to know what the tags were in order to save them. If you know what they are, they you should be able to figure out what combinations would be useful in trend charts. If these charts are mostly for equipment troubleshooting and not for monitoring the process, then it is valuable to know what problems have occurred in the past, so that charts for those tags can be created. I would think that operator actions, such as motor start/stop and process start/stop indicators would also be need to be saved, along with certain pressures and temperatures.
 
Last edited:
You want to change pens at runtime? No problem. I'll assume you are using RSView32. Use the TrendX tool not the standard trend tool. Right click on the trend graphic during runtime, then select chart properties, then click on the pens tab and you can add pens.
 
and logging 50 tags every second is not a problem, I am logging at least that many. Can you even get a PC today with less than a 40 gig HD?
 

Similar Topics

Hi All, Can anybody guide me for configuring historical trends of analog data? I am using RsView version 4.0 and Micrologix 1200 Plc. Regards...
Replies
6
Views
3,955
Hello, I have converted RSView 32 to FTView SE 14 (I have tested FTView 12 before as well and there were some difficulties so I moved on to...
Replies
4
Views
166
Okay, something I have not seen before.. RSView SE. I am working on an existing project. There is a value the customer wants trended and it is...
Replies
4
Views
732
I have a request to integrate a pause button in RSlogix to be able to start/stop a video. Video format is not defined at the moment, so it could...
Replies
2
Views
751
Hello everyone, I am having a problem with conversion from RSView32 to FT View SE Local project on version 12.00 (CPR 9 SR 12). Firstly, I have...
Replies
6
Views
1,317
Back
Top Bottom