2 of 2 people found this helpful
Good morning Jeremy,
Please try this PE to see if that fix your problem:
if (Hour('*')<10) then (TagTot('GASFLOW_UOMperHOUR','y+10h','t+10h')*24) else (TagTot('GASFLOW_UOMperHOUR','t+10h','*')*24)
if (Hour('*')<10) then (TagTot('GASFLOW_UOMperHOUR','y+10h','*')*24) else (TagTot('GASFLOW_UOMperHOUR','t+10h','*')*24)
I selected on Bold the change that I made, the problem that you have is because you are using TagTot for an hour that doesn´t exist yet, this makes tattot make a predicition and give you the wrong value that you want. For example, if the actual hour is 8 am (Hour < 10) then you will ask PI to retrieve the TagTot from yesterday at 10hrs (That´s OK) to today at 10 hours... but the actual hour is 8 am, so how can PI make the totalize until 10 hours if now is 08 am? that´s why PI is giving your a prediction. As I can see you don´t want that so only need to change the 't+10h' for '*', with that you will have the values that you want, you can try this on a Dataset on Processbook to see how will be the values and avoid wait until tomorrow.
Please let me know if that was helpful or not.
You are definitely on the right track with your answer. The ultimate should take into account that TagTot may not cover a full 24 hours. If the trigger time is 4:00 AM, then TagTot should be multiplied by 18, not 24.
Plus the PE does not account for time transitions for daylight saving time. Here in Texas, there is one day a year with 23 hours and another day with 25.
Thank you. This makes perfect sense to me. I was unaware that TagTot would try to predict or forecast the data, rather than just say to itself, "hm...we're at 8am, and 10am doesn't exist yet, so just show until 'now'."
I have changed the tags and will reply back tomorrow if this works. It's not a super important/major issue, as the curve tends to give a good end result (if you follow the trend up, the 9:59am point before the 10am reset is pretty spot on).
1 of 1 people found this helpful
It´s good to know that was helpful,
Try the PE and tell us how went you.
PD: Sorry for my bad English.
1 of 1 people found this helpful
Hello again Jeremy,
I know you are hard at work implementing the suggestion from Noé Alvarado de la Cruz, and your question is purely about Performance Equations and not Asset Analytics. However, for completeness and posterity of the topic for future readers who may be using Asset Analytics, here is an example analyses that works in those special corner cases of before 10:00 AM as well as during Daylight Saving Time transitions:
This is just a simple example. Instead of using '*' for my tests, I forced a trigger time of 4:00 AM Today. While your input tag is 'GASFLOW_UOMperHOUR' with the appropriate volume flow rate per hour, I substituted the dimensionless 'Sinusoid'.
To keep the image narrow enough, i.e. not so wide it can't be displayed on many smaller devices, I broke the analyses into many expressions. Doing so makes a better learning exercise since you may see each expression's evaluation along the journey to the final answer. I also believe that breaking an analyses down into many expressions is just one of many reasons why I prefer Asset Analytics over PE.
For those Spring Forward transitions with a 23-hour day, the RangeHours will show 23. Likewise the Fall Back transition will have RangeHours at 25.
For a TriggerTime of 4:30 PM, that is to say 16:30, then the TriggerHour would be 16 and the RangeHours would be 6, not 24.
Obsolete: The reason for the AdjustedTriggerString may not be apparent from this example since I input a time that aligns on a whole hour. Imagine the TriggerTime really being 4:25:30 AM Today. The AdjustedTriggerTime would then differ from that TriggerTime. Updated: I altered the analyses to that TriggerTime no longer fell on a whole hour. A new graphic replaced the outdated one.
Marked the correct answer. Changing t+10h to * worked great. Now the tag only increases, then resets back to zero at 10am. Perfect!