SCPI Control in Python Plugins

Technical
, ,
1

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, 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. 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.

2 Likes
2

@brennen_direnzo , @rolf_madsen , any thoughts since the last post about this?

1 Like
3

Not apart from what I wrote on the issue.

4

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.

1 Like
5

I’ve submitted this issue here to cover this:

2 Likes