Hugovdberg / PIconnect

A python connector to the OSISoft PI and PI-AF databases
MIT License
91 stars 41 forks source link

PIConnect OS Dependency? #537

Closed cmurph53 closed 3 years ago

cmurph53 commented 4 years ago

Background

I have been using this great module to quickly grab some data and have built my own functions for analysis (this is my first introduction to OSI Soft applications).
Initially built this on my Windows PC but have recently switched to MacOS systems.

Issue

I am now unable to access the server with this module (returns "TestingAF") even when I explicitly indicate the server and/or database. I've spent substantial time parsing through the documents but can't seem to find what I'm missing.
I understand that the PI SDK runs on 32- and 64-bit Windows platforms and provides access to servers on all PI platforms - am I unable to leverage this module due to my OS?

Example Script

with PI.PIAFDatabase(server='sname', database='dname') as database:
    print(database.server_name)
>>> TestingAF

/opt/anaconda3/lib/python3.7/site-packages/PIconnect/PIAF.py:89: UserWarning: Server "sname" not found, using the default server.
  warn(message=message.format(server=server), category=UserWarning)

Current System

Thanks for the support!

ldariva commented 4 years ago

As far as I know the PIconnect is just a wrapper for the AFSDK. So you need the AFSDK dll installed in you machine. You got it when you have OSI PI client software installed on it. I don't know if there is MacOS version for it.

Hugovdberg commented 4 years ago

The fact that you get the TestingAF server means the SDK wasn't found. In the early days not having the SDK raised an error, but that meant I could not perform any automated testing at all, since I cannot install it on the Travis servers. Therefore I turned it into a warning, and injected a testing SDK that does nothing, but at least provides the correct methods. I think I might have to go full Volkswagen and properly detect the testing environment in a way that outside the testing bench not having the SDK raises an error again ;-)

If you have the SDK installed on your mac than there might be an issue with the detection of the SDK location. Currently PIconnect looks for an environment variable PIHOME, and otherwise assumes C:\Program Files\PIPC as the default location, and then appends the path AF\PublicAssemblies\4.0. I have no idea what the path to the SDK looks like on mac, and even if this works for everyone on Windows. Some of these things were simply used because that's how it worked on my machine.

So there is no real OS dependency for the python package, but I don't know how it should work outside a Windows environment.

So the first question is: Do you have the SDK installed on macOS? If so, what is the path to OSIsoft.AFSDK.dll?

cmurph53 commented 4 years ago

@Hugovdberg Thanks for getting back to me!

I had the same assumption regarding the OS dependency, seeing as it is built within python.

I don't believe that I have the SDK installed on my macOS and I'm not sure that I can - on the OSI Soft website, under PI SDK Overview it states "The PI SDK runs on 32- and 64-bit Windows platforms and provides access to servers on all PI platforms".

I do still have access to the machine that I originally used and have copied over all of the AF files, including OSIsoft.AFSDK.dll.

Is it also possible for me to feed variables that specify additional information about the server in order to access it?

Hugovdberg commented 4 years ago

Combining the information from this StackExchange question and the AF SDK documentation, I think it will not work on non-Windows computers as it is built on the .NET Framework. Therefore the OS dependency is not dictated by PIconnect but by OSIsoft.

I'm not sure if it is possible to use other access mechanisms, such as a web API but for now there will not be MacOS/Linux support.

Hugovdberg commented 3 years ago

As there is no actionable issue with the PIconnect package I'm closing this issue. Should OSIsoft release an SDK on .NET 5/.NET core, which runs natively on MacOS and Linux the package might need an overhaul anyway.