2 of 2 people found this helpful
You are correct that the PI SDK is on its way out.
AF SDK doesn't have the ability to access the PI Data Archive's message log at the moment.
In this case, we recommend using our PowerShell Tools for the PI System.
Here's a great post that should help you get started using the Powershell tools: Getting started with the new PowerShell Tools for the PI System
The particular command of interest to you is Get-PIMessage.
I haven't played around with this but it looks like you should able to execute PS commands from C# (if you are targeting a C# solution). More info here: Executing PowerShell scripts from C# – Keith Babinec's Development Blog.
Perhaps someone in the community has done this before can share their experience.
I guess I'll have to drop back to using the PISDK for now since I need to embed this functionality into a new product we are working on.
You'd have thought OSI would do a better job of it - addressing the message log prgrammatically isn't exactly obscure, and I wish they did more work on these things before releasing them. I have the same problem (I'm supposed to be future proofing an application) but I'm going to have to have a mismash of PI-SDK and AF-SDK because they didn't bother to do the job properly.
Hello Paul Booth,
I believe PI AF SDK offers great functionality and great performance but agree that there's a shortcoming when it comes to PI Message Log access.
We have just recently started a new initiative, called Uservoice where we collect enhancement requests publicly. You can sign in with your SSO account, post your ideas and vote for the ideas of others. We did that to be able to take data driven decisions when developing our products into the future.
I have taken myself the freedom to create a new enhancement request Expose methods to retrieve messages from the PI Message log to PI AF SDK on behalf of Jeff McMahon, you and possibly other users. Please allow me to invite you on adding a comment and voting for the request.
In my case it is actually writing to it that is required. However, once you get the message log interface in, I'm sure it will do both.
Because I missed that in my enhancement request, I suggest you add at least a comment about your requirement to write to PI Message Log through AF SDK.
Paul (et al.),
I am having some trouble with the List2 method of the MessageLog2 interface. What I would like to do is return the last N (say 10) warning (or worse) pi messages. I have some code that returns messages but I think I misunderstand the docs from the pisdk.chm.
The code segment looks like...
var piServer = sdk.Servers[server];
var m = (MessageLog2) piServer.MessageLog;
var messages = m.List2(null,DateTime.Now, count, "*", "*", -1, pisdkSeverityLevel.slWarning);
where the first parameter of the List2 method is the start date. The docs say...
If StartDate is set to –1.0 and EndDate and Count are valid, Count messages are returned ending with the EndDate. Messages are always returned in chronological order.
I have tried setting this parameter to -1, -1F, -1.0F, null etc. Null is the only value that returns any results (all others return a COMException suggesting bad argument). The results I see are the *first ever* 10 messages (starting in 2015).
Any suggestions on what the magic flag is for the start date ?
- I have tried changing both start and end dates,
- I have also tried 3 different versions of the PISDK including the recent 2016 release,
- I have only tried the 64bit pisdk,
- I have other implementations of List2 that return what I expect when I supply start and end dates as well as a count limit,
- I have a work around using "*-30d", "*", and -1 for count and using Linq to properly 'order' and 'take' what I am looking for but this obviously won't scale
Sorry for the delayed reply.
It seems like using the -1 parameter results in a bug where it tries to read that value as a date. There's an internal work item that's already created for the issue.
I can't seem to figure out a good way around this issue at moment so, unless someone else has another approach, I think you'll need to stick with your workaround for the time being.