Thank you for sharing the background of your question. I could imagine you've done this to get some feedback on the idea itself too.
It was at the EMEA UC in Paris a few years ago when I first heard Denis Vacher talking about how development had implemented an early version of future data. It surprised me that future data points were treated as a separate set of points supposed to co-exist with the historical points. But the reasoning made perfect sense to me.
I don't enjoy playing the role of an "always negative idea killer" because I understand myself as a rather positive human being. There are however some questions to consider but you may have found the answers to those for yourself already and developed a bulled proof concept covering your requirements. If this is the case, please reach out to OSIsoft Technical Support and introduce your concept. Ask them to escalate your support case to the PI Data Archive experts to receive their comments.
Where exactly do you see the issue with AF SDK? Is it with reading from the right collective member or is it with writing? Is it just you don't know how you are connected? Do you like to share a snippet of your code that does not work as expected?
1 of 1 people found this helpful
thanks for thinking with me. I must admit though that I do not completely understand what you are saying.
I don't want any feedback on the idea itself and I am completely on par with the idea that future datapoints are treated as a separate set of points.
I just want to copy old values of a PI Point from one collective member to another future PI Point on the same collective member because that is a requirement over here.
We simply must maintain the history of a PI Point and copy this history to a Future PI Point.
In the mean time, as how it always goes, I found the solution.
It took some time to figure it out but I succeeded.
What to do:
//Select the PI Collective
var sourcePIServer = OSIsoft.AF.PI.PIServer.FindPIServer(null, "mypiservername");
// Get the collective members
var collectiveMembers = from p in sourcePIServer.Collective.Members
// Loop through the collective members
foreach (var collectiveMember in collectiveMembers)
var values = sourcePIPoint.RecordedValues(timeRange, OSIsoft.AF.Data.AFBoundaryType.Inside, "", true);
if (values.Count > 0)
destinationPIPoint.UpdateValues(values, parameters.UpdateOption, OSIsoft.AF.Data.AFBufferOption.DoNotBuffer);
The initialisation of the source and destination PI Points is done previously.
Hope this helps for future stumblers of this requirement.
I read your posting with a lot of interest. I'm curious what your reasoning is for converting a historical PI Point to a future PI Point? Are you working with forecasts?
In addition, how many PI Points are you converting? Are you converting all your PI Points?
the reason for converting historical PI Points is indeed using them as forecasts.
The forecasts are now in a SQL database and loaded via an RDBMS interface.
Since future PI Points are there, we are in the process of converting these PI Points and retire the RDBMS interfaces.
We are definitely not converting all PI Points, because it doesn't make sense to store measured values in future PI Points.
1 of 1 people found this helpful
Thank you for clarifying about your use case and even more for clearly stating that it doesn't make much sense to store measured values in future PI Points. Please accept my apology for getting you wrong yesterday.
For everybody stumbling across this thread please note that we strongly recommend against mixing predicted and measured data in the same PI point.
I should have given some more context to why I want this. That was maybe my mistake.
I was just thinking in a technical direction too much.
Lesson for me for the next time I post a question here :-)