Override output timestamp when the output is also input for the analysis
If the output of your analysis is also used as an input for the analysis, the option offset the output timestamp relative to the trigger time is grayed out and you see the message "Cannot override output time stamp if any output is used as an input within an analysis". This protection makes sense sometimes because you could cause unsafe triggering scenarios, but there are also valid configurations that are blocked by this. It would be good if there was some way to override this protection in AF in certain situations.
The PI Square post below also describes a similar use case:
https://pisquare.osisoft.com/thread/15971-cannot-override-output-timestamp-if-any-output-is-used-as-an-input-within-an-analysis
ADMIN RESPONSE
Aug 20, 2022
For this particular use case, you should be able to use the TagTot() function which executes at 6:00am with an output timestamp override for 5:30am. It's not clear why you're using output as input. Can you provide an example?
Input checking is a totally normal aspect of building any analytic, and so it should be expected this may be used for any type of analytic. For example, I have an analytic which takes a complex Digital input showing a unit's live operating status, (including many states such as Pretreat, Operation, Backwashing, CIP, Offline) and uses various system parameters to create a simpler filtered output status, with just two or three statuses. The unit does occasionally run in unexpected orders if it has been manually shut down mid-cycle, and so the analytic needs to check the current value of the filtered output status as part of its logic to ensure that it is stepping to a sensible filtered state that will enable KPI calculation. The analysis output time may be selected to correspond to the original status change time, or may be adjusted if a conflicting indicator is detected (non-zero flowrate, for example).
I have seen other cases where Analyses are designed to check some logic and then increment its output value, but have to send it back to the top of the current hour rather than the current timestamp. The analytic can only correctly increment the output value by reading its own previous output value.
Occasionally analyses need to check the last value of their own output, and occasionally they must override their output timestamp. Plenty of engineers do come up against this limitation (layer of protection), and then purposefully design around it.
One example of crazy time stamp shifting would be lab samples. Samples from the day before are tested some time, any time, later in the day or sometimes a few days later with the time stamp forced back to match the sampled time (i.e., using PutVal or DataLogger). The analyses need to wait for the samples to be entered, but then refer to them at the sampled time then apply it's override for final synching of the output.
Input checking is a totally normal aspect of building any analytic, and so it should be expected this may be used for any type of analytic. For example, I have an analytic which takes a complex Digital input showing a unit's live operating status, (including many states such as Pretreat, Operation, Backwashing, CIP, Offline) and uses various system parameters to create a simpler filtered output status, with just two or three statuses. The unit does occasionally run in unexpected orders if it has been manually shut down mid-cycle, and so the analytic needs to check the current value of the filtered output status as part of its logic to ensure that it is stepping to a sensible filtered state that will enable KPI calculation. The analysis output time may be selected to correspond to the original status change time, or may be adjusted if a conflicting indicator is detected (non-zero flowrate, for example).
I have seen other cases where Analyses are designed to check some logic and then increment its output value, but have to send it back to the top of the current hour rather than the current timestamp. The analytic can only correctly increment the output value by reading its own previous output value.
Occasionally analyses need to check the last value of their own output, and occasionally they must override their output timestamp. Plenty of engineers do come up against this limitation (layer of protection), and then purposefully design around it.