I am studying OpenTab and have the SDK up running. I would try to see how real-world resources are implemented. I tried to install ‘X-Series Signal Analyzers Spectrum Analyzer Commands(A.06.06v5)’ with success. Then I would look at the source code. I looked in Keysight.OpenTap.Plugins.ScpiNetInstrument.Ag90x0_SA_A_06_06v5.sln with Visual Studio
I don’t understand how this resource is working. There are some extreme large files (395000+ lines ). But nothing implementing the instrument base class.
Can I find some general documentation for these resources somewhere? Or can somebody explain how this instrument driver is made at a high level?
The ScpiNetInstruments are auto-generated instrument drivers, so might not be the best reference for understanding how instruments are handled in OpenTAP.
The Developer Guide gives a high-level introduction on Instruments:
Some examples:
The SDK/Examples include a few example instruments, e.g. SimpleInstrument.cs
The Demonstration plugin also includes a few examples, e.g. PowerAnalyzer.cs
Now I tried to have a look at a power supply driver. This was also an autogenerated type. Here I could find the class implementing instrument base class (6500+ lines of code) and now I understand these types of drivers.
In my world it is a must to use instrument drivers. 1. They isolate code that are specific for that instrument, always good to make logical separation of code. 2. They should make the steps smaller and simpler when steps do not need to handle instrument details. 3. They enable instrument interchangeability. The problem with these autogenerated drivers is the do not meet any of these requirements. They just provide a new way of writing SCPI Command. I will not recommend to using them.
From a grumpy old man.
@tch11 fair point. Those SCPI based Plugins are really designed for simple instrument control. They simplify a lot of the details of dealing with SCPI such as the string handling, VISA layer, and parsing, but for more complex tests, they are not the recommended solution, I agree.
@tch11 - when you think about a driver, how many commands do you typically have in a driver? Do you have an example that you could share for a driver that makes sense to you? You could share it in a DM / email if privacy is important.
Also, what sort of instruments are you working with? Are they simple or complex (power supply vs Network Analyzer for example)? When you talk about interchangeability, do you have just a couple different models that you are interchanging with, or need to support “all Network Analyzers that exist”?
The project we are looking into will use MXG RF generator, MXA RF Analyzer, Programmable power supply, some none VISA/SCPI items (CLI). I think we are going to develop the drivers ourselves . When doing so we will only develop support for instrument features we need. We will try to make the instrument interfaces high-level; this will also ease interchangeability. We will not need interchangeability from the start. But it will come. And it will be so much easier to prepare it from the start. Does anybody know if there is instrument plug-ins that are not of the autogenerated type?
Ps. I know about the IVI instrument classes. Sorry that is another discussion
@tch11 yes, many people do the same, with just implementing a subset of the functionality. Many haven’t open sourced them yet, so there are not tons of public examples, but here is one for the MXG specifically:
You’ll notice there is also an ISg interface class in that project that will allow of interchangeability of instruments:
). But nothing implementing the instrument base class.
. When doing so we will only develop support for instrument features we need. We will try to make the instrument interfaces high-level; this will also ease interchangeability. We will not need interchangeability from the start. But it will come. And it will be so much easier to prepare it from the start. Does anybody know if there is instrument plug-ins that are not of the autogenerated type?