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.
Well Curly, maybe it will be sorted now since there are so many of us talking about it
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
Well Curly, maybe it will be sorted now since there are so many of us talking about it
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 [/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.
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.
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.
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 ?
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.
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.
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.
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?
[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.
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.
)
.
