Graph Accuracy - Magic Spikes, Appear & Dissapear

Hi, On our trend displays trend lines are showing spikes where there should be none. (see attached files and video )

The problem seems to be related to when another trend line makes a change. Any trend line can affect the other trend line :prayer:

Each trend line displays correctly when the other trend lines are switched off.

The application is for monitoring max and min power variables. So, as you can appreciate we could do without these magical spikes :confused:

Pens are set to min/max which we need to display the “real” spike (average improves screen but does not fix it, and brings its own peculiaritys :cry: )

Version #'s
Ignition Platform 7.3.2 (b533)
SQL Bridge Module 5.33.1 (b68)
Vision Module 5.3.2 (b301)
Reporting Module 1.3.2 (b46)
Symbol Factory Module 2.5.1 (b26)
Java Version 1.6.0_34
JVM Memory 385.4 / 494.9

(Note Database values are offset by one hour to values on trend, and min/max values are reset once daily at 11:30 approx.)

I hope you can help with this problem

Thank you

Sean.
Data from spikes error I.xls (36 KB)

The spikes have to do with a caching problem in the client. It is a bug we know about and there is a workaround. We just need to disable the cache for now. Open the designer and select Project > Properties from the file menu. Choose Client > General on the left hand side. Check the “Disable Tag History Data Cache” and save your project. The spikes should go away. We are working on a fix for the bug and will let you know when it is completed.

Hi Travis,

Thanks for the quick response.

I am new to the forum and did try a search, but found no record of this.

Is there a place where known bugs are listed that I can check first, would have saved me a lot of time :frowning: .

Thanks

Sean.

Hi Travis,

I have tried what you suggested and cleared the cahe on the PC but the spikes are still there ?

regards

Sean

I reported same problem posted as “Jumpy Real Time Trends” back in January

viewtopic.php?f=72&t=7554

with no resolution to problem

[quote=“Curlyandshemp”]I reported same problem posted as “Jumpy Real Time Trends” back in January

viewtopic.php?f=72&t=7554

with no resolution to problem[/quote]

Well Curly, maybe it will be sorted now since there are so many of us talking about it :wink:

All I can say is that if you need to see the proper data switch off the other trends, at least then you know what you are looking at. (ref video above)

I’m sure ignition will have a solution by the end of the week :prayer: :prayer: :prayer:

[quote=“Sean49”][quote=“Curlyandshemp”]I reported same problem posted as “Jumpy Real Time Trends” back in January

viewtopic.php?f=72&t=7554

with no resolution to problem[/quote]

Well Curly, maybe it will be sorted now since there are so many of us talking about it :wink:

All I can say is that if you need to see the proper data switch off the other trends, at least then you know what you are looking at. (ref video above)

I’m sure ignition will have a solution by the end of the week :prayer: :prayer: :prayer:[/quote]

In my case, it is only 1 data point on a real time trend with spikes appearing and disappearing as the trend advances with time.
If a vew a few minutes of real time trend data, problem does not appear, but customer wants data trended for past 8 hours, and when more data points are on the trend, problem appears.

If the table from which your retrieving the values you want to plot includes dataintegrity try deleting all the rows where dataintergrity <> 192.

@Sean49 - If you run a SELECT COUNT(*) FROM sqlth_sce, how many rows do you get returned?

Hey,

First off, I can promise you that many changes have been made since January. I can say with strong certainty that you two are talking about completely separate issues, both of which have been fixed. However, I wouldn’t dare claim that there are no problem with this any more, because just by coincidence I’ve been working the last few days on a couple of similar issues, that are related to changes in 7.5.

Curlyandshemp - what version are you running now? In the thread that you referenced, I suggested a work around and that the problem would be fixed in 7.3.4. There was no feedback… (of course, I know I didn’t explicitly post when 7.3.4 was released, but you must be beyond that now- are you still having the same problem?)

Sean49 - I would definitely suggest upgrading to the last 7.3 release, 7.3.8. I seem to remember the problem you describe, and believe it relates to this entry in the 7.3.3 change log:

[quote]Tag history queries using min/max interpolation mode returning incorrect values in some
queries involving tags that don’t change often. Returned values interpolate between both
the min and the max value ranges, causing incorrect and unnecessary values to be reported.[/quote]

You can download that update from Downloads>Archived.

Regards,

In the range displayed in the video all dataintergrity = 192, (there are some dataintergrity = 600 outside the selected range), but then this I’m sure, can happen while updating a tag or with comms problems, and I would expect it not to create the bizarre results illustrated.

@michael - 13953 ?

[quote=“Colby.Clegg”]Hey,

Sean49 - I would definitely suggest upgrading to the last 7.3 release, 7.3.8. I seem to remember the problem you describe, and believe it relates to this entry in the 7.3.3 change log:

[quote]Tag history queries using min/max interpolation mode returning incorrect values in some
queries involving tags that don’t change often. Returned values interpolate between both
the min and the max value ranges, causing incorrect and unnecessary values to be reported.[/quote]
[/quote]

@Colby - We will schedule an upgrade,(This requires shutting down the server) but I’m not sure that the description above relates to my problem though. It is the values of another tag (specifically when the value changes) that are affecting a completely different tag.

Have you tried to enter my data (in the attached file) into a database and check the trends at the times indicated ?

Hi,

I didn’t see the attached file before, I’ll load them up and look. The change log entry I posted may or may not relate, but there were other fixes as well. Upgrading to 7.3.8 is your safest/most logical next step- from 7.3.2 to that there were many fixes, and 7.3.8 was a very stable version. If I happen to find a specific problem based on your data, it’s going to be in (and fix in) 7.5. We are no longer back porting fixes to 7.3.

Now the question about the “sce” table was a good one - that table can contribute to data being considered “bad”, which can in turn potentially lead to issues. That’s quite a few rows, though if you’ve been running for a long time, it may be spread across that time.

Basically, here’s what happens: For each historical scan class (defined in sqlth_scinfo), a row is maintained in the sqlth_sce table. While the system runs, it updates the “end time” for each scan class. If the last end time was more that 2x the scan class rate away, it inserts a new rows. In other words, for periods in time when there isn’t coverage in the SCE table, the system was down, or not running correctly. This is used in the query to generate “stale” quality values. HOWEVER, we’ve seen a few situations, especially with SQL Server, where rows aren’t updated correctly, or erroneously report that they’re too old. Lots of entries in this table can lead to little periods of bad data.

The simplest fix is to simply delete everything in the sce table, and wait for new rows to be put in by the running scan classes. After that, just run a query to set the “start_time” to 0 for all rows. If you had any scan classes that got deleted, you would need manually insert rows for those, but that’s unlikely.

Regards,

[quote=“Colby.Clegg”]Hey,

First off, I can promise you that many changes have been made since January. I can say with strong certainty that you two are talking about completely separate issues, both of which have been fixed. However, I wouldn’t dare claim that there are no problem with this any more, because just by coincidence I’ve been working the last few days on a couple of similar issues, that are related to changes in 7.5.

Curlyandshemp - what version are you running now? In the thread that you referenced, I suggested a work around and that the problem would be fixed in 7.3.4. There was no feedback… (of course, I know I didn’t explicitly post when 7.3.4 was released, but you must be beyond that now- are you still having the same problem?)

Sean49 - I would definitely suggest upgrading to the last 7.3 release, 7.3.8. I seem to remember the problem you describe, and believe it relates to this entry in the 7.3.3 change log:

[quote]Tag history queries using min/max interpolation mode returning incorrect values in some
queries involving tags that don’t change often. Returned values interpolate between both
the min and the max value ranges, causing incorrect and unnecessary values to be reported.[/quote]

You can download that update from Downloads>Archived.

Regards,[/quote]

Colby,

I tried your suggested reponse and it made no difference. This is an out of town job site and I planning to be there next week to re visit this issue and other project items.
I beleive last time I was at the job site in June, I brought the application up to the latest V7.3 at the time.

Hi,

Ok, Sean, I loaded your data into 7.3.2, saw the spikes, and then loaded it into 7.3.8 and didn’t see them. I tried various combinations of settings, and it’s possible that I overlooked something, but I think that’s fairly strong evidence that you should upgrade to 7.3.8. In playing with your data, I noticed another issue that was fixed between those versions, where the values of the min and max aggregation buckets can change as you scroll (it previously interpolated them based on the window size, and doesn’t in 7.3.8 ).

@Curlyandshemp - 7.3.8 was released in middle of June, so I suppose you’re at least pretty close to it. Where you planning on doing any upgrades on this trip? Perhaps we can break off on PM or something and discuss options/plan of attack.

Regards,

[quote=“Colby.Clegg”]Hi,

Ok, Sean, I loaded your data into 7.3.2, saw the spikes, and then loaded it into 7.3.8 and didn’t see them. I tried various combinations of settings, and it’s possible that I overlooked something, but I think that’s fairly strong evidence that you should upgrade to 7.3.8. In playing with your data, I noticed another issue that was fixed between those versions, where the values of the min and max aggregation buckets can change as you scroll (it previously interpolated them based on the window size, and doesn’t in 7.3.8 ).

@Curlyandshemp - 7.3.8 was released in middle of June, so I suppose you’re at least pretty close to it. Where you planning on doing any upgrades on this trip? Perhaps we can break off on PM or something and discuss options/plan of attack.

Regards,[/quote]

Colby,

just checked my notes, I have V7.2.11 at the site. I cannot install V7.3.8 as there is a cost involved from the V7.2 to V7.3 update.
It will not go well with my customer to tell him he needs to pay for a fix that they have been complaing about since the original install.
Should I be contacting my account manager on this?

Yeah, it would probably be best to give them a call.

[quote=“Colby.Clegg”]Hi,
Ok, Sean, I loaded your data into 7.3.2, saw the spikes, and then loaded it into 7.3.8 and didn’t see them. I tried various combinations of settings, and it’s possible that I overlooked something, but I think that’s fairly strong evidence that you should upgrade to 7.3.8. In playing with your data, I noticed another issue that was fixed between those versions, where the values of the min and max aggregation buckets can change as you scroll (it previously interpolated them based on the window size, and doesn’t in 7.3.8 ).
[/quote]

Ok Colby,

Thnaks for that, thats does seem fairly definitive. I just didn’t want to upgrade to 7.3.8 only to discover we needed to upgrade again to 7.4 or 7.5

I will organise the upgrade with our customer.

I consider the matter resolved. I will report back if there are any issues.

Thank you for your help and particulary the promptness which is most important.

My status is now gone from :prayer: to :thumb_right: :smiley:

Cheers

Sean

You can upgrade to 7.5 if you want, though I only tested with beta 3 of 7.5.3, which has had a few charting changes (to be clear: some things were modified between 7.4 and 7.5, which is why things that may not have been an issue in 7.3 & 7.4 popped up).

However, 7.3 is the most direct fix. It’s not long term, in that we’re no longer making changes to it, but 7.3.8 is considerably better than 7.3.2, so I’d say that’s the place to start.

Regards,