SCPI: How popular is it among you?

[Bicurico]

Hi,

I am contemplating the implementation of SCPI to my "VMA Simple Spectrum Analyser" software, which is available in versions for SMA/NWT/D6/LTDZ, Siglent SSA, HP 859X and R&S CMU200/CRTU.

The idea would be to implement a telnet server on a given port, where the user can talk to the software with SCPI commands.

Obviously, implementing this is a lot of work. The main reason of doing it would be for educational purposes: my software can be used by students on cheap devices (<100 Euro) and having support for SCPI sounds interesting to me.

But I wonder, how popular SCPI really is among professionals using test equipment? Do you write your own scripts with SCPI commands? Do you use it a lot? Or is SCPI only used by few of you and only to capture the data to i.e. Excel?

Would you program scripts in VB or Matlab, using SCPI as a standard interface?

Any further comments on this?

Thanks,
Vitor

[RoGeorge]

It's the de facto in the instruments industry.  SCPI can be implemented over different interfaces, I've seen it over GPIB, Serial, USB, LAN or WiFi.  Since you thought about telnet, I guess you plan to go with LAN.  You may want to read about LXI, VISA, VXI11, maybe to IVI, too, which is the highest abstraction level, at IVI level one doesn't need to know the model/manufacturer of an instrument, only the class.  I didn't check, but I guess there is a VNA class defined already  <-- no VNA class here https://www.ivifoundation.org/specifications/default.aspx , might be good, though IVI might only make sense in the industry of automated tested, not for a small VNA.

If your instrument has Linux, that would be a great plus, you'll have most of the components ready as libraries.

There are a few open source projects already, might be of a great help than starting from scratch.

[Wolfgang]

Implementing SCPI depends on the level of perfection required.
If you leave out all the syntactic sugar it can successfully implemented on AVR Arduinos without problems.

See here:
https://electronicprojectsforfun.wordpress.com/homebrew-scpi-controllable-instruments-with-arduino-controllers/

For controlling this (and other brands like Rigol, Keysight, Tektronix or R&S) I use VISA and Python. That works really well.

[free_electron]

When implementing SCPI : go read the documentation first. Don't just start inventing new commands. Think about what to put in what branches of the tree. ( many branches are defined).

That being said : been using SCPI since the 90's. First on 34401 and Keithley 2400 machines later on all kinds of stuff.
do implement the * commands as well.
Other very important commands :  the one where you can retrieve an entire setup as a single command string to send it back. This basically lets you fetch the entire current configuration of the device as a single ascii string. You can later send that back to the device. this is very useful when creating programs. you can set up the machine using the front panel and once you got it exactly set right simply 'capture' the state. That works better than trying to figure out the entire sequence by sending commands one by one.

[pigrew]

SCPI is the standard, and what I use for most instrument communication. However, it is uncommon to implement it over telnet (some devices do like Siglent).

Lately, I've been using python for instrument control, but in the past have used C#, C, LabView, and HP Vee. These mostly use the VISA API to communicate with the instruments. I compose the actual SCPI commands in my software (and don't have experience using the IVI driver abstraction models).

Instead of telnet, I'd suggest using HiSLIP v2 (which includes security provisions), or VXI-11. These will more seamlessly interact with the VISA libraries than telnet does. VXI-11 might be trickier to implement, since it requires a Sun RPC server...

(For fun, I implemented VXI-11 in python, though I never actually did anything with it... my plan was a VXI proxy for instruments that did not natively support USBTMC, VXI, or GPIB....).

[rcjoy]

For a LAN connection, SCPI via the VXI-11 protocol would be the standard.  SCPI via telnet is useful for debugging, though.

[TiN]

Strange question, since SCPI is used nearly by everyone for programming\communicating with instruments made in last 30+ years. Some instruments have proprietary protocols, but those are tiny minority in T&M market.

Using SCPI and other older protocols daily with Python scripts and remote programming experiments.

[boB]

We are writing some Python code to control Power supply, Multimeter and relay board over USB.

Seems that SCPI is necessary for this.  Simple enough.

boB 🌜

[Berni]

SCPI is the industry standard.

Most test equipment you find on the market uses it. Might not be the most elegant protocol but it works well. Being a very simple protocol also makes it easy to implement while also easy to debug as it is just human readable text.

Just make sure you read up the documentation of a similar modern SCPI instrument beforehand. That way you can use the same commands in the same way to be consistent. This allows the same software to be compatible with multiple instruments.

[RoGeorge]

SCPI has only a handful of required standard commands, for example '*IDN?', or '*RST', etc.  Most of the other commands are specific to each instrument, and not described by the SCPI standard.  The syntax of a command, and how to respond to commands is described completely by the SCPI standard, but the commands themselves are almost never the same between different manufacturers.

Only at the very top protocol, in IVI, all SCPI commands, from all the instruments of the same class, are translated by an IVI driver into standard commands that will control any instrument of the given type, no matter that power supply is from Keysight or Rigol. 

The IVI layer is done on the computer end.  The instrument only speaks SCPI text, wrapped in different other layers depending on the physical interface, for example LXI for LAN vs USBTMC for USB.

I've read once a PDF were it was described the state machine to interpret SCPI commands, it was described with enough details to implement SCPI in a new instrument.  Can not find it right now  , not sure if it was in one of the SCPI standards PDF, or from some other source.  Will post it if I can find that again.



Later edit:
-------------
Not the one I was looking for, but close enough https://www.ivifoundation.org/docs/scpi-99.pdf from this page at IVI foundation https://www.ivifoundation.org/specifications/default.aspx.



Later later edit:
--------------------
It looks like no VNA instrument class is defined at IVI  , only these:

Instrument Classes:
IVI-4.1: IviScope Class Specification    Word    PDF
IVI-4.2: IviDmm Class Specification    Word    PDF
IVI-4.3: IviFgen Class Specification    Word    PDF
IVI-4.4: IviDCPwr Class Specification    Word    PDF
IVI-4.5: IviACPwr Class Specification    Word    PDF
IVI-4.6: IviSwtch Class Specification    Word    PDF
IVI-4.7: IviPwrMeter Class Specification    Word    PDF
IVI-4.8: IviSpecAn Class Specification    Word    PDF
IVI-4.10: IviRFSigGen Class Specification    Word    PDF
IVI-4.12: IviCounter Class Specification    Word    PDF
IVI-4.13: IviDownconverter Class Specification    Word    PDF
IVI-4.14: IviUpconverter Class Specification    Word    PDF
IVI-4.15: IviDigitizer Class Specification    Word    PDF

Source:  https://www.ivifoundation.org/specifications/default.aspx

[Berni]

Then again a VNA is pretty close to a spectrum analyzer so you can probably present yourself as one of those and add in some signal generator commands for setting up the stimulus.

In any case it is the easiest to just take the SCPI manual of a existing modern VNA instrument and copy all the most important commands. The modern stuff already adheeres to the standards.

You don't need to copy all the commands since they are not mandatory, but the more you implement the better compatible you are. For any proprietary stuff it is also fine to add in your own commands, just avoid any of the common names used by SCPI to be sure.

[tv84]

Guys, I think Vitor is mainly looking for your feedback regarding the use of such feature (SCPI).

Do you use or not? Frequently or not?

Those answers may provide him the impetus to embrace such task.

[RoGeorge]

Maybe adding a poll might be the right way to find out usage statistics.

Not sure if I understood the situation from the OP.  SCPI alone in a program doesn't make much sense to me, because one needs to know the instrument very well to take advantage of it.  I wouldn't know how to present to the user an interface to SCPI and to a program at the same time (without asking the user to write code).  Then, on the PC side, all the components are in place, it only remain to glue them together.

Also, SCPI alone is nothing, has only about 10 commands standard, about interrogating the status of the instrument, while any average instrument has hundreds of SCPI proprietary commands.  Not much is standardized, except the syntax and how to process/answer the command.  SCPI needs many other layers and protocols to make it useful while remote controlling an instrument, and the only thing that could make SCPI interchangeable is the IVI layer, AFAIK.  Otherwise, each instrument has its own set of SCPI commans that must be known by the user in order to make use of those commands.



To answer the title, yes, I'm using SCPI sometimes, but I've used as well Modbus from my DMM that doesn't know SCPI, or sent text over COM ports, or set variables in a embedded Linux over SSH (PlutoSDR), etc.

For the SCPI alone, it's standard, though many of the electronists or hams might not want to get dirty with any kind of remote controlled instruments, except if it were to be a simple program, with a clean GUI and no tinkering.

- Those who like to tinker with software, will tinker no matter it's SCPI or something else.
- Those who don't like programming will want the nice GUI, and don't care what's under that.
- SCPI by itself has no particular advantage for a small VNA/hobby usage, can be whatever.
- SCPI is a must have for automated testing in an industrial setup, or for instruments present in a research lab.  Might be a plus when marketing a product, too.

[free_electron]

the advantage of scpi is that it is plaintext, human readable., and can be transported over whatever and controlled from whatever. it doesn't matter.

[Berni]

Guys, I think Vitor is mainly looking for your feedback regarding the use of such feature (SCPI).

Do you use or not? Frequently or not?

Those answers may provide him the impetus to embrace such task.

Well everyone is saying that SCPI is the way all test equipment is controlled by automation. So if you are to add automation support for your instrument, then SCPI is indeed the best way to do it. As soon as you do something proprietary you make things harder (I am looking at you shitty serial port remote control instruments that use a weird serial protocol that seemingly had its spec made by a monkey randomly hitting a typewriter, then once implementing it in your code finding it sometimes randomly stops working for no damn reason). Also if i need to call a special proprietary DLL using a special driver to talk to an instrument you have failed.

Me personally i have used SCPI on >50% of all the test equipment i own. Any sort of more involved test setup that involves collecting a significant amount of data benefits from being automated. Manually stepping trough long tests by twiddling knobs and typing things into an excel sheet gets annoying pretty quick and often makes worse test results. Computer have better timing control than a distracted human that is watching a youtube video in an attempt to not get bored during a 1 hour long test. Computers can also collect points a lot faster, making for a finer resolution graph.

Educational is also a reason to use SCPI since it makes talking to the instrument look like talking to a real VNA (the ones that cost as much as your car cost when new and is so heavy you ask another person to help you move it).

[Gribo]

I definitely use SCPI, and in the OP case, I would grab any Keysight VNA programming manual, and use it as inspiration.

[Bicurico]

As tv84 correctly said, I am at this point just trying to figure out how popular SCPI really is. If it is a standard most professional users of test equipment use, then I might indeed consider implementing it.

I understand that SCPI has only few standard commands, a standard logic/syntax and that all other commands are specific to the equipment and thus a manual is required.

What I don't know is how probable it is that people in labs will actually hack a script to interface the test equipment via SCPI, for example to automate some measurements.

The reason I am thinking about this is because a user of my software asked if my software has any scripting or macro language to automate measurements. I never thought about it!

While wondering how I could implement something like this, it hit me that implementing SCPI over telnet would be fairly easy to implement (though a lot of work). This would have two positive outcomes:
A) You could indeed automate measurements with my software through SCPI.
B) This could be a nice feature for education, as you could learn about SCPI using a cheap LTDZ device.

If I implement this for the cheap LTDZ type of devices, I could easily port it to my Siglent, HP and R&S versions. This would be odd, because my software itself interfaces to these devices through SCPI! But my implementation could add SCPI commands for measurements or functions that the original device does not offer.

At the end of the day, this is my hobby and I find this a cool idea for the sake of it. I just wonder how popular this function would be, mainly for point B) above.

Thanks for your input so far.

Regards,
Vitor

[RoGeorge]

That would be very unusual.  The problem is that SCPI is not a language.  It does not have comparison, decisions, loops, variables, functions, nothing.  SCPI was made for physical instruments, to send imperative commands only, and to receive some data.

SCPI means the instrument can be controlled by text commands, not only by physical buttons.  Browse the pdf I've linked before, SCPI-99, to see what it is about.

My recommendation would be to choose an already existing language for scripting.  Nobody would want to learn a weird definition of yet another language defined by SCPI commands.  Would be cumbersome and unwanted.

Use something small and open, like TCL, or Lua.  If you want to be popular, use Python.  Anyway to talk from a computer program to an SCPI capable instrument you don't need to implement anything about SCPI.  The program just pass the SCPI string to the instrument.  The PC program side needs to implement VISA, or else it could as well just open a TCP/IP socket and send the text.  (though there are already many FOSS implementations, it would be a waste of effort to re-implement VISA).

SCPI is not for scripting, is for plain text commands only.  Any scripting language can handle text, so you can pass that to any SCPI instrument you may have connected to your PC program.  SCPI is for the instrument side, that is where the text command are parsed.

[free_electron]

My recommendation would be to choose an already existing language for scripting.

i vote for VBscript. Any other language is crap, especially anything that requires semicolons , curly braces or indentation.
Let the flamewars begin !
come to think of it, simply implement HP's instrument basic.

that's the thing with SCPI. it is NOT a language. It is an API. an API that is language agnostic (apart from english. God forbid we start making french or german SCPI... :mesure:voltage:courent direct  ... :mess:wiederstand:vier drate )

[Bicurico]

I may have not explained well what my intention is.

I do know what SCPI is, how it is defined, etc. In fact, my software communicates through SCPI to the supported devices!

And yes, it does not make much sense to use my software through SCPI if you want to talk to a device that is already capable of receiving SCPI commands itself. But that is not the point.

The point, to start with, is: let's take this cheap chinese SMA/NWT/D6/LTDZ devices, which are capable to work as a spectrum analyzer with tracking generator. They implement a really poor protocol and are not shipped with an endorsed software to actually use them. So I made my own software, which turns theses devices into spectrum analyzers, at least function wise (they lack accuracy, user selectable RBW and many other issues).

If my software would include SCPI functionality, you could control these device without having to rely on the original protocol, which is hardly user friendly and which does not do any measurements: it just dumps the sweep data in some odd format.

My software would, through SCPI, dump a real sweep in dBm, for instance. Or you could toggle TG on/off, or carry out some measurement or function of my software.

If you then send/receive SCPI commands/data through your preferred scripting language, you can do automated measurements, without me having to implement some "yet another scripting language".

This way automation would be possible and people could learn how to use a test equipment through SCPI, without having to purchase a "real" test equipment.

My original question could be refrased: "Is it, in 2022, useful to teach students about SCPI for accessing data from test equipment and automating measurements?"

On a side note: I have no clue how to develop a software in Visual Studio .net and incorporating a scripting language like VBscript or Python.

[RoGeorge]

Totally makes sense to write such a SCPI bridge/driver/however you decide to call it.  Make it run as a standalone, you might even sell it independently from the big VNA program you already have.  Then, your existing program will use the SCPI bridge you just wrote just as if it would talk to some native SCPI instrument.

In this case, I would just make a bridge, from SCPI to whatever else those small instruments are using.  More tempting for me would be to make it is as a standalone "SCPI driver/bridge", so it can work without of the other VNA/GUI program, so the user would be able to use the small VNAs on any OS and with whatever other program or language they wish.

This wouldn't cover any scripting for your existing VNA program, that's up to you to implement however you find it suitable for what you already have in the big VNA program.  I'll be tempted to write just a wrapper for the most important functions that you already use, document it a little, and let the user call them from whatever scripting language prefers.  Though I'm not a programmer, I might be wrong with the wrapper interface, IDK.

As a side note, the DMM I've mention before with only Modbus and no SCPI (it's a Metrix MTX3238 from Chauvin Arnoux), has such a SCPI to Modbus bridge as payed software.

[Berni]

I hate products that include a scripting language as the only form of automation.

Doing that forces the user to implement whatever they are trying to do in that language. The user might not even be familiar with the language and so they have to learn how to use it in the first place.

Labs generally write there own SCPI automation software for running the particular test. This can be done in any language under the sun. The use of NI LabView is also quite popular for doing this, in fact it is so industry widespread that they can charge a few grand for a yearly subscription license. I always found labview horrible personally. I prefer using C# instead (i know it, has a good IDE, runs fast, handles lots of data easily, can easily make a interactive GUI with pretty looking live graphs etc..)

The great thing with SCPI is also being able to swap out instruments. I often reuse my scripts with
different instruments. Things like DMMs, PSUs, Electronic loads..etc tend to be nicely standardized, so i can just swap it out and it works without any changes to the script(Like maybe the little 300W BK Precision load is not cutting it so i swap it with the big boy Agilent 2kW boar anchor). As soon as you do something proprietary like a special driver DLL or a built in scripting language this is no longer possible to do.

All i have to do is import the VISA DLL into my application. Suddenly using just a few lines of code i can talk to pretty much any piece of test equipment. It does not matter if the eqipment is using GPIB, RS232, USB, Ethernet, GPIB on a GPIB to Ethernet bridge...etc. Heck the instrument might be on the other side of the building on wifi. My application just says what instrument it wants to talk to and it magically connects. As a nice bonus the Keysight IO implementation of VISA also has a nice debugger window where you can spy on the SCPI traffic running over any of these interfaces while your app is running. This comes in very useful in tracking down bugs. Using Keysights VISA DLL is not limited to Keysight gear, it works with all other vendors (just has some extra features for keysight gear, like showing pictures of instruments and suggesting commands)

[pdenisowski]

My original question could be rephrased: "Is it, in 2022, useful to teach students about SCPI for accessing data from test equipment and automating measurements?"

Having worked directly with test and measurement instrument customers for almost 25 years, my answer would be "yes, absolutely"  If anything, I would say the importance of SCPI has been increasing, not decreasing, over time.

A basic knowledge of what SCPI is and how to use it should be part of every EE's training:  the "return on investment" for learning SCPI is, in my experience, quite high and it's also a very portable skill.  My feeling is that anything that introduces students to SCPI early in their engineering careers would be very helpful.

[free_electron]

My original question could be refrased: "Is it, in 2022, useful to teach students about SCPI for accessing data from test equipment and automating measurements?"

absolutely, especially since it takes like 1 minute to learn...
here we go
- it's a tree structure. you descend down a branch to execute an operation
- a fresh command begins with : and anytime you switch branches there is another colon. example :measure:voltage:dc. if the fist character is a : we go to the root. it works like a directory structure , except slashes we use colons.
- to stay in a current branch but send more than one operation use semicolon
- if an command takes arguments use a space to separate them
  example :source:sweep:start 1khz;stop 10khz     [:]new command , [source] descend into source branch , [:sweep]descend into sweep settings. [start 1Khz]set parameter start to 1khz,[;] stay in current branch] [stop 10khz] set parameter stop to 10khz
- to read back , append a ?

that's it.

[pdenisowski]

As a nice bonus the Keysight IO implementation of VISA also has a nice debugger window where you can spy on the SCPI traffic running over any of these interfaces while your app is running. This comes in very useful in tracking down bugs.

This functionality (being able to "sniff" the SCPI commands) is actually becoming fairly widespread among test and measurement instrument manufacturers.  Some instruments even have a web-based interface that allows you to display and save all SCPI "traffic" regardless of where it's coming from or which VISA implementation is being used.  And some instruments will log SCPI activity locally to a file on the instrument as well.

Another useful feature you'll find on some vendors' instruments is a "SCPI recorder" that monitors what you do via the GUI and then creates a text file with the corresponding SCPI commands -- saves a lot of time looking up and formatting commands 

https://scdn.rohde-schwarz.com/ur/pws/dl_downloads/dl_application/application_notes/1gp98/1GP98_2E_SCPI_Recorder.pdf