Software for automated testing (SCPI)? - Page 1
Forum section: electronics / general

author: RoGeorge
author_rank: Super Contributor
timestamp: December 29, 2020, 08:20:17 pm
content: 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 supplyDevice 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?

author: EmmanuelFaure
author_rank: Regular Contributor
timestamp: December 30, 2020, 12:06:06 pm
content: Python

author: alm
author_rank: Super Contributor
timestamp: December 30, 2020, 02:05:22 pm
content: 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 withpython-ivifor instrument-specific drivers (I found it fairly easy to extend with new instruments that weren't supported yet),python-vxi11for accessing instruments over Ethernet,matplotlibandpandasfor analysing long time series of data.

author: RoGeorge
author_rank: Super Contributor
timestamp: December 30, 2020, 06:41:10 pm
content: 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#343639Meanwhile I've searched and the only free and active project I've found was "Skippity". It works for any OS (based on Java), but allSkipittycan 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 Toolsis 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.

author: alm
author_rank: Super Contributor
timestamp: December 30, 2020, 07:20:05 pm
content: 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:import iviimport numpy as npfrom time import sleepimport csvimport datetimeOUTPUT_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.outputsk237_op.current_limit = 0.01k237_op.voltage_level = 0k237_op.enabled = Truevoltages = 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 = voltsleep(10)csvw.writerow({'datetime': datetime.datetime.utcnow().isoformat(),'set_voltage': volt,'measure_current': k237_op.measure('current'),})k237_op.enabled = FalseAnd to plot the I-V curve:Code:import matplotlib.pyplot as pltimport pandas as pdimport syscurve = pd.read_csv(sys.argv, parse_dates=['datetime'])curve.plot.scatter('set_voltage', 'measure_current')plt.show()

author: RoGeorge
author_rank: Super Contributor
timestamp: December 31, 2020, 12:51:56 pm
content: Thank you for mentioning python-ivi and python-vxi11Gave 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_capturehttps://hackaday.io/project/5807-driverless-rigol-ds1054z-screen-capture-over-lanNo 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 modulesPython IVIandPython VXI11. There is also aPython USBTMCfor 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:VISAVirtual Instrumentation Software ArchitectureGPIBGeneral Purpose Interface Bus (parallel bus also known as IEEE488 or IEC625 bus)VXI-11Standard LAN protocol for remote control of measurement instruments for InstrumentationATEAutomated Test EquipmentT&M instrumentTest and measurement instrumentUSB-TMCTest and Measurement Class for USB instruments. These instruments can be controlled using VISA.LANLocal Area Network (also known as Ethernet)APIApplication Programming InterfaceHiSLIPHigh-Speed LAN Instrument ProtocolThe 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.htmlhttps://www.rohde-schwarz.com/tr/driver-pages/remote-control/glossary_231242.htmlIVI 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?

author: RoGeorge
author_rank: Super Contributor
timestamp: December 31, 2020, 02:23:52 pm
content: 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?

author: pwlps
author_rank: Frequent Contributor
timestamp: December 31, 2020, 05:31:42 pm
content: 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.

author: RoGeorge
author_rank: Super Contributor
timestamp: December 31, 2020, 06:02:07 pm
content: 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_loggerhttps://github.com/RoGeorge/DS1054Z_data_loggerOnce 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_stationTBH 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.

author: pwlps
author_rank: Frequent Contributor
timestamp: December 31, 2020, 06:58:57 pm
content: Quote from: RoGeorge on December 31, 2020, 06:02:07 pmI 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?QuoteIn 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 ?

author: RoGeorge
author_rank: Super Contributor
timestamp: December 31, 2020, 08:22:34 pm
content: Quote from: pwlps on December 31, 2020, 06:58:57 pmYes, 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.

author: pwlps
author_rank: Frequent Contributor
timestamp: December 31, 2020, 09:37:12 pm
content: Quote from: RoGeorge on December 31, 2020, 08:22:34 pmVisa 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.

author: alm
author_rank: Super Contributor
timestamp: December 31, 2020, 10:06:32 pm
content: 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.Quote from: RoGeorge on December 31, 2020, 12:51:56 pmI 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 likeN0XF0,0B10,0,0L0.001,0XN1X. Compare this tok237_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 instrumentsUse an abstraction that one individual came up with and used for their personal projectsCome 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-offQuote from: RoGeorge on December 31, 2020, 12:51:56 pmI don't have a great answer for this, but there are a couple of forks of Python-ivi on Github. You can look atopen PRs. Orforks. For example,this oneappears to add basic support for the Rigol DS10xxZ series, andthis oneadds 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.Quote from: RoGeorge on December 31, 2020, 12:51:56 pmIt 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 fromfrom alexforencich. For the function gen, there does not seem to be a very similar instrument already implemented. The closest I see right now isthe 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.

author: RoGeorge
author_rank: Super Contributor
timestamp: January 02, 2021, 06:32:41 pm
content: 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) oscilloscopetogether with many other instruments, for Rigol somewhere aroundpage 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-ivihttps://github.com/python-ivi/python-ivi- a python-ivi project by user alexforencichhttps://github.com/alexforencich/python-ivi/- a python-ivi project by user ianrreeshttps://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.

author: alm
author_rank: Super Contributor
timestamp: January 02, 2021, 08:37:25 pm
content: Quote from: RoGeorge on January 02, 2021, 06:32:41 pmOn 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.Quote from: RoGeorge on January 02, 2021, 06:32:41 pmOne 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.Quote from: RoGeorge on January 02, 2021, 06:32:41 pmThere are source files that can build a man page athttps://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.Quote from: RoGeorge on January 02, 2021, 06:32:41 pmIn 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 seea bunch of open PRs, which have not been merged (yet). And alsoa 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 has4 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.

author: HB9EVI
author_rank: Frequent Contributor
timestamp: January 02, 2021, 09:35:55 pm
content: python, pyvisa and tkinternothing is easier today to do a gui for those devices

author: RoGeorge
author_rank: Super Contributor
timestamp: January 03, 2021, 12:07:38 am
content: Quote from: alm on January 02, 2021, 08:37:25 pmAbout 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:2021-01-03 00:41, Sun=====================- manually searched all forks fromhttps://github.com/python-ivi/python-ivi/network/members- only these have DS1054https://github.com/Unconventional/python-ivi/tree/master/ivi/rigolhttps://github.com/ul-gh/python-ivi/tree/master/ivi/rigolhttps://github.com/shanea/python-ivi/tree/master/ivi/rigolhttps://github.com/gedankenexpt/python-ivi/tree/master/ivi/rigolhttps://github.com/qpit/python-ivi/tree/master/ivi/rigolhttps://github.com/edupo/python-ivi/tree/master/ivi/rigolhttps://github.com/nicedwarf/python-ivi/tree/master/ivi/rigolhttps://github.com/JoelLinn/python-ivi/tree/master/ivi/rigolhttps://github.com/duckythescientist/python-ivi/tree/master/ivi/rigolhttps://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:masterand 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 conflictsIt 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.

author: alm
author_rank: Super Contributor
timestamp: January 03, 2021, 07:11:14 pm
content: Quote from: RoGeorge on January 03, 2021, 12:07:38 amNicedwarf 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.Quote from: RoGeorge on January 03, 2021, 12:07:38 amThe 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:git clone https://.../alexforencich/python-ivigit remote add nicedwarf https://.../nicedwarf/python-ivigit merge rnicedwarf/masterAs opposed to the other way around (merging alexforencich into nicedwarf).Quote from: RoGeorge on January 03, 2021, 12:07:38 amThis never happened to meQuote from: RoGeorge on January 03, 2021, 12:07:38 amI 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.

author: RoGeorge
author_rank: Super Contributor
timestamp: January 03, 2021, 08:34:28 pm
content: 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.

author: souldevelop
author_rank: Regular Contributor
timestamp: January 06, 2021, 02:16:46 am
content: 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, DM3068This 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.

author: olafnew
author_rank: Newbie
timestamp: May 17, 2021, 08:06:01 pm
content: Is there a download link? Is the project opensourced?

author: rfclown
author_rank: Frequent Contributor
timestamp: May 24, 2021, 04:02:56 pm
content: 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 visaThis 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 100reads the instrument ID from GPIB instrument 18visa TCPIP0::172.33.9.120::INSTR ":sour:freq:cw 2402 MHz"sets the frequency of an MXG signal generator via Ethernet connectionvisa TCPIP0::172.33.9.111::INSTR scdp -r 1000000 -f screen.bmpfor a Siglent oscope, asks for a screen capture, and sends the results to a fileYou 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.