6 Replies Latest reply on Aug 29, 2016 7:01 PM by JeremyMahon

    TagTot calculation going negative after midnight when source data stays positive

    JeremyMahon

      Hi all. I recently implemented some PEs that use the TagTot function to give us a daily gas burn total. The gas day goes from 10am-10am, rather than midnight-midnight. A sample of the logic is below:

       

      if (Hour('*')<10) then (TagTot('GASFLOW_UOMperHOUR','y+10h','t+10h')*24) else (TagTot('GASFLOW_UOMperHOUR','t+10h','*')*24)

       

      Essentially, I am saying that if the hour is prior to 10am, then give me "yesterday's" total from y+10h to t+10h, else give me the running total from t+10h until current time. Makes sense, works as expected...until midnight hits. It jumps way up and then the trend/values start to decline--which is not expected behavior for a "totalizer." The source data remains relatively constant for this unit so it's odd that the totalizer trend would decline. I would expect its slope to go flatter if a unit was coming offline (therefore less gas burn) but this unit runs almost 24/7 (therefore relatively constant gas flow). Any ideas? See trend below (showing yesterday ...

       

        • Re: TagTot calculation going negative after midnight when source data stays positive
          NoéAlvarado

          Good morning Jeremy,

          Please try this PE to see if that fix your problem:

          Previous PE:

          if (Hour('*')<10) then (TagTot('GASFLOW_UOMperHOUR','y+10h','t+10h')*24) else (TagTot('GASFLOW_UOMperHOUR','t+10h','*')*24)

          New PE:

          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.

          Regards,

          Noé.

          2 of 2 people found this helpful
          • Re: TagTot calculation going negative after midnight when source data stays positive
            Rick Davin

            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:

             

            Crossing Midnight.png

             

            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 TriggerTimeUpdated: I altered the analyses to that TriggerTime no longer fell on a whole hour.  A new graphic replaced the outdated one.

            1 of 1 people found this helpful
            • Re: TagTot calculation going negative after midnight when source data stays positive
              JeremyMahon

              Marked the correct answer. Changing t+10h to * worked great. Now the tag only increases, then resets back to zero at 10am. Perfect!