Grafic bug in version 5.79


kanber

Recommended Posts

I attached the files which ı see problem. problem is that when ı open a text file for read values, grafic is not true and when ı zoom to grafic it will show me true. you can see with 3 and 6 hours it is diffrent full screen and zoom. ı also attached print screen...

what was problem with my programme or anything else.

Error.zip

Link to comment
Share on other sites

To optimize the graph plotting when you are zoomed way out and have a lot of data points, DAQFactory reduces the dataset by doing boxcar min/max on the data. If we didn't do this, graphs with lots of data would take many seconds to draw. This method shows the detail well (meaning you see the peaks and valleys), but may cause intermediary values to disappear until you zoom in. This, I believe is what you are seeing. You can see the three peaks at 4pm, but the data reduction causes a slanting connecting line.

Link to comment
Share on other sites

You could reduce the data down yourself using whatever technique works for your data. Maybe the smooth() function? But that will drop off the peaks. If there are gaps in the data, you might want to reduce the line gap threshhold on the General page so that the graph doesn't connect points that are widely spaced.

Link to comment
Share on other sites

I also reduce data. Look at attached file before I reduce data I save data every 5 sec. and this will be 18 MB. and open the graph it takes long time for display. and I change saving format. 3B9.txt new methot. and file size 309 KB. and it is not show correct graph. but with old metot file size 17.562 KB and it is show correct graph. you can try with attached file...

it is not problem with reduce data...

Error.zip

Link to comment
Share on other sites

I did not need the big file, just error.ctl, which had the data for the day in question.

The problem is the format of your data. You have 6 data points grouped tightly together, and then a 20 minute gap, then another 6 data points. Inside this group you have a peak and a normal, almost 0, value. When DAQFactory reduces the data and you are scaled to 24 hours, it just happens that each of these groups ends up in its own boxcar. DAQFactory takes the min and max for the boxcar, which results in only two points for the group. Unfortunately, that means that instead of getting 0 - 10 - 0 in close time proximity, you get 0 - 10, then a big gap, then 0 - 10. In that gap you get a connecting line, which is why you get the slanted line. If you zoom in even, say to 12 hours, the boxcar picks up the next group and the slanting goes away.

You have two solutions:

1) set the line gap threshold to something small, like 100, so it doesn't make this connecting line. This will make the graph look a bit weird, but more accurate

2) In whatever sequence is polling the data, have it repetitively add the last value in the block of data every second or so during the gap. This will create enough data points that the graph will display correctly when zoomed out.

Link to comment
Share on other sites

Hello guys,

I've also had such kind of problems with graphing. I understand the complexity of the trendfunctionality, because DAQFactory has to deal with a lot of data and performance at the same time.

But maybe it sounds a bit hard, but my opinion is that DAQFactory should have a trend functionality which works OKin all situations, we should not be worried about specific settings, or behaviour when the user zooms in/out.

Nowadays trending is rather standard in many applications and programs. In all the programs trending works without any worries about special settings. I know that you guys work very hard and know that you have to deal with a lot of problems. Also working on the new release takes a lot of time.

I would be pleased when DAQFactory can improve the trend functionality.

Greetings,

Bart van Diepen

Pro Control Process Automation B.V.

Link to comment
Share on other sites

We always appreciate feedback and will certainly try and improve the graphing to avoid this issue in the next big release. However, I believe a little explanation is required:

99% of applications that offer trending do it on static data, not real time data. Static data is easy to optimize. You can read part of the data and render it, then go back for more to get more detail without worry that the data set has changed. The other 1% that trend live data do not offer the flexibility of DAQFactory trending, namely the ability to put full expressions in the trend. They all require you to create a separate variable or data set, and then plot it.

So, its a little bit of a trade off. In 8 years, and about 10,000 users, this is the first time we've ever seen this issue. When coming up with the optimization algorithm 8 years ago, we never even thought about someone taking data in this way and that it would cause this problem (which it only does under certain scaling). While it is a valid issue and one we will hopefully be able to address, we aren't going to give up the power and flexibility of DAQFactory trending that sets it apart from the rest to solve a problem that 1 in 10,000 sees and that there is a simple workaround.

That all said, I want to repeat that we want to hear everyone's opinions as much of DAQFactory's development path is determined by user feedback.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.