Software for automated testing (SCPI)?

[RoGeorge]

There are 3 Rigol instruments with LXI (SCPI capable and already connected in a LAN)
- a DS1054z oscilloscope
- a DG4102 DDS generator
- a DP832 power supply

Device under test is usually a hobby project.  Sometimes it requires many repeated settings and repeated measurements, e.g.
- measure a filter response with the DDS and the scope over many ranges of magnitude and frequency
- measure temperature stability with many minutes in between to wait for thermal equilibrium
- simple data logging over long intervals of time, etc.

So far I was tinkering myself with hand made SCPI scripts, data saving as text files on a PC, and later manually plotting and charting in a spreadsheet or in Python.

I am looking for small and free for home use software tool, or language, to do automated measurements.  The only one I know so far is either LabVIEW (which is huge and not for Linux), or manual scripting which usually escalates into cumbersome programming exercise which diverts me from focusing on the DUT's hardware.

- 1. What to use to automate measuring of a DUT response?
- 2. What the industry uses?
- 3. What do you recommend to use for home/hobby projects?

[EmmanuelFaure]

Python

[alm]

There was a LabVIEW version for Windows, Mac and Linux last time I checked. I've used it on all three platforms. Hardware drivers may not be available for all platforms, though. If you are used to any kind of normal (text-based source) programming, you'll probably not enjoy working on complex LabVIEW programs. I certainly didn't.

From what I know, the industry uses either LabVIEW or their favourite language (be it C#, Python, etc) with abstractions for instrument access like VISA and IVI.

For hobby, I use Python with python-ivi for instrument-specific drivers (I found it fairly easy to extend with new instruments that weren't supported yet), python-vxi11 for accessing instruments over Ethernet, matplotlib and pandas for analysing long time series of data.

[RoGeorge]

Checked LabVIEW today, and it looks like the free edition (LabVIEW Community Edition) is for Windows only.  Only the payed LabVIEW seems to be working for Linux or Mac.
https://www.ni.com/ro-ro/support/downloads/software-products/download.labview-community.html#343639

Meanwhile I've searched and the only free and active project I've found was "Skippity".  It works for any OS (based on Java), but all Skipitty can do for now is linear scripts.  The only flow control it has is an IF/THEN/ELSE/ENDIF and it's one level only, no nested IFs.

Lua + LXI Tools is another option I want to test since long ago, but never found the time to learn Lua.
https://www.eevblog.com/forum/testgear/open-source-lxi-tools-and-liblxi-v1-0-released-for-gnulinux/

Guess I'll stick with Python for now.
 

[alm]

Once you get the basics down, the scripts really don't have to be very complicated. Once you have one, you can copy and modify for the next project.

This acquires an I-V trace of a two terminal device (in my case a MOV) using a Keithley SMU:

Code: [Select]

import ivi
import numpy as np
from time import sleep
import csv
import datetime

OUTPUT_FILE = 'k237-trace-SNR-A150k-mov.csv'
FIELDNAMES = ['datetime', 'set_voltage', 'measure_current']

k237 = ivi.keithley.keithley237("TCPIP::192.168.0.122::gpib,15::INSTR",
                                id_query=True)
k237_op = k237.outputs[0]
k237_op.current_limit = 0.01
k237_op.voltage_level = 0
k237_op.enabled = True

voltages = np.arange(-250, 260, 10)
with open(OUTPUT_FILE, 'w') as csv_file:
    csvw = csv.DictWriter(csv_file, fieldnames=FIELDNAMES)
    csvw.writeheader()
    for volt in voltages:
        k237_op.voltage_level = volt
        sleep(10)
        csvw.writerow({
            'datetime': datetime.datetime.utcnow().isoformat(),
            'set_voltage': volt,
            'measure_current': k237_op.measure('current'),
        })
    k237_op.enabled = False

And to plot the I-V curve:

Code: [Select]

import matplotlib.pyplot as plt
import pandas as pd
import sys


curve = pd.read_csv(sys.argv[1], parse_dates=['datetime'])
curve.plot.scatter('set_voltage', 'measure_current')
plt.show()


[RoGeorge]

Thank you for mentioning python-ivi and python-vxi11 

Gave them a try and it all works great, better than my Python scripts from when python-vxi11 was not yet a thing:
https://github.com/RoGeorge/DS1054Z_screen_capture
https://hackaday.io/project/5807-driverless-rigol-ds1054z-screen-capture-over-lan
No dependencies and nothing to install, but yes, my lame coding style and a shameless plug. 

I would probably use python-vxi11 from now on, seems to be working faster (no idea why) than sending text SCPI commands over a TCP/IP socket.  I would like to thank Alex Forencich for his very, very useful Python modules Python IVI and Python VXI11.  There is also a Python USBTMC for USB connected instruments.

Also found his topic about the above IVI project here, on EEVblog:
https://www.eevblog.com/forum/testgear/python-based-instrument-control/ 

I would like to try python-ivi, but from the 3 SCPI instruments I have, only the Rigol DP832 (DP800 series) power supply has IVI instrument definition.  I couldn't find IVI definition files for Rigol DS1054Z (DS1000Z series) oscilloscope, or for DG4102 (DG4000 series) DDS generator.  It was quite a surprise nobody took the time to define the DS1054z oscilloscope, which is probably the most common oscilloscopes in the last 5 years or so.

That makes me think that maybe yet another abstraction layer (the IVI layer) might not be such a productive idea for non-industrial use, therefore might not be so popular.  Took a look at the doc page about adding a new type of instrument, and not sure if I have the skills and the time to define the IVI drivers for the Rigol oscilloscope and generator.

Just for the docs, so I won't forget the IVI drivers stack and all the confusing acronyms again 5 years from now:   

Code: [Select]

VISA Virtual Instrumentation Software Architecture
GPIB General Purpose Interface Bus (parallel bus also known as IEEE488 or IEC625 bus)
VXI-11 Standard LAN protocol for remote control of measurement instruments for Instrumentation
ATE Automated Test Equipment
T&M instrument Test and measurement instrument
USB-TMC Test and Measurement Class for USB instruments. These instruments can be controlled using VISA.
LAN Local Area Network (also known as Ethernet)
API Application Programming Interface
HiSLIP High-Speed LAN Instrument Protocol
The image is not mine, all the rights belongs to R&S, source:
https://www.rohde-schwarz.com/tr/driver-pages/remote-control/instruments-drivers-vs.-plain-scpi-commands_231246.html
https://www.rohde-schwarz.com/tr/driver-pages/remote-control/glossary_231242.html

IVI acronym (Interchangeable Virtual Instrument) is missing from the above page.  All the IVI specifications defined by the IVI Foundation are free to download (e.g. IVI oscilloscope specs are "IVI-4.1: IviScope Class Specification"):
https://www.ivifoundation.org/specifications/


- 1.  I've noticed you used python-ivi in your Python example above, and not python-vxi11 and SCPI commands.  Are there some benefits I am missing here?  Why dealing with yet another abstraction layer (IVI) instead of just sending SCPI commands, which SCPI commands are usually very well described in each instrument programming manual?

-2.  Any idea where I could find more IVI instruments files for python-ivi?  Looking for Rigol DS1054Z and DG4102.

-3.  You said it might be fairly easy to define new instruments.  I am familiar with Python and many other languages, but not a software developer.  Numerous wrappings and abstraction layers usually confuse me.  Not sure what will be the benefits of having an IVI oscilloscope instead of an SCPI oscilloscope, and if those benefits will worth the time of learning yet another abstraction layer.  What does "fairly easy" means when adding a new oscilloscope or a new DDS generator, as a very rough estimation?  An hour, a day, a week, or maybe more?

[RoGeorge]

I don't even know there were IVI drivers for Windows, thank you for mentioning that.  Searched and found some IVI drivers from Rigol in msi format.  Not sure if I could use those to create IVI files for Python-IVI on Linux.

What intrigues me is yesterday I was looking at the examples given in the DS1000Z programming guide, and they were using a VISA connection for LabVIEW, followed by SCPI commands, so they were seem to be using the oscilloscope with specific SCPI commands and not as an abstract IVI instrument.  Not sure why.  My assumption was that there was no IVI driver for DS1000Z, and that is why the lower level of SCPI control was chosen.

Now I see there are some Windows drivers from Rigol, with IVI in the name, yet the examples are not using IVI?
Is this just a wrong naming for calling the drivers IVI instead of VISA, or is it something else I don't know?

Anybody here using the DS1000 or DG4000 as IVI instruments?

[pwlps]

For simple logging you might have a look at Ian's software : https://www.eevblog.com/forum/metrology/3458a-logging-via-windows-app-revisited/
It was initially for multimeters like 3458A but since SCPI commands are configurable it will work with any other device (no scripting though).

In my opinion the IVI layer might be interesting if you are using many devices of the same type e.g. many different oscilloscopes, so that having a higher abstraction level to address a generic scope may simplify coding, otherwise I don't see any advantage over SCPI because you have to learn how to code specific commands anyway.

[RoGeorge]

Will look at that thread, too, thank you.

For basic logging I already published scripts that works on any any OS and requires nothing to install many years ago:
https://github.com/RoGeorge/DP832_charger_logger
https://github.com/RoGeorge/DS1054Z_data_logger

Once I even made a PID controller for a soldering iron heater from a DP832 power supply and a DS1054Z scope: 
https://rogeorge.wordpress.com/2016/09/23/zero-parts-thermostated-soldering-station/
https://github.com/RoGeorge/SCPI_solder_station

TBH I was hoping in the last decade something spectacular came into existence, maybe something even better than the ancient LabVIEW, but all I can find is only incremental progress in standardization and some data transfer speed increase.  Nothing groundbreaking and no spectacular changes yet.

Turned out the automated testing field doesn't changed much in the last decade or so.
 

[pwlps]

For basic logging I already published scripts that works on any any OS and requires nothing to install many years ago:
https://github.com/RoGeorge/DP832_charger_logger
https://github.com/RoGeorge/DS1054Z_data_logger

I had a look at those, one thing I don't understand is you're saying "No drivers are required to be installed on the PC", how does it communicate ?  Is it via a direct TCP/IP connection without protocol or with a proprietary protocol?
   

TBH I was hoping in the last decade something spectacular came into existence, maybe something even better than the ancient LabVIEW, but all I can find is only incremental progress in standardization and some data transfer speed increase.  Nothing groundbreaking and no spectacular changes yet.

Turned out the automated testing field doesn't changed much in the last decade or so.
 

In principle VISA was designed to bring such a standardised way. However there is always a compromise between standardization and efficiency (data transfer speed, parallel I/O), NB. this is what I tried to address and optimize in my library (used by Ian's software).
But at the end I don't quite see if it would be possible to devise a single, generic and best interface: easy to implement without any technical knowledge,  very efficient and compatible with everything ? 

[RoGeorge]

I had a look at those, one thing I don't understand is you're saying "No drivers are required to be installed on the PC", how does it communicate ?  Is it via a direct TCP/IP connection without protocol or with a proprietary protocol?

Yes, some of them were using telnet to instrument's IP port 5555 (for some reason all Rigol instruments are using the 5555 port), some other might just sent TCP/IP packets by opening a socket to the IP:port of the instrument, I don't recall which one are the github published ones.

You can even open a telnet session with your favorite telnet program at, say 192.168.1.3:5555 if that is the IP address of your instrument, and type "*IDN?" in the telnet client, and your Rigol instrument should respond (assuming its IP address is indeed 192.168.1.3).  Yes, tt is _that_ simple, I couldn't believe my eyes when I first read about this, but it works.   

One can either open a telnet session to the IP:port's instrument, or just start sending text TCP/IP packets to the instrument IP:port and the instrument will respond the SCPI sent commands, but there is yet another LAN protocol that I didn't know back than, the VXI11.  It turned out that Rigol (and probably other instruments, too) have faster transfer rates over VXI11 than over telnet or TCP/IP packets on a LAN socket, no idea why.

I'm very grateful some professional software developers wrote many VXI11 implementations in the last 5-10 years, and even more abstract IVI layers.  Will happily use those instead of mine, a big grateful thank you, just that I was stumbled there was no ground braking new concept in the automated testing of our last decade or so.
 

[pwlps]

One can either open a telnet session to the IP:port's instrument, or just start sending text TCP/IP packets to the instrument IP:port and the instrument will respond the SCPI sent commands, but there is yet another LAN protocol that I didn't know back than, the VXI11.  It turned out that Rigol (and probably other instruments, too) have faster transfer rates over VXI11 than over telnet or TCP/IP packets on a LAN socket, no idea why.

Visa network connections (and therefore IVI being a higher level protocol on top of it) rely mostly on VXI11. This protocol is a sort of GPIB equivalent over TCP/IP.  VXI11 is getting old though and a lot of new hardware now implement a much faster HiSlip protocol (see the LXI standard, https://www.lxistandard.org/About/VXI-11-and-LXI.aspx).
I don't know either why Rigol is faster with VXI11 compared to raw packets, but note that there is much more than the raw data transfer speed that is important in the protocol, for example :
- VXI11 handles message termination : there is no need for termination characters therefore both text and binary data can be reliably transferred using the same IO functions;
- a separate channel is available to query the device status (status byte), this can be used to optimize the data flow and/or avoid blocking the app/thread when waiting for data;
- a low-level "clear"  command allows to flush device's IO buffers after an error so that you can easily recover from any IO error (there is no easy way to recover from errors in telnet or raw TCP/IP);
- an out-of-band channel is available for service-request messages from devices, this can dramatically improve the performance and is important for real-time apps.

[alm]

So IVI is an industry standard. They defined interfaces for C and C#, I believe. Python-ivi is an unofficial implementation of a similar interface. The drivers you might get from manufacturers are generally not compatible with Python-ivi.

- 1.  I've noticed you used python-ivi in your Python example above, and not python-vxi11 and SCPI commands.  Are there some benefits I am missing here?  Why dealing with yet another abstraction layer (IVI) instead of just sending SCPI commands, which SCPI commands are usually very well described in each instrument programming manual?

I had two problems that I solved by using Python IVI:

• Raw commands for some instruments, especially older instruments, can be really ugly. For this particular SMU, to set the output to sourcing 10V, and measure current clamped to 1 mA, would be something like N0XF0,0B10,0,0L0.001,0XN1X. Compare this to k237_op.voltage_level = volt. I'm fine to figure out this cryptic sequence once, but I certainly don't want to be looking at it every time I use the instrument.
• I want to be able to replace instruments without substantially having to alter the script. For example, in another test I might want to use a Keithley 2400 SMU (which uses SCPI) instead of a Keithley 237 SMU.

As a software developer, it's clear to me that an abstraction can solve both these problems. So then I can:

• Use an industry-standard abstraction that has been implemented many times for different instruments
• Use an abstraction that one individual came up with and used for their personal projects
• Come up with my own (basically like #2)

I tried #3 at some point, but it felt like reinventing the wheel. And I figured if I use the work of someone else, why not try something that seems to work for the big vendors like NI? I certainly don't love IVI, but it seems sufficient for my needs so far, and I certainly don't have the motivation to attempt to design something better.

In a real-world measurement, I might have a Keithley 199 (R2D2 like commandset) DMM, HP 3458A (its command set is kind of a predecessor of SCPI) DMM, Agilent 34401A DMM (SCPI), Keithley 2000 DMM (subtly different flavor of SCPI than Agilent). Needing to look up and enter the specific commands for all these instruments would not be fun, never mind if I decide to swap one for the other. But of course this is what works for me. You might make a different trade-off

-2.  Any idea where I could find more IVI instruments files for python-ivi?  Looking for Rigol DS1054Z and DG4102.

I don't have a great answer for this, but there are a couple of forks of Python-ivi on Github. You can look at open PRs. Or forks. For example, this one appears to add basic support for the Rigol DS10xxZ series, and this one adds support for some R&S scopes. So right now it's a bit of a mess. Clearly the developer has not been very active lately.

-3.  You said it might be fairly easy to define new instruments.  I am familiar with Python and many other languages, but not a software developer.  Numerous wrappings and abstraction layers usually confuse me.  Not sure what will be the benefits of having an IVI oscilloscope instead of an SCPI oscilloscope, and if those benefits will worth the time of learning yet another abstraction layer.  What does "fairly easy" means when adding a new oscilloscope or a new DDS generator, as a very rough estimation?  An hour, a day, a week, or maybe more?

It depends on how similar the instrument is to already supported instrument. In general, if there's already a similar instrument from the same manufacturer and time period supported, it can be as simple as copying it and editing some variables like model number, channel count, bandwidth, voltage / current ranges, etc. If you look at the Rigol DS10xxZ files above, that's all they contain. In that case, an hour might be enough.

If it's really something that is not yet supported, it might take up to a week. Like with some fiddly instrument that would hang on certain sequences. For some instruments, I had to dig in the documentation from the IVI Foundation to figure out how to best implement it. Those took a couple of days. I think the first instrument took me about a week, and the next usually within a day unless it was particularly tricky or finicky.

So for the DSO you could try to use the drivers from from alexforencich. For the function gen, there does not seem to be a very similar instrument already implemented. The closest I see right now is the Rigol function gen built in scopes. I would try to copy that and change it to the specifics of that instrument, and to be a stand-alone instrument instead of a scope add-on.

[RoGeorge]

Now it completely makes sense, thank you for taking the time to explain.  Will prefer IVI commands over those native to each instrument whenever possible.

About the Windows Rigol IVI drivers (the ones written by Rigol), they are indeed IVI drivers, in the sense the drivers for the Rigol instruments I was looking for are registered to the IVI foundation, each with it's own capabilities:
- DP800 (DP832) DC power source
- DG4000 (DG4102) function generator
- DS1000Z (DS1054Z) oscilloscope
together with many other instruments, for Rigol somewhere around page 24 of IVI Foundation registered drivers.

For the generator the IVI capabilities were "Basic" only, but that was back in 2009, maybe I should power one of the old Windows laptops and install the latest proprietari IVI drivers.

One more thing about ANY proprietary IVI drivers for Windows, there is a python project that can detect any installed Windows IVI driver and make those available from Python (works on Windows only).
https://pypi.org/project/pyivi/


About the python-ivi drivers, thank you for the links to the DS1054Z osc drivers.  I am quite confused which is which, need to untangle them and look at the sources.  So far there is:
- a python-ivi project by user python-ivi https://github.com/python-ivi/python-ivi
- a python-ivi project by user alexforencich https://github.com/alexforencich/python-ivi/
- a python-ivi project by user ianrrees https://github.com/ianrrees/python-ivi/

Only the last 2 have IVI drivers for the oscilloscope, thought none of the 3 projects list the Rigol osc as available.
 

Need to try those 2 python-ivi drivers, and the Windows drivers, too, and see how it all goes.  At worst I'll use the SCPI over VXI11 and that's it for now.

Maybe I'll give it a try, too, at writing the generator one.  By looking at the IVI specs for a function generator, IviFgen has 378 pages, seems like a huge task.

Just for the docs, found some man pages by Alex Forencich, not sure for what product exactly are they for (I have installed python-ivi but 'man pythonivi' does not find any pages:
https://www.systutorials.com/docs/linux/man/1-pythonivi/

So far it seems to me that python-ivi is the most advanced open source IVI for Python, and it looks like most of it was written by Alex Forencich, but I'm very bamboozled by all the branches, and don't know which one to use for my 3 rigol instruments, and why DG4102 and DS1054Z seem to have IVI drivers in python-ivi, yet are not listed as compatible instruments in the main page of the project.
 

[alm]

One more thing about ANY proprietary IVI drivers for Windows, there is a python project that can detect any installed Windows IVI driver and make those available from Python (works on Windows only).
https://pypi.org/project/pyivi/

On Windows, this could certainly an option to be able to use the manufacturer drivers. I guess it depends on a the quality of the Rigol software. Given some of the other Rigol software like Ultra Sigma, I'm not particularly hopeful, but I've never tried their IVI drivers.

About the python-ivi drivers, thank you for the links to the DS1054Z osc drivers.  I am quite confused which is which, need to untangle them and look at the sources.  So far there is:
- a python-ivi project by user python-ivi https://github.com/python-ivi/python-ivi
- a python-ivi project by user alexforencich https://github.com/alexforencich/python-ivi/
- a python-ivi project by user ianrrees https://github.com/ianrrees/python-ivi/

One of the links in my previous post linked to a list of dozens of forks of the python-ivi projects. The first two seem kind of official (given that Alex Forencich seems to be the lead developer, I'm not sure what the difference is, maybe one is considered more final?). The work on Rigol scopes in the third one seems older and less complete than in the Alex Forencich repository, so I'd think #2 is the best bet.

Clearly the people making the changes did not bother to update the README file with supported devices for some reason.

Just for the docs, found some man pages by Alex Forencich, not sure for what product exactly are they for (I have installed python-ivi but 'man pythonivi' does not find any pages:
https://www.systutorials.com/docs/linux/man/1-pythonivi/

There are source files that can build a man page at https://github.com/python-ivi/python-ivi/tree/master/doc. It may be that they don't get automatically installed when you install the Python package.

So far it seems to me that python-ivi is the most advanced open source IVI for Python, and it looks like most of it was written by Alex Forencich, but I'm very bamboozled by all the branches, and don't know which one to use for my 3 rigol instruments, and why DG4102 and DS1054Z seem to have IVI drivers in python-ivi, yet are not listed as compatible instruments in the main page of the project.

In open source developer, there is general a core person or team (in this case Alex). They are the one in charge of the main version of the project. Other people can contribute by forking the repository, making whatever changes they desire, and if they want, can request this to be incorporated in the main project using a pull request. The core developer(s) can then decide to merge it, reject it, or request changes before they will merge it.

So for the python-ivi/python-ivi repository, you can see a bunch of open PRs, which have not been merged (yet). And also a number of closed PRs. If you look at the most recently merged that was not closed by the creator (because they gave up or some other reason) was in 2016. That's why I'm saying the project has not been active. The alexforencich repository has 4 open PRs, and no merged PRs yet.

So if the main project is not merging in changes, then the changes will remain in all those forks. Unless one of those forks gains momentum and starts merging things from other forks. That's why I said it's a bit of a mess right now.

[HB9EVI]

python, pyvisa and tkinter

nothing is easier today to do a gui for those devices

[RoGeorge]

One of the links in my previous post linked to a list of dozens of forks of the python-ivi projects. The first two seem kind of official (given that Alex Forencich seems to be the lead developer, I'm not sure what the difference is, maybe one is considered more final?). The work on Rigol scopes in the third one seems older and less complete than in the Alex Forencich repository, so I'd think #2 is the best bet.

Clearly the people making the changes did not bother to update the README file with supported devices for some reason.

About that one, it was on the todo list to look in all the forks, but postponed because I am not fluid using git/github.

Tried to search for Rigol drivers in all the forks, but for some reason I couldn't, github wanted me to login for advanced search, but Microsoft locked me away for my password checksum was found on some pwned pass lists, so to change the github pass I would need to use the registration email, which email insists that I should have double authentication which I absolutly don't want to set, bla, bla, I hate unsolicited and enforced "protection" 

Anyway, ended up clicking on each fork, then appended the path to the Rigol IVI files.   
Most of them don't have any Rigol oscilloscope, so I kept only the ones that have at least Rigol IVI for scopes.

Code: [Select]

2021-01-03 00:41, Sun
=====================
- manually searched all forks from
    https://github.com/python-ivi/python-ivi/network/members

- only these have DS1054
    https://github.com/Unconventional/python-ivi/tree/master/ivi/rigol
    https://github.com/ul-gh/python-ivi/tree/master/ivi/rigol
    https://github.com/shanea/python-ivi/tree/master/ivi/rigol
    https://github.com/gedankenexpt/python-ivi/tree/master/ivi/rigol
    https://github.com/qpit/python-ivi/tree/master/ivi/rigol
    https://github.com/edupo/python-ivi/tree/master/ivi/rigol
    https://github.com/nicedwarf/python-ivi/tree/master/ivi/rigol
    https://github.com/JoelLinn/python-ivi/tree/master/ivi/rigol
    https://github.com/duckythescientist/python-ivi/tree/master/ivi/rigol
    https://github.com/alexforencich/python-ivi/tree/master/ivi/rigol

- alexforencich - This branch is 32 commits ahead of python-ivi:master.
- nicedwarf - This branch is 85 commits ahead, 40 commits behind alexforencich:master.

Looks to me like the most recent work (regarding Rigol drivers) is from the user 'nicedwarf', the only one that has oscilloscopes with signal generator included, thought I don't get how can a clone be 40 commits behind the original, when the original have had only 32 commits.

Would it be OK to make local copies for all three
- python-ivi:master
- alexforencich:master
- nicedwarf:master
and try to merge them offline, with git?

And now I need to learn how to merge with git... 

Looks like the yak shaving is going deeper and deeper:
- about a week ago want to learn about PolyPhase Mixers -> which leaded to switching capacitors study
- switching capacitors -> LTspice Bode plots too slow
- measured Bode plots -> personal SCPI scripts also slow (a long ago postponed todo was to move to VXI11)
- raw TCP SCPI scripts slow -> VESA/VXI11
- VXI11 -> IVI (nice to have)
- python-ivi forks mess -> advanced github file search
- advanced github search -> github login required
- github login -> mail access required
- mail access -> double factor authentication required
- double factor -> manual search
- manual search results -> git merge and hope for no conflicts

It doesn't look like I'm getting any closer to the goal of testing some new ideas about on/off switches. 
Not to mention all the IviFgen specs reading in between.

[alm]

Looks to me like the most recent work (regarding Rigol drivers) is from the user 'nicedwarf', the only one that has oscilloscopes with signal generator included, thought I don't get how can a clone be 40 commits behind the original, when the original have had only 32 commits.

Nicedwarf is a clone of the alexforencich repo. That repository has 652 commits, and is 32 commits ahead of python-ivi. So by that logic, the nicedwarf repository is 8 commits behind python-ivi.

Would it be OK to make local copies for all three
- python-ivi:master
- alexforencich:master
- nicedwarf:master
and try to merge them offline, with git?

The alexforncich repository is ahead of the python-ivi repository, and no commits behind, so there is no benefit in merging in python-ivi.

For merging, I think this strategy would work the best (in pseudo-code):

Code: [Select]

git clone https://.../alexforencich/python-ivi
git remote add nicedwarf https://.../nicedwarf/python-ivi
git merge rnicedwarf/master
As opposed to the other way around (merging alexforencich into nicedwarf).

Looks like the yak shaving is going deeper and deeper:

This never happened to me

Not to mention all the IviFgen specs reading in between.

I hope reading the code for the Rigol built-in AWG and Tek AWG, together with the programming instructions for the DG, will be of use.

[RoGeorge]

Will try another merge the way you said, thanks!

Didn't continued today, but did a three way file by file diff yesterday, with Meld.  The only differences were some newly added instruments.  All the other diffs were just cosmetic changes.  No diff problems in python-vxi11 either.

To preserve the git history, will merge using git, then diff the end result (with Meld) against the manually merged from yesterday, and do any further changes in my own git merged fork.

[souldevelop]

hi, i am working on this aspect, but it is a project in my spare time. i think it has great development prospects. At present, this project has been completed with multimeter module support:

(1).Keysight (Agilent/HP) 34401A, 34410A, 34461A, 34470A, 3458A
(2). Gwinstek GDM8261A, GDM8341, GDM8342, GDM8352, GDM9060, GDM9061
(3).Tektronix (Keithley) DMM4020, DMM4040, DMM4050, DMM6500, DMM7510, K2000, K2001, K2002, K2010, K2015, K2100, K2110
(4). RIGOL DM3058, DM3068
This project will support signal sources, oscilloscopes, DC power supplies and other data acquisition equipment in the future.
Currently, the progress of this development project is very slow, because I don’t have more equipment for testing. If you can help me, I can speed up the progress.

[olafnew]

Is there a download link? Is the project opensourced?

[rfclown]

I use LabVIEW (since version 2.0). I've used it on MAC, Unix and Windows. I started measurement automation using QuickBASIC and an IOTech GPIO card in the late 80's. Made the switch to LabVIEW a few years  later.

But I also do a little in C. LabVIEW uses NIVISA for talking to anything, and NIVISA is a free download. With that, you can use any language you choose. My languages of choice are LabVIEW, C, and scripting (batch or sh). I wrote a simple utility to do VISA write/read from a DOS command line. compiles with gcc. to compile:

gcc visa.c -l:"C:\Program Files (x86)\IVI Foundation\VISA\WinNT\lib\msc\visa32.lib" -o visa

This assumes you installed VISA in the default directory. I also put the visa.h and visatype.h files in the directory I'm compiling from.

Type "visa -h" for a short help. Examples of usage:

visa GPIB0::18::INSTR *IDN? -r 100
reads the instrument ID from GPIB instrument 18

visa TCPIP0::172.33.9.120::INSTR ":sour:freq:cw 2402 MHz"
sets the frequency of an MXG signal generator via Ethernet connection

visa TCPIP0::172.33.9.111::INSTR scdp -r 1000000 -f screen.bmp
for a Siglent oscope, asks for a screen capture, and sends the results to a file

You can use this utility in a batch file to do automation or simple setups. Or just use the C code as a template for your own code. It's pretty simple. I've also attached the executable which was compiled on a Win10 machine. Might not work for you if you have a different number of bits (32 vs 64).

edit: I just now read the whole thread. Sounds like you already had something like this a long time ago.