4 Replies Latest reply on May 5, 2009 5:38 PM by spilon

    SDK calls in Excel / DataLink


      VCampus as far as I am aware allows us to develop applications using the SDK - with similar kind of rights as with the old PI-DAP software toolkit. But it requires a GUID key to register your application for use against a production PI Server?


      Can you confirm whether it is OK to make SDK calls from within existing PI Clients, such as ProcessBook and DataLink without the need for such registration. These clients will already be connected to the PI Server, so the additional calls are piggy backing onto that existing connection. I ask because the PIPutVal macro in DataLink, for example, does not allow annotations to be written, requiring some SDK calls to include this functionality. Also, the batch reports that are given as examples from OSI all use SDK.


      Technically I know that this is not a problem, but from a legal point of view can users make SDK calls inside the PI Clients?

        • Re: SDK calls in Excel / DataLink

          Have you seen Steve's response to a similar issue?



          • Re: SDK calls in Excel / DataLink

            Thanks for the important question. One part of the answer that is not variable is that vCampus provides development rights with our various programming interfaces and one needs the appropriate license to deploy/distribute the developed applications (PI Data Access Package [DAP] or PI Data Access [DA] Module, as you pointed out).


            As for your "real" question (PI SDK code within PI ProcessBook or Microsoft Excel with PI DataLink), it depends on the Software License Agreement (SLA) one has with OSIsoft, so I invite you to review it and talk to your Account Manager if need be. If you don't know who your Account Manager is or need additional details regarding your organization specifically, please do not hesitate to contact us at vCampus@osisoft.com directly - it will be a pleasure to help you find the right information.

              • Re: SDK calls in Excel / DataLink

                I work in the PI Support Teams in a number of different companies.  I don't develop "products" or "applications" as such.


                What I do do, in the context of their support teams, is knock together various bits of VBA code that use the SDK in Excel/ProcessBook.  For example writing tools in excel that will help build/compare tag lists.  Or writing a bit of VBA in ProcessBook to allow them to enter a value into a PI tag.  Simple stuff that makes supporting the PI system easier and provides a little bit of user functionality.


                To be absolutely certain, are you saying that the "legality" of this would depend precisely on what License agreements the particular client has with OSISoft?  For example would it be legal for a client that has bought a simple "vanilla" PI server with DA and a couple of interfaces?


                Also, when this gets enforced by the PI Licencing system, would it mean a new GUID for every little bit of code I write?


                I would guess that most people who support the PI system have, at some point, knocked together bits of code to help them do their job so this is likely to be a big issue.





                  • Re: SDK calls in Excel / DataLink

                    Ian Gore

                    are you saying that the "legality" of this would depend precisely on what License agreements the particular client has with OSIsoft


                    Yes, absolutely. Although the majority of the current SLAs do allow that.


                    Ian Gore

                    would it mean a new GUID for every little bit of code I write?


                    No. In fact you cannot use your own GUID in this context. Remember you are leveraging the PI SDK connection(s) already established by PI ProcessBook or PI DataLink and these have their own GUIDs (OSIsoft GUIDs, that is).


                    If you ever come accross an SLA that does cover that of usage, simply contact your Account Manager and request an amendment to the SLA; we have a standard, no-cost, new product admendment that will update all definititions to allows that.