7 Replies Latest reply on Jun 20, 2014 8:48 AM by Gregor

    Recalculation PE no modification timestamp

    marco.zoccoli

      Hi all,

       

      Is there a method to recalculate  values of the last day  for a tag (PE):

       

      - once a day

       

      - without change on timestamps, but only on values

       

      for example, a tag with hourly scan class:

       

      45 at 01:00:00 of 02/06

       

      28 at 02:00:00 of 02/06

       

      ...

       

      34 at 23:00:00 of 02/06

       

      21 at 00:00:00 of 03/06

       

       

       

      At  7:00:00 of 03/06 I would try to recalculate values for this tag, from 01:00:00 of 02/06 to 00:00:00 of 03/06, without changes on timestamps, but only on values (if necessary).

       

      Regards,

       

      Marco

        • Re: Recalculation PE no modification timestamp

          Hi Marco,

           

          Please look into the PI Server Application User Guide for PI Performance Equation Recalculator.

            • Re: Recalculation PE no modification timestamp
              marco.zoccoli

              Hi Gregor,

               

              thanks for your feedback. I am trying with some points to realize the recalculation, but I have a question: if a PE is recalculated on PI Source with PI Performance Equation Recalculator, can I set a tag on interface PItoPI on PI Destination that received all the changes provided on tag on PI Source?

               

              I am thinking to set something as "History Recovery"  form PI-ICU, but I do not know all the parameters to change.

               

              Thanks,

               

              Marco

                • Re: Recalculation PE no modification timestamp

                  Hello Marco,

                   

                  Replicating recalculations via PI-to-PI increases complexity. I am 83% sure this would work but I suggest configuring the PI to PI destination for archive data collection (Location4 <> 1) instead of using history recovery. I am not sure if Location5 (archive write mode) should be 2 or 4 but don't expect a big difference with pure archive data collection. Since my understanding is that you will not want compression being applied, please make sure /DC is not set to something else than zero (/DC=0) if specified within the interface startup file.

                    • Re: Recalculation PE no modification timestamp
                      marco.zoccoli

                      Hi Gregor,

                       

                      seems that, only when the scanclass of tag PItoPI has been setted to 1 (scanclass signed for exception only) we can have the replication of recalculation. Location 5 should be 2 or 4 indifferently; so no compression is applied and /DC parameter is not setted in the interface startup file.

                       

                      Can I change another parameter on PI-ICU and/or on tag?

                       

                      Regards,

                       

                      Marco

                        • Re: Recalculation PE no modification timestamp

                          Hello Marco,

                           

                          When recalculating PE Recalculator substitutes existent archive events. This is not generating Snapshot updates (exceptions). I may be mistaken but my first attempt would be setting up PI-to-PI tags for archive data collection (scan class <> 1).

                           

                          There are many screws to drive. Please take my suggestion as a configuration to start with and if you don't get the expected results, please consult the PI-to-PI Interface manual.

                            • Re: Recalculation PE no modification timestamp
                              marco.zoccoli

                              Hi Gregor,

                               

                              On PI ICU we found on this path: PItoPI ---> Optional, this option: “Specify maximum events to retrieve for a single point in each call to get history”. We looked for information on the PItoPI manual e we found this explanation:

                               

                              “This parameter is available for PI 3.3 or higher receiving servers. If checked, the user may supply a maximum number of events to retrieve for a single point in each call to get history. With each call to retrieve history, one call is made to put it into the receiving server. At lease one of these calls will be over the network, so using a small number could result in performance problems. The command line equivalent for this flag is /mh=x, where x is the maximum number of events to retrieve per point per call.”

                               

                              Can this parameter influence the automatic updating of PItoPI tags (when the relative PE had been recalculated) and does it determine the number of values of PItoPI tag which can be affected by this automatic updating?

                               

                              Thank you,

                               

                              Marco

                                • Re: Recalculation PE no modification timestamp

                                  Hello Marco,

                                   

                                  To my understanding /mh applies when running PI-to-PI in history recovery mode. Is this what you plan to do or do you intend running the interface continuously and transfer archive updates to the destination?

                                   

                                  With the settings I suggested, I expect PI-to-PI Interface to sign up for archive updates with PI Update Manager. This way the interface should be able to substitute events on the destination when events on the source become substituted by PI Performance Equation Recalculator. Have you tried the suggested configuration?

                                   

                                  As mentioned before, there are many screws to drive but you need to start somewhere and see what happens. If results differs from the expectation, try to understand the difference and consult the manual to see if there's a switch that allows changing the behavior. I further suggest testing with a single tag first and add additional on success in smaller chunks.

                                   

                                  To answer your question, /mh just specifies the maximum number of events per tag retrieved within a single cycle. Hence I consider this switch more related to performance tuning rather than impacting functionality.