I thought I could use AF Analyses to write data with a futur timestamp but there is no fonction to do that (even to write data in the past with an other timestamp than *) ?
In version 1, the output time stamp = trigger time stamp. We do have several customers asking for an enhancement to allow users to configure output timestamps. That's on our future enhancements list.
Meanwhile, can you better describe what you're trying to do? (What your application does?) Perhaps there are workarounds that's suitable for you.
Thank you for your answer.
We work on a project with the objective to calculate forecast consumption and linepack.
We know that AF Analyses allow us to do that and I am trying to make a prove on concept using Dolorean to put data in the futur.
Do you know if this enhancements will be in the AF 2.6.1.x version planned in Q3 ?
This feature will not be in AF 2.6.1, but rather in a future version.
You can trick the current version of Abacus to write to future timestamps of PI Points though.
The list of fix and enhancements is avalaible ?
The list of enhancement requests is quite long and since we prioritize and re-prioritize often, we don't publish the entire list as priorities change. Right now, for AF 2.6.1, one major feature would be steam tables, along with many bug fixes. The entire list of fixes and enhancements will be made available when the product releases.
The list is kind of available. Please visit OSIsoft Technical Support and proceed to Search Knowledge Base and further to Known Issues. There are 2 tabs, "Known Issues" and "Enhancements". Select "Enhancements" and "PI AF" from the Product ComboBox. There are additional filters for version and severity. Please note that there are as well internal "Known Issues" and "Enhancements" that you will not see.
I'm quite interested in learning about your trick. Dirty tricks are always available, but if you could enlighten us on your probably neat trick?
It is an undocumented feature so use at your own risk, it may get changed in a future Abacus version.
You have to use a future tag as the output for an Attribute otherwise the future timestamp is rejected, obviously. You know that mysterious "RelativeTime" field in the PI Point DR configuration screen, well if you specify an offset into the future then the output from your Abacus expression that writes to that Attribute, it's timestamp is adjusted by that offset: so if your schedule is periodic every 1 hour, the output attribute has a +7d offset specified then your next scheduled output will actually be + 7 days into the future from the event time. You can quite easily write future data with Abacus + DeLorean. For example, you would probably keep the attribute with no offset specified as the top level attribute and if you're calculating some forecast data then you would probably add child attributes referring to the top level attribute with the required offset specified in each child and explicitly refer to those in your expressions - e.g. name your variable "Forecast1Day" with an output variable of "Attribute|Attribute1DayForecast". Of course this means that you have to know your forecasting structure upfront to represent it as an Attribute hierarchy. It would be much better to control the output timestamp directly rather than indirectly.From memory it even works with backfilling.
Sigh.... I'm going to tell tech support to bounce all calls to you now. I think I have your mobile number here somewhere....
It is not as if anyone can use this in production, until DeLorean is released, so you have plenty of time to patch it.
Yes, it is a goal is to deliver another version of Abacus / AF Analyses that does not require use of such an unproven trick. As stated earlier, there are definitely other good use cases besides future data for controlling the timestamp of the output - this feature just did not make the cut for AF 2.6.
Apologies for my late reply. Thanks very much for your idea. The RelativeTime property is very handy, and i use it a lot. Especially as you can use that to lookup the time from another attribute which can determine some specific time logic. In the past i've used a custom DR to give me all kind of points in time yesterday, tomorrow, last month, begin of year, etc.
Just never tought to use that on an Abacus analysis! For persistence, DeLorean is needed, but for ad-hoc stuff this already works. So if the logic for determining future data can run in realtime this will already work today. It's quite an elegant idea, and looking at orthogonality why shouldn't it work with Abacus too?
But i agree with the OSIsoft guys that theory is something different than tested and supported scenarios! I'll call RJK Solutions for support on this. :-)
Retrieving data ...