Author Topic: Python scripts to control instruments using LXI SCPI - no drivers required  (Read 1750 times)

0 Members and 1 Guest are viewing this topic.

Offline RoGeorge

  • Frequent Contributor
  • **
  • Posts: 408
  • Country: ro
I have a few scripts that can control Rigol instruments connected to a LAN.
They were useful to me many times, maybe others want to use them too.
They are free, open source, works from the command line for both Windows and Linux, and does not need to install any drivers.



The story was that after I bought my first Rigol, a DS1054Z oscilloscope, I tried to control it remotely, from the PC. I ended up installing drivers from Rigol and National Instruments, drivers that came together with a few GB of bloated software, which I didn't like it at all.

Later, I found out that all instruments that have LXI can talk over the LAN using plain text SCPI commands. No drivers are required for LXI. You can simply Telnet or Net Cat the SCPI command using the instrument IP and port 5555 or 5566.
https://hackaday.io/project/6857-master-your-rigol-from-command-line

This is great for most of the SCPI commands, but not good for ones that returns binary data, like the BMP file returned after an oscilloscope screen capture. So I wrote a small Python script to capture the screen from the oscilloscope. In this script I tried to use the Telnet libraries already available in Python.

The problem using Telnet is that it was designed for text messages. The RFC 854 specifications for Telnet protocol, define the character NULL (0x00) as "No Operation", so when any 0x00 byte was encountered in the BMP file sent by the scope, the Python Telnet library silently discard it, messing up the BMP file format. So I hacked the Telnet library to let 0x00 unaffected, and after that it was possible to receive and decode the BMP screen captured from the scope.

For other SCPI commands that returns only text messages or text values, the standard Telnet or Net Cat can be used.
« Last Edit: September 30, 2016, 11:44:55 PM by RoGeorge »
 

Offline bson

  • Supporter
  • ****
  • Posts: 740
  • Country: us
I'd recommend using python-vxi11 for actual scripting.  The LXI branding just means the instrument implements VXI-11, which is a way of tunneling GPIB over SunRPC.  This has some benefits in that GPIB implements various signaling that can't be communicated using plain old text, and works transparently with GPIB-to-Ethernet bridges like the ICS 8065 (which is what I use) for older instruments that have GPIB but not VXI-11, or any Ethernet at all for that matter.  It also makes it easy to share instruments, so I can sit and develop a test on the couch using my MacBook Pro, then actually run it on the Linux machine I use for data logging remotely over ssh in a screen session.
<This space intentionally left blank>
 

Offline RoGeorge

  • Frequent Contributor
  • **
  • Posts: 408
  • Country: ro
Glad to here about alternatives.  :D

I give it a try, but python-vxi11 didn't worked for me. At a quick glance into the code, it seems like python-vxi11 is dependent of the VISA drivers, e.g. NI-VISA, and can not work without VISA installed. Thought, I am not sure about that.

Can python-vxi11 work on a clean machine, without any VISA?
« Last Edit: October 01, 2016, 08:54:01 AM by RoGeorge »
 

Offline RoGeorge

  • Frequent Contributor
  • **
  • Posts: 408
  • Country: ro
Recent changes/upgrades of the forum's database made me wonder if the old posts are still fine, so I stumble into this one, which was intended to be a collection of my Rigol scrips. Python-VXI didn't worked for me.

Another script that serves me well (this one is Windows only, but it can be easily ported on Linux, too):
  • DS1054Z_data_logger - is displaying and logging the Vavg of all 4 channels of a DS1054Z oscilloscope while saving the data in the PC as a CSV file. The CSV file can be opened or copied and post-processed while the logging is running, no need to wait until the logging has been finished.

The value "9.9E37" is the SCPI value corresponding to the oscilloscope screen displaying "Avg=*****"

This is how the produced CSV file looks like:
Code: [Select]
YYYY-MM-DD,HH:MM:SS,CH1(Vavg),CH2(Vavg),CH3(Vavg),CH4(Vavg)
2017-03-24,14:35:09,1.133774e-01,9.9E37,9.9E37,9.9E37
2017-03-24,14:35:19,1.112045e-01,9.9E37,9.9E37,9.9E37
2017-03-24,14:35:29,5.585327e-02,9.9E37,9.9E37,9.9E37
2017-03-24,14:35:39,9.314423e-02,9.9E37,9.9E37,9.9E37
2017-03-24,14:35:49,1.023407e-01,9.9E37,9.9E37,9.9E37
2017-03-24,14:35:59,1.030106e-01,9.9E37,9.9E37,9.9E37

And its CMD capture:

Offline Neuromodulator

  • Contributor
  • Posts: 37
I played a bit with LXI some time ago, but used python sockets instead of Telnet. I found that remote control of the scope is very unreliable, even with their own drivers and software. For instance I found that if I sent two commands too quick, one would not be processed, even after waiting for the completion of the first command (If I remember correctly). There were also some issues when using too big memory buffers (for faster memory reading). You still can automate stuff, but the system isn't as robust as I was hoping.
 

Offline bson

  • Supporter
  • ****
  • Posts: 740
  • Country: us
Python-vxi11 doesn't need or even use VISA drivers, it talks SunRPC directly to the VXI-11 network controller.  I use it on OSX and Linux and don't have that broken VISA driver garbage and discovery services installed anywhere.  Instead, all my physical GPIB buses terminate at a pair of ICS8065 network controllers that talk VXI-11 only.  This excepts the instruments I have that can talk VXI-11 directly.  I mostly sit and work out the scripting code on a MacBook Pro on the couch and when it seems to work I move it over to a small Intel NUC box on the wall behind my bench...  VXI-11 is absolutely rock solid, in fact I can go move the entire network, power cycle switches, reconfigure the VLAN, and whatnot and it'll just keep going.  I can even power cycle the 8065 in use if I feel like it.  This is in total contrast to the patently brittle, ghetto, over-engineered VISA discovery services and drivers where if you so much as look at it wrong you have to reboot to get it working again.  For a while.
<This space intentionally left blank>
 

Offline RoGeorge

  • Frequent Contributor
  • **
  • Posts: 408
  • Country: ro
I played a bit with LXI some time ago, but used python sockets instead of Telnet. I found that remote control of the scope is very unreliable, even with their own drivers and software. For instance I found that if I sent two commands too quick, one would not be processed, even after waiting for the completion of the first command (If I remember correctly). There were also some issues when using too big memory buffers (for faster memory reading). You still can automate stuff, but the system isn't as robust as I was hoping.

From my tests, either Telnet or a simple TCP socket works good enough (lately I was dropping the Telnet and used a TCP socket, too), and any instability seems to be related to the LXI implementation or the firmware version. If I check for errors and for command completeness, then it is stable enough for use in a supervised lab.

Still, as you noticed too, Rigol LXI is far from perfect. I will not use any Rigol LXI instruments to control a nuclear power plant.
:)
« Last Edit: March 25, 2017, 06:34:07 AM by RoGeorge »
 
The following users thanked this post: Chalky

Offline Chalky

  • Regular Contributor
  • *
  • Posts: 89
  • Country: nz
How are you checking for errors and command completeness?

Yeah, all you need to do is fart in the wrong direction and DS2000's LXI hangs.
 

Offline RoGeorge

  • Frequent Contributor
  • **
  • Posts: 408
  • Country: ro
In the first versions I was simply waiting about a second between commands. Of course, this was very slow.
Then, I was using *OPC?. I guess my scripts published on github are still using OPC query. For big data transfers, OPC doesn't help, you must check that all the expected data has arrived before sending another command.

Later, I stopped using Telnet, and open a TCP socket instead. Also I start looking for errors too, not only for the completeness of SCPI command, but I bumped into some firmware bugs that make my DS1054Z to freeze any LXI communication until the next power cycle, so these changes are not published yet on my github scripts. Since the actual scripts cover my needs, I didn't spent more time for improvements.

So far, yes, it works, but I won't use Rigol for life support equipment any time soon.
 ;D


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf

 

http://opalkelly.com/