We are using Ignition version of 7.3.1 (b496) and there still seems to be some weird behavior on trends (easy chart).
I’ve attached a screenshot that demonstrates the issue. The green pen is actually changed from value 235 to value 230 at 23:14, but when we look at the picture it seems that this value has been bouncing between 235 and 230 first at ~22:06 and bounced again at 23:14. But, If I zoom close enough, then everything is normal and value between 22:06 and 23:14 is 235 all the time, just as it supposed to be.
There also seems to be relation between other pens, because if I remove the red pen from the picture (untick it and press apply) , then the bouncing at 22:06 disappears, but short bouncing at 23:14 remains.
Probably the best thing to do would be to look at the raw values in the database. I’m assuming you’re using SQLTags history, in which case the data is stored in the latest “sqlt_data_*” partition, with the tag id defined for the path in the “sqlth_te” table.
You could also try running a similar query using a table. You would probably want a table and a date range component, and then start off with a query similar to what the easy chart is doing: min/max, fix results of 300. Once you verify the same behavior, change the query to “on change”. The table will show results with bad quality where the chart won’t, so also be on the lookout for values with red overlays.
I noticed the same issue. When zoomed out it looks weird but when zoomed in it looks fine, See attached: Note the almost perfect saw tooth pattern on both the green as well as the blue trends. When I zoom into this period, they go away.
This is on a 5 second trend with analog deadband in version 7.3.1
Is this on a historical chart, or a realtime? If realtime, try going to Help>Diagnostics in the client, and clicking the “clear tag history cache” button. On next refresh, does it look correct?
No it did not. It appears when zoomed out, and disappears when zoomed in. Here is a view of the plot after clearing the tag cache and opening it again (in the designer)
Its curious to see the almost perfect saw tooth pattern in some of the trends
Would it be possible for you to export some of the raw data for me so I could mock it up here? It must be something to do with the min/max interpolation- when you zoom in, it’s less likely that there will be multiple values per window.
Also, as I mentioned before, could you try mocking up a similar query with a table? It’s possible that doing that would give us more info. Of course, if you can get me some of the raw data, I can do that here. If you’re using MySQL, you could just use the “SELECT INTO OUTFILE” command to output some or all of november’s data into a text file. I can set up a support ticket that you can upload to, if necessary.
Not sure if you still need to upload this but I’ll set the ticket to allow for uploads again.
Just so you know, once I edit the ticket to allow for uploads you will only have 24hrs to complete your upload. If for some reason you are unable to upload the file(s) in the next 24hrs then you can give us a call here in support when you have the files ready and we can re-enable the uploading option on the ticket at that time.
We are seeing a similar trending issue. Clearing the history cache under Help>Diagnostics also had not effect. This particular tag is a valve percentage. I believe when the ramp pattern starts, the value is actually zero, the end of a batch. At the top of the ramp pattern, the value is actually 100%, the start of a new batch. So during the duration of the the ramp pattern, it should be 0.
You can see this a little better in the attachment which shows 4 hours instead of 2.
Man, I’m still having a hard time trying to replicate this. Everything I’ve mocked up keeps working correctly (including everything I’ve tried with Alex’s data). I must be missing some key component of it.
One thing though: could any of you guys perhaps try running the latest 7.3.2 beta and see if it still happens? As part of different tests, we noticed that min/max mode (which is definitely involved in this problem) wasn’t behaving as one might expect, so we made a few changes. One big part of that was to stop interpolating the max value- which is exactly what seems to be guiding the high edge of these trend segments on this thread. So, I suspect that this might have been fixed as a result of that.
I added the same datalog and trend to test server running 7.3.2-beta4 (b522). It seems like the effect is still there, although not as many drop-lines down to zero, and not as often. The straight line connecting two points exists (instead of sitting at one value and making a step change) and can be seen, but usually there is only one or two drop lines to zero. I did notice that panning the trend back will cause additional drop-lines to be created. They don’t seem to be created in the same place every time. When panning, it seems the a drop line is created on the left edge of the trend along the y-axis at times during redraw. Sometimes it goes away, sometimes it sticks around.
