Instrument control software choices

[Joel_l]

Are there any good generic instrument control software packages? Something that's brand agnostic. I would like to control my Siglent, R&S, and Keysight equipment from one package. Some is USB only, some has USB and LAN. If it runs on Linux, even better. I'm not a fan of LabView. Each brand has their own control software, but I want to use all the equipment in one test environment.

Anything out there?

Joel

[technogeeky]

Are there any good generic instrument control software packages? Something that's brand agnostic. I would like to control my Siglent, R&S, and Keysight equipment from one package. Some is USB only, some has USB and LAN. If it runs on Linux, even better. I'm not a fan of LabView. Each brand has their own control software, but I want to use all the equipment in one test environment.

Anything out there?

Joel

The most well known project to do such a thing is called sigrok. Whether your hardware is supported or not is a different story.
 

[abraxa]

Whether your hardware is supported or not is a different story.

We're always happy to add support for new devices *wink, wink*

[troyosaurus2014]

I can only think of PyVISA (python wrapper for virtual instruments). There's some tutorial videos on YouTube and documentation available online.

[theatrus]

I think this is an under-served market, but yeah there isn't much. In the past, I've just wrapped existing VISA drivers or polled directly over SCPI (if available) when building test stands. Trying to build some of flows in LabView would be maddening.

[LaurentR]

If you have a small set of instruments and are not trying to make a very generic test environment that could be used with lots of different instruments, I'd certainly recommend talking to your instruments through SCPI using the various Visa drivers (already built into Linux).

Python is an option with PyVisa, but really you could use any language as SCPI is text-based.

SCPI has the advantage that it is usually well documented for all devices and you'll be able to fully exploit the features of your instruments. SCPI being text-based it's also very easy to have an interactive session with the instrument to see what happens when you do xyz.

[colorado.rob]

Whether your hardware is supported or not is a different story.

We're always happy to add support for new devices *wink, wink*

How much time is involved in adding (complete) support for a bench DMM, LXI power suppy, o-scope or signal generator?  I'd really love to see some of my equipment supported.  I'd consider funding work to get them supported in PyVisa and Sigrok.

[abraxa]

Whether your hardware is supported or not is a different story.

We're always happy to add support for new devices *wink, wink*

How much time is involved in adding (complete) support for a bench DMM, LXI power suppy, o-scope or signal generator?  I'd really love to see some of my equipment supported.  I'd consider funding work to get them supported in PyVisa and Sigrok.

That very much depends on your definition of "complete". DMM support is usually quick and painless since there are a few more or less common protocols that we support in a generic manner already. Power supply support is a bit more elaborate but still rather simple since it's just a bunch of SCPI commands. Scope support can range anywhere from "straightforward" to "hard", depending on the docs available and the quality of the firmware in the device. The signal generator again shouldn't be a big deal if it speaks SCPI and you don't need specialty features such as modulation or want to use it as an arbitrary signal generator. So like I said, it very much depends on what you need and what your expectations are.

[colorado.rob]

Whether your hardware is supported or not is a different story.

We're always happy to add support for new devices *wink, wink*

How much time is involved in adding (complete) support for a bench DMM, LXI power suppy, o-scope or signal generator?  I'd really love to see some of my equipment supported.  I'd consider funding work to get them supported in PyVisa and Sigrok.

The signal generator again shouldn't be a big deal if it speaks SCPI and you don't need specialty features such as modulation or want to use it as an arbitrary signal generator. So like I said, it very much depends on what you need and what your expectations are.

By complete, I mean arbitrary signal generator support in my arbitrary signal generator, including modulating waveforms.  Will this take hours, days, weeks or months of work?

[biot]

By complete, I mean arbitrary signal generator support in my arbitrary signal generator, including modulating waveforms.  Will this take hours, days, weeks or months of work?

sigrok doesn't currently have AWG support as a device class. Adding that, weeks (if you know your way around sigrok already). A GUI client is a different matter. You'd have to talk abraxa into it :-)

[colorado.rob]

sigrok doesn't currently have AWG support as a device class.

Got it.  Not to detract from sigrok, but I think I'll stick with PyVISA for now since I can do most everything I need in Python.  (Even though I am a C++ programmer by day.)  I may try doing some demos in Jupyter.  I can get high-level Python libs for just about everything I own written & tested in 1-2 months, including loading waveforms into an AWG (I'll have two shortly), having those waveforms generated in scipy or GNU Radio.

[theatrus]

Using Jupyter with PyVISA or even SCPI is pretty compelling now that you mention it. Would be a great lab notebook as well for teaching...

[Dwaine]

I agree with you.   I use python for all my test gear and it just works.  I even use my raspberry Pi 3 as my main logging computer on my bench.  It's great

[Joel_l]

So it seems for me, I should just write my own. I did this once for a test environment at work, I think then I used X-Forms to develop the GUI and wrote all the code behind it in C. Another project that should be fun, but to find time......Ugh

[edpalmer42]

'Write your own' covers a lot of territory.

Some years ago when I started to upgrade my lab, I looked around at what was available.  I'm not a programmer, but I've dabbled in code for many years.  Because it was free and easy, I started using EZGPIB which is a Pascal interpreter with GPIB extensions.  It also does serial ports and therefore, USB.  I don't know if it can be coaxed into doing LAN.  I'd never used Pascal, but found it relatively easy to pick up.  Add in the examples that were included, and it takes almost no time to hack up a data collection and logging program.

I'm starting to transition to Python.  Once you get past the syntax, the biggest time waster is learning what functions are available and how to use them.  Same with Arduino.  I've done a couple of small projects there and spent most of the time looking for functions I could use.

Bottom line here is that 'writing your own' isn't an onerous task.  You don't need an all singing, all dancing, real-time GUI monstrosity if all you want to do is log some data.

Ed

[thermistor-guy]

I "write my own" using gawk (GNU awk) scripts. One script does the test instrument control and raw data logging. Another script post-processes the log file to extract the data of interest, and output it as an Octave data file. Then I load the data using GNU Octave.

This setup works on a Win PC with Cygwin, or a Linux PC. It would probably work on a raspberry pi, but I haven't tried it yet.

My instruments connect to a LAN, either directly or via some kind of converter (e.g. a Wiznet 110SR). The control/logging script uses netcat to communicate with the instruments' LAN ports. gawk has a nice co-process feature, which allows scripts to spawn concurrent tasks as/when needed - no need to do everything in a single thread, unless of course you want to.

I was dreading "writing my own", but once I made some system-level decisions (standardize on ethernet, use gawk and netcat), and got some basic scripts working (e.g. simply send *idn? to an instrument and log the response), it turned out to be a lot of fun.