PicoScope 7 Software
Available on Windows, Mac and Linux
[Python] device class question
-
Christian B.
- Newbie
- Posts: 0
- Joined: Fri Mar 06, 2020 10:05 am
[Python] device class question
Hi,
After investing some time to write a wrapper for the ps2000a based on the ps2000aExamples I noticed that there is a device class. The README states:
picosdk.device.Device contains the concrete class which represents a PicoScope with a valid handle. It caches some information about the device state, like the currently selected voltage ranges of the channels.
The documentation of file states:
Definition of the Device class, which provides access to SDK functions which require a device handle, including capturing data and configuring the AWG.
But if I got it correctly this class is exactly what I was looking for. However neither the README text nor the DOCSTRING are really explaining that this class is "the way to go". The fact that anyScopeExamples is not really prominently present does not help either.
So here is my suggestion:
Clearly write in the README and the documentation that the device class is a good starting point and actually already deals with a lot of stuff which are else manually done in the psXXXXaExamples.
Another thing is that the device DOCSTRING states that there is the AWG functionality included but I do not see any related code for that. I would provide a patch but my knowledge of the API is still very limited right now. Is there an expert around which could give an estimation of how much effort would be needed to implement the AWG stuff for the device class?
best regards,
Christian
After investing some time to write a wrapper for the ps2000a based on the ps2000aExamples I noticed that there is a device class. The README states:
picosdk.device.Device contains the concrete class which represents a PicoScope with a valid handle. It caches some information about the device state, like the currently selected voltage ranges of the channels.
The documentation of file states:
Definition of the Device class, which provides access to SDK functions which require a device handle, including capturing data and configuring the AWG.
But if I got it correctly this class is exactly what I was looking for. However neither the README text nor the DOCSTRING are really explaining that this class is "the way to go". The fact that anyScopeExamples is not really prominently present does not help either.
So here is my suggestion:
Clearly write in the README and the documentation that the device class is a good starting point and actually already deals with a lot of stuff which are else manually done in the psXXXXaExamples.
Another thing is that the device DOCSTRING states that there is the AWG functionality included but I do not see any related code for that. I would provide a patch but my knowledge of the API is still very limited right now. Is there an expert around which could give an estimation of how much effort would be needed to implement the AWG stuff for the device class?
best regards,
Christian
-
Christian B.
- Newbie
- Posts: 0
- Joined: Fri Mar 06, 2020 10:05 am
Re: [Python] device class question
After looking into the wrapper for a couple of hours I noticed that there are plenty of repetitions on those files. E.g. 2000a.py, 3000a.py, and 4000a.py a very similar if one replace every 2000a/3000a/4000a with picodevice. What was the reasoning behind basically copy every single file instead of introducting a base class which is then derivated and overloaded accordingly by the different library types? And why the strange decision to first distinguish between the "drivers" instead of simply provide the device classes and a resource manager which allow to find, identify and select devices e.g. similar to pyvisa?
If there is interest in an overhauled version (i.e. the will to review/accept such a big pull request) and some export regarding the wrapper which could help me with some insights as well as testing I would like to volunteer to do the required refactoring.
If there is interest in an overhauled version (i.e. the will to review/accept such a big pull request) and some export regarding the wrapper which could help me with some insights as well as testing I would like to volunteer to do the required refactoring.