Can\'t set time period to Trend less than 3 hour

[Piterskiy]

Good afternoon I found some interesting bug when try to set time period to any Trend Group in Standard Trend Window when set time interval more than 3 hour - everything works fine. When I try to set time interval less than 3 hour I see in client logs "Query aborted with the following error: HistQuery, constructAnswerMsg, archive request returns an error (empty answer from archive)". Is it a bug?

If I set time period with no compression functions (AC types) with more than 100 000 values I see nothing in parameter that has more 100 k values on trend and ruler show this "-". Meanwhile server log shows me this "Unexpected state, ArReadRequestInfo, add Group Result, Query retrieves too many values, allowed maximum: 100 000 - query interrupted"

In my situation values came to my system very rapidly and I couldn't use time interval less than 3 hours because of first problem and more than 8 hours because of the second problem (too rapidly changing values about 5 times in a second).
Now I solve the most part of this problem - I start to use AC types compressions, but I still leave the functionality to the administrator to use pure values (without compresiion) and that's why I ask you the second question: Could I set more than 100 000 values to display on trends theoretically?

Maybe I could change QT ruler in TrendView to show with not "-" but something like "*-select shorter time interval".

[mkoller]

"Could I set more than 100 000 values to display on trends theoretically? "

Yes, the trend can cope with that, but it might be slow when you try then to scroll/zoom.

[Piterskiy]

Martin Koller wrote:

"Could I set more than 100 000 values to display on trends theoretically? "

Yes, the trend can cope with that, but it might be slow when you try then to scroll/zoom.

Could you suggest where can I increase this parameter?

[mkoller]

When you use the value archive, then you need to set the config entry
[valarch]
queryMaxValues = ...

[Piterskiy]

Thank you!

But the question about 3 hours remains.

[leoknipp]

as Martin Koller has wrote the trend can display more than 100.000 values for every curve.
If you still get an error when reading historical values from the database you can increase the limits for historical requests. Which limit needs to be changed depends on the log message which is written.
An explanation for a lot of log messages can be fouind in the section FAQ --> Log-Messages.

Are you using an own trend panel or the pre defined functionality for the "variable trend"?

Saving values 5 times per second in the database is not very common. To reduce the amount of data saved in the archives you can use archive smoothing, e.g. old/new comparison, value dependent smooting.
If possible you should use the _smooth config to limit the number of values received from the PLC and send to the event manager by the driver.

Best Regards
Leopold Knipp
Senior Support Specialist

[Piterskiy]

I saw this FAQ section there is no description about my error:
When I try to set time interval less than 3 hour I see in client logs "Query aborted with the following error: HistQuery, constructAnswerMsg, archive request returns an error (empty answer from archive)"
I use WinCC OA 3.12 patch 25

I use default trend viewer.

I use smooth config but values changes rapidly and I should also have archive with pure values (not AC).

I don't know what exactly happens when I try to look at any values in less than 3 hours interval but it looks like archive couldn't find anything, maybe it's because of UTC time (+3) or something else.

[leoknipp]

I made a test with the variable trend (System Management --> Reports --> Variable Trend).
Even when choosing a time range where no data is stored in the archive no error is shown.

What is meant with "default trend viewer" in your posting?

If you are already using the smoothing functions and still have a high update rate of 5 values / second you should check the smoothing options you have chosen.
When saving values 5 times / second you should take into account that you have about 430.000 values / day for a single dp element.

Best Regards
Leopold Knipp
Senior Support Specialist