Trend Lines Dropping Out

The value on trend lines will often drop to 0.0. See attached pdfs. The following data comes from the SQL statement …

SELECT from_unixtime(t_stamp/1000) as ‘time’, floatvalue, dataintegrity FROM sqlt_data_1_2010_09
WHERE tagid = 17

[size=85]2010-09-17 17:51:14 5.46687459945679 192
2010-09-17 17:57:24 5.51749992370606 192
2010-09-17 18:03:44 5.56812524795532 192
2010-09-17 18:09:44 5.61875009536743 192
2010-09-17 18:15:55 5.67218780517578 192
2010-09-17 18:21:55 5.72234344482422 192
2010-09-17 18:27:55 5.77390623092651 192
2010-09-17 18:39:35 5.72281265258789 192[/size]

There is no value of 0.0 around the time the trend lines drops out.

Also, what are trend lines supposed to do when the dataintegrity in not equal to 192?
trend zoomed.pdf (47.3 KB)
trend.pdf (82.4 KB)

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.


Ah, I see. The trend line should have “gaps” when the data is poor quality - it shouldn’t drop to 0.0.

Try binding a table to a SQLTags historian query for the same tags and range and see what values you’re getting.


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.

ndx, pump on, timestamp
491 1 2011-02-02 01:33:52
492 0 2011-02-02 04:21:23
493 1 2011-02-02 07:01:50

This data is logged in a transaction group with only one discrete value written on change. Take a look at the plot this generates (attachment)

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.

ndx,pump on, timestamp
491 1 2011-02-02 01:33:52
492 0 2011-02-02 04:21:23
493 1 2011-02-02 07:01:50

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.

OK, there are two problems here.

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.

Thank you for the detailed analysis.

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…