If you need the exact time range for each 10 mins, like 9:00, 9:10, 9:20, the offset setting is necessary. offset is not just tell the interface to fetch data several time later when arrive the scanning time, but will tell the interface to fetch the data on the punctual time.
For example, your source PI Point will have the data 9:00, and you need to calculate it and store this value. The result should be 9:00. And, this PI Point will have the value at 9:03, but this time, it is not necessary to be calculated. However, some time, PI server might need to restart or backup or some other issue. Therefore, we cannot be sure the PI server will run at the next punctual time and the PI Point will receive the data at the punctural time. Therefore, the first value of your PI Point might be at 15:07, and then, your PE will calculate it, and will calculate the future value every 10 mins after 15:07. Therefore, you need offset. If your setting of offset is 00:00:00, and scan frequency is 00:10:00, the PE will calculate the value at 15:10, not 15:07. This setting is the exact one to insure your timestamp at the punctual time as you expected.
first of all thanks for your esaustive reply. I'm checking the configuration file for PE (pipeschd): the scanclass is 'f=00:10:00,00:00:00'; so the offset is already setted.
Have you any other idea about the issue?
Attached you will find a tag configuration (scanclass = 17 is 'f=00:10:00,00:00:00')
Thanks a lot,
tagconfig.rar 7.0 KB
It can also happen that an interface is falling behind because scans cannot be completed in time. The same is valid for PI Performance Equation Scheduler. /Perf=<#> can be used in the startup file to define how often a performance summary is written to the log, where <#> is a placeholder for the amount of hours. E.g. /Perf=1 would output a performance summary once an hour. The summary is per scan class and is expressed as a percentage of skipped scans and scans on time. I recommend first checking with the PI Message Log on the PI Server if pipeschd might be falling behind from time to time (skipped scans).
If there are indeed skipped scans you may want to create an additional instance of PI Performance Equation Scheduler and move points over that are affected.
I will try Gregor, just a question: how many points (just an idea) a PI Performance Equation Scheduler can manage without problems?Thanks for your help, Marco
This mainly depends on how expensive / time consuming the equations are that you are doing and also how many executions fall into the same execution / scan.
Assume you have scan classes defined as follows:
and you have about 200 tags assigned to each scan class. This means that each 10 minutes 800 scans have to be performed at once.
This said, one can use the offset to do some load balancing or distribute tags between multiple instances of PI Performance Equation Scheduler. But still there's a chance scans cannot be completed in time e.g. in case single equations require retrieving millions of events from PI Data Archives like it is the case when calculating running hours over several years for the complete period with each execution. In such cases, creating event triggered calculated tags that only add the recently added portion (between 2 events), can help a lot because queries are executed a lot faster and you usually don't have to expect historical events changing.