Open source lxi-tools and liblxi v1.0 released for GNU/Linux

[lundmar]

Hi,

I have released lxi-tools and liblxi for GNU/Linux - see https://lxi-tools.github.io

• lxi-tools provide a commandline tool with a simple interface for discovering LXI compatible instruments, sending SCPI messages, and capturing screenshots
• liblxi is a C library which provides a high level API for LXI instrument discovery (using VXI-11 or mDNS/DNS-SD) and basic SCPI communication (using RAW/TCP or VXI-11/TCP)

It's fully open source and available for download.

For details on how to use the commandline interface please see https://github.com/lxi-tools/lxi-tools

Installation:
Latest lxi-tools:  lxi-tools-1.16.tar.xz  (Changes, GitHub)
Latest liblxi:  liblxi-1.9.tar.xz  (Changes, GitHub)

Install latest stable version using snap:  $ snap install lxi-tools
Install latest development version using snap:  $ snap install lxi-tools --edge
Supported snap architectures: amd64, i386, armhf

Visit https://snapcraft.io to see how to install snap for your distribution.

If you are a Windows user you can install e.g. Virtualbox (see https://www.virtualbox.org) and install Linux (e.g. Ubuntu 17.10) in a VM under which you install and run lxi-tools.
Note: Remember to reconfigure the VMs network interface to use a bridged network adapter (not NAT).

Motivation:
This open source project is for people who don't care for the proprietary, costly, and often times inferior tools available for controlling LXI compatible instruments. The very reason I authored lxi-tools/liblxi is because I wanted better and simpler tools for controlling my instruments. Stuff like NI VISA drivers/tools etc. are just too bloated for my taste and not really open source friendly. I think we can do better. After all, LXI is an open standard so why not make some proper open source tools to support it

Tested instruments:
The lxi commandline tool included in lxi-tools is tested to work successfully with the following instruments:

Instrument	Working features
Keysight Technologies MSO-X 3024T	(discover+scpi+screenshot)
Rigol Technologies DS1104Z	(discover+scpi+screenshot)
Rigol Technologies DS2302	(discover+scpi+screenshot)
Rigol Technologies DG4062	(discover+scpi+screenshot)
Rigol Technologies DG4102	(discover+scpi+screenshot)
Rigol Technologies DG4162	(discover+scpi+screenshot)
Rigol Technologies DP831	(discover+scpi+screenshot)
Rigol Technologies DP832	(discover+scpi+screenshot)
Rigol Technologies DM3068	(discover+scpi+screenshot)
Rigol Technologies DSA815	(discover+scpi+screenshot)
Rigol Technologies MSO2302A	(discover+scpi+screenshot)
Rigol Technologies DP832	(discover+scpi+screenshot)
Rohde & Schwarz HMO 1202	(discover+scpi+screenshot)
Siglent Technologies SDG1032X	(discover+scpi+screenshot)
Siglent Technologies SDG2122X	(discover+scpi+screenshot)
Siglent Technologies SDG6052	(discover+scpi+screenshot)
Siglent Technologies SDS1202X-E	(discover+scpi+screenshot)
Siglent Technologies SDS1204X-E	(discover+scpi+screenshot)
Siglent Technologies SDS2304X	(discover+scpi+screenshot)
Siglent Technologies SDM3045X	(discover+scpi+screenshot)
Siglent Technologies SDM3055	(discover+scpi+screenshot)
Siglent Technologies SDM3065X	(discover+scpi+screenshot)
Siglent Technologies SPD3303X-E	(scpi)
Siglent Technologies SSA3032X	(discover+scpi+screenshot)

Thanks to all the users in this forum who are helping to test and improve lxi-tools! 

Future work include:

• Test with more instruments (looking for testers with instruments)
• Add screenshot plugins for more instruments
• Push it to the most popular GNU/Linux distributions (Ubuntu/Debian, Fedora/RHEL, etc.)
• Make it work on non-GNU/Linux systems
• Extend discover feature to support mDNS/DNS-SD
• Add HiSlip/TCP support
• Add support for advanced LXI scripts written in Lua
• Add a modern QT GUI app to support running advanced scripts in test recipe mode (run, pause, continue, pass/fail etc.)
• Maybe add a simple QT GUI app for capturing and showing screenshots
• Add IPv6 support
• ...

Call for contributors:
Anyone who would like to contribute to this project is welcome to join in. All types of contributions are welcome (code, feature ideas, doc, test, etc.).

/Martin

P.S.: Developers/hackers, feel free to contribute. Start maybe by adding e.g. screenshot plugins for your favorite LXI instruments and push them upstream to lxi-tools via GitHub.
P.P.S: For inspiration, see https://github.com/lxi-tools/lxi-tools/blob/master/src/plugins/screenshot_rigol-1000z.c which is the code for the screenshot plugin for Rigol 1000z oscilloscopes.
P.P.P.S: I'm not in any way affiliated with the LXI consortium. This is a fully independent open source effort.

Steps for building and installing the latest versions from git source (Ubuntu/Debian example):

Code: [Select]

sudo apt-get install git automake autogen autoconf libtool libreadline-dev libc-dev-bin libc6-dev libavahi-core-dev libavahi-common-dev libavahi-client-dev libxml2-dev

mkdir lxi && cd lxi
git clone [url]https://github.com/lxi-tools/liblxi[/url] && cd liblxi
./autogen.sh
./configure --prefix=$HOME/opt/lxi
make install
cd ..

git clone [url]https://github.com/lxi-tools/lxi-tools[/url] && cd lxi-tools
./autogen.sh
./configure --prefix=$HOME/opt/lxi LDFLAGS=-L$HOME/opt/lxi/lib
make CFLAGS=-I$HOME/opt/lxi/include install
cd ..

export PATH=$HOME/opt/lxi/bin:$PATH

[HoracioDos]

I've opened an issue for lxi-tools. Perhaps I'm messing things up when compiling

[lundmar]

I've opened an issue for lxi-tools. Perhaps I'm messing things up when compiling

Nope - you did actually find a real bug. Thanks for your github reporting.

It enabled me to quickly release lxi-tools v1.1 which includes the fix. It is available at http://lxi-tools.github.io

[lundmar]

New versions of lxi-tools and liblxi are available at http://lxi-tools.github.io

They include some important bug fixes that resolves issues with some instruments not responding.

[awallin]

do you have plans for python bindings?

Might be a stupid question, but what's the difference between LXI and VXI11?
I've been using this for basic things - with good success: https://github.com/python-ivi/python-vxi11

thanks,
Anders

[lundmar]

do you have plans for python bindings?

Not at the moment. Mostly because I don't have a need for it myself. However, if anyone wants to contribute some python bindings I welcome it.

Might be a stupid question, but what's the difference between LXI and VXI11?

It's a perfectly fine question. The short answer is that the LXI standard defines the set of communication protocols used in a LXI/Ethernet enabled instrument. Such protocols include HTTP, VXI11, etc. and in the future HiSLIP. VXI11 is the specific RPC protocol that is used to communicate eg. SCPI commands. It is a fairly dated and slow protocol that will eventually be replaced with the more modern and faster HiSLIP (High-Speed LAN Instrument Protocol).

liblxi provides a simple high level C api that abstracts away the details of the VXI protocol for doing simple stuff like discovering instruments, sending SCPI commands, and receiving responses. Eventually it will do the same for HiSLIP.

[lundmar]

New versions of lxi-tools and liblxi are available at https://lxi-tools.github.io

Updates includes some important bug fixes that resolve issues with timeout and receive errors. The API used to connect has also been improved.

For those using Fedora there will be updated packages available in 1-2 weeks or so.

[lundmar]

A new version of lxi-tools has been released - see https://github.com/lxi-tools/lxi-tools

The screenshot feature has now become a subcommand of the lxi tool instead of the separate tool rigol_1000z_screenshot.

Code: [Select]

Usage: lxi [--version] [--help] <command> [<args>]                                                  

  -v, --version                       Display version                                               
  -h, --help                          Display help                                                  

Commands:                
  discover [<options>]                Search for LXI devices                                        
  scpi [<options>] <scpi-command>     Send SCPI command                                             
  screenshot [<options>] <filename>   Capture screenshot to file                                    

Discover options:        
  -t, --timeout <seconds>             Timeout (default: 3)                                          

Scpi options:            
  -a, --address <ip>                  Device IP address                                             
  -t, --timeout <seconds>             Timeout (default: 3)                                          
  -x, --dump-hex                      Print response in hexadecimal                                 
  -f, --dump-file <filename>          Save response to file                                         
  -i, --interactive                   Enter interactive mode                                        
  -s, --script <filename>             Run script file                                               

Screenshot options:      
  -a, --address <ip>                  Device IP address                                             
  -t, --timeout <seconds>             Timeout (default: 3)                                          
  -m, --model <name>                  Name of device model (model/family)                           
  -l, --list                          List supported device models                                  

Code: [Select]

EXAMPLES
       Send SCPI command to LXI device:

              lxi scpi -a 192.168.0.42 "*IDN?"

       Capture screenshot from LXI device with specific model/family:

              lxi screenshot -a 192.168.0.42 -m rigol-1000z my-screenshot.png

Also added is a small screenshot plugin framework which makes it possible to easily add screenshot support for new instruments for those interested in doing so.

[RoGeorge]

I noticed that running "lxi discover" does not find any instrument when running on a Debian 8.0 installed in a VMware machine that is running under Windows 10, but sending SCPI commands to specified addresses works just fine.

- The Debian 8 VMware machine is set to use "NAT: Used to share the host's IP address".
- All the Rigol instruments respond when pinged from Deb8.
- In the PC there are 2 physical network cards, one of them is used for the instruments, 192.168.1.*, the other physical network card is for Internet connection, 192.168.100.*
- Both the Internet and the ping to any Rigol instrument works just fine from either Win10 or the Deb8 VMware machine.

For the moment I don't have a native Debian 8 installation without using VMware.

Is this a bug?

Code: [Select]

[email protected]:~$ lxi scpi -a 192.168.1.3 *IDN?
RIGOL TECHNOLOGIES,DS1104Z,DS1ZA16*,00.04.04.SP3
[email protected]:~$ lxi scpi -a 192.168.1.4 *IDN?
RIGOL TECHNOLOGIES,DP832,DP8C16*,00.01.11
[email protected]:~$ lxi scpi -a 192.168.1.5 *IDN?
Rigol Technologies,DG4102,DG4E17*,00.01.12
[email protected]:~$ lxi discover
Searching for LXI devices - please wait...

Broadcasting on interface lo
Broadcasting on interface eth0

No devices found

[email protected]:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:0c:29:*:*:* brd ff:ff:ff:ff:ff:ff
    inet 192.168.146.134/24 brd 192.168.146.255 scope global dynamic eth0
       valid_lft 1711sec preferred_lft 1711sec
    inet6 fe80::20c:*:*:*/64 scope link 
       valid_lft forever preferred_lft forever
[email protected]:~$ 

[lundmar]

I noticed that running "lxi discover" does not find any instrument when running on a Debian 8.0 installed in a VMware machine that is running under Windows 10, but sending SCPI commands to specified addresses works just fine.

- The Debian 8 VMware machine is set to use "NAT: Used to share the host's IP address".

Thats your problem right there - broadcast messages do not translate through NAT and so the lxi discover command will never receive a response from your instrument.

The way to solve it is reconfiguring your VMWare guest to use a bridged network adapter instead of a NAT one.

FYI - lxi discover is tested to work fine with a bridged network adapter from a guest under VirtualBox. I highly recommend using VirtualBox instead of VMWare, but for other reasons

[lundmar]

I've added screenshot support for more instruments:

Code: [Select]

$ lxi screenshot --list
            Name   Description
keysight-iv2000x   Keysight InfiniVision 2000 X series oscilloscopes (experimental)
           rigol   Rigol 1000z/2000/4000 series oscilloscopes
      rs-hmo1000   Rohde & Schwarz HMO 1000 series oscilloscopes (experimental)
  tektronix-2000   Tektronix MSO/DPO 2000 series oscilloscopes (experimental)

It's experimental since I don't have the instruments to test on. But in theory it should work assuming the instrument documentation is accurate

Example:

Code: [Select]

lxi screenshot --adress 192.168.0.40 --model rigol screenhot.png
Saved PNG screenshot image to screenhot.png

[RoGeorge]

Great, thank you! 

Questions and comments:

- AFAIK all Rigol oscilloscopes use the same SCPI command for a screenshot. Why it was necessary in the code to separate them by 1000/2000/4000 models?
- Also, since lxi-tools allows running a SCPI text file, why not just defining a text SCPI file for each instrument, so the user can add its own instrument any time?
- A thing that I noticed when capturing screenshots with my software was that I was lazy enough to write a small script to increment the file name, so I made the code to put a timestamp in the filename. That was useful because once a command it's typed in the terminal, it's very easy to repeat it by simply "up arrow" and "enter", and the previous screenshot files will not be overwritten.
- I can add screnshots for the Rigol DG4000 DDS signal generators if you want, and for the Rigol DP832 power source. Should I make a pull request, or just tell you here the SCPI commands after manually testing them on my instruments?

[lundmar]

- AFAIK all Rigol oscilloscopes use the same SCPI command for a screenshot. Why it was necessary in the code to separate them by 1000/2000/4000 models?

I know. It is the exact same plugin code being run for all the rigol model names but I though it looked better in the list but I think I will end up collapsing it back into one model name "rigol".

- Also, since lxi-tools allows running a SCPI text file, why not just defining a text SCPI file for each instrument, so the user can add its own instrument any time?

The point of the screenshot command is to make it extremely simple to quickly grab a screenshot from a supported model. The best thing for users to do is to simply push a plugin upstream or use liblxi to solve their screenshot needs. Also, you cant easily define in a text file how to strip headers/footers of various complexity - it would quickly become a messy solution. However, I have been pondering to add support for maybe sending/receiving binary data via files using the "lxi scpi" command, in which case users can do whatever they want, even implement screenshot capturing for unsupported models even though I would prefer them to push plugins so everyone can benefit.

- A thing that I noticed when capturing screenshots with my software was that I was lazy enough to write a small script to increment the file name, so I made the code to put a timestamp in the filename. That was useful because once a command it's typed in the terminal, it's very easy to repeat it by simply "up arrow" and "enter", and the previous screenshot files will not be overwritten.

I want the user to be able to explicitly define the resulting filename regardless of image format. This way you can do exactly what you just have done via scripting. But maybe I could make the filename optional so that if no filename is provided it will automatically save to screenshot001.png, screenshot002.png, etc.. Timestamp is not necessary as it would be redundant information since files include a time stamp. **DONE**

- I can add screnshots for the Rigol DG4000 DDS signal generators if you want, and for the Rigol DP832 power source. Should I make a pull request, or just tell you here the SCPI commands after manually testing them on my instruments?

Sure, do a pull request if you want to take a shot at the code. Actually, I was looking a bit quickly through the DP832 docs but didn't find the scpi command for capturing screenshots. I assume it is the same as other rigols but I'm not sure. If not, we can quickly create plugins for specific Rigol models.

[lundmar]

FYI - I've added raw/TCP support for sending commands:

Code: [Select]

lxi scpi --raw --address 192.168.0.42 "*IDN?"
RIGOL TECHNOLOGIES,DS1104Z,DS1ZA1234567890,00.04.04.SP3

It is faster than VXI-11 but does not provide the same advantages that VXI-11 brings, in particular there is no timeout/control handling in case your SCPI command somehow stalls/crashes.

A configurable communications backend has also been added to liblxi in the effort to support raw/TCP and also in preparation for adding support for HiSlip/TCP in the future.

These changes will be included in the upcoming releases.

[lundmar]

- I can add screnshots for the Rigol DG4000 DDS signal generators if you want, and for the Rigol DP832 power source. Should I make a pull request, or just tell you here the SCPI commands after manually testing them on my instruments?

Please, if you can don't hesitate to test the lxi tool with any LXI/LAN enabled instrument you have


I'm looking to hear from anyone who would like to test lxi-tools with their LXI/LAN instruments so that we can improve it steadily. The more instruments that the tools are tested against the better. I'm going to add a list of tested instruments in the README.

[RoGeorge]

I can test DG4102 screenshot when I'll return home, maybe next Monday or Tuesday.

[rhb]

FYI

liblxi fails in ./configure because it can't find ifaddrs.h on Solaris 10 u8

lxi-tools fails in ./configure because it can't find libreadline even though liibreadline is in /app/lib and /app/lib is in LD_LIBRARY_PATH

FWIW I have 397 executables in /app/bin, all of which were compiled from source.

Back during the workstation wars I built a large system for SunOS, AIX, IRIX, CLIX, Ultrix and HP-UX with only two #ifdefs in the code.  One for byte sex and the other for FORTRAN record length.  The only build dependency was the presence of Gnu make on all systems.  We now have autotools just to make code portable across linux distros.

[lundmar]

FYI

liblxi fails in ./configure because it can't find ifaddrs.h on Solaris 10 u8

lxi-tools fails in ./configure because it can't find libreadline even though liibreadline is in /app/lib and /app/lib is in LD_LIBRARY_PATH

FWIW I have 397 executables in /app/bin, all of which were compiled from source.

Back during the workstation wars I built a large system for SunOS, AIX, IRIX, CLIX, Ultrix and HP-UX with only two #ifdefs in the code.  One for byte sex and the other for FORTRAN record length.  The only build dependency was the presence of Gnu make on all systems.  We now have autotools just to make code portable across linux distros.

I'm sorry but lxi-tools and liblxi are designed for use with GNU/Linux systems only.

I'm not surprised you run into issues trying to install it on Solaris and I can't really recommend doing so. If I'm not mistaken Solaris still uses the Solaris C library and clearly it does not include ifaddrs.h . The GNU C library includes it.

The autotools readline check included is a very basic one. If it fails it could be because of missing or wrong configure options.

[rhb]

Congratulations on recreating the major mistakes of the last 70 years.

Did you ever hear of POSIX?  RMS coined the name and the concept.  If you write to the C  and POSIX standards your code will run easily almost anywhere.  That was why that 500,000+ line mixture of C, FORTRAN, lex and yacc ran on all those different systems.  The package was a port from VMS and I insisted on conformance to standards.  It was in regular use for almost 20 years with no support at all for probably 10 years.  There were no bugs left.  We had fewer than a dozen user submitted bugs the first year of deployment and it went down from there.  Every build included a large test suite.  When we wrote a module, we wrote tests for it and ran it on all the supported platforms.  It makes you very sensitive to where the standards say that behavior is "undefined" or "implementation dependent".  So you don't do stupid stuff.

The readline check fails because autotools is semantically and conceptually broken.  It is *supposed* to look in all the directories in LD_LIBRARY_PATH.  I don't try to fix broken machine generated code.  I wasted an entire week trying to get Octave to work once because they botched the autotools setup.  Never mind that R compiled just fine.  I've compiled a lot of code that uses Gnu readline.  Ken Thompson wrote early versions of Unix in fewer lines than a configure script!

The consequence is simply that I shall write my own software rather than contribute to yours. A command line LXI interface is just an example program  from "Advanced Programming in the Unix Environment" by Stevens and Rago decorated with some LXI details.  It can also be done in python or perl, though I don't care much for either.

There's a Dilbert cartoon on the cover of Stevens and Rago that's very relevant.  The interchange in the last  frame is "You're one of those condescending Unix users."  "Here's a nickel, kid.  Get yourself a better computer."

[lundmar]

Congratulations on recreating the major mistakes of the last 70 years.

Did you ever hear of POSIX?  RMS coined the name and the concept.  If you write to the C  and POSIX standards your code will run easily almost anywhere.  That was why that 500,000+ line mixture of C, FORTRAN, lex and yacc ran on all those different systems.  The package was a port from VMS and I insisted on conformance to standards.  It was in regular use for almost 20 years with no support at all for probably 10 years.  There were no bugs left.  We had fewer than a dozen user submitted bugs the first year of deployment and it went down from there.  Every build included a large test suite.  When we wrote a module, we wrote tests for it and ran it on all the supported platforms.  It makes you very sensitive to where the standards say that behavior is "undefined" or "implementation dependent".  So you don't do stupid stuff.

The readline check fails because autotools is semantically and conceptually broken.  It is *supposed* to look in all the directories in LD_LIBRARY_PATH.  I don't try to fix broken machine generated code.  I wasted an entire week trying to get Octave to work once because they botched the autotools setup.  Never mind that R compiled just fine.  I've compiled a lot of code that uses Gnu readline.  Ken Thompson wrote early versions of Unix in fewer lines than a configure script!

The consequence is simply that I shall write my own software rather than contribute to yours. A command line LXI interface is just an example program  from "Advanced Programming in the Unix Environment" by Stevens and Rago decorated with some LXI details.  It can also be done in python or perl, though I don't care much for either.

There's a Dilbert cartoon on the cover of Stevens and Rago that's very relevant.  The interchange in the last  frame is "You're one of those condescending Unix users."  "Here's a nickel, kid.  Get yourself a better computer."

 

I'm sorry but I think your criticism is quite misdirected. I get a feeling you are angry for other reasons and you are just here to prolong whatever workstation wars you have been engaged in for years. I mean, it's all very nice stories but I can't fix the world for you.

Autotools is by no means perfect but it is still the preferred way of distributing software for GNU/Linux systems.

And let me repeat myself, lxi-tools and liblxi is written for GNU/Linux systems (as stated on the frontpage of https://lxi-tools.github.io and in all the READMEs). This means it will not work on POSIX only systems.

I'm a professional SW engineer and I'm a big fan of POSIX and I use it extensively in most software that I write. However, for some applications, part of the software rely on system level features which are not covered by any of the available POSIX standards. In case of liblxi I'm relying on specific interfaces that allows me to discover and manage all available network interfaces to be used in the lxi discover feature. No such interfaces are available via POSIX. Hence I write that part of the code specifically for GNU/Linux systems because it is the most popular platform out there in the *nix world.

To support Solaris I would have to write and maintain these code parts specifically for Solaris. Unfortunately, I simply don't have any plans to support Solaris. Why? Because fact is Solaris is a dying platform with a small and rapidly declining user base. This is true, now more than ever, especially since Oracle laid off the Solaris core development staff this year. R.I.P.

[RoGeorge]

Made a new build today and testing right now, so brace yourself for a lot of and , but no , even if you fully deserve all the appreciation.

While my general impression about lxi-tools is a very good one , and I highly appreciate what you already put there, in the next messages I will focus only on what I don't like, or on what didn't work as I expected. Many of them will rather be about my personal preferences and feature requests, maybe some misusage from my side, so not exactly a bug report. Didn't looked into the code yet.

I will repeatedly post here while testing, but I will avoid discussing solutions during testing, so please don't get annoyed if I don't reply until tomorrow.

[rhb]

I'm a professional SW engineer and I'm a big fan of POSIX and I use it extensively in most software that I write. However, for some applications, part of the software rely on system level features which are not covered by any of the available POSIX standards. In case of liblxi I'm relying on specific interfaces that allows me to discover and manage all available network interfaces to be used in the lxi discover feature. No such interfaces are available via POSIX. Hence I write that part of the code specifically for GNU/Linux systems because it is the most popular platform out there in the *nix world.

Other than not being portable to non-Gnu/Linux systems, I don't see what this does

int lxi_discover(struct lxi_info_t *info, int timeout)
{
    struct sockaddr_in *broadcast_addr;
    struct ifaddrs *ifap;
    int status;

    // Go through available broadcast addresses
    if (getifaddrs(&ifap) == 0)
    {
   struct ifaddrs *ifap_p = ifap;

   while (ifap_p)
   {
            if ((ifap_p->ifa_addr) && (ifap_p->ifa_addr->sa_family == AF_INET))
            {
      broadcast_addr = (struct sockaddr_in *) ifap_p->ifa_broadaddr;

      // Notify current broadcast address and network interface via callback
      if (info->broadcast != NULL)
                    info->broadcast(inet_ntoa(broadcast_addr->sin_addr), ifap_p->ifa_name);

      // Find LXI devices via broadcast address
      status = discover_devices(broadcast_addr, info, timeout);

            }
            ifap_p = ifap_p->ifa_next;
   }
   freeifaddrs(ifap);
    }

    return LXI_OK;

that can't be done with this from POSIX.1 aka IEEE Std 1003.1 2004

9964 NAME
19965 SYNOPSIS
19966 #include <net/if.h>
if_nameindex — return all network interface names and indexes
struct if_nameindex *if_nameindex(void);
19967
19968 DESCRIPTION
19969 The if_nameindex( ) function shall return an array of if_nameindex structures, one structure per
19970 interface. The end of the array is indicated by a structure with an if_index field of zero and an
19971 if_name field of NULL.
19972 Applications should call if_freenameindex( ) to release the memory that may be dynamically
19973 allocated by this function, after they have finished using it.
19974 RETURN VALUE
19975 An array of structures identifying local interfaces. A NULL pointer is returned upon an error,
19976 with errno set to indicate the error.
19977 ERRORS
19978 The if_nameindex( ) function may fail if:
[ENOBUFS]
19979
Insufficient resources are available to complete the function.
19980 EXAMPLES
19981 None.
19982 APPLICATION USAGE
19983 None.
19984 RATIONALE
19985 None.
19986 FUTURE DIRECTIONS
19987 None.
19988 SEE ALSO
19989 getsockopt ( ), if_freenameindex( ), if_indextoname( ), if_nametoindex( ), setsockopt ( ), the Base
19990 Definitions volume of IEEE Std 1003.1-2001, <net/if.h>

It looks to me as if ifaddrs got written so someone could claim to be a Linux kernel contributor on their resume.

Anger is not the correct word.  Annoyed is more accurate.  I hate seeing unportable code that could trivially have been written to be portable to any Unix system.   I've had to fix far too much of it.

Solaris is quite alive despite being So Larry's.  Illumos (nee OpenSolaris) is actively developed and maintained by a number of small companies.  And MacOS is Unix, as are FreeBSD, OpenBSD and NetBSD.

If you don't understand the absurdity of autotools, then you don't grok the Unix tradition.

In this particular instance, I probably will fix your code, starting with dumping autotools.  An error generated by a compiler or linker is trivial to fix.  An error generated by autotools is pretty much impossible.  The Octave and  autotools developers both blamed each other.

[RoGeorge]

Just in case somebody else want to give it a try starting from the github sources, I built lxi-tools like this (on a Debian 8.9 jessie):

Code: [Select]

cd ~
mkdir lxi-tools
cd lxi-tools/
git clone https://github.com/lxi/liblxi
cd liblxi/
su
apt-get update
apt-get install automake
apt-get install autogen autoconf libtool

./autogen.sh 
./configure
make
make install
cd ..

git clone https://github.com/lxi/lxi-tools
cd lxi-tools/
./autogen.sh

apt-get install libreadline-dev

./configure
make
make install

exit
cd ..

# not required any more ???
# export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/lib"

lxi

Test setup
Debian 8 running inside VMware 12 Player running inside Windows 10
Three LXI instruments are connected to LAN:

• 192.168.1.3 is a Rigol DS1054Z oscilloscope
• 192.168.1.4 is a Rigol DP832 power supply
• 192.168.1.5 is a Rigol DG4102 arbitrary waveform generator

Tested commands

1.

Code: [Select]

[email protected]:~/lxi-tools$ lxi
Usage: lxi [--version] [--help] <command> [<args>]

  -v, --version                        Display version
  -h, --help                           Display help

Commands:
  discover [<options>]                 Search for LXI devices
  scpi [<options>] <scpi-command>      Send SCPI command
  screenshot [<options>] [<filename>]  Capture screenshot

Discover options:
  -t, --timeout <seconds>              Timeout (default: 3)

Scpi options:
  -a, --address <ip>                   Device IP address
  -t, --timeout <seconds>              Timeout (default: 3)
  -x, --dump-hex                       Print response in hexadecimal
  -f, --dump-file <filename>           Save response to file
  -i, --interactive                    Enter interactive mode
  -s, --script <filename>              Run script file
  -r, --raw                            Use raw/TCP
  -p, --raw-port <port>                Use raw/TCP port (default: 5555)

Screenshot options:
  -a, --address <ip>                   Device IP address
  -t, --timeout <seconds>              Timeout (default: 15)
  -m, --model <name>                   Name of model
  -l, --list                           List supported models

[email protected]:~/lxi-tools$ 

Passed

2.

Code: [Select]

[email protected]:~/lxi-tools$ lxi --version
lxi v1.6
[email protected]:~/lxi-tools$ lxi -v
lxi v1.6
[email protected]:~/lxi-tools$ lxi -h
Usage: lxi [--version] [--help] <command> [<args>]

  -v, --version                        Display version
  -h, --help                           Display help

Commands:
  discover [<options>]                 Search for LXI devices
  scpi [<options>] <scpi-command>      Send SCPI command
  screenshot [<options>] [<filename>]  Capture screenshot

Discover options:
  -t, --timeout <seconds>              Timeout (default: 3000)

Scpi options:
  -a, --address <ip>                   Device IP address
  -t, --timeout <seconds>              Timeout (default: 3000)
  -x, --dump-hex                       Print response in hexadecimal
  -f, --dump-file <filename>           Save response to file
  -i, --interactive                    Enter interactive mode
  -s, --script <filename>              Run script file
  -r, --raw                            Use raw/TCP
  -p, --raw-port <port>                Use raw/TCP port (default: 5555)

Screenshot options:
  -a, --address <ip>                   Device IP address
  -t, --timeout <seconds>              Timeout (default: 15000)
  -m, --model <name>                   Name of model
  -l, --list                           List supported models

[email protected]:~/lxi-tools$ lxi --help
Usage: lxi [--version] [--help] <command> [<args>]

  -v, --version                        Display version
  -h, --help                           Display help

Commands:
  discover [<options>]                 Search for LXI devices
  scpi [<options>] <scpi-command>      Send SCPI command
  screenshot [<options>] [<filename>]  Capture screenshot

Discover options:
  -t, --timeout <seconds>              Timeout (default: 3000)

Scpi options:
  -a, --address <ip>                   Device IP address
  -t, --timeout <seconds>              Timeout (default: 3000)
  -x, --dump-hex                       Print response in hexadecimal
  -f, --dump-file <filename>           Save response to file
  -i, --interactive                    Enter interactive mode
  -s, --script <filename>              Run script file
  -r, --raw                            Use raw/TCP
  -p, --raw-port <port>                Use raw/TCP port (default: 5555)

Screenshot options:
  -a, --address <ip>                   Device IP address
  -t, --timeout <seconds>              Timeout (default: 15000)
  -m, --model <name>                   Name of model
  -l, --list                           List supported models

[email protected]:~/lxi-tools$ 

Failed - Cosmetic
Help syntax "Usage: lxi [--version] [--help] <command> [<args>]" suggests <command> is mandatory and the rest optional, but <command> is not mandatory i.e for help and version. Maybe consider "help" and "version" as commands instead of options, or change the help to something like "Usage: lxi --version | --help | <command> [<args>]"

3.

Code: [Select]

[email protected]:~/lxi-tools$ lxi discover
Searching for LXI devices - please wait...

Broadcasting on interface lo
Broadcasting on interface eth0
    Found "RIGOL TECHNOLOGIES,DS1104Z,DS1ZA16*,00.04.04.SP3" on address 192.168.1.3
    Found "Rigol Technologies,DG4102,DG4E17*,00.01.12
4.SP3" on address 192.168.1.5
    Found "RIGOL TECHNOLOGIES,DP832,DP8C16*,00.01.11

4.SP3" on address 192.168.1.4

Found 3 devices

[email protected]:~/lxi-tools$ 

Failed - Major inconvenience
Leftovers from the previous instrument description text to the next instrument description. This must be investigated, just to be sure there is no out of range memory addressing at runtime.

The *IDN? answer for the last 2 instruments is:

Code: [Select]

[email protected]:~/lxi-tools$ lxi scpi -a 192.168.1.5 *IDN?
Rigol Technologies,DG4102,DG4E17*,00.01.12
[email protected]:~/lxi-tools$ lxi scpi -a 192.168.1.4 *IDN?
RIGOL TECHNOLOGIES,DP832,DP8C16*,00.01.11
[email protected]:~/lxi-tools$ 

[RoGeorge]

4.

Code: [Select]

[email protected]:~/lxi-tools$ lxi discovery
Error: No IP address specified
[email protected]:~/lxi-tools$ 

Failed - Minor inconvenience
Misleading error message. There is a typo in the command name, "discovery" instead of "discover",  not a missing IP.

[glarsson]

I hate seeing unportable code that could trivially have been written to be portable to any Unix system.   I've had to fix far too much of it.

Agree 100%. A common way to write code for Linux is to grep /usr/include until you find something. 

[RoGeorge]

5.

Code: [Select]

[email protected]:~/lxi-tools$ lxi scpi -r -a 192.168.1.3 "CHAN1:DISP?"
1
[email protected]:~/lxi-tools$ lxi scpi -a 192.168.1.3 "CHAN1:DISP?"
1
[email protected]:~/lxi-tools$ lxi scpi -a 192.168.1.3 -r "CHAN1:DISP?"
1
[email protected]:~/lxi-tools$ lxi scpi -ra 192.168.1.3 "CHAN1:DISP?"
1
[email protected]:~/lxi-tools$ lxi scpi -ra 192.168.1.3 "CHAN1 DISP?"
Command error
[email protected]:~/lxi-tools$ lxi scpi -a 192.168.1.3 "CHAN1 DISP?"
Error: Read error (timeout)
Error: Failed to receive message
[email protected]:~/lxi-tools$ 

Passed

[RoGeorge]

6.

Code: [Select]

[email protected]:~/lxi-tools$ lxi screenshot
Error: Missing address
[email protected]:~/lxi-tools$ lxi screenshot -a 192.168.1.3
Error: Missing model
[email protected]:~/lxi-tools$ lxi screenshot -a 192.168.1.3 -m rigol
Saved screenshot image to screenshot-000.png
[email protected]:~/lxi-tools$ lxi screenshot -a 192.168.1.3 -m rigol -f DS1Z_SCR.png
lxi: invalid option -- 'f'

Passed

Feature request 6.1. - add an option to specify the filename
Feature request 6.2. - add a shorter syntax, like "scr" for "screenshot"
Feature request 6.3. - make model optional, and auto identify the model using the IP and *IDN?
Feature request 6.4. - add an option for datetime-stamp in the filename
Feature request 6.5. - add an option for instrument ID in the filename (can be more than just 1 oscilloscope on the same network, so after a save there is no way to identify where from is the captured screen)
Feature request 6.5. - add an option to immediately open the captured screenshot - for making multiple screen captures (manually) until the best waveform is captured

[lundmar]

Made a new build today and testing right now, so brace yourself for a lot of and , but no , even if you fully deserve all the appreciation.

While my general impression about lxi-tools is a very good one , and I highly appreciate what you already put there, in the next messages I will focus only on what I don't like, or on what didn't work as I expected. Many of them will rather be about my personal preferences and feature requests, maybe some misusage from my side, so not exactly a bug report. Didn't looked into the code yet.

I will repeatedly post here while testing, but I will avoid discussing solutions during testing, so please don't get annoyed if I don't reply until tomorrow.

Thanks.

Don't worry, I'm always looking for constructive feedback so we can steadily improve the tools and squash any bugs found.

Thank you for your thorough testing. Let me comment on your findings accordingly:

1. Check.

2. I believe the way the commandline is described is fairly conventional. Yes, strictly speaking <command> is optional. However, you can't really do anything without the commands. I think it will only confuse users more if we make everything optional. Popular tools like git is described in a similar way.

3. Good catch. I've pushed a commit that should fix the issue. This is exactly why I need someone with multiple instruments to test I only have a single LXI instrument to test with

4. To be fixed. Update: FIXED

5. Check.

6.1 Already implemented,   "screenshot [<options>] [<filename>]  Capture screenshot" . If no filename is provided it will autoresolve it.

6.2 Sorry no. I'm not a fan of shorthand expressions like scr. To help lazy people the tool features full bash autocompletion Try e.g. 'source <prefix>/share/bash-completion/completions/lxi' to load completion
manually.

6.3 Seemingly a good idea. Assuming ID strings are consistent then it is possible. I think it should be added to the TODO list as a possible feature in the future. It is something that the screenshot plugin framework should be modified to support.

6.4 Hmm, you win. However, we don't want an option for it. I'll just add date-time by default Update: FIXED

6.5 Appending the ID is a bit more tricky since you don't want to include the full string in the screenshot filename. This is something that each screenshot plugin needs to handle because only it will know what to strip from the ID strings of the instruments it supports. This can work if ID strings are consistent, if not it will be troublesome. Add it to the TODO list. As an alternative and simpler solution we could append the model and IP to the filename.

6.6 A good idea but I think this feature should be reserved for a separate graphical screenshot tool to be included in lxi-tools. Something to put on the TODO list too. A simple QT or GTK application would do the job.

Btw. feel free to register a github account and submit any issues you find in the lxi-tools issue tracker: https://github.com/lxi/lxi-tools/issues . Using github issues makes it easier to track and manage issues.

[lundmar]

I hate seeing unportable code that could trivially have been written to be portable to any Unix system.   I've had to fix far too much of it.

Agree 100%. A common way to write code for Linux is to grep /usr/include until you find something. 

I don't think anyone disagrees here to the extend it is possible. Just be mindful not everything can be done in portable code and sometimes non-portable code is required, especially when dealing with hw interfaces.

Also, this is one open source project among many that I'm doing in the little spare time that I have available so I don't have the time to put endless rigor into making everything portable in the first go. That being said, anyone is welcome to contribute to the project and fix any issues they might find, including portability issues.

[glarsson]

I don't think anyone disagrees here to the extend it is possible. Just be mindful not everything can be done in portable code and sometimes non-portable code is required, especially when dealing with hw interfaces.

True, but the non-portable code can be located in separate files to make it easier to port to different platforms.

Also, this is one open source project among many that I'm doing in the little spare time that I have available so I don't have the time to put endless rigor into making everything portable in the first go. That being said, anyone is welcome to contribute to the project and fix any issues they might find, including portability issues.

I was looking at adding code to sigrok or port lxi-tools to macOS (a certified UNIX with a marketshare larger than Linux) but did get the feeling that contributions to lxi-tools supporting platforms other than Linux was not welcome.

[lundmar]

True, but the non-portable code can be located in separate files to make it easier to port to different platforms.

True, especially if there is a lot of it. Conditional ifdefs will do fine for smaller code bits, which is the case here.

I was looking at adding code to sigrok or port lxi-tools to macOS (a certified UNIX with a marketshare larger than Linux) but did get the feeling that contributions to lxi-tools supporting platforms other than Linux was not welcome.

Any contributions to improve lxi-tools or liblxi are welcome. Yes, it is initially made for and tested on GNU/Linux systems but that is mainly because I don't have the bandwidth nor access to test and support other platforms. In other words, I'm not opposed to supporting other platforms but only if someone would like to contribute/help maintain that support. That being said, not much is required to make it work on most platforms.

If you want to help make lxi-tools and liblxi work on macOS I welcome it 

[lundmar]

Other than not being portable to non-Gnu/Linux systems, I don't see what this does

vxi11_discover() iterates through the broadcast addresses of all available network interface. For each iteration it calls discover_devices() using the broadcast address to find the instruments.

Using getifaddrs() etc. is technically not portable code as it is not blessed by posix, it is however available on most platforms, including Linux, macOS, *BSD, and even Solaris 11+.

If you are not satisfied I invite your to contribute a variant of vxi11_discover() that works on your platform. Making it 100% portable is likely not possible since platforms like Linux are fading away their IOCTL support for retrieving network interface information (broadcast addresses etc.) in favor of a more efficient netlink mechanism.

By the way, you are looking at some old code there. See https://github.com/lxi/liblxi for latest.

[rhb]

FWIW I started porting it to Solaris 10 u8.  It's actually nicely written code from the little  I've looked at.  The code I'm using was downloaded from github as a tarball after you started this thread.  So I'm not sure how you can call it old.  Once I've got it running on Solaris, it will work on MacOS and *nix in general. 

if_nameindex() returns all the network interfaces and *is* part of  POSIX  and on Solaris 10 u8 which is so ancient I keep it off the Internet. It's the last Sun released version before it became So Larry's. So as a rough guess, 10 years old.  But nothing can match the Sun/Forte debugger.  Everything else is "flint knives and stone axes".  And I've used probably a dozen different *nix  debuggers.

At the moment I've got lxi_discover() commented out while I deal with other Gnuisms.   Once I've got it to run, I'll fix lxi_discover().

Yes, I'm a grumpy old man.  I've supported over 2 million lines of badly written code that other people inflicted upon the world.  I'm really tired of seeing the same mistakes made over and over again.  IBM created JCL to fix the problem of hard coded filenames.  And of course, *everyone* using JCL knew that everything after a space was a comment because that was the 360 assembler convention. Then 10-20 years later the Motif mob hard coded  xkeysymdb.  After 20+ years I've finally forgotten where. We now have a version of xclock that consumes more memory than most of the computers I've used had available. Your phone needs more horsepower than a Cray YMP.  Ain't progress grand!

[lundmar]

FWIW I started porting it to Solaris 10 u8.  It's actually nicely written code from the little  I've looked at.  The code I'm using was downloaded from github as a tarball after you started this thread.  So I'm not sure how you can call it old.  Once I've got it running on Solaris, it will work on MacOS and *nix in general. 

Sounds good 

Sorry, I meant old as in 5 days old ... the code your are looking at is from before I did some rearrangements to support configurable communication backends (VXI11/TCP vs. RAW/TCP).

if_nameindex() returns all the network interfaces and *is* part of  POSIX  and on Solaris 10 u8 which is so ancient I keep it off the Internet.

Yes, however, getting interface names is not the problem. The problem is going from an interface name or index to actually retrieving the broadcast address in a portable way. I can't find any APIs for this except doing using ioctl() requests which is fine but not really well supported on recent Linux kernels anymore. From the little digging I've done this far I expect we need to do platform handling for this piece of code. I don't recall but I think this is the very reason I did what I did when I wrote this 2-3 years ago, I went with the seemingly most portable implementation.

Yes, I'm a grumpy old man.  I've supported over 2 million lines of badly written code that other people inflicted upon the world.  I'm really tired of seeing the same mistakes made over and over again.  IBM created JCL to fix the problem of hard coded filenames.  And of course, *everyone* using JCL knew that everything after a space was a comment because that was the 360 assembler convention. Then 10-20 years later the Motif mob hard coded  xkeysymdb.  After 20+ years I've finally forgotten where. We now have a version of xclock that consumes more memory than most of the computers I've used had available. Your phone needs more horsepower than a Cray YMP.  Ain't progress grand!

Well, I guess you earned your right to be grumpy

Please bear in mind that I'm doing this open source project among quite a few other open source projects that I maintain in the little spare time I have available, so don't expect everything to be perfect. I simply don't have the time to put the same rigor in this as I do in my professional software projects. That being said, I think it is in a fair shape and with the help from your guys (contributors) I'm sure we can steadily improve it and maybe add some interesting features along the way.

Also, I think we have more views in common than you might think. For example, I share your lack of enthusiasm for perl and python. This is one of the very reasons I created lxi-tools/liblxi - I wanted a proper implementation in C for my LXI instrument control needs.

[lundmar]

There have been lots of changes and bug fixes recently so I'm pushing new releases which are available for download at https://lxi.github.io

For a summary of changes see:

https://github.com/lxi/lxi-tools/releases/tag/v1.6
https://github.com/lxi/liblxi/releases/tag/v1.4

[lundmar]

The *IDN? answer for the last 2 instruments is:

Code: [Select]

[email protected]:~/lxi-tools$ lxi scpi -a 192.168.1.5 *IDN?
Rigol Technologies,DG4102,DG4E17*,00.01.12
[email protected]:~/lxi-tools$ lxi scpi -a 192.168.1.4 *IDN?
RIGOL TECHNOLOGIES,DP832,DP8C16*,00.01.11
[email protected]:~/lxi-tools$ 

Question, does the rigol screenshot plugin work with these two instruments?

Fun fact, after looking at the screenshot SCPI commands offered by various instruments I have to say that Rigol is by far the one with the most well structured / cleanest SCPI command syntax.  Instruments from the big manufacturers like Tektronix, Keysight, etc. have such cumbersome and illogically named commands. In other words, their syntax is influenced by too much legacy stuff that makes no sense in 2017. They could all do with a good cleanup.

[dpenev]

Hello,

I built lxi-tools from git. I get the following error.
What can be wrong?
 
[email protected]:~/lxi-tools/lxi-tools$ lxi discover
Searching for LXI devices - please wait...

Broadcasting on interface lo
Broadcasting on interface eth0
    Found "RIGOL TECHNOLOGIES,DS2302,DS2XXXXXXXXXXXXX,00.03.05.SP3" on address 192.168.1.59

Found 1 device

[email protected]:~/lxi-tools/lxi-tools$ lxi screenshot -a 192.168.1.59 -m rigol 
Error: Read error (timeout)
Error: Failed to receive message


Thanks
Dimitar

[lundmar]

[email protected]:~/lxi-tools/lxi-tools$ lxi discover
Searching for LXI devices - please wait...

Broadcasting on interface lo
Broadcasting on interface eth0
    Found "RIGOL TECHNOLOGIES,DS2302,DS2XXXXXXXXXXXXX,00.03.05.SP3" on address 192.168.1.59

Found 1 device

[email protected]:~/lxi-tools/lxi-tools$ lxi screenshot -a 192.168.1.59 -m rigol
Error: Read error (timeout)
Error: Failed to receive message

Thanks for the bug report. Apparently retrieving screenshots from the 2000 series scopes differs slightly from the 1000 series.

To solve this I've made separate plugins for each series.

Try update to the latest lxi-tools git and use the "rigol-2000" model.

Let me know if it works or fails. Thanks.

[dpenev]

Hi Lundmar,

Thank you for the fast update

lxi screenshot -a 192.168.1.59 -m rigol-2000 #Works fine now

I have following extra questions. Not sure which are important taking the current development plan in mind

1. Can there be a option for png instead of bmp? png are smaller.

2. The following doesn't work
[email protected]:~$ lxi scpi -ra 192.168.1.59 -m rigol-2000 "CHAN1 DISP?"
lxi: invalid option -- 'm'
[email protected]:~$ lxi scpi -ra 192.168.1.59  "CHAN1 DISP?"             
Error: Timeout
Error: Failed to receive message
Can I send scpi commands to my DS2000

3. I have Siglent SSA3021X instrument.
lxi screenshot -a 192.168.1.59  #Doesn't work for it. Is it a big deal to add support?

4. Few other test samples
lxi screenshot -m rigol-1000 #doesn't work for DP832.
lxi scpi -a 192.168.1.60  "*IDN?" #OK for my DP832.

It is interesting that for the DP832 If I send wrong scpi command I see "Wrong command" on the instrument display and I can not get any response from now on unless i reboot DP832. Is it a problem of DP832?

In general I think lxi-tools is a very good tool!
I  hope soon it will grow to support more instruments.
It can be a backbone for a real lab automation.
I really hate the big NI VISA drivers and stuff ... 

Thanks
Dimitar   

[lundmar]

lxi screenshot -a 192.168.1.59 -m rigol-2000 #Works fine now

1. Can there be a option for png instead of bmp? png are smaller.

The image format depends on which formats the instrument supports. PNG is certainly the preferred format but not all instruments support it. The Rigol 2000 series supports PNG for internal storage of screenshots but it is not documented whether it is possible to retrieve PNG remotely. Please try out the '"rigol_2000_png" branch and let me know if it creates a proper PNG for you. If not I'm afraid it is not possible unless the lxi tool itself starts doing BMP->PNG conversion but I think that is a bad idea. I would rather provide the raw material straight from the instrument and then the user can do as they please.

2. The following doesn't work
[email protected]:~$ lxi scpi -ra 192.168.1.59 -m rigol-2000 "CHAN1 DISP?"
lxi: invalid option -- 'm'

Correct. The scpi command does not accept '-m'. Only the screenshot command requires this in order to use the corresponding screenshot plugin.

See 'lxi --help' or 'man lxi' to see which options applies to which command.

[email protected]:~$ lxi scpi -ra 192.168.1.59  "CHAN1 DISP?"             
Error: Timeout
Error: Failed to receive message
Can I send scpi commands to my DS2000

Yes, I expect so. Please try without the '-r' option. The raw option is faster but also less reliable because it uses basic RAW/TCP instead of the VXI11/TCP. Perhaps the instrument has crashed maybe due to an invalid command in which case the instrument has a hard time to recover in case of RAW/TCP (handled better by VXI11).

3. I have Siglent SSA3021X instrument.
lxi screenshot -a 192.168.1.59  #Doesn't work for it. Is it a big deal to add support?

If the instrument is LXI compatible, that is, it supports the VXI11/TCP protocol then it should just work.

However, it is not clear to me which Siglent instruments supports VXI11. The documentation for Siglent instruments seem sparse on this topic.

It is possible this instrument does not support VXI11 in which case you might want to try the --raw option instead and maybe in combination with --raw-port if the default port differs from 5555. You might have to do some digging to figure out what port is used (if used at all).

Actually, I've been in contact with Siglent asking if they would like to support the project with some of their instruments for testing so that we can make the tools work with their instruments. Sadly, I haven't heard from them yet. Feel free to write Siglent and ask them to support this project. I think there is a Siglent support thread in this forum where they are listening

4. Few other test samples
lxi screenshot -m rigol-1000 #doesn't work for DP832.

I wouldn't expect it to since the plugin is tailored for the 1000z series scopes.

I took a quick look at the DP800 programmers manual and I couldn't find any evidence that it supports remote screenshot downloads so I'm afraid it is not possible to create a working plugin for this series unless there is an undocumented screenshot feature that I'm not aware of.

lxi scpi -a 192.168.1.60  "*IDN?" #OK for my DP832.

It is interesting that for the DP832 If I send wrong scpi command I see "Wrong command" on the instrument display and I can not get any response from now on unless i reboot DP832. Is it a problem of DP832?

Please try make sure _not_ to use the raw option in this case. We know that Rigol has issues with stalling invalid commands which ends up blocking the RAW/TCP channel. With VXI11/TCP the client tells the instrument that commands are executed under a certain timeout and it handles it accordingly so you can continue to send commands. With RAW/TCP there is no such mechanism.

In general I can't recommend using the --raw option unless you really need the performance gain.

In general I think lxi-tools is a very good tool!
I  hope soon it will grow to support more instruments.
It can be a backbone for a real lab automation.
I really hate the big NI VISA drivers and stuff ... 

Thanks
Dimitar

Thank you. Yes, I think you can get a long way with lxi-tools for convenient commandline operations. liblxi can also be quite useful if you are in need of a simple programmers API for your LXI instrument control needs. Hopefully it can grow into something useful for people who don't like the proprietary and often inferior tools. The very reason I authored lxi-tools/liblxi is because I wanted better tools for my GNU/Linux system. Also, I agree, stuff like NI VISA drivers etc. are just too bloated for my taste and not really open source friendly. I think we can do better. After all, LXI is an open standard so why not make some proper open source tools to support it 

[borjam]

Anger is not the correct word.  Annoyed is more accurate.  I hate seeing unportable code that could trivially have been written to be portable to any Unix system.   I've had to fix far too much of it.

(Warning, @Ludmar, not criticizing you although I really hope this can help instill a bit more love for portability!)

I bear your pain, dude.

And some Linux militant attitude certainly doesn't help. This week I sent a pull request to the OpenVSwitch project. A really stupidest, trivialest portability issue that certainly won't make me win an ACM Turing award.

What really annoyed me was the comment by the developer who accepted the pull request: "Ugh, another place that FreeBSD makes builds gratuitously fail."

A source file included <netinet/icmp6.h>, which, as usual, needs definitions from <sys/types.h>.

The original source looked like this:

Code: [Select]

#include <config.h>
#include <ctype.h>
#include <errno.h>
#include <netinet/in.h>
#include <netinet/icmp6.h>
#include <string.h>
#include <sys/types.h>

And it barfed on FreeBSD because <sys/types.h> is not included from <netinet/icmp6.h>. On Linux it is, it seems. What I
find really curious is that useless <sys/types.h> after <string.h> given that it's been included from <netinet/icmp6.h>.
<netinet/icmp6.h> actually includes <string.h>, <sys/types.h> and so on.

The fix for FreeBSD, OS X and presumably other *BSD derived networking code (anything but Linux, despite being *BSD
derived but sometimes seemingly butchered for the sake of it) was trivial, hence my shiny ACM Turing award. Just moving the <sys/types.h> to a position before <netinet/icmp6.h>. It always makes sense to put the #include lines more or less in a generalistic
to specialized order, so I moved it after <errno.h> (should have been ctypes.h but I was in "let's make this just work" mode and
I didn't give it a second thought).

Now, in the Linux world it seems to be customary to have system include files include themselves everything they need. I know
that lots of #include lines are annoying, but even if you are careful with #ifdef barriers and such I find it much better to have the programmer add the proper includes in the right order, so that you won't find portability surprises. But the Linux folks decided to somewhat hide all this...

Anyway what I found really annoying was the "Hey, FreeBSD breaking stuff" attitude. Linux manierism zealots don't help open source software at all, which is a pity.

[lundmar]

(Warning, @Ludmar, not criticizing you although I really hope this can help instill a bit more love for portability!)

I don't want to but let me make it clear anyway since this topic keeps popping up. I'm fully aware what it takes to make portable programs and I'm all for it. However, one has to start somewhere and in my case it means starting out making it work on the most popular platform and the one that I'm using - thats why I put the GNU/Linux stipulations on the projects. Since this is a project I'm doing in my sparse spare time I wanted to focus on features rather than portability to begin with. That being said, I welcome anyone who would like to contribute to the project by improving the code, and that includes fixing any portability issues also. I expect eventually we will remove the GNU/Linux stipulations once the portability issues have been addressed (the few that there are).

It's always easier to criticize than actually do

[HoracioDos]

I think you shouldn't give away your work, code it your own way and sell it.
Microsoft, Oracle, IBM have a proven business model. (We do what we want and not what you need and we charge for it)
PD: You should include a "Call Home" feature and sell usage stats. By the way I would donate a good red wine for Tio!

[lundmar]

By the way I would donate a good red wine for Tio!

Ha ha, well - I'm glad you like tio It's just a small no-nonsense serial tty tool with a simplified interface and a few useful features. Less is more.

[borjam]

Ha ha, well - I'm glad you like tio It's just a small no-nonsense serial tty tool with a simplified interface and a few useful features. Less is more.

Speaking of what I might feel inclined to send a bottle of Spanish red wine northwards

[lundmar]

Speaking of what I might feel inclined to send a bottle of Spanish red wine northwards

Guys don't send me that much red wine as I'm not much of a wine drinker. However, I'll accept some of that fine Argentinian beef and Spanish chorizo ha ha

[dpenev]

1. Can there be a option for png instead of bmp? png are smaller.

The image format depends on which formats the instrument supports. PNG is certainly the preferred format but not all instruments support it. The Rigol 2000 series supports PNG for internal storage of screenshots but it is not documented whether it is possible to retrieve PNG remotely. Please try out the '"rigol_2000_png" branch and let me know if it creates a proper PNG for you. If not I'm afraid it is not possible unless the lxi tool itself starts doing BMP->PNG conversion but I think that is a bad idea. I would rather provide the raw material straight from the instrument and then the user can do as they please.

I have tested the rigol_2000_png branch. It produce file with png extension but it is actually a bit map, same size, BMP header. 

2. The following doesn't work
[email protected]:~$ lxi scpi -ra 192.168.1.59 -m rigol-2000 "CHAN1 DISP?"
lxi: invalid option -- 'm'

Correct. The scpi command does not accept '-m'. Only the screenshot command requires this in order to use the corresponding screenshot plugin.

See 'lxi --help' or 'man lxi' to see which options applies to which command.

[email protected]:~$ lxi scpi -ra 192.168.1.59  "CHAN1 DISP?"             
Error: Timeout
Error: Failed to receive message
Can I send scpi commands to my DS2000

Yes, I expect so. Please try without the '-r' option. The raw option is faster but also less reliable because it uses basic RAW/TCP instead of the VXI11/TCP. Perhaps the instrument has crashed maybe due to an invalid command in which case the instrument has a hard time to recover in case of RAW/TCP (handled better by VXI11).

Yes without -r I seems to get better results, thank you.

3. I have Siglent SSA3021X instrument.
lxi screenshot -a 192.168.1.59  #Doesn't work for it. Is it a big deal to add support?

If the instrument is LXI compatible, that is, it supports the VXI11/TCP protocol then it should just work.

However, it is not clear to me which Siglent instruments supports VXI11. The documentation for Siglent instruments seem sparse on this topic.

It is possible this instrument does not support VXI11 in which case you might want to try the --raw option instead and maybe in combination with --raw-port if the default port differs from 5555. You might have to do some digging to figure out what port is used (if used at all).

Actually, I've been in contact with Siglent asking if they would like to support the project with some of their instruments for testing so that we can make the tools work with their instruments. Sadly, I haven't heard from them yet. Feel free to write Siglent and ask them to support this project. I think there is a Siglent support thread in this forum where they are listening

The Siglent SSA3000 programing manual is at http://www.siglentamerica.com/USA_website_2014/Documents/Program_Material/SSA3000X_ProgrammingGuide_PG0703X_E03D.pdf

Some results below which probably answers some of the questions you have defined ?
[email protected]:~/lxi-tools$ lxi scpi -a 192.168.1.61  "*IDN?"     
Siglent Technologies,SSA3032X,SSA3XXXXXXXXXXXXX,1.2.8.5a
[email protected]:~/lxi-tools$ lxi scpi -a 192.168.1.61  ":SYSTem:TIME?"
024429
[email protected]:~/lxi-tools$ lxi scpi -a 192.168.1.61  ":SYSTem:DATE?"
20171110
[email protected]:~/lxi-tools$ lxi scpi -a 192.168.1.61  "FREQuency:STAR?"
+1.2560000000E+07
[email protected]:~/lxi-tools$ lxi scpi -a 192.168.1.61  "FREQuency:STOP?"
+2.2560000000E+07
[email protected]:~/lxi-tools$ lxi scpi -a 192.168.1.61  ":MMEMory:STORe"
[email protected]:~/lxi-tools$ lxi screenshot -a 192.168.1.61
Error: Missing model
[email protected]:~/lxi-tools$ lxi screenshot -a 192.168.1.61 -m rigol-2000
Error: Failed to receive message
[email protected]:~/lxi-tools$ lxi screenshot -a 192.168.1.61 -m rigol-1000
Error: Failed to receive message
[email protected]:~/lxi-tools$ 

It seems ":MMEMory:STORe" can capture the screen but not sure if the data can be retreated remotely. 

4. Few other test samples
lxi screenshot -m rigol-1000 #doesn't work for DP832.

I wouldn't expect it to since the plugin is tailored for the 1000z series scopes.

I took a quick look at the DP800 programmers manual and I couldn't find any evidence that it supports remote screenshot downloads so I'm afraid it is not possible to create a working plugin for this series unless there is an undocumented screenshot feature that I'm not aware of.

I see

lxi scpi -a 192.168.1.60  "*IDN?" #OK for my DP832.

It is interesting that for the DP832 If I send wrong scpi command I see "Wrong command" on the instrument display and I can not get any response from now on unless i reboot DP832. Is it a problem of DP832?

Please try make sure _not_ to use the raw option in this case. We know that Rigol has issues with stalling invalid commands which ends up blocking the RAW/TCP channel. With VXI11/TCP the client tells the instrument that commands are executed under a certain timeout and it handles it accordingly so you can continue to send commands. With RAW/TCP there is no such mechanism.

In general I can't recommend using the --raw option unless you really need performance gain.

I see

Thank you
Dimitar

[lundmar]

I have tested the rigol_2000_png branch. It produce file with png extension but it is actually a bit map, same size, BMP header. 

Ok. Then it does not look like it is possible to download a PNG screenshot. BMP will have to do for the 2000 series.

The Siglent SSA3000 programing manual is at http://www.siglentamerica.com/USA_website_2014/Documents/Program_Material/SSA3000X_ProgrammingGuide_PG0703X_E03D.pdf

Some results below which probably answers some of the questions you have defined ?
[email protected]:~/lxi-tools$ lxi scpi -a 192.168.1.61  "*IDN?"     
Siglent Technologies,SSA3032X,SSA3XXXXXXXXXXXXX,1.2.8.5a
[email protected]:~/lxi-tools$ lxi scpi -a 192.168.1.61  ":SYSTem:TIME?"
024429
[email protected]:~/lxi-tools$ lxi scpi -a 192.168.1.61  ":SYSTem:DATE?"
20171110
[email protected]:~/lxi-tools$ lxi scpi -a 192.168.1.61  "FREQuency:STAR?"
+1.2560000000E+07
[email protected]:~/lxi-tools$ lxi scpi -a 192.168.1.61  "FREQuency:STOP?"
+2.2560000000E+07
[email protected]:~/lxi-tools$ lxi scpi -a 192.168.1.61  ":MMEMory:STORe"
[email protected]:~/lxi-tools$ lxi screenshot -a 192.168.1.61
Error: Missing model
[email protected]:~/lxi-tools$ lxi screenshot -a 192.168.1.61 -m rigol-2000
Error: Failed to receive message
[email protected]:~/lxi-tools$ lxi screenshot -a 192.168.1.61 -m rigol-1000
Error: Failed to receive message
[email protected]:~/lxi-tools$ 

It seems ":MMEMory:STORe" can capture the screen but not sure if the data can be retreated remotely. 

I did a quick scan through the manual and it does not seem like there is any documented ways to download a screenshot. Yes, you can store screenshots in the local memory subsystem but there are no ways to download that file remotely either. It's a bit silly they don't support such useful feature. Also, the description of each SCPI command is quite lacking. So, unfortunately it seems it will not be possible to create a screenshot plugin to support this Siglent instrument. I guess the only positive thing here is that sending scpi commands to the instrument works fine.

[dpenev]

Indeed,

BTW did you get some useful information from silentna about screen capture from their oscilloscopes?

Thanks
Dimitar

[lundmar]

Indeed,

BTW did you get some useful information from silentna about screen capture from their oscilloscopes?

Thanks
Dimitar

No useful details. SDS1000X/SDS2000X are claimed to support screenshots but without instruments to test on I'm going to focus on other features and instruments.

[lundmar]

Feature request 6.3. - make model optional, and auto identify the model using the IP and *IDN?

Thanks for this good idea feature request . I've implemented it in https://github.com/lxi/lxi-tools/commit/4b07a40e1c07afb099b0842a34e1f01e8031b462

This means that the lxi tool can now be used like this:

Code: [Select]

$ lxi screenshot --address 192.168.1.210 
Loaded rigol-1000 screenshot plugin
Saved screenshot image to screenshot_192.168.1.210_2017-11-10_16:07:48.png

The way it works is that it retrieves the ID string of the instrument and matches that against regular expressions provided in each plugin. The plugin with most matches is selected. Using regular expression matching is quite powerful so I expect this will work fine for future needs. Currently, only the Rigol plugins work with this feature as they are the only ones defining useful .regex entries. The other plugins will have to follow when someone shows up with real instruments that can be tested.

Also, I've done away with any model vs. plugin confusion and simplified the interface to manually specify which screenshot plugin to use:

Code: [Select]

$ lxi screenshot --address 192.168.1.210 --plugin rigol-1000
Saved screenshot image to screenshot_192.168.1.210_2017-11-10_16:08:36.png

Feature request 6.5. - add an option for instrument ID in the filename (can be more than just 1 oscilloscope on the same network, so after a save there is no way to identify where from is the captured screen)

I've implemented a compromise solution in https://github.com/lxi/lxi-tools/commit/080681f7af460b47c24ad09f46809fa65c5cb687

Trying to add unique instrument ID in the screenshot filename is troublesome because the IDN strings have no strictly guaranteed format (only guidelines) so we can run into all sorts of trouble trying to render something useful from it. Hence the alternative solution is to simply embed the instrument IP in the screenshot filename to help tell from which instrument screenshot files originate. It's not an unique identifier but it is sufficient for most use cases.

[lundmar]

Some important features and bug fixes have been added so I'm releasing a new version of lxi-tools:
https://github.com/lxi/lxi-tools/releases/download/v1.7/lxi-tools-1.7.tar.xz

For a summary of changes please see:
https://github.com/lxi/lxi-tools/releases/tag/v1.7

Thanks to especially RoGeorge for his thorough testing and useful feature requests. Also thanks to dpenev for his testing and help fixing the rigol-2000 screenshot plugin. I've added the instruments that you guys have tested working in the list of tested instruments in the README of lxi-tools.

P.S.: I want to add you guys to the list of contributors in the AUTHORS file. If you are ok with that, please let me know.

[lundmar]

I've refined and added some more information to the original post that started this thread. People might find it useful information.

[dpenev]

Hello,

A bit off topic but can be useful for someone .

I have SSA3021X and inspired by the lxi-tool I have implemented procedure to capture the instrument screen from a PC.
It uses lxi-tool to send ":MMEMory:STORe" command
and telnet to download the file.
I hope Siglent will implement a way to transfer a file using scpi command so this script will become unnecessary

extract the two scripts from the tar in a directory
from this directory execute

Code: [Select]

./ssa3000x_print print.png

Note that you need to specify the file name with the extension png.
I guess each time new file name is required. 
Files with path is not supported.

The shell scrip is not polished but is working for me.
Feel free to improve and please share.

Thanks
Dimitar   

[lundmar]

I hope Siglent will implement a way to transfer a file using scpi command so this script will become unnecessary

I hope so too. It's quite the detour to have to go manually retrieve the screenshot file like that through the back channel but nice job getting there

You should request Siglent to create a new firmware for the SSA3000 so that it becomes possible to simply dump the screenshot directly via the VXI11 channel. It would be faster and more elegant and should be trivial for them to implement.

I like the fact they are using TI AM335x but its funny to see how they did not remove the traces of the "evm" strings.

[lundmar]

I've pushed a new release of lxi-tools which adds a screenshot plugin for the new Siglent SDS1000X series scopes:

https://github.com/lxi/lxi-tools/releases/tag/v1.8

It's experimental, that is, it is not tested. If anyone has such an instrument feel free to try it out and let me know if it works. Thanks.

[lundmar]

3. I have Siglent SSA3021X instrument.
lxi screenshot -a 192.168.1.59  #Doesn't work for it. Is it a big deal to add support?

Update: I've added a screenshot plugin for the Siglent SSA3000X series spectrum analyzers.

It does not do a full screen capture but it captures the inner frame of interest, that is, the signal data window. Please try it out and let me know if it works.

Thanks to Jason from Siglent for providing the info necessary to create the plugin.

[dpenev]

Hi lundmar,

I have tested it from the git master and I get empty bmp.
I have checked  your plugin and I saw that you are not using the response from SCPI command or do I miss something?
In case this is a bug please check  screenshot_siglent-sds1000x.c as well.

[lundmar]

I have checked  your plugin and I saw that you are not using the response from SCPI command or do I miss something?
In case this is a bug please check  screenshot_siglent-sds1000x.c as well.

You are correct. I have pushed a fix for both Siglent screenshot plugins. Thanks.

FYI - I'm currently working on improving the discover feature by searching for instrument services using mDNS/DNS-SD. I'm curious if it will work with Siglent instruments because I know that the classic VXI11 discover feature that we support now does not work.

[dpenev]

Hello

Still the following doesn't work
 
lxi screenshot -a 192.168.1.61 -p siglent-ssa3000x /share/scr3.png
I am sending you the file I get


at my side
lxi discover
Searching for LXI devices - please wait...

Broadcasting on interface lo
Broadcasting on interface eth0
    Found "Siglent Technologies,SSA3032X,SSA3XXXXXXXXXX,1.2.8.5a" on address 192.168.1.61

Found 1 device

[lundmar]

lxi screenshot -a 192.168.1.61 -p siglent-ssa3000x /share/scr3.png
I am sending you the file I get

Hmm, does not look like a bitmap. I've pushed a new change to test. Can you try it out and send me a new file? Thanks.

Also, can you try without the -p option, just to see if it automatically loads the correct plugin.

at my side
lxi discover
Searching for LXI devices - please wait...

Broadcasting on interface lo
Broadcasting on interface eth0
    Found "Siglent Technologies,SSA3032X,SSA3XXXXXXXXXX,1.2.8.5a" on address 192.168.1.61

Found 1 device

Oh great. I was told by Siglent that some of their instruments may not discover but it could be a tool issue. Apparently the recent SSA and presumably also SDS works fine with the lxi-tools discover feature. Either way, we will soon have a discover --mdns option which will allow for finding even more instruments, in particular next gen LXI instruments

[lundmar]

FYI - I've released new versions of liblxi and lxi-tools which add support for searching for LXI instruments using mDNS/DNS-SD as described by the most recent LXI device specification.

This means it is now possible to discover modern LXI instruments that do not support the older VXI-11 discover mechanism.

To search for LXI instruments using mDNS/DNS-SD simply add the --mdns option to the discover command like so:

Code: [Select]

$ lxi discover --mdns

[dpenev]

Hi Lundmar

With the latest liblxi and lxi-tools I get:

[email protected]:/home/dpenev/lxi-tools/lxi-tools# lxi discover --mdns
lxi: unrecognized option '--mdns'
[email protected]:/home/dpenev/lxi-tools/lxi-tools# lxi discover
Searching for LXI devices - please wait...

Error: Unknown discover type (532306400)

No devices found

[email protected]:/home/dpenev/lxi-tools/lxi-tools#

[lundmar]

Hi Lundmar

With the latest liblxi and lxi-tools I get:

[email protected]:/home/dpenev/lxi-tools/lxi-tools# lxi discover --mdns
lxi: unrecognized option '--mdns'
[email protected]:/home/dpenev/lxi-tools/lxi-tools# lxi discover
Searching for LXI devices - please wait...

Error: Unknown discover type (532306400)

No devices found

[email protected]:/home/dpenev/lxi-tools/lxi-tools#

It looks like you are not running latest version of lxi-tools. I assume you are pulling the latest from git? Perhaps you forgot to run make install?

Both liblxi and lxi-tools must match latest versions.

Also, for the new feature to work you must install libavahi-core-dev libavahi-common-dev libavahi-client-dev

[dpenev]

Hello,

I tried the latest version

"lxi discover" is working for my Rigol DS2000 scope and my Siglent SSA3000 amalyzer

[email protected]:~/lxi-tools/lxi-tools$ lxi discover --mdns
Searching for LXI devices - please wait...

No services found

Should I start something on my PC?

Screenshot for SSA3000  doesn't work at my side
lxi screenshot -a 192.168.1.61 -p siglent-ssa3000x scr10.png

I am attaching two files I get with line like the above.

[lundmar]

I tried the latest version

"lxi discover" is working for my Rigol DS2000 scope and my Siglent SSA3000 amalyzer

Great. Thanks for testing 

[email protected]:~/lxi-tools/lxi-tools$ lxi discover --mdns
Searching for LXI devices - please wait...

No services found

Should I start something on my PC?

No, its fine. It simply means that these particular instruments do not advertise their presence using mDNS. It's a relatively new feature that many LXI instruments do not support yet.

Screenshot for SSA3000  doesn't work at my side
lxi screenshot -a 192.168.1.61 -p siglent-ssa3000x scr10.png

I am attaching two files I get with line like the above.

Yeah, the files still look like they contain rubbish. There is a pattern but it is certainly not PNG. Perhaps I'm missing some SCPI commands to reconfigure the instrument for PNG image format. I will talk to Siglent to check if I'm missing something here.

By the way, could you please try firing the following command:

Code: [Select]

lxi screenshot -a 192.168.1.61

And tell me if it autodetects the correct screenshot plugin ("siglent-ssa3000x"). Thanks.

[PeDre]

I have added some plugins for Rigol devices, the changed files are in the tar archive.
I can't handle git yet.

Peter

[email protected]:~/Programme/lxi/bin$ ./lxi screenshot --list
            Name   Description
keysight-iv2000x   Keysight InfiniVision 2000X series oscilloscopes (experimental)
      rigol-1000   Rigol DS/MSO 1000z series oscilloscopes
      rigol-2000   Rigol DS/MSO 2000 series oscilloscopes
    rigol-dg4000   Rigol DG4000 series function generator
    rigol-dm3000   Rigol DM3000 series digital multimeter
     rigol-dp800   Rigol DP800 series power supply
    rigol-dsa800   Rigol DSA800 series spectrum analyzer
    rigol-dsa700   Rigol DSA700 series spectrum analyzer
      rs-hmo1000   Rohde & Schwarz HMO 1000 series oscilloscopes (experimental)
siglent-sds1000x   Siglent SDS 1000X series oscilloscopes (experimental)
siglent-ssa3000x   Siglent SSA 3000X series spectrum analyzers (experimental)
  tektronix-2000   Tektronix DPO/MSO 2000 series oscilloscopes (experimental)

Edit: tar archiv  new uploaded

[lundmar]

I have added some plugins for Rigol devices, the changed files are in the tar archive.
I can't handle git yet.

Peter

[email protected]:~/Programme/lxi/bin$ ./lxi screenshot --list
            Name   Description
keysight-iv2000x   Keysight InfiniVision 2000X series oscilloscopes (experimental)
      rigol-1000   Rigol DS/MSO 1000z series oscilloscopes
      rigol-2000   Rigol DS/MSO 2000 series oscilloscopes
    rigol-dg4000   Rigol DG4000 series function generator
    rigol-dm3000   Rigol DM3000 series digital multimeter
     rigol-dp800   Rigol DP800 series power supply
    rigol-dsa800   Rigol DSA800 series spectrum analyzer
    rigol-dsa700   Rigol DSA700 series spectrum analyzer
      rs-hmo1000   Rohde & Schwarz HMO 1000 series oscilloscopes (experimental)
siglent-sds1000x   Siglent SDS 1000X series oscilloscopes (experimental)
siglent-ssa3000x   Siglent SSA 3000X series spectrum analyzers (experimental)
  tektronix-2000   Tektronix DPO/MSO 2000 series oscilloscopes (experimental)

Edit: tar archiv  new uploaded

Thanks Peter, good stuff 

I've merged your files and made a git commit on your behalf. See https://github.com/lxi/lxi-tools/commit/c0a4199c50f819e069d96285b7de89be927b8cb6

I would like to add you to the contributor list in the AUTHORS file (see https://github.com/lxi/lxi-tools/blob/master/AUTHORS ). I can add you as "PeDre from EEVBlog forum" or by name/email like the others listed. Please let me know what you prefer. Thanks.

Also, have you tested any of the plugins? If not, I will add "(experimental)" to the plugin descriptions.

Isn't it fascinating to see the many different ways Rigol do screenshot SCPI commands? Consistency across products is apparently not a thing at Rigol he he. However, I don't think other manufacturers do much better.

[PeDre]

The DM3068 is simulated, with my own programmed LXI server.
The DSA700 is identical to the DSA800.
The other devices have been tested.

Peter

Code: [Select]

[email protected]:~/Programme/lxi/bin$ ./lxi discover
Searching for LXI devices - please wait...

Broadcasting on interface lo
Broadcasting on interface enp2s0
  Found "Rigol Technologies,DG4162,DG4D135100282,00.01.12" on address 192.168.1.54
  Found "RIGOL TECHNOLOGIES,DP831,DP8F174900273,00.01.14" on address 192.168.1.55
  Found "RIGOL TECHNOLOGIES,MSO2302A,DS2F161650093,00.03.05.SP3" on address 192.168.1.52
  Found "Rigol Technologies,DM3068,DM301513679735,01.01.00.01.07.00" on address 192.168.1.37
  Found "Rigol Technologies,DSA815,DSA8A143300837,00.01.18.00.02" on address 192.168.1.51
  Found "RIGOL TECHNOLOGIES,DS1104Z,DS1ZB161150038,00.04.04.SP3" on address 192.168.1.53

Found 6 devices

[email protected]:~/Programme/lxi/bin$ ./lxi screenshot -a 192.168.1.54
Loaded rigol-dg4000 screenshot plugin
Saved screenshot image to screenshot_192.168.1.54_2017-11-23_18:53:19.bmp

[email protected]:~/Programme/lxi/bin$ ./lxi screenshot -a 192.168.1.55
Loaded rigol-dp800 screenshot plugin
Saved screenshot image to screenshot_192.168.1.55_2017-11-23_18:52:03.bmp

[email protected]:~/Programme/lxi/bin$ ./lxi screenshot -a 192.168.1.52
Loaded rigol-2000 screenshot plugin
Saved screenshot image to screenshot_192.168.1.52_2017-11-23_19:02:32.bmp

[email protected]:~/Programme/lxi/bin$ ./lxi screenshot -a 192.168.1.37
Loaded rigol-dm3000 screenshot plugin
Saved screenshot image to screenshot_192.168.1.37_2017-11-23_18:52:23.bmp

[email protected]:~/Programme/lxi/bin$ ./lxi screenshot -a 192.168.1.51
Loaded rigol-dsa800 screenshot plugin
Saved screenshot image to screenshot_192.168.1.51_2017-11-23_18:52:50.bmp

[email protected]:~/Programme/lxi/bin$ ./lxi screenshot -a 192.168.1.53
Loaded rigol-1000 screenshot plugin
Saved screenshot image to screenshot_192.168.1.53_2017-11-23_19:02:47.png

[dpenev]

the plugin for SSA3000x is automatically recognized, see bellow

[email protected]:~/lxi-tools/lxi-tools$ sudo lxi screenshot -a 192.168.1.61
Loaded siglent-ssa3000x screenshot plugin
Saved screenshot image to screenshot_192.168.1.61_2017-11-23_19:56:10.bmp

[lundmar]

The DM3068 is simulated, with my own programmed LXI server.
The DSA700 is identical to the DSA800.
The other devices have been tested.

Peter

Code: [Select]

[email protected]:~/Programme/lxi/bin$ ./lxi discover
Searching for LXI devices - please wait...

Broadcasting on interface lo
Broadcasting on interface enp2s0
  Found "Rigol Technologies,DG4162,DG4D135100282,00.01.12" on address 192.168.1.54
  Found "RIGOL TECHNOLOGIES,DP831,DP8F174900273,00.01.14" on address 192.168.1.55
  Found "RIGOL TECHNOLOGIES,MSO2302A,DS2F161650093,00.03.05.SP3" on address 192.168.1.52
  Found "Rigol Technologies,DM3068,DM301513679735,01.01.00.01.07.00" on address 192.168.1.37
  Found "Rigol Technologies,DSA815,DSA8A143300837,00.01.18.00.02" on address 192.168.1.51
  Found "RIGOL TECHNOLOGIES,DS1104Z,DS1ZB161150038,00.04.04.SP3" on address 192.168.1.53

Found 6 devices

[email protected]:~/Programme/lxi/bin$ ./lxi screenshot -a 192.168.1.54
Loaded rigol-dg4000 screenshot plugin
Saved screenshot image to screenshot_192.168.1.54_2017-11-23_18:53:19.bmp

[email protected]:~/Programme/lxi/bin$ ./lxi screenshot -a 192.168.1.55
Loaded rigol-dp800 screenshot plugin
Saved screenshot image to screenshot_192.168.1.55_2017-11-23_18:52:03.bmp

[email protected]:~/Programme/lxi/bin$ ./lxi screenshot -a 192.168.1.37
Loaded rigol-dm3000 screenshot plugin
Saved screenshot image to screenshot_192.168.1.37_2017-11-23_18:52:23.bmp

[email protected]:~/Programme/lxi/bin$ ./lxi screenshot -a 192.168.1.51
Loaded rigol-dsa800 screenshot plugin
Saved screenshot image to screenshot_192.168.1.51_2017-11-23_18:52:50.bmp

[/code]

Great, thanks. Then I will simply consider them all non-experimental and also add your instrument models to the list of tested instruments.

Your own LXI server? (VXI-11 or RAW?) Sounds interesting - is it something publicly available? What language is it written in?

FYI - I'm currently writing a full blown HiSlip/TCP client/server library in C so we can have first class open source HiSlip support on GNU/Linux systems and in particular lxi-tools of course.

Btw., you din't tell me how you would like to be added in the AUTHORS file.

Thanks.

[lundmar]

the plugin for SSA3000x is automatically recognized, see bellow

[email protected]:~/lxi-tools/lxi-tools$ sudo lxi screenshot -a 192.168.1.61
Loaded siglent-ssa3000x screenshot plugin
Saved screenshot image to screenshot_192.168.1.61_2017-11-23_19:56:10.bmp

Great, thanks. At least we know that feature works.

I'll get back to you once I get a response from Siglent on exactly what SCPI commands are required for PNG capture.

[PeDre]

The server is programmed in Xojo for Windows and uses VXI-11.
Was only programmed for a test for my screen capture program.
http://peter.dreisiebner.at/rigol-bildschirmkopie-lan/

I don't need to be named as an author.

Peter

[lundmar]

The server is programmed in Xojo for Windows and uses VXI-11.
Was only programmed for a test for my screen capture program.
http://peter.dreisiebner.at/rigol-bildschirmkopie-lan/

Nice. I don't know much of xojo but it looks cool.

I don't need to be named as an author.

Too late, I've already added you as "PeDre from EEVBlog forum" in the contributor section

I think it is best to do so on principle to show it is not a one man show and also to put credit where credit is due.

@RoGeorge, @depenev : I've also added both of you by EEVBlog nickname. I appreciate all the testing and ideas you guys have contributed - it has allowed me to vastly improve the tool over the last few weeks.

After all, I think it is appropriate since it is thanksgiving day in some parts of the world today

[lundmar]

The DSA700 is identical to the DSA800.
The other devices have been tested.

By the way, is there any chance any of the devices you have tested can be reconfigured for PNG screenshot download?

PNG is the preferred image format for the plugins so if it is possible that would be great. I know that DS2000 series only supports BMP for some unknown reason.

[lundmar]

FYI - I've made new releases. This time it is mostly documentation updates but also a bunch of new Rigol screenshot plugins thanks to PeDre.

[PeDre]

The DSA700 is identical to the DSA800.
The other devices have been tested.

By the way, is there any chance any of the devices you have tested can be reconfigured for PNG screenshot download?

PNG is the preferred image format for the plugins so if it is possible that would be great. I know that DS2000 series only supports BMP for some unknown reason.

The DSA800 can also handle screen shots in PNG format, but takes twice as long to do so.
The Rigol devices are fastest with the BMP format.
It is better to change the format when saving.

Peter

DSA815:

Code: [Select]

0020[08:14:59] ------------------------------------------------------------
0021[08:14:59] Sende SCPI-Kommando: :SYStem:SNAPscr? BMP
0022[08:15:11] Die Daten wurden in 12,2 Sekunden empfangen (12157,66 ms).
0023[08:15:20] ------------------------------------------------------------
0024[08:15:20] Sende SCPI-Kommando: :SYStem:SNAPscr? PNG
0025[08:15:45] Die Daten wurden in 24,2 Sekunden empfangen (24232,16 ms).
0026[08:15:57] ------------------------------------------------------------

[lundmar]

The DSA800 can also handle screen shots in PNG format, but takes twice as long to do so.
The Rigol devices are fastest with the BMP format.
It is better to change the format when saving.

Ok, I see. I thought PNG would be faster because of the smaller size but obviously the image compression is too costly in time for whatever CPU Rigol is using. Lets just keep it as it is then.

[3hristian]

Howdy,

I keep running into issues with LXI-TOOLS...
so far support from Lundar has been great. Jet spamming GitHub with issues that might only be my system isn't too great.

I have been following install instructions on this forum jet I got stuck here:
after installing LIB, and TOOLS trying to start the program on the command line.

Code: [Select]

$ lxi --help
lxi: error while loading shared libraries: liblxi.so.1: cannot open shared object file: No such file or directory

i am running

Code: [Select]

Linux LAB 4.4.0-53-generic #74-Ubuntu SMP Fri Dec 2 15:59:10 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Or

Code: [Select]

Linux Mint 18.1 Cinnamon 64-bit

if that floats your goat.

As solving this issue has many solutions hence I wanted to ask first before fumbling around.

[lundmar]

Howdy,

I keep running into issues with LXI-TOOLS...
so far support from Lundar has been great. Jet spamming GitHub with issues that might only be my system isn't too great.

I have been following install instructions on this forum jet I got stuck here:
after installing LIB, and TOOLS trying to start the program on the command line.

Code: [Select]

$ lxi --help
lxi: error while loading shared libraries: liblxi.so.1: cannot open shared object file: No such file or directory

i am running

Code: [Select]

Linux LAB 4.4.0-53-generic #74-Ubuntu SMP Fri Dec 2 15:59:10 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Or

Code: [Select]

Linux Mint 18.1 Cinnamon 64-bit

if that floats your goat.

As solving this issue has many solutions hence I wanted to ask first before fumbling around.

Hi 3hristian,

No worries, you just keep spamming github as much as you like - that is what is what the issue tracker is for

I'm sorry about your installation issue - luckily it's a temporary situation. I'm working on getting lxi-tools/liblxi into Debian so that they will eventually be included in distributions like Ubuntu and Mint. This way users don't have to bother with the challenges of manual installation. Currently software packages are being updated for Fedora. I hope to find a lxi-tools/liblxi maintainer for Debian soon.

Assuming you followed the git install instructions in the top of this thread to the letter then you shouldn't run into any issues with lxi-tools not finding liblxi. However, the issue you see can be bypassed by using for example this command:

Code: [Select]

$ LD_LIBRARY_PATH=$HOME/opt/lxi/lib ./lxi --version
v1.12

Or by simply exporting the variable like so and running the lxi tool:

Code: [Select]

$ export LD_LIBRARY_PATH=$HOME/opt/lxi/lib
$ lxi --version
lxi v1.12

Assuming your install location is $HOME/opt/lxi as suggested in the git install instructions.

[lundmar]

I realize that many people are not comfortable building and installing stuff from source. Unfortunately it takes quite some effort and time to find package maintainers for the various distributions and even then there is usually a large turnaround time to update packages

To try bypass these issues I've created a snap for lxi-tools.

This means that it is now possible to install the latest release version of lxi-tools on the most popular distributions like so:

Code: [Select]

$ snap install lxi-tools

The great thing about snaps is that I maintain the snap directly and when I update my lxi-tools snap it will be immediately available for users to install. No delay! 

It's pretty cool, check it out.

I've tested it on Fedora 27 and Ubuntu 17.10 but it should work on various other distributions too (Mint, ArchLinux, Debian, Gentoo, OpenSuse, Manjaro, etc.).

See https://snapcraft.io for how to install snap on your distribution.

P.s.: There is one minor issue though: after installing the lxi-tools snap the tool command is 'lxi-tools.lxi' and not 'lxi'. Will be fixed later.
P.p.s: lxi-tools snap details can be seen here: https://dashboard.snapcraft.io/dev/snaps/8744

[nctnico]

I realize that many people are not comfortable building and installing stuff from source. Unfortunately it takes quite some effort and time to find package maintainers for the various distributions and even then there is usually a large turnaround time to update packages

The easy way around that is to pack everything (including libraries) into a distribution independant package like firefox does. A statically linked binary should work well too.

[lundmar]

I realize that many people are not comfortable building and installing stuff from source. Unfortunately it takes quite some effort and time to find package maintainers for the various distributions and even then there is usually a large turnaround time to update packages

The easy way around that is to pack everything (including libraries) into a distribution independant package like firefox does. A statically linked binary should work well too.

That is true. However, there are some advantages to the snap solution because it actually includes and runs lxi-tools inside its own containerized Ubuntu core image runtime that runs specific versions of dynamic services like e.g. avahi that lxi-tools rely on for mDNS/DNS-SD discovery. If I do a static it is likely that the avahi dbus interface protocol will not work on various distributions because of version differences of their avahi daemon. Also, it's a big plus for end users that they can use the simple snap install command to manage their lxi-tools package and when I push updates they will have a super easy way to upgrade ('snap refresh lxi-tools'). In the end, that is simpler than messing with and setting up a static tarball that might or might not work. The snap support will only improve and spread to more distributions so for application distribution this is the future and I'm jumping right in he he. Once I get the last details of my lxi-tools snap sorted out it will be perfect.

[lundmar]

FYI - it is now possible to install latest development version using snap:

Code: [Select]

$ snap install lxi-tools --edge

The lxi-tools snap from the edge channel automatically follows the latest git version via automatic CI using https://build.snapcraft.io

Also, the lxi-tools snap is now built for the following architectures: amd64, i386, armhf

For those interested, here is the snapcraft configuration for the lxi-tools snap: https://github.com/lxi/lxi-tools.snapcraft

[lundmar]

FYI - I've renamed the website from lxi.github.io to lxi-tools.github.io

Also, there are new releases of lxi-tools and liblxi which include latest fixes and documentation changes.

New snaps are also available for instant upgrade. For those who already have lxi-tools snap installed try (note that it might already be automatically updated):

Code: [Select]

snap refresh lxi-tools

Or, if you don't have it installed already, simply:

Code: [Select]

snap install lxi-tools

After snap is installed, you will have to run this command:

Code: [Select]

$ snap alias lxi-tools.lxi lxi

To make the normal 'lxi' command work. Else only 'lxi-tools.lxi' will work. It's a temporary situation until my snap is approved automatic alias support by vote of the snap guys.

I've also created a new logo for the project just to spruce things up a bit

If anyone runs into issues installing using snap please let me know. Thanks.

[dpenev]

Hi lundmar,

Just to confirm that lxi snap and aliasing seem to be working fine on my Ubuntu 14.04 box.
 

[lundmar]

Hi lundmar,

Just to confirm that lxi snap and aliasing seem to be working fine on my Ubuntu 14.04 box.

Thats interesting, I didn't expect snaps to be supported on such old Ubuntu installations but I guess it only demonstrates how powerful snaps are.

Thanks for the feedback

Btw. I haven't heard from Siglent yet regarding the screenshot file format on the SSA3000 - I think most people are off due to extended Thanksgiving holidays.

[dpenev]

Oh it is not that old actually but yes I had to install snap demon and it doesn't come pre-installed out of the box 

[lundmar]

Oh it is not that old actually but yes I had to install snap demon and it doesn't come pre-installed out of the box

Still impressive though.

Oh by the way, I just got a response from Siglent and they provided me an undocumented SCPI command for doing a full screenshot capture on the SSA3000 series

In fact, I've already pushed a fix for the siglent-ssa300x plugin so you will be able  to test it immediately via the snap edge channel:

Code: [Select]

$ snap install lxi-tools --edge

Or, if you have it already installed, you can make sure it is up-to-date and using the edge channel like so:

Code: [Select]

$ snap refresh lxi-tools --edge

Please let me know if the plugin now works for you. You might have to take care to increase the default timeout as the image BMP data is rather large.

[BloodyCactus]

hmmm

Code: [Select]

> /snap/bin/lxi --version
cannot change current working directory to the original directory: Permission denied

> sudo /snap/bin/lxi --version
cannot change current working directory to the original directory: Permission denied

> cd /tmp
> lxi --version
lxi v1.13

oh, solved my own problem, posting here for posterity. You get the above error if you run it when your in an NFS mounted directory/path.


oh and screenshot fails on hmo-rs1000 (I have hmo1202)

Code: [Select]

> lxi screenshot -p rs-hmo1000 -a scope
Saved screenshot image to screenshot_scope_2017-11-28_19:55:38.png

> file screenshot_scope_2017-11-28_19\:55\:38.png 
screenshot_scope_2017-11-28_19:55:38.png: data

you can see the

Code: [Select]

'G' 0D 0A 1A 0A 00 00 00 0D

but we are missing

Code: [Select]

89 50 4E

the start of the PNG magic...



putting in the missing header shows a valid PNG from the scope

Code: [Select]

> file qq.png 
qq.png: PNG image data, 640 x 520, 8-bit colormap, non-interlaced

[lundmar]

hmmm

Code: [Select]

> /snap/bin/lxi --version
cannot change current working directory to the original directory: Permission denied

> sudo /snap/bin/lxi --version
cannot change current working directory to the original directory: Permission denied

> cd /tmp
> lxi --version
lxi v1.13

oh, solved my own problem, posting here for posterity. You get the above error if you run it when your in an NFS mounted directory/path.

Yeah, sorry about that.

It has to do with the way that snaps work. All snaps are running in a security enabled Linux container which means that the snap is only allowed access to certain subsystems. For example, in case of lxi-tools, it can only access your network and home directory (if it was not NFS network mounted). The main upside of having such level of security is that I am allowed to distribute updates quickly and directly to end users without having to go through the slow package update procedures of the various Linux distributions which can take weeks or even months sometimes. And the downsides... well, you just found one he he. That being said, I will investigate if it possible to reconfigure the snap to gain access to network mounted file systems.

oh and screenshot fails on hmo-rs1000 (I have hmo1202)

Code: [Select]

> lxi screenshot -p rs-hmo1000 -a scope
Saved screenshot image to screenshot_scope_2017-11-28_19:55:38.png

> file screenshot_scope_2017-11-28_19\:55\:38.png 
screenshot_scope_2017-11-28_19:55:38.png: data

you can see the

Code: [Select]

'G' 0D 0A 1A 0A 00 00 00 0D

but we are missing

Code: [Select]

89 50 4E

the start of the PNG magic...

Fixed! Thanks for the detailed debug info. It was very helpful

It's fixed in this commit: https://github.com/lxi-tools/lxi-tools/commit/04a7cbf9a61af9ead886d4a4a29ddc11b61cbe34

The git commit automatically triggers an update of the lxi-tools snap in the edge channel so you should be able to update to it immediately:

Code: [Select]

snap refresh lxi-tools --edge

By the way, can you please try fire this command?

Code: [Select]

 $ lxi screenshot -a scope 

Which should automatically load the correct screenshot plugin. If it fails please provide me the IDN string of your instrument.

Thanks

[BloodyCactus]

Code: [Select]

[ sgeorge @ workstation ] - [ /tmp ]  
[$]> lxi screenshot -a scope
Error: Read error (timeout)
Error: Failed to receive message
Error: Unable to retrieve instrument ID

needs a -p, so here is my IDN

Code: [Select]

Found "Rohde&Schwarz,HMO1202,nnnnnnnnn,05.886"

The "05.886" is firmware version.
The "nnnnnnnnn" is numeric serial number (I blanked mine out).
The "HMO1202" can change, depending on bandwidth ID code installed.

Doing

Code: [Select]

lxi screensscreenshot -p rs-hmo1000 -a scope
Saved screenshot image to screenshot_scope_2017-11-28_21:43:12.png

does not actually put "screenshot_scope_2017-11-28_21:43:12.png" on disk. not in my home directory, or anywhere...

ok. found them in

Code: [Select]

/tmp/snap.1000_lxi-tools_ql0gGm/tmp/

which is

Code: [Select]

drwx------   3 root    sgeorge 4.0K Nov 28 19:50 snap.1000_lxi-tools_ql0gGm

how very strange.

PNG do load correctly tho.

[lundmar]

Code: [Select]

[ sgeorge @ workstation ] - [ /tmp ]  
[$]> lxi screenshot -a scope
Error: Read error (timeout)
Error: Failed to receive message
Error: Unable to retrieve instrument ID

Hmm, strange. I didn't expect it to fail retrieving the ID. Can your please verify that the following command works for you?

Code: [Select]

$ lxi scpi -a scope "*IDN?"

If that also fails please try with IP address instead of 'scope'.

Doing

Code: [Select]

lxi screensscreenshot -p rs-hmo1000 -a scope
Saved screenshot image to screenshot_scope_2017-11-28_21:43:12.png

does not actually put "screenshot_scope_2017-11-28_21:43:12.png" on disk. not in my home directory, or anywhere...

ok. found them in

Code: [Select]

/tmp/snap.1000_lxi-tools_ql0gGm/tmp/

which is

Code: [Select]

drwx------   3 root    sgeorge 4.0K Nov 28 19:50 snap.1000_lxi-tools_ql0gGm

how very strange.

Yes, since your home directory is NFS network mounted, the lxi-tools snap can't access your home directory. And when you are in /tmp the security container redirects the files to the tmp of the snap. magic...

The good news is that the NFS home issue is apparently something which has been resolved and a fix should soon be available with newly released snap subsystems. Unfortunately, only recent Ubuntu and Fedora systems are deploying latest versions of snap/snapd. In other words, if you are running a recent Ubuntu version (e.g. 17.10)  chances are it will soon be available.

PNG do load correctly tho.

Good

[BloodyCactus]

Hmm, strange. I didn't expect it to fail retrieving the ID. Can your please verify that the following command works for you?

Code: [Select]

$ lxi scpi -a scope "*IDN?"

Code: [Select]

lxi scpi -a scope "*IDN?"
Rohde&Schwarz,HMO1202,nnnnnnnnn,05.886

lxi screenshot -a 192.168.0.107 also fails, without -p

Yes, since your home directory is NFS network mounted, the lxi-tools snap can't access your home directory. And when you are in /tmp the security container redirects the files to the tmp of the snap. magic...

my home dir isnt nfs mounted. (everything off my ~ is nfs mounted, but ~/ is physical). it works in my home dir. I was actually in /tmp (which is also phsycal), but I guess snap cant run from /tmp for security.

[lundmar]

Code: [Select]

lxi scpi -a scope "*IDN?"
Rohde&Schwarz,HMO1202,nnnnnnnnn,05.886

Ok good. Then something is different when the ID is retrieved using the screenshot command. I will have to review the code to see if I can spot the bug - I'll get back to you on this tomorrow.

my home dir isnt nfs mounted. (everything off my ~ is nfs mounted, but ~/ is physical). it works in my home dir. I was actually in /tmp (which is also phsycal), but I guess snap cant run from /tmp for security.

Ok, got it. Then the problem is not too bad then, except it is of course annoying for your use case that you can't have it write directly to your NFS share. Some say that it is possible for a snap to write to an NFS share if you use the 'mount --bind <location of nfs> <some mount dir in your home>' command to basically map/mount your NFS share into your home and this way the snap will see it as a normal dir.

[lundmar]

Code: [Select]

lxi scpi -a scope "*IDN?"
Rohde&Schwarz,HMO1202,nnnnnnnnn,05.886

Ok good. Then something is different when the ID is retrieved using the screenshot command. I will have to review the code to see if I can spot the bug - I'll get back to you on this tomorrow.

Ok, I've found and fixed the bug. It was a very silly and simple bug

The bug basically truncated the timeout to 1 ms when using the screenshot command which made retrieval of the instrument ID fail in your case.

The fix should be available via the edge channel now. Let me know if it works for you. Thanks.

[BloodyCactus]

Ok, I've found and fixed the bug. It was a very silly and simple bug

The bug basically truncated the timeout to 1 ms when using the screenshot command which made retrieval of the instrument ID fail in your case.

The fix should be available via the edge channel now. Let me know if it works for you. Thanks.

Code: [Select]

lxi screenshot -a scope -p rs-hmo1000

works.

Code: [Select]

> lxi screenshot -a scope 
Loaded rs-hmo1000 screenshot plugin

hangs.

no change when using IP. still hangs.

with gdb, I get (but probably not much good to you).

Code: [Select]

#0  0x00007ffff76b76f0 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007ffff76f14e3 in readtcp (ctptr=0x60a6b0 "\004", 
    buf=0x60e3d0 "d, Robert Gauthier, Floyd Wilder, Mark Drissel, Kenny Lyons,\n#  Paul Dunne, Tirath Pannu, Mike L", len=4000) at clnt_tcp.c:480
#2  0x00007ffff76ea946 in fill_input_buf (rstrm=0x60a770) at xdr_rec.c:567
#3  get_input_bytes (len=4, addr=0x7fffffbecbac "", rstrm=<optimized out>) at xdr_rec.c:586
#4  set_input_fragment (rstrm=<optimized out>) at xdr_rec.c:605
#5  xdrrec_getbytes (xdrs=<optimized out>, [email protected]=0x7fffffbecbfc "\377\177", [email protected]=4)
    at xdr_rec.c:262
#6  0x00007ffff76eab83 in xdrrec_getlong (xdrs=<optimized out>, lp=0x7fffffbecc18) at xdr_rec.c:218
#7  0x00007ffff76f6aab in __GI_xdr_u_long ([email protected]=0x60a718, [email protected]=0x7fffffbecca0) at xdr.c:214
#8  0x00007ffff76e9791 in __GI_xdr_replymsg ([email protected]=0x60a718, [email protected]=0x7fffffbecca0)
    at rpc_prot.c:135
#9  0x00007ffff76f12ae in clnttcp_call (h=0x60a690, proc=10, xdr_args=0x7ffff7bd07f1 <xdr_Create_LinkParms>, 
    args_ptr=0x7fffffbecdb0 "\220\246`", xdr_results=0x7ffff7bd0ad1 <xdr_Create_LinkResp>, 
    results_ptr=0x60a0e8 "\210\v\230\367\377\177", timeout=...) at clnt_tcp.c:287
#10 0x00007ffff7bd01e8 in create_link_1 () from liblxi.so.1
#11 0x00007ffff7bcedb2 in vxi11_connect () from liblxi.so.1
#12 0x00007ffff7bcea0e in lxi_connect () from liblxi.so.1
#13 0x0000000000404339 in rs_hmo1000_screenshot ()
#14 0x0000000000403525 in screenshot ()
#15 0x0000000000402384 in main ()

[lundmar]

Code: [Select]

> lxi screenshot -a scope 
Loaded rs-hmo1000 screenshot plugin

hangs.

Fixed!

New snap available.

What happened is that the automatic screenshot plugin detection first connects to the device to obtain the device ID which is used to automatically match which plugin to load and then it disconnects before it connects again later to retrieve the screenshot but someone forgot to disconnect and that obviously causes a hang for instruments that only support 1 active connection.

Thanks for the testing/debug

This is exactly the type of testing I'm looking for - the more instruments tested the better so we can catch and eliminate bugs like this.

Btw. I've added a new benchmark command which can be useful for comparing the VXI-11 request/response performance of instruments:

Code: [Select]

lxi benchmark -a <ip>

Example:

Code: [Select]

$ lxi benchmark -a 192.168.1.210
Benchmarking by sending 100 ID requests. Please wait...
Result: 19.5 requests/second

[dpenev]

Hello,

I got this:
[email protected]:~$ sudo snap refresh lxi-tools --edge     
snap "lxi-tools" has no updates available
[email protected]:~$ lxi -v
lxi v1.13
[email protected]:~$ lxi screenshot -a 192.168.1.61   
Loaded siglent-ssa3000x screenshot plugin
Error: Failed to receive message
[email protected]:~$

[lundmar]

Hello,

I got this:
[email protected]:~$ sudo snap refresh lxi-tools --edge     
snap "lxi-tools" has no updates available
[email protected]:~$ lxi -v
lxi v1.13

Thats's good. On some systems snaps automatically updates to the latest version available in their active channel (stable, candidate, beta, or edge).

[email protected]:~$ lxi screenshot -a 192.168.1.61   
Loaded siglent-ssa3000x screenshot plugin
Error: Failed to receive message
[email protected]:~$

Hmm. It looks like your SSA3000X instrument does not respond to or recognize the "SCDP." command.

I also notice you seem to be running the latest firmware

I'll talk to Siglent again to verify that the "SCDP." command is actually supported by latest public firmware.

Thanks for testing.

[lundmar]

FYI - I've updated the original post that started this thread to include install instructions/hints for getting lxi-tools working with Windows.

Perhaps some would like to share their experience with VMs and lxi-tools.

[dpenev]

Hi Lundmar,

I don't find SCDP command in the SSA3000X programming manual.

[lundmar]

Hi Lundmar,

I don't find SCDP command in the SSA3000X programming manual.

Hi,

True - I'm told it is an undocumented command that should work with SSA3000X. However, I suspect that maybe it is only available in firmware that has not been released yet. I'll check with Siglent to make sure and get back to you. It would be nice if we could get the screenshot plugin working seamlessly with this nice instrument.

[lundmar]

I don't find SCDP command in the SSA3000X programming manual.

I've updated the siglent-ssa3000x plugin - I've added some termination characters to the capture command which might make a difference for this particular instrument.

Let me know if that gets it going.

FYI - snap revision 110 or later:

Code: [Select]

$ snap info lxi-tools 
name:      lxi-tools
summary:   Open source LXI tools
publisher: lundmar
description: |
  Lxi-tools is a collection of open source software tools that enables control
  of LXI compatible instruments such as modern oscilloscopes, power supplies,
  spectrum analyzers etc.
snap-id: yha3V4dqfwJwpjSWgMFEMViAlQ2iMdL7
commands:
  - lxi-tools.lxi
tracking:    edge
installed:   1.13 (110) 14MB -
refreshed:   2017-12-01 02:08:58 +0100 CET
channels:               
  stable:    1.12 (42)  14MB -
  candidate: ?               
  beta:      ?               
  edge:      1.13 (110) 14MB -

[lundmar]

Following the usual rapid release cycle I have made a new release of lxi-tools available.

For an overview of the changes please see https://github.com/lxi-tools/lxi-tools/releases/tag/v1.13

This release adds a new simple benchmark feature. Also, some important fixes has gone into the screenshot feature.

Thanks to BloodyCactus for helping out ironing out the remaining issues with the Rohde & Schwarz HMO 1000 screenshot plugin

This release is available for install via the snap stable channel:

Code: [Select]

$ snap install lxi-tools

[HoracioDos]

Please stop improving this thing. I'm getting tired of compiling it almost every week 

[lundmar]

Please stop improving this thing. I'm getting tired of compiling it almost every week 

Ha ha HoracioDos

I can highly recommend you install via snap instead - it updates automatically. No need to manually compile stuff anymore

[HoracioDos]

I can highly recommend you install via snap instead - it updates automatically. No need to manually compile stuff anymore

I prefer flatpak or old school compile

[lundmar]

I can highly recommend you install via snap instead - it updates automatically. No need to manually compile stuff anymore

I prefer flatpak or old school compile

Well, it looks like snap is winning over flatpak in the popularity race... just saying

Either way, they are not that much different. They solve some of the same issues but snap provides a more straightforward and polished interface for end users.

[lundmar]

hmmm

Code: [Select]

> /snap/bin/lxi --version
cannot change current working directory to the original directory: Permission denied

> sudo /snap/bin/lxi --version
cannot change current working directory to the original directory: Permission denied

> cd /tmp
> lxi --version
lxi v1.13

oh, solved my own problem, posting here for posterity. You get the above error if you run it when your in an NFS mounted directory/path.

Oh, by the way. I don't know why I didn't think of this before but you can try install the snap with disabled confinement like so:

Code: [Select]

snap install lxi-tools --classic

Then of course rerun the snap alias command if you want to have it recognize the 'lxi' command.

Try it out - maybe that will solve your permission denied on NFS filesystems.

[crispus]

Hi,

I have a couple of suggestions:
1. a parameter for discover - either the network adress, interface name, etc (when you have many interfaces it takes some time)
2. I'm not able to take a screenshot on DM3058:

Code: [Select]

[email protected]: /s/l/out $ bin/lxi discover                   
Searching for LXI devices - please wait...

Broadcasting on interface lo
Broadcasting on interface eth0
  Found "Rigol Technologies,DM3058,DM3XXXX,01.01.00.02.02.00" on address 192.168.1.144

[email protected]: /s/l/out $ bin/lxi screenshot -a 192.168.1.144 screenshot
Loaded rigol-dm3000 screenshot plugin
<I can hear a beep on the multimeter>
<some time after>
Error: Read error (timeout)
Error: Failed to receive message
[email protected]: /s/l/out $ 

I do have the latest version built from github.

[lundmar]

Hi,

I have a couple of suggestions:
1. a parameter for discover - either the network adress, interface name, etc (when you have many interfaces it takes some time)

Perhaps I'll add an option for which interface to broadcast on. Something like:

Code: [Select]

$ lxi discover --interface wlan0

For now, to speed things up a bit, you can decrease the timeout. Usually '--timeout 1' is sufficient.

2. I'm not able to take a screenshot on DM3058:

Code: [Select]

[email protected]: /s/l/out $ bin/lxi discover                   
Searching for LXI devices - please wait...

Broadcasting on interface lo
Broadcasting on interface eth0
  Found "Rigol Technologies,DM3058,DM3XXXX,01.01.00.02.02.00" on address 192.168.1.144

[email protected]: /s/l/out $ bin/lxi screenshot -a 192.168.1.144 screenshot
Loaded rigol-dm3000 screenshot plugin
<I can hear a beep on the multimeter>
<some time after>
Error: Read error (timeout)
Error: Failed to receive message
[email protected]: /s/l/out $ 

I do have the latest version built from github.

Do you have the latest firmware from Rigol installed?

I believe that the screenshot plugin has been tested with a DM3068 by PeDre. Perhaps there is a subtle difference in how it retrieves the screenshot for the two models.

[crispus]

I didn't (yet) upgrade the multimeter; it is as I received it (version 01.01.00.02.02.00)
I'll try to upgrade it and post the result.

The timeout workaround is good, now it takes 3 seconds instead of 10.

[PeDre]

Hello Martin (lundmar),

just for your information.
The Rigol DM3068 only works without a waitlock flag. The flag may be set automatically when the VXI connection is established. The waitlock flag is used by many VXI functions as a parameter, e. g. device_read, see parameter Device_Flags.
The DM3058 may not work because of this. I have not received any feedback from anyone about this device and my program.
My VXI-simulator ignores this flag. The Rigol DS6000 and DG4000 with old firmware are also affected.

Peter

Edit:
What I wrote can't be the mistake. The IDN is received by the Rigol DM3058,
so the waitlock flag isn't the problem.

[crispus]

If helps, I updated the firmware to the latest version and same error (timeout).
On MSO1104Z-S, DG4062 and DSA815 screenshot works with no problem.

[lundmar]

Hello Martin (lundmar),

just for your information.
The Rigol DM3068 only works without a waitlock flag. The flag may be set automatically when the VXI connection is established. The waitlock flag is used by many VXI functions as a parameter, e. g. device_read, see parameter Device_Flags.
The DM3058 may not work because of this. I have not received any feedback from anyone about this device and my program.
My VXI-simulator ignores this flag. The Rigol DS6000 and DG4000 with old firmware are also affected.

Peter

Edit:
What I wrote can't be the mistake. The IDN is received by the Rigol DM3058,
so the waitlock flag isn't the problem.

Ahh right, yes - the DM was the one you simulated. Either way, I've disabled any locking requests during establishment of the VXI-11 connection. It might fix the issue.

[lundmar]

If helps, I updated the firmware to the latest version and same error (timeout).
On MSO1104Z-S, DG4062 and DSA815 screenshot works with no problem.

Ok. I've updated liblxi so that the lxi_connect() function does not try to set up any locking during establishment of the VXI-11 connection. Please update and try it out.

In case you don't want to bother with manual compilation the snap version should already be available on the edge channel.

Snap build status can be monitored here: https://build.snapcraft.io/user/lxi-tools/lxi-tools.snapcraft

[lundmar]

Doh!

I've just studied the documentation for DM3058 and DM3068.

It seems that the SCPI command that we use to request screenshot data ":display:data?" is actually not supported on these instruments.

It might be an undocumented feature but it does not seem to be the case.

Looks like we will have to remove the rigol-dm3000 plugin.

@PeDre , you agree?

[lundmar]

lxi screenshot -a 192.168.1.59 -m rigol-2000 #Works fine now

1. Can there be a option for png instead of bmp? png are smaller.

The image format depends on which formats the instrument supports. PNG is certainly the preferred format but not all instruments support it. The Rigol 2000 series supports PNG for internal storage of screenshots but it is not documented whether it is possible to retrieve PNG remotely. Please try out the '"rigol_2000_png" branch and let me know if it creates a proper PNG for you. If not I'm afraid it is not possible unless the lxi tool itself starts doing BMP->PNG conversion but I think that is a bad idea. I would rather provide the raw material straight from the instrument and then the user can do as they please.

Update: The screenshot command now supports redirecting the screenshot image data to stdout. To do so simply use '-' as the output filename. This means it is now possible to pass on the captured image to external tools for image processing, such as converting it to a different image format. For example, to convert to .jpg using imagemagicks convert tool:

Code: [Select]

$ lxi screenshot --address 10.0.0.42 - | convert - screenshot.jpg

This feature will be included in the upcoming release. It is already available in the snap edge channel.

[PeDre]

Looks like we will have to remove the rigol-dm3000 plugin.

@PeDre , you agree?

I have received feedback from two users that the Rigol DM3068 (Firmware 01.01.00.01.08.00.01 and 01.01.00.01.09.00) with the SCPI command ":DISP:DATA?" and my program works. This applies to the LAN and USB connection.

Peter

[PeDre]

I found Wireshark protocols in my records.
The error was the timeout when creating the connection (CREATE_LINK). The timeout could then be used for write or read commands.

Peter

[lundmar]

Looks like we will have to remove the rigol-dm3000 plugin.

@PeDre , you agree?

I have received feedback from two users that the Rigol DM3068 (Firmware 01.01.00.01.08.00.01 and 01.01.00.01.09.00) with the SCPI command ":DISP:DATA?" and my program works. This applies to the LAN and USB connection.

Peter

Ok good - so it is just an undocumented feature.

I found Wireshark protocols in my records.
The error was the timeout when creating the connection (CREATE_LINK). The timeout could then be used for write or read commands.

Peter

Ok, then my latest changes should hopefully solve the issue.

Thanks for the helpful input Peter

@crispus, Please test latest git or snap and let us know if works or fails. Also, thank you for testing 

Man, I wish I had more instruments so I could create a small lab with various instruments for regression and feature testing.

[crispus]

@crispus, Please test latest git or snap and let us know if works or fails. Also, thank you for testing 

If you refer to https://github.com/lxi-tools/liblxi/commit/12017460e30654e6b10ac99e982bb0d534b9df5e , I tested yesterday and it doesn't seem to work.
I will check again this evening and post the results.

Man, I wish I had more instruments so I could create a small lab with various instruments for regression and feature testing.

I mentioned that I have also MSO1104Z-S, DG4062 and DSA815-TG. And periodically I could run some regression tests.

[lundmar]

@crispus, Please test latest git or snap and let us know if works or fails. Also, thank you for testing 

If you refer to https://github.com/lxi-tools/liblxi/commit/12017460e30654e6b10ac99e982bb0d534b9df5e , I tested yesterday and it doesn't seem to work.
I will check again this evening and post the results.

I appreciate the double check. Even I sometimes forget to install the library after updating it he he. Otherwise, the snap is readily available (revision #214 or newer).

Man, I wish I had more instruments so I could create a small lab with various instruments for regression and feature testing.

I mentioned that I have also MSO1104Z-S, DG4062 and DSA815-TG. And periodically I could run some regression tests.

If you can confirm/test that your DG4062 and MSO1104Z-S works with discover+scpi+screenshot then I would like to add them to the list of tested instruments. The DSA-815 is already in the list. Thanks.

Regarding regression testing, I might reach out to you if I feel that some testing is needed before a release that includes significant changes.

[crispus]

Still doesn't work (neither with snap --edge, nor from source files)
Same error (the following output is from snap):

Code: [Select]

$ lxi
Usage: /snap/lxi-tools/220/bin/lxi [--version] [--help] <command> [<args>]

$ lxi screenshot -a 192.168.1.144 - 
Loaded rigol-dm3000 screenshot plugin
Error: Read error (timeout)
Error: Failed to receive message

Discover && screnshots works from other instruments:

Code: [Select]

 $ lxi discover --timeout 1
Searching for LXI devices - please wait...

Broadcasting on interface lo
Broadcasting on interface eth0
  Found "Rigol Technologies,DG4062,DG4xxx,00.01.12" on address 192.168.1.67
  Found "RIGOL TECHNOLOGIES,MSO1104Z,DS1xxxx,00.04.04.SP3" on address 192.168.1.149
  Found "Rigol Technologies,DM3058,DM3xxx,01.01.00.02.02.00" on address 192.168.1.144

$ lxi screenshot -a 192.168.1.67 - | convert - fg.png
$ lxi screenshot -a 192.168.1.149 - | convert - osc.png
$ ll *.png
-rw-rw-r-- 1 user user 141799 dec 11 22:34 fg.png
-rw-rw-r-- 1 user user  20750 dec 11 22:34 osc.png

Maybe it is useful to include in version name the git commits id (tools & lib) in order to be sure on what commit is the binary.
SCPI commands seems to work as well.

[lundmar]

Still doesn't work (neither with snap --edge, nor from source files)
Same error (the following output is from snap):

Code: [Select]

$ lxi
Usage: /snap/lxi-tools/220/bin/lxi [--version] [--help] <command> [<args>]

$ lxi screenshot -a 192.168.1.144 - 
Loaded rigol-dm3000 screenshot plugin
Error: Read error (timeout)
Error: Failed to receive message

Update 2: Your trace confirmed we get a timeout waiting for response to the screenshot capture command. Please try the following (requires latest because of a fix to interactive mode):

Code: [Select]

$ lxi scpi --address <ip> --interactive

And in interactive mode please enter the following:

Code: [Select]

:disp:data?
:system:error?

I'm not fully convinced that your DM firmware supports the first command so I expect you will see a system error message like e.g. '-113,"Undefined header; keyword cannot be found"'.

Discover && screnshots works from other instruments:

Code: [Select]

 $ lxi discover --timeout 1
Searching for LXI devices - please wait...

Broadcasting on interface lo
Broadcasting on interface eth0
  Found "Rigol Technologies,DG4062,DG4xxx,00.01.12" on address 192.168.1.67
  Found "RIGOL TECHNOLOGIES,MSO1104Z,DS1xxxx,00.04.04.SP3" on address 192.168.1.149
  Found "Rigol Technologies,DM3058,DM3xxx,01.01.00.02.02.00" on address 192.168.1.144

$ lxi screenshot -a 192.168.1.67 - | convert - fg.png
$ lxi screenshot -a 192.168.1.149 - | convert - osc.png
$ ll *.png
-rw-rw-r-- 1 user user 141799 dec 11 22:34 fg.png
-rw-rw-r-- 1 user user  20750 dec 11 22:34 osc.png

Thanks - I've added them to the list of tested instruments. Also, I've added you to the list of contributors.

Maybe it is useful to include in version name the git commits id (tools & lib) in order to be sure on what commit is the binary.
SCPI commands seems to work as well.

Yeah, I might add that.

[crispus]

Yeah, you're right:

Code: [Select]

$ lxi scpi -a 192.168.1.144 --interactive
Connected to 192.168.1.144
Entering interactive mode (ctrl-d to quit)

lxi> :disp:data?
Error: Read error (timeout)
Error: Failed to receive message
lxi> :system:error?
-113,"Undefined header; keyword cannot be found"
lxi> :system:error?
0,"No error"
lxi> :disp:data?
Error: Read error (timeout)
Error: Failed to receive message
lxi> :system:error?
-113,"Undefined header; keyword cannot be found"
lxi> ^C

I can't see any screenshot related in the programming manual for DM3058

[lundmar]

Yeah, you're right:

Code: [Select]

$ lxi scpi -a 192.168.1.144 --interactive
Connected to 192.168.1.144
Entering interactive mode (ctrl-d to quit)

lxi> :disp:data?
Error: Read error (timeout)
Error: Failed to receive message
lxi> :system:error?
-113,"Undefined header; keyword cannot be found"
lxi> :system:error?
0,"No error"
lxi> :disp:data?
Error: Read error (timeout)
Error: Failed to receive message
lxi> :system:error?
-113,"Undefined header; keyword cannot be found"
lxi> ^C

I can't see any screenshot related in the programming manual for DM3058

Ok.

Btw., did you upgrade to latest firmware?

It's a pretty weird regression if earlier firmware versions support this command but the latest does not. Or perhaps it is only the DM3068 that unofficially supports it.

[crispus]

Btw., did you upgrade to latest firmware?

Yes, it seems that already had the latest version. The tricky part though, in the release notes the version contains an additional 02: 1.01.00.02.02.00 on the multimeter versus 1.01.00.02.02.00.02 in the release notes.

[lundmar]

Btw., did you upgrade to latest firmware?

Yes, it seems that already had the latest version. The tricky part though, in the release notes the version contains an additional 02: 1.01.00.02.02.00 on the multimeter versus 1.01.00.02.02.00.02 in the release notes.

He he, yeah - those two numbers can make you go blind trying to spot the difference.

So, since the screenshot plugin certainly won't work with the DM3058 I'm thinking I will add to the description that it only works with DM3068.

Or at least, I will assume it to be working with DM3068 until someone tells me otherwise.

Either way, thank you for your testing. I'm sorry we couldn't make it work.

As a last resort, you could try ask Rigol to add screenshot support to their firmware but it might be a futile task - I don't know how much Rigol listens to their users.

[lundmar]

New releases of lxi-tools and liblxi are now available via snap, tarball, or git.

This is a feature and bug fix release.

For a complete overview of changes please see:
https://github.com/lxi-tools/lxi-tools/releases/tag/v1.14
https://github.com/lxi-tools/liblxi/releases/tag/v1.8

A lot of new screenshot plugins have been added which add support for many of Siglents instruments.

Also, the screenshot command has been improved so it is now possible to redirect the captured screenshot image directly to external tools for simple or advanced image processing such as resizing, scaling, adding text, format conversion, etc. It's quite a powerful feature. For example, to embed a time stamp in the image, upscale the image to 150%, and convert it to JPG, simply use the lxi tool in combination with e.g. ImageMagicks image manipulation tools like so:

Code: [Select]

$ lxi screenshot -a 10.0.0.42 - | convert -fill white -draw "font-size 16 text 100,100 '`date`'" -scale 150% - screenshot.jpg

Or, to add a label with time stamp:

Code: [Select]

$ lxi screenshot -a 10.0.0.42 - | montage -geometry +0+0 -background white -label "`date`" -scale 150% - screenshot.png

ImageMagicks image manipulation tools support various image operations and over 200 image formats which should satisfy the needs of most users

Also, I would like to put a big thank you to Siglent who has been very helpful to test and make sure that lxi-tools works well with all of their LXI compatible instruments 

[dpenev]

Hi lundmar,

I have tested the latest lxi tool v1.15 and screenshot is working fine on my Siglent SSA3021X


A minor note which would be a bit more convenient for me is if I would able to write directly to my share 
At the moment I get an error

lxi screenshot -a 192.168.1.61 /share/scr2.bmp
Loaded siglent-ssa3000x screenshot plugin
Error: Could not write screenshot file (No such file or directory)

Thank you for your work.
Dimitar

[lundmar]

Hi lundmar,

I have tested the latest lxi tool v1.15 and screenshot is working fine on my Siglent SSA3021X


A minor note which would be a bit more convenient for me is if I would able to write directly to my share 
At the moment I get an error

lxi screenshot -a 192.168.1.61 /share/scr2.bmp
Loaded siglent-ssa3000x screenshot plugin
Error: Could not write screenshot file (No such file or directory)

Thank you for your work.
Dimitar

You're welcome. I'm glad we finally have it working.

Yes, an unfortunate consequence of using snap at the moment is that it runs in a security confined environment so writing to anywhere outside of your home directory is denied. I'm told this is something which might be fixed in future versions of snap.

Until then there is a little trick you can do to bypass the confinement:

Code: [Select]

$ lxi screenshot -a 10.0.0.42 - | convert - screenshot.png

This way it is the unconfined convert tool that writes the screenshot file and so you can write anywhere you like.

Actually, you can even skip the convert tool assuming your know the image file format extension:

Code: [Select]

$ lxi screenshot -a 10.0.0.42 - > screenshot.png

[ralphrmartin]

Just tried to install this unsuccessfully on debian.

I first installed snap as described, and all went well. I then tried

snap install lxi-tools --edge

and got

error: cannot install "lxi-tools": Get https://search.apps.ubuntu.com/api/v1/snaps/details/core?channel=stable&fields=anon_download_url%2Carchitecture%2Cchannel%2Cdownload_sha3_384%2Csummary%2Cdescription%2Cdeltas%2Cbinary_filesize%2Cdownload_url%2Cepoch%2Cicon_url%2Clast_updated%2Cpackage_name%2Cprices%2Cpublisher%2Cratings_average%2Crevision%2Cscreenshot_urls%2Csnap_id%2Csupport_url%2Ctitle%2Ccontent%2Cversion%2Corigin%2Cdeveloper_id%2Cprivate%2Cconfinement: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

snap install lxi-tools

gives the same result.

Any idea what is up?

Thanks.

[lundmar]

Just tried to install this unsuccessfully on debian.

I first installed snap as described, and all went well. I then tried

snap install lxi-tools --edge

and got

error: cannot install "lxi-tools": Get https://search.apps.ubuntu.com/api/v1/snaps/details/core?channel=stable&fields=anon_download_url%2Carchitecture%2Cchannel%2Cdownload_sha3_384%2Csummary%2Cdescription%2Cdeltas%2Cbinary_filesize%2Cdownload_url%2Cepoch%2Cicon_url%2Clast_updated%2Cpackage_name%2Cprices%2Cpublisher%2Cratings_average%2Crevision%2Cscreenshot_urls%2Csnap_id%2Csupport_url%2Ctitle%2Ccontent%2Cversion%2Corigin%2Cdeveloper_id%2Cprivate%2Cconfinement: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

snap install lxi-tools

gives the same result.

Any idea what is up?

Thanks.

I notice that "api/v1/snaps" is involved. I'm not sure but I think recent versions of snap uses snap api v2.

I just installed lxi-tools successfully on Debian 9.3 (Stretch) which uses snap/snapd version 2.29.4.2.

Which Debian and snap version are you using?

EDIT: It looks like snap/snapd is only officially supported on latest stable Debian (Stretch).

[ralphrmartin]

I'm using
GNU/Linux testing Stretch
and
snap    2.21-2+b1

I've realised that testing with Stretch is now a bit outdated, so have changed just to testing. Having done that, all seems OK.

Oops, spoke too soon. While snap install worked OK, I now get

bash: lxi: command not found


Am I doing something silly?

[ralphrmartin]

OK, so I found the binary: /snap/bin/lxi

But trying to run it as

/snap/bin/lxi

gives

cannot bind-mount the mount namespace file /proc/2556/ns/mnt -> lxi-tools.mnt: Permission denied
support process for mount namespace capture exited abnormally

[crispus]

Do you have /var or /tmp as symbolic link?

[lundmar]

I'm using
GNU/Linux testing Stretch
and
snap    2.21-2+b1

I've realised that testing with Stretch is now a bit outdated, so have changed just to testing. Having done that, all seems OK.

Good

Oops, spoke too soon. While snap install worked OK, I now get

bash: lxi: command not found


Am I doing something silly?

I don't think so. Actually, the snap binaries are prefixed with the name of the snap. So in case of lxi-tools the lxi binary is named "lxi-tools.lxi". However, the lxi-tools snap recently gained support for adding the automatic alias lxi -> lxi-tools.lxi when installing so the lxi command should just work.

You can list the installed aliases like so:

Code: [Select]

snap aliases

If the alias is not listed you can install it manually:

Code: [Select]

snap alias lxi-tools.lxi lxi

You might also consider using Debian stable. I mean, Debian testing can include broken stuff

[lundmar]

FYI - lxi-tools was recently picked up by a Debian package maintainer so I expect to see it available in Debian stable in about 1 year or so

Of course, it will be available in unstable/testing long before that.

[ralphrmartin]

Hmm

 snap aliases
gives
Command        Alias  Notes
lxi-tools.lxi  lxi    -

so that does not seem to be the problem.

Neither /var nor /tmp are aliases.

snap version
now gives
snap version
snap    2.27.6-2
snapd   2.27.6-2
series  16
debian  unknown
kernel  4.13.0-1-amd64

Any either ideas on how to get this to run? Even trying to run it as root gives permission errors - and it is not on my path...

[lundmar]

Hmm

 snap aliases
gives
Command        Alias  Notes
lxi-tools.lxi  lxi    -

so that does not seem to be the problem.

Neither /var nor /tmp are aliases.

snap version
now gives
snap version
snap    2.27.6-2
snapd   2.27.6-2
series  16
debian  unknown
kernel  4.13.0-1-amd64

Any either ideas on how to get this to run? Even trying to run it as root gives permission errors - and it is not on my path...

The permission denied errors are likely somehow related to the fact that snaps are running in security confinement. You can try disable this confinement like so:

Code: [Select]

$ snap refresh lxi-tools --devmode

Or

Code: [Select]

$ snap refresh lxi-tools --classic

Either way, I think your best option is to use Debian stable since it includes the latest snap version (2.29.x) which is tested to work.

However, if you don't feel like distro downgrading/upgrading you can always compile and install it manually from source as described in the top post of this thread (see e.g. git build steps).

If you feel brave I have also attached the pre-release .deb packages that I got from the Debian maintainer - I have tested them with Debian 9.3.

P.s. If you get it up and running feel free to let us know what specific instruments you might have tested successfully. Thanks.

[ralphrmartin]

Both of those variants did nothing, just giving
snap "lxi-tools" has no updates available

However the deb files seem to have worked.

Thanks!

I'll try it out with some instruments in the next few days I hope.

[lundmar]

Both of those variants did nothing, just giving
snap "lxi-tools" has no updates available

I think that is expected because there is no new refresh/download available but despite this message it is supposed to change the confinement setting.

However the deb files seem to have worked.

Thanks!

I'll try it out with some instruments in the next few days I hope.

Great - feel free to share your findings.

Unfortunately I will not be able to provide updated .deb packages moving forward except when the Debian package maintainer decides to do so. The great thing about snap is it is always up to date and I can push updates directly to users literally within minutes.

[ralphrmartin]

Well, findings so far are discovery works for these devices:

  Found "Rigol Technologies,DG4062,[serial#]" on address 192.168.1.207
  Found "KEYSIGHT TECHNOLOGIES,MSO-X 3024T,[serial#],07.20.2017102614" on address 192.168.1.206

Tried sending *IDN? to both - worked OK.

Captured a screenshot from the Keysight, which resulted in a png file, but when I tried to view it, I got told it was not a png.
Running the file command on it just told me it was data.
The first few bytes of the file look like this:
00000000: 470d 0a1a 0a00 0000 0d49 4844 5200 0003  G........IHDR...
00000010: 2000 0002 0008 0200 0000 f5c9 9fbd 0000   ...............
00000020: 2000 4944 4154 7801 edbd 4dac 2cdb 75df   .IDATx...M.,.u.
00000030: 77ce 7df7 f123 fc92 68c1 a114 0e2c 4422  w.}..#..h....,D"
00000040: a297 c086 ded3 e01a a000 3940 3290 022a  [email protected]*
00000050: 4311 b888 151a be9c 270c e051 8078 1a22  C.......'..Q.x."
00000060: 4090 115f 9217 27b8 8092 a108 5883 0089  @.._..'.....X...

Trying to use the Keysight 2000 plugin didn't help.

Captured a screenshot from the Rigol, which resulted in a bmp file, but when I tried to view it, I got told it had a bogus header.
Running file on it told me it was a jpeg!
Changing the file extension to jpg gave me a correct picture of the screen.

[ralphrmartin]

Just out of curiosity, I tried building this on a Mac. Unfortunately, it didn't work as rpcgen does not have a -M argument on  MacOS X.

[lundmar]

Well, findings so far are discovery works for these devices:

  Found "Rigol Technologies,DG4062,[serial#]" on address 192.168.1.207
  Found "KEYSIGHT TECHNOLOGIES,MSO-X 3024T,[serial#],07.20.2017102614" on address 192.168.1.206

Tried sending *IDN? to both - worked OK.

Good.

Captured a screenshot from the Keysight, which resulted in a png file, but when I tried to view it, I got told it was not a png.
Running the file command on it just told me it was data.
The first few bytes of the file look like this:
00000000: 470d 0a1a 0a00 0000 0d49 4844 5200 0003  G........IHDR...
00000010: 2000 0002 0008 0200 0000 f5c9 9fbd 0000   ...............
00000020: 2000 4944 4154 7801 edbd 4dac 2cdb 75df   .IDATx...M.,.u.
00000030: 77ce 7df7 f123 fc92 68c1 a114 0e2c 4422  w.}..#..h....,D"
00000040: a297 c086 ded3 e01a a000 3940 3290 022a  [email protected]*
00000050: 4311 b888 151a be9c 270c e051 8078 1a22  C.......'..Q.x."
00000060: 4090 115f 9217 27b8 8092 a108 5883 0089  @.._..'.....X...

Trying to use the Keysight 2000 plugin didn't help.

Yeah, you are the first to actually test the Keysight plugin. Clearly something needs to be fixed. I'll look into it.
Update: Fixed and ready for testing. Also, the screenshot command should now auto detect your 3000X instrument and automatically load the plugin.

Captured a screenshot from the Rigol, which resulted in a bmp file, but when I tried to view it, I got told it had a bogus header.
Running file on it told me it was a jpeg!
Changing the file extension to jpg gave me a correct picture of the screen.

Oh, interesting. In the screenshot plugin for the dg4000 we assume the image to be BMP but it seems we need to fire an additional command to make sure the format is BMP. I'll fix that.
Update:  Fixed and available in the latest snap on the edge channel.

By the way, if you want to test with snap you could install latest Debian stable (9.3) in a VirtualBox VM - that's what I'm doing on my Ubuntu system to test Debian stuff. In case you do that, remember to make the network adapter bridged (not NAT).

[lundmar]

Just out of curiosity, I tried building this on a Mac. Unfortunately, it didn't work as rpcgen does not have a -M argument on  MacOS X.

Unfortunately we don't want to make do without the -M flag because it is what produces thread-safe code. I'm not sure why rpcgen on mac does not support this flag - perhaps too old version of rpcgen?

[PeDre]

Oh, interesting. In the screenshot plugin for the dg4000 we assume the image to be BMP but it seems we need to fire an additional command to make sure the format is BMP. I'll fix that.
Update:  Fixed and available in the latest snap on the edge channel.

The Rigol DG4000 has an image format setting:
Utility -> Print Set -> Format = Bmp, Jpeg, Png
I don't know any options for the image format and the SCPI command ":HCOPy:SDUMp:DATA?"

Edit:
There's the SCPI command:
:HCOPy:SDUMp:DATA:FORMat BMP|JPEG|PNG
:HCOPy:SDUMp:DATA:FORMat?

[ralphrmartin]

Thanks for the fixes.

I'm already running Debian in a VM, in bridged mode, on my Mac.  But my SSD does not have enough space for yet another VM.

I suppose the answer is to uninstall the deb and just install from the Github source, if snap doesn't work (for whatever reason).

[ralphrmartin]

There's definitely something wrong with the way the snap version is working. I just installed a fresh Debian stretch in a VirtualBox VM, did
apt-get install snapd
then
snap install lxi-tools
which all seemed to work OK.
But then any of the commands
lxi
lxitools
lxi-tools
just gives me "command not found".

Write once run anywhere is a noble goal - but seems rather too fragile...

[lundmar]

There's definitely something wrong with the way the snap version is working. I just installed a fresh Debian stretch in a VirtualBox VM, did
apt-get install snapd
then
snap install lxi-tools
which all seemed to work OK.
But then any of the commands
lxi
lxitools
lxi-tools
just gives me "command not found".

These are the exact steps I do on Debian 9.3:

Code: [Select]

$ lsb_release -d
Description:   Debian GNU/Linux 9.3 (stretch)
$ snap --version
snap    2.29.4.2
snapd   2.29.4.2
series  16
debian  9
kernel  4.9.0-4-amd64
$ su -
$ snap install lxi-tools --edge
$ lxi --version
lxi v1.16
$ lxi-tools.lxi --version
lxi v1.16
$ snap aliases
Command        Alias  Notes
lxi-tools.lxi  lxi    -

Write once run anywhere is a noble goal - but seems rather too fragile...

At least it is a goal

[lundmar]

There's the SCPI command:
:HCOPy:SDUMp:DATA:FORMat BMP|JPEG|PNG
:HCOPy:SDUMp:DATA:FORMat?

Exactly - that is the command I added to fix the format for the DG to force it to BMP. I'm wondering if the same trick needs to be applied to any of the other rigol plugins.

[ralphrmartin]

Well, here is my output

#lsb_release -d
Description:   Debian GNU/Linux 9.3 (stretch)

#snap --version
snap    2.29.4.2
snapd   2.29.4.2
series  16
debian  9
kernel  4.9.0-4-amd64

#snap install lxi-tools --edge
lxi-tools (edge) 1.16 from 'lundmar' installed

#lxi --version
bash: lxi: command not found

#lxi-tools.lxi --version
bash: lxi-tools.lxi: command not found

#snap aliases
Command        Alias  Notes
lxi-tools.lxi  lxi    -

All looks the same - apart from the fact that lxi is not found...
I've got no idea how it can be working on your system and not on mine.
I've had exactly the same result now on both Debian testing and a fresh Debian stretch.

[lundmar]

Well, here is my output

#lsb_release -d
Description:   Debian GNU/Linux 9.3 (stretch)

#snap --version
snap    2.29.4.2
snapd   2.29.4.2
series  16
debian  9
kernel  4.9.0-4-amd64

#snap install lxi-tools --edge
lxi-tools (edge) 1.16 from 'lundmar' installed

#lxi --version
bash: lxi: command not found

#lxi-tools.lxi --version
bash: lxi-tools.lxi: command not found

#snap aliases
Command        Alias  Notes
lxi-tools.lxi  lxi    -

All looks the same - apart from the fact that lxi is not found...
I've got no idea how it can be working on your system and not on mine.
I've had exactly the same result now on both Debian testing and a fresh Debian stretch.

I think I've spotted your problem.

I assume you are using the "su" command to go root. Try "su -".

With the first I see the same as you. With the latter everything works fine.

Also, I normally just switch to and install as root but then exit back to my "test" user and it still works.

[ralphrmartin]

Thanks. using
su -
instead of
sudo bash
to get a root terminal did the trick (except I still have to be root to use the lxi command).

[lundmar]

Thanks. using
su -
instead of
sudo bash
to get a root terminal did the trick (except I still have to be root to use the lxi command).

Great. Let me know if the fixed screenshot plugins work with your DG and MSO. You should be able to simply do:

Code: [Select]

$ lxi screenshot --address <instrument ip>

I'm not that familiar with the Debian ways of user management. On Ubuntu I don't even have to switch to root to install/remove/use snaps.

[ralphrmartin]

Screenshot works well now for keysight, producing a bmp file, and for the Rigol, also producing a bmp file. 
(Without specifying plugins to use).

Keep up the good work! 

[lundmar]

Screenshot works well now for keysight, producing a bmp file, and for the Rigol, also producing a bmp file. 
(Without specifying plugins to use).

Keep up the good work! 

Thanks

And thank you for your patience getting the snap running. Great to finally have a Keysight instrument tested working

For your testing effort I've added you to the list of contributors.

[lundmar]

New releases available via snap or source.

Changes:
https://github.com/lxi-tools/lxi-tools/releases/tag/v1.16
https://github.com/lxi-tools/liblxi/releases/tag/v1.9

The changes fix the keysight-ivx and rigol-dg4000 screenshot plugins. The discover feature has also been improved with a fallback to request ID via HTTP/XML - this should make it possible to discover instruments from e.g. Aim-TTi.

Also added are fixes making it ready for packaging in Debian and FreeBSD.

[lundmar]

I know that some people would welcome a GUI for lxi-tools.

Here is a first try at adding a simple QT5 GUI:



In its first iteration it can simply discover instruments via VXI-11.

To keep the UI simple and easy-to-use I think the next step would be to feature a right-click context menu for the listed instruments which provides the following options:

* Send SCPI command
* Take screenshot (only shown if a matching screenshot plugin is available)
* Benchmark
* Copy Instrument ID
* Copy IP Address

The GUI application binary will be named lxi-gui but will also be possible to start via the commandline lxi tool using the following command: lxi gui

If there are any GUI or QT5 designers out there who are interested in helping creating this GUI application feel free to join in

Also, if anyone wants to add a custom, fast, simple or advanced GUI for their particular instrument it is now possible with this lxi-tools/QT5 stack. Contributors are welcome to add any useful instrument tools to lxi-tools.

[ralphrmartin]

Just a thought: it could perhaps be useful if some of the most common SCPI commands could be available in a menu, e.g. perform self-test.

[lundmar]

Just a thought: it could perhaps be useful if some of the most common SCPI commands could be available in a menu, e.g. perform self-test.

Yeah - the "IEEE 488.2 Common Commands".

http://na.support.keysight.com/vna/help/latest/Programming/GP-IB_Command_Finder/Common_Commands.htm

I'm considering introducing separate tabs/panes for each of the following features: Discovery, SCPI, Screenshot, Benchmark.

Then have the SCPI, Screenshot, and Benchmark features operate on the instrument selected in Discovery.

I'm about to focus on implementing the HiSlip protocol - it will be a while before I revisit the GUI so I'm open for ideas and suggestions.

An instrument manufacturer is kindly sponsoring a HiSlip instrument so I will soon have something to test against 

[lundmar]

Siglent Technologies has kindly lent me their new SDS1204X-E oscilloscope (200 MHz, 4 channels) to help the lxi-tools open source effort

I hooked it up, calibrated the 4 included probes, and after enabling the network interface (DHCP) it was easily discovered with lxi-tools.



It turns out that this is an absolutely blazingly fast scope, especially in terms of LXI/LAN SCPI command processing performance!

With the benchmark feature I'm getting ~300 requests/s via TCP/VXI11:

Code: [Select]

$ lxi benchmark --address 192.168.1.125
Benchmarking by sending 100 ID requests. Please wait...
Result: 301.5 requests/second

And I get ~600 requests/s via TCP/RAW:

Code: [Select]

$ lxi benchmark --raw --address 192.168.1.125
Benchmarking by sending 100 ID requests. Please wait...
Result: 598.9 requests/second

This is quite impressive. Compared, the performance of e.g. the Rigol DS1054Z is ~30 requests/s via TCP/VXI11 and ~160 requests/s via TCP/RAW.

Of course, the faster performance is to be expected from a newly released scope which clearly uses a newer and faster chipset. However, fact still is, it is very fast and it is one of the first low cost scopes that makes it possible to easily implement a poor-mans data logger using LXI/LAN polling that can consistently sample data at e.g. 100 Hz or more.

I also notice that Siglent uses standard LXI ports as defined here: http://www.lxistandard.org/About/LXI-Protocols.aspx

That is, the available network ports for the SDS1204X-E are:

Code: [Select]

$ nmap -p- 192.168.1.125

Starting Nmap 7.60 ( [url]https://nmap.org[/url] ) at 2018-01-08 15:18 CET
Nmap scan report for 192.168.1.125
Host is up (0.042s latency).
Not shown: 65529 closed ports
PORT     STATE SERVICE
23/tcp   open  telnet
80/tcp   open  http
111/tcp  open  rpcbind
918/tcp  open  unknown
5024/tcp open  scpi-telnet
5025/tcp open  scpi-raw

Nmap done: 1 IP address (1 host up) scanned in 40.14 seconds

In particular, they use standard port 5025 for SCPI/RAW and port 5024 for SCPI/telnet. This is one of the odd things that Rigol fails to do for the DS1054Z (they place it on non-standard port 5555):

Code: [Select]

$ nmap -p- 192.168.1.210

Starting Nmap 7.60 ( [url]https://nmap.org[/url] ) at 2018-01-08 15:19 CET
Nmap scan report for 192.168.1.210
Host is up (0.080s latency).
Not shown: 65529 closed ports
PORT     STATE SERVICE
80/tcp   open  http
111/tcp  open  rpcbind
617/tcp  open  sco-dtmgr
618/tcp  open  dei-icda
619/tcp  open  compaq-evm
5555/tcp open  freeciv

Nmap done: 1 IP address (1 host up) scanned in 40.54 seconds

Taking a screenshot with the SDS1204X-E is very fast too:

Code: [Select]

$ time lxi screenshot -a 192.168.1.125
Loaded siglent-sds screenshot plugin
Saved screenshot image to screenshot_192.168.1.125_2018-01-08_15:37:22.bmp

real    0m0,361s
user    0m0,006s
sys     0m0,026s

Only ~0.4 second!

It's also nice to see that the Siglent scope has a small and light form factor which feels solid.

My first impressions are good - I'm looking forward to more testing with this instrument during the development of the GUI frontend for lxi-tools. It will also make a nice addition to the pool of instruments that I plan to use for lxi-tools performance and regression testing.

[BloodyCactus]

just because, why not R&S HMO1202 (which seems surprisingly slow...)

Code: [Select]

[ sgeorge @ workstation ] - [ ~/git/rai1/c64_c128_plus4 ] (master*) 
[$]> lxi --version
lxi v1.17

[ sgeorge @ workstation ] - [ ~/git/rai1/c64_c128_plus4 ] (master*) 
[$]> lxi benchmark --address scope.cactus
Benchmarking by sending 100 ID requests. Please wait...
Result: 13.9 requests/second

[ sgeorge @ workstation ] - [ ~/git/rai1/c64_c128_plus4 ] (master*) 
[$]> lxi benchmark --raw --address scope.cactus
Benchmarking by sending 100 ID requests. Please wait...
Result: 12.6 requests/second

[ sgeorge @ workstation ] - [ ~/git/rai1/c64_c128_plus4 ] (master*) 
[$]> nmap -p- scope.cactus

Starting Nmap 7.01 ( https://nmap.org ) at 2018-01-08 20:39 EST
Nmap scan report for scope.cactus (192.168.0.107)
Host is up (0.0022s latency).
Not shown: 65530 closed ports
PORT     STATE SERVICE
80/tcp   open  http
111/tcp  open  rpcbind
1024/tcp open  kdm
1025/tcp open  NFS-or-IIS
5025/tcp open  unknown

Nmap done: 1 IP address (1 host up) scanned in 11.73 seconds

[lundmar]

just because, why not R&S HMO1202 (which seems surprisingly slow...)

He he - that is truly slow!

That must be the lowest benchmark scores I has seen so far.

I'm not that surprised though - well established big company instrument manufacturers like R&S tend to over engineer things and this sometimes leads to over engineered cost reduction. Likely their instrument is featuring a low cost, low performance application/communication processor or their application/network stack is horribly inefficient - I think the former is probably the case.

[ralphrmartin]

Another instrument for you: Keysight 34461A multimeter.
Discovery works fine.
Sending scpi commands seems OK (e.g. *IDN? returns the expected ID string).
Trying to take a screenshot results in it trying to use the rigol-1000Z plugin, and thence timeout. Telling it to use the keysight-ivx plugin gave the same result.
Doing a benchmark gave a result of 45.1 requests a second.

[lundmar]

Another instrument for you: Keysight 34461A multimeter.
Discovery works fine.
Sending scpi commands seems OK (e.g. *IDN? returns the expected ID string).
Trying to take a screenshot results in it trying to use the rigol-1000Z plugin, and thence timeout. Telling it to use the keysight-ivx plugin gave the same result.
Doing a benchmark gave a result of 45.1 requests a second.

Thanks. If you share the ID string that this instrument returns then I can fix the plugin matching part.

It looks like we need to create a new screenshot plugin for this instrument as it handles screenshots differently from the oscilloscopes.

EDIT: I have added a new screenshot plugin "keysight-dmm" that should work with your 34461A multimeter. Let me know how it works for you.