Cached trends

Hi,

I am using RSView32 on site here and had a question about how a similar effect to the cached trends of RSView32 could be implemented.

i.e. if I had a tag I was logging on a 5 minute basis for historical use, but wished to store a weeks worth of second by second information in order to see dynamic information (i.e. what the flow was doing on a pump when it broke down) (we’re a mine so this happens more often than not)

Thoughts?

-Alex

The only way to accomplish this today would be to log the data using two separate historical transaction groups and combine the data using a query. Not rocket science, but also not very obvious.

We’ve been working on some improvements for the SQLTags Historian feature that should help address this idea where you want fine-grained detail but only for a short timeframe, and beyond that you accept coarser logging.

There are a few ways we want to attack this problem of variable density history. One is that we want to have generational consolidation within the SQLTags Historian. This means that as data ages, the Historian will “digest” it into a format that is coarser and more well-suited to quickly handling queries that span a long timespan.

Another feature would be age-based thinning of data, where data that was logged at a very fine resolution gets thinned out as it ages.

These two ideas are pretty similar, they may be combined into a single concept. We’re going to be improving SQLTags Historian for Ignition 7.3, and I expect that some features along these lines will be included in that release.

That is great news that some of these features will be in 7.3

This is something I have battled with rsv in that I can set a trend to be cached but the more cached trends the more the client slowsdown.

Currently I am doing as you indicated and logging information to two locations (i.e. seperate databases for fine and coarse information). The use of a fine database instead of local caching seems to keep rsv clients from slowing down while still providing fine information useful for catching highspeed transients like pump cavitation etc.

The manual part (downside) of it is that every now and then I have to go and delete the old information from the fine database to keep the size down.

Seperating the databases was useful in that I can keep a ‘simple’ backup model for the fine database and so don’t have to worry about transaction file growth.

If this can be simplified through some sort of coarsening routine built in to ignition this would be awesome. (no need for two databases). I tried this myself through scripting in VB but it would take a couple of days to reduce a couple of months of 1 second information (1000 tags) down to a 5 min basis). Mind you I am by no means an expert at SQL so my query is probably horrendously inefficient.

Lookingo forward to the new features!

did the age based thinning of data make it into 7.3? If not any idea on when/if it will be implemented? I came up with my own solution to do this but it is ridiculously slow and horribly inept.

Thanks!