I also would see it at certain zoom levels and not at others.
Hi
We have exactly same issue in couple projects.
Trend is making those 0 lines depending zoom level and pen selection.
Even when enable/disable different pen that pen waht is looking strange.
I made some more testing and find out that all pens waht are showing this strange lines have gew data integrity 0 values in history. So some reason there is logged row where is value = 0 and dataintegrity=0.
After changing history aggregation in tag to discreate this seems to be stopped.
Now I have few days trend working as expected.
I can give you remote acces on our server if wanted to test/see problem.
Br
Tommi
Thanks. I’m still actively trying to track this down, although I didn’t get much of a chance to work on it this week. However, we finally saw something that might be related in one of our test cases, so hopefully we can track it down soon.
I’m fairly certain the problem is with min/max query mode with analog data. You can change it to discrete, as you did, or change the query to display “average” instead of “min/max”. I would probably do the latter, because changing the mode to discrete actually changes the way the data is stored (doesn’t use the analog compression algorithm).
Anyhow, this is one of my top priorities to get resolved next week.
Regards,
Hi
I tried to change trend display method to Average but then it gives really strange displays?
Trend values are changing based on zoom level?
So keeping it Min/Max gives right values except those strange saw lines.
If you need access to our server just let me know.
We/you can also make changes there if needed.
Br
Tommi
Hi
I made small clean query to database deleting all dataintegrity = 0 records away from one of the tags.
It did not change anything, just let you know.
Br
Tommi
I tried the Average mode as a workaround. It does seem to get rid of the false ramp pattern, but it also resulted in some incorrect values being displayed. For instance, we have a pen that sits at 100 for a little while at the end of a cycle which then goes to 0 in-between cycles. Instead of displaying 0, the pen was shown to be sitting at 11.41.
Finally! I’ve tracked it down and fixed it. It will be in 7.3.3. I’ll try to push the build guys to get a beta up soon so you guys can confirm, and mostly because I’m sure you’re getting annoyed with the strange trends by now.
Since you guys are all inquisitive, I’m sure someone will ask why it was happening: basically, it was caused by having a pen that didn’t change for a while, on top of a pen that had many changes. With pens that are set to “min/max”, the one with many changes will generate two values per time window. The pen with no changes was being asked to generate two values, and instead of interpolating between the previous and next value consistently, it was interpolating between the previous and both the min and max of the next window. Anyhow, this was introduced in 7.3, when we made some changes to how data is stored, and how min/max interpolates.
As for “Avg” mode, I’m fairly sure the values are correct, for what they are- the average of multiple values in a window. Unfortunately, they can be misleading, as you don’t see the full range of the value in the time range. As you zoom in, things become more “accurate”, as you have fewer occurrences of multiple values per window. Anyhow, this defect of averaging is exactly why min/max exists- so you can see the true range, at the trade of of a “busier” graph.
Thanks for your patience everyone,
Hi everyone,
7.3.3 Beta 2 is now available in the development downloads section, and should take care of this problem. Let me know if you have any issues.
Regards,
Has anybody been able to confirm that this has been fixed? I know it works for me, but I’d like someone else to confirm as well!
Regards,
Hi Colby,
I tried this on a test gateway and it seems to mostly function properly. Since this is a test system, I’ve been on the 2 hour license and I have seen some minor strangeness when some values were logged and the dataintegrity isn’t 192. For instance, in one case I had a gap in a pen and when zooming in closer it had a drop line that went down close to a zero value. In the data itself there were two records with zeros; the first with dataintergrity 500, the second 600.
The other issue I saw was identical to the false ramp with a drop to zero in the ramp. The start of the ramp was actually a zero logged value and the end had a value (20.3) with dataintegrity 900 about 40 minutes later. I believe this was probably when the license timed out. The pen should probably have remained at zero the whole time. There was then a gap in values as one would expect when the license was reset.
Lou
I am limited by not having a spare instance of SQLserver to log to. Could I just install the 7.3.3b2 module into my gateway for 15 min or so? or will this cause issues when I want to return to 7.3.1?
Hi,
The fix doesn’t affect the storage of data at all, so you shouldn’t need another instance to store to, unless you’re talking about setting up another complete gateway and pointing it there while the main system logs to the first.
Anyhow, the problem lies in the gateway, not in the vision module, so the only way to test is to upgrade everything. So, I suppose you might want to wait for the actual release.
Regards,
Hi!
I’ve been testing this fix and now the zooming and drawing seems to be working fine, thanks.
Now my problem are faulty values in database. I use modbus TCP v2 driver and somehow it seems to store values where “dataintegrity”=0 and “floatvalue”=0 to “sqlt_data” table and I know that those values aren’t really zero (this looks terrible on trends). Our modbus server is located on a mobile device and this connection might get broken at any time, so I think there has to be some issue between the modbus driver and data storage driver at the time when the connection breakes down.
regards
-Heikki
Hi,
I’ll look into this, though I suspect that it’s working more or less like it should, but you just don’t like the behavior: the chart does not show values with bad quality. Therefore, it can sometimes look like the value goes to 0 (and for some reason, I think the graph might even draw lines to 0 when the quality goes bad). At any rate, if it is indeed working like this, perhaps the answer is to add an option to allow the graph to show bad data.
I’ll take a look and let you know what I find.
Regards,
Hi!
To clarify the issue, we are using an “Easy chart” with “Tag Pens” and tags are stored in external MySQL database.
Based on what I’ve seen, I don’t agree that trends don’t show values with bad quality. At least my trends will show zero values on records where “dataintegrity=0” and “floatvalue=0” (records verified with MySQL WorkBench). But is “dataintegrity=0” consired as bad, I don’t know.
For me, it would be best if the trend would only show data values where “dataintegrity=192” and gaps if it’s anything else. Also if there wouldn’t be any “dataintegrity=0” and “floatvalue=0” records in database, would work for me too, but at least the “floatvalue” should be “null” if the “dataintegrity”=0, because that’s not a real measured value, such as temperature.
regards
-Heikki
Hi,
Ok, I’ve investigated the problem and found that interpolated values were being generated between the good and bad raw points. I’ve fixed this for 7.3.3, so now only the good value will be used until the time of the bad value. This means that the graph won’t show those drops- instead, it will just show a gap.
This will be available in the next 7.3.3 beta (I believe beta 5).
Regards,
Hi!
I just installed 7.3.3 beta 5 and now the trend seems to handle bad qualities properly. Thanks.
regards
-Heikki