Any reason you’re querying sqltags historian data by hand? By doing this you miss out on a lot of work that the sqltags historian system does during querying, such as correct interpolation where data wasn’t changing. When you query it manually, the quality of the data also isn’t taken into account unless you “hide” the bad quality information by hand in your query.
I used the query just to examine the data to see if the value actually fell to zero. The trends uses whatever the historian pen uses in the EasyChart customizer. I am not using my own query to make the trend.
I have attached a screen shot of a table with a SQLTag binding. I am not sure what you are looking for in that. That data does not drop out (attachment).
This is happening in all of my trends, for no apparent reason. I looks like some big pumps are turning on and off several times a day as a result of this bug. Here is ALL the data in a pump status table for today.
Ok now I’m confused. Whats driving that status chart? The transaction group’s table or SQLTags history? What was that table showing - it doesn’t look related to the other pump on/off data.
The status chart (blue is off, green is on) is plotting data with an Easy Chart from a table created by a transaction group with only one tag (pump on) that is triggered to log when the status changes. The blue gaps in the middle of the green sections do not reflect any change in value (1 -> 0) in the source table.
The pump comes on at 01:33:52. It goes off at 04:21:23. The chart shows that the pump went off and back on again four times during that period. It did not.
I just want to make sure I understand whats going on here. At the beginning of this thread you were talking about SQLTags History. Now you’re talking about data stored by a transaction group. Did something change?
Can you get this behavior to exhibit itself in the Designer, and then export the window while it’s in the poor state and post it here or email it to us? That would help us diagnose what is going on.
There’s a painting problem with the Easy Chart component when the style of a discrete tag’s trend is set to “Digital Area”. There are gaps in the digital area trend that are not present in underlying dataset. There is a trouble ticket on this. I set my chart style to “Digital” and the problem went away. I’m a happy camper. I thought the look of a “Digital Area” trend was kinda cool, but it’s something that integrators might want to shy away from for now.
The other problem is that analog trends drop to 0.0 occasionally, even when I’m certain that the tag’s value is clamped, by the PLC, above 0. This is not an Easy Chart bug. The Easy Chart correctly plots the values in the underlying dataset in this case. I cannot pin-point the problem right now, but I suspect that the Ignition Modbus UA server, and its response to communication failures, is the source of it. I’ve toggled back and forth between using Kepware’s Mobus OPC-UA server and Ignition’s. In the historical dataset, Kepware consistently responds with Nulls on communication failures, Ignition occasionally responds with 0.0. I wish I could be more helpful, but that’s all can come with for now.
Regarding issue #1 (the digital area painting) - it isn’t really a “painting bug”. All renderers skip datapoints with poor quality - its just that visually, when an area renderer skips a datapoint it looks like it has “dropped” to zero. I’m not quite sure what the correct response on our part would be here…
