PI SDK is announced to become deprecated and hence we strongly recommend against using it with recent development efforts. There are only a few methods missing in AF SDK compared to PI SDK but AF SDK offers a lot more flexibility, better integration with .NET Framework and hence easier application development compared to dealing with COM objects plus bulk calls for data reads and writes. Please also note that some recent setup kits are shipped without PI SDK which means that the times are over you could expect PI SDK being installed on every PINS. What made you chose PI SDK?
Have you checked if the local PI Message Log or the PI Message Log on the PI Data Archive has additional information? I could imagine that the error is due to missing privileges.
Please post your C# code if it allows to reproduce the issue.
Hi Gregor, thanks for responding.
I know PI-SDK is deprecated but this is legacy software from 2003 and I do not have time to rewrite it to use AF-SDK (is that even supported from unmanaged C++?). All our current PI-related development uses .NET and AF SDK.
I checked the PI message log and the only related message (copied from SMT) just says:
[Server] 10.49.10.87 [ID] 6079 [Time] 19/01/2017 10:55:47 [Program] pibasess [Priority] 10 [ProcessOSUser] SYSTEM [ProcessID] 3748 [Severity] Information [Source1] Point Table
Point [Name: BHLW1~RTU_FAIL~PC~AI, ID: 6794] - Created by user GLOSDEV\tinklerj (userid: 12, cnxnid: 546)
The issue is not that the method does not work. It does work (see above), but because a meaningless error is triggered it is not returning the PIPoint object as documented.
Still working on the C# version, will post when finished.
Using C# and experimenting, I have discovered that this issue occurs with PI-SDK if either ptsecurity or ptgroup is among the point attributes included in PIPoints.Add(), and the specified PIGroup is one I have created myself. It is nothing to to with C++ vs C#. I can email the code if this would useful.
Remember that the PIPoints.Add() operation always creates the point with whatever attributes are supplied - but in the above cases an exception is generated, and the PIPoint object is not returned (which I need; though I suppose I could ignore that specific exception and then retrieve the point explicitly from PIPoints).
My settings are
ptsecurity = "genadmin: A(r,w) | g: A(r,w) | PIWorld: A()"
ptaccess = "o:rw, g:rw, w:"
ptowner = "genadmin"
ptgroup = "g"
The PIGroup "g" and PIUser "genadmin" do exist on the server, see image below.
If the group "piadmins" (the default) is specified instead of "g", no exception is generated.
Can anyone think of an explanation for this behaviour?
Now I will try it using AF SDK.
Using AF SDK in C#:
The same behaviour is exhibited (the point is created) but this time the exception when group security attribute is present is:
"Unexpected behavior. Expected Stream object count of 1. Actual object count (0) was returned"
Stack trace (down to main() program):
at OSIsoft.PI.Net.Stream.CreateStream(ClientChannel channel, String name, IDictionary`2 definition)
at OSIsoft.PI.Net.Stream.CreateStream(ClientChannel channel, String name, Tuples`2 definition)
at OSIsoft.AF.PI.PIMDAHelper.StreamCreateStream(ClientChannel channel, String streamName, Tuples`2 attrList)
at OSIsoft.AF.PI.PIServer.CreatePIPoint(String pointName, IDictionary`2 attributeValues)
at SDKCreatePoint.Program.Main(String args) in C:\Work\ProjectsNotInVSS\SDKCreatePointAF\Program.cs:line 89
Since this still doesn't work with (the latest - 2016 SP1) AF SDK, I guess this should now be submitted as a support request?
I get what is happening here - maybe.
My application is connecting to the PI server by trust as piadmin.
After creating the point with owner = genadmin(rw) and group = g(rw) (world no access), then the app cannot subsequently retrieve the point since it does not have access to it (piadmin is not a member of the "g" group). I guess that the Add method not only creates the point but tries to read it back again (to get all the attributes and return them to the caller?). But this fails with the COM error "point does not exist" since there is no equivalent in the COM to the -10401 access error.
If i'm right, then if I add piadmin to the "g" group it should all work. But it doesn't. Damn, I really thought I had it. After all, I can see the point via SMT (also connected via the same trust, as piadmin).
Actually it did work eventually, perhaps not the first time because of some caching? Anyway, problem solved.