My Wonderware Intouch trends are very slow?

[drspanda]

Hello and welcome to intouch people,

These days I am having problem with fetching trends in Intouch very slow...I don't know where to look...The data are fetched from a .csv file.

thanks.

 

[rdrast]

What do you mean 'fetching trends from a .csv file' ?
If that is a new feature in InTouch, forgive that I am unaware of it.
Generally, InTouch historical trending information is stored in a proprietary format, which can be exported to .csv files. Later versions of InTouch (I'm thinking 8.0 and above) can also use a SQL Database as a historian, which shouldn't be slow.

If you are trying to retrieve many pens, for a long time period (8/16/24 hours or more), then the trend control (either Built-in, or the Archestra Historian) have to do a great deal of processing to render them.

I suppose the first place I'd look, is your historical logging configuration. If you have a minimum sample period set to 0.001 seconds (yes, unrealistic, I know), you are recording a boatload of data that really isn't changing in any way that can be meaningfully captured by InTouch. Same goes for if you are monitoring, oh, say, Temperature. If you are concerned with normal industrial process temperatures, the 'logging deadband' should probably be set no lower than 0.5 degrees. If the logging deadband is set to 0.01 degrees, again, you are recording virtually meaningless information. -- Well, that depends, if, in the temperature example, your nominal operating range is from 0 to 10 degrees C, then perhaps recording 0.01 degree differences might be justified.

I normally set my logging deadbands to be one half of the smallest logged increment I'm interested in. As in, if my process variable span is 0 to 400 degrees, and I'm only interested in whole degrees, my logging deadband is 0.5 degrees. If the PV is 0 to 10 Newtons, and I want resolution to 0.1 Newtons, my logging deadband is 0.05 Newtons.

The InTouch default deadband of 0 means absolutely any change in a tag will be logged. Since, by default, InTouch only logs things that change from one update to the next by more than the default, a default deadband of 0 will force it to update the log virtually every OPC/DDE/DAServer read (which also has the side-effect of making your logs dependent on the scan time of your communications servers.

How does this make retrieving a historical trend slow? The trend display must interpolate every single transition, and then decide which ones should actually be displayed. Even with a decent graphics card and monitor, and HMI running at even 1920x1280 pixels can only display a maximum of 1920 points. If you are trying to read a constantly updated historical file that has 6,292,891 data records for a given time period, the trend display is responsible for either intelligently querying the data file for every 3,277'th point (which it does NOT) or, reading in all information, including timestamps, for every single point, and interpolating the results to fit in your 1920 pixel width display.

 

[Tark]

Also check the Keep Log Files for: X days setting in the Historical Logging Properties. The longer you keep the log files, the longer it takes to search through those log files.

 

[OZEE]

As a rule, if your trends are getting slow, it's because it has too much data to sort through in building the trends. Basically, there are two "causes" for too much data:

1) Too many log files -- like Tark said. (Do you ~really~ need data for 90 days? Or is 10 days adequate??)

2) Too many data points in the log files. Check how often you're logging the data. (Do you ~really~ need to log data 10 times/second or every time an analog value changes?)

Another hazard of never deleting log files that are accumulating an obscene amount of data is that your hard drive will eventually fill up, too.