# SCPI Control in Python Plugins **URL:** \ **Category:** Technical\ **Tags:** python, plugin, opentap-sdk\ **Created:** [August 7, 2021, 12:13am UTC](https://forum.opentap.io/t/scpi-control-in-python-plugins/421 "2021-08-07T00:13:10Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![arvind.sundararajan](https://avatars.discourse-cdn.com/v4/letter/a/ed8c4c/32.png) [@arvind.sundararajan](https://forum.opentap.io/u/arvind.sundararajan)\ **Post date:** [August 7, 2021, 12:13am UTC](https://forum.opentap.io/t/scpi-control-in-python-plugins/421/1 "2021-08-07T00:13:10Z")
I’ve been working on a custom UXA plugin in Python and would like to share some hurdles I encountered for SCPI control. As outlined in [this post](https://forum.opentap.io/t/creating-python-classes-derived-from-c-class/353), SCPI control of instrument plugins does not work the same way in Python as it does for C# and there are a few different ways to go about it. I’d like feedback from the community what the best approach would be moving forward for plugin developers, and possibly in the source code. As I understand it, the problem is that the `OpenTap.ScpiInstrument` class is abstract, so it cannot be subclassed by PythonNET as it can in C#, which is clearly how it should be used for C# plugins. This is already captured by this open Gitlab issue: [Make ScpiInstrument Not Abstract (#717) · Issues · OpenTAP / OpenTAP · GitLab](https://gitlab.com/OpenTAP/opentap/-/issues/717). As it suggests, it seems like making `OpenTap.ScpiInstrument` public would solve this entire issue and is the most straightforward: - Though the class is abstract, it has no abstract methods or properties, so it could be made concrete and any virtuals overridden by its subclasses as necessary. - Even its constructor is public, not protected, which is questionable since its constructor could never be invoked by a non-subclass anyway. But since there’s nothing abstract happening in the ctor it could safely be made public. - The pyhelpers approach offered simply derives `OpenTap.ScpiInstrument` to make it concrete. I used `OpenTap.Plugins.BasicSteps.GenericScpiInstrument`, which looks like it does the same. I went down a similar route as John and wrote my own Python SCPI wrapper around `OpenTap.Plugins.BasicSteps.GenericScpiInstrument`. I then subclassed this with my UXA plugin (with the longer-term goal of writing multiple higher-level instrument plugins), which I added as the instrument type for my test steps. But the wrapper feels like unnecessary extra work when SCPI functionality does exist in the C# SDK, but just can’t be used by Python. A couple suggestions for improvement are to change `OpenTap.ScpiInstrument` from abstract to concrete, or to add a Python `ScpiInstrument` wrapper to PythonTap which derives the Instrument plugin type already defined. It would also be helpful if there was a page on the OpenTAP Python page about SCPI communication for Python instrument plugins, explaining how to do so and any recommended approaches. ---
**Author:** ![arvind.sundararajan](https://avatars.discourse-cdn.com/v4/letter/a/ed8c4c/32.png) [@arvind.sundararajan](https://forum.opentap.io/u/arvind.sundararajan)\ **Post date:** [August 7, 2021, 12:14am UTC](https://forum.opentap.io/t/scpi-control-in-python-plugins/421/2 "2021-08-07T00:14:36Z")
@brennen_direnzo , @rolf_madsen , any thoughts since the last post about this? ---
**Author:** ![rolf\_madsen](https://avatars.discourse-cdn.com/v4/letter/r/43a26b/32.png) [@rolf\_madsen](https://forum.opentap.io/u/rolf_madsen)\ **Post date:** [August 9, 2021, 7:11am UTC](https://forum.opentap.io/t/scpi-control-in-python-plugins/421/3 "2021-08-09T07:11:27Z")
Not apart from what I wrote on the issue. ---
**Author:** ![john.berlien](https://avatars.discourse-cdn.com/v4/letter/j/ac91a4/32.png) [@john.berlien](https://forum.opentap.io/u/john.berlien)\ **Post date:** [August 9, 2021, 1:38pm UTC](https://forum.opentap.io/t/scpi-control-in-python-plugins/421/4 "2021-08-09T13:38:19Z")
I think there’s two things that could be done here. One is the GitLab Issue that Arvind references, that would be a good start. Being able to wrap around ScpiInstrument directly instead of GenericScpiInstrument would _look_ a lot better. The other is creating a “PythonScpiInstrument” that does what Arvind and I have talked about, which isn’t at all difficult, and including it with the Python plugin, both as an example of the “inheritance workaround” and others being able to directly use the SCPI functionality of OpenTAP in Python without _everyone_ having to write their own. ---
**Author:** ![brennen\_direnzo](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.opentap.io/brennen_direnzo/32/6_2.png) [@brennen\_direnzo](https://forum.opentap.io/u/brennen_direnzo)\ **Post date:** [August 9, 2021, 2:10pm UTC](https://forum.opentap.io/t/scpi-control-in-python-plugins/421/5 "2021-08-09T14:10:09Z")
I’ve submitted this issue here to cover this: > **[Add a Python ScpiInstrument wrapper to PythonTap (#37) · Issues · OpenTAP /...](https://gitlab.com/OpenTAP/Plugins/python/-/issues/37)** > > From discussion here: https://forum.opentap.io/t/scpi-control-in-python-plugins/421 and https://forum.opentap.io/t/creating-python-classes-derived-from-c-class/353 and related to this issue (with an alternative solution):