I'm doing a report, and taking basic average for every hour (interval) for 24 hours. From Midnight to Midnight (all the way to seconds, 00:00:00) I keep getting slightly different numbers... this shouldn't be.... does Basic Average have some fuzzy precision or something that is keeping it from giving me the same numbers?
- Where's the data coming from?
- Are there actual records at 00:00:00?
- What's the query?
- "I keep getting slightly different numbers." On the same query or on similar queries?
2 Likes
And most importantly, what's the script you're using? we can't even begin to help without knowing what you're doing 
Hi all, thank you and sorry for the late response... I'm not even using a script, I'm just using some tags as a data source with 'Basic Average' as the Aggregation Mode. The sample size is interval with 24 hours. The numbers come back differently each time I run it even though the start and stop dates are the same.
Oh, I assumed cause of this:
You'll need to supply a lot more information before anyone can figure out what you're doing and what could possibly be wrong.
"Basic Average" is mentioned in the documentation in the context of Tag History Bindings in Vision | Ignition User Manual but you haven't mentioned tag history in your posts. (And you haven't answered the questions asked in post #2.) If you are using this then you also need to study how the tag historian works. There's a link in the article.
Fair! To all have have pointed out my lack of detail, I apologize, and thank you for answering my questions. Here you can see I am trying to make a rough 'midnight' to 'midnight' with StartDate and EndDate params. That 2nd column, lbsperhour_mod always comes back with a different value.
Observe this report, run twice within seconds, with a different result.
Strangely, it seems like only the bottom row is changing.
changed to 'reporting' tag!
So you want midnight to midnight for the current day or the previous day?
Why not use the midnight | Ignition User Manual expression function to generate the proper timestamp rather than the complex date arithmetic?
I take it back, I'm trying to do last 24 hours to present, not midnight to midnight.
Wouldn't that just be:
//StartDate
setTime(addHours(now(),-23),getHour24(addHours(now(),-23)),0,0)
//EndDate set to next flat hour
setTime(now(), getHour24(addHours(now(),1)),0,0)
Or
//StartDate
setTime(addHours(now(),-24),getHour24(addHours(now(),-24)),0,0)
//EndDate set to flat hour
setTime(now(), getHour24(now()),0,0)
Also, on your Tag History query, if you expand the Advanced section, do you have Prevent Interpolation Checked?
1 Like
Then every-time you run it, it will be different won't it? If the data is constantly changing, so I would assume that the average would also be changing as your window is sliding.
Like @lrose said. Make sure prevent interpolation is un-checked checked.
So the weird thing is the data is constantly changing for the last hour on that list. So, it's a previous hour (which should be properly defined as an hour). The arithmetic whittles off all of the seconds and minutes so that it should be an unchanging hour window.
Interpolation is unchecked. I'll try those versions... but it seems like mine are working from the StartDate and EndDate that are printed on the report.
Prevent Interpolation should be checked. That way the system isn't injecting values that don't exist.
Awesome, thank you! So it seems my arithmetic expression wasn't up to the task but the ones you provided are yielding unchanging results.
I extended out my time startdate/enddate printouts to include seconds, and my expression still shows correctly:
I get the almost same output with your expressions:
I'm not sure why, but the version you had works better. It also includes the current hour kind of in the end date, but it doesn't show that row yet at the top of the report (good because the hour isn't complete).
Weird, but solved! Thank you. It would be nice to know why that happens.
That your expressions were working at all, is a bit suprising to me, as the documentation for the dateArithmetic() function doesn't list 'min' as a valid field value. That may just be an error in the manual though.
The only thing I can come up with is that the dateArithmetic() function will preserve the millisecond field of the date object it works against, where as the setTime() function is documented to not preserve the millisecond field. Meaning that it will return a date with the millisecond field set to zero. Because the historian stores data by millisecond this does matter in the context of your query. So, you would include or exclude particular data points depending on the millisecond field.
4 Likes