Poll

What OS platform would you like to see lxi-tools ported to next?

Windows
macOS
Other
Don't port it - Linux is the future for all!

Author Topic: Open source lxi-tools and liblxi v1.0 released for GNU/Linux  (Read 89571 times)

0 Members and 1 Guest are viewing this topic.

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« on: October 07, 2017, 05:51:10 pm »
Hi,

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

The lxi-tools open source project provides the following:
  • "lxi" - a command line tool that features a simple interface for discovering LXI compatible instruments, sending SCPI messages, capturing screenshots, benchmarking, and scripted automation
  • "lxi-gui" - a GUI application that features some of the same features as the command line tool and additional features such as a screenshot viewer and a data recorder
  • "liblxi" - 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.21.tar.xz  (Changes, GitHub)
Latest liblxi:  liblxi-1.13.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:

InstrumentWorking features
Keysight Technologies AWG 33612A(discover+scpi+screenshot)
Keysight Technologies DMM 34461A(discover+scpi+screenshot)
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 HMC 8012(discover+scpi+screenshot)
Rohde & Schwarz HMC 8043(discover+scpi+screenshot)
Rohde & Schwarz HMO 1202(discover+scpi+screenshot)
Rohde & Schwarz HMO 3054(scpi+screenshot)
Rohde & Schwarz RTB 2004(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 (recurring task, looking for testers with instruments)
  • Add screenshot plugins for more instruments (recurring task)
  • Push it to the most popular GNU/Linux distributions (Ubuntu/Debian, Fedora/RHEL, etc.)
  • Make it work on non-GNU/Linux systems (Windows, macOS, etc.)
  • Extend discover feature to support mDNS/DNS-SD
  • Add HiSlip/TCP support
  • Add a modern QT GUI app with features from commandline tool
  • Add support for advanced scripting in Lua
  • Add GUI feature to support running advanced scripts in a test batch mode (run, pause, continue, pass/fail etc.)
  • 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.).

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: lxi-tools is not in any way affiliated with the LXI consortium. It 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 liblua5.2-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
« Last Edit: July 08, 2018, 09:32:22 am by lundmar »
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline HoracioDos

  • Frequent Contributor
  • **
  • Posts: 344
  • Country: ar
  • Just an IT monkey with a DSO
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #1 on: October 07, 2017, 08:51:23 pm »
I've opened an issue for lxi-tools. Perhaps I'm messing things up when compiling
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #2 on: October 07, 2017, 11:11:21 pm »
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
« Last Edit: December 20, 2017, 12:49:05 pm by lundmar »
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #3 on: October 17, 2017, 01:53:47 pm »
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.
« Last Edit: December 20, 2017, 12:49:24 pm by lundmar »
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline awallin

  • Frequent Contributor
  • **
  • Posts: 694
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #4 on: October 17, 2017, 04:56:12 pm »

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
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #5 on: October 17, 2017, 08:27:10 pm »
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.
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 
The following users thanked this post: nugglix

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #6 on: October 26, 2017, 03:25:18 pm »
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.
« Last Edit: December 20, 2017, 12:47:44 pm by lundmar »
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #7 on: October 28, 2017, 06:12:00 am »
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.
« Last Edit: December 20, 2017, 12:47:58 pm by lundmar »
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6145
  • Country: ro
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #8 on: October 29, 2017, 07:29:36 pm »
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]
rogeorge@debian80:~$ lxi scpi -a 192.168.1.3 *IDN?
RIGOL TECHNOLOGIES,DS1104Z,DS1ZA16*,00.04.04.SP3
rogeorge@debian80:~$ lxi scpi -a 192.168.1.4 *IDN?
RIGOL TECHNOLOGIES,DP832,DP8C16*,00.01.11
rogeorge@debian80:~$ lxi scpi -a 192.168.1.5 *IDN?
Rigol Technologies,DG4102,DG4E17*,00.01.12
rogeorge@debian80:~$ lxi discover
Searching for LXI devices - please wait...

Broadcasting on interface lo
Broadcasting on interface eth0

No devices found

rogeorge@debian80:~$ 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
rogeorge@debian80:~$
« Last Edit: October 29, 2017, 07:41:21 pm by RoGeorge »
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #9 on: October 29, 2017, 08:05:24 pm »
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 :)
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #10 on: October 30, 2017, 07:03:58 pm »
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
« Last Edit: November 02, 2017, 02:12:20 pm by lundmar »
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 
The following users thanked this post: grouchobyte

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6145
  • Country: ro
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #11 on: October 30, 2017, 07:27:58 pm »
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?

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #12 on: October 30, 2017, 08:48:27 pm »
- 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.
« Last Edit: October 31, 2017, 01:16:49 am by lundmar »
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #13 on: November 01, 2017, 08:13:34 pm »
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.
« Last Edit: November 01, 2017, 08:19:15 pm by lundmar »
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 
The following users thanked this post: dr.diesel

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #14 on: November 01, 2017, 10:06:47 pm »
- 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.

https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6145
  • Country: ro
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #15 on: November 02, 2017, 01:22:50 am »
I can test DG4102 screenshot when I'll return home, maybe next Monday or Tuesday.
 
The following users thanked this post: lundmar

Offline rhb

  • Super Contributor
  • ***
  • Posts: 3476
  • Country: us
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #16 on: November 04, 2017, 09:19:31 pm »
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.
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #17 on: November 04, 2017, 11:17:37 pm »
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.
« Last Edit: November 04, 2017, 11:19:51 pm by lundmar »
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline rhb

  • Super Contributor
  • ***
  • Posts: 3476
  • Country: us
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #18 on: November 05, 2017, 01:33:20 am »
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."
 
The following users thanked this post: cdev

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #19 on: November 05, 2017, 03:15:27 am »
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.
« Last Edit: December 20, 2017, 12:49:59 pm by lundmar »
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 
The following users thanked this post: Gabri74

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6145
  • Country: ro
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #20 on: November 06, 2017, 04:04:32 pm »
Made a new build today and testing right now, so brace yourself for a lot of :blah: and :rant:, but no :clap:, 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.

Offline rhb

  • Super Contributor
  • ***
  • Posts: 3476
  • Country: us
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #21 on: November 06, 2017, 05:10:30 pm »
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

Quote
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

Quote
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.
 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6145
  • Country: ro
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #22 on: November 06, 2017, 05:40:00 pm »
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]
rogeorge@debian80:~/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

rogeorge@debian80:~/lxi-tools$
Passed

2.
Code: [Select]
rogeorge@debian80:~/lxi-tools$ lxi --version
lxi v1.6
rogeorge@debian80:~/lxi-tools$ lxi -v
lxi v1.6
rogeorge@debian80:~/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

rogeorge@debian80:~/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

rogeorge@debian80:~/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]
rogeorge@debian80:~/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

rogeorge@debian80:~/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]
rogeorge@debian80:~/lxi-tools$ lxi scpi -a 192.168.1.5 *IDN?
Rigol Technologies,DG4102,DG4E17*,00.01.12
rogeorge@debian80:~/lxi-tools$ lxi scpi -a 192.168.1.4 *IDN?
RIGOL TECHNOLOGIES,DP832,DP8C16*,00.01.11
rogeorge@debian80:~/lxi-tools$
« Last Edit: November 06, 2017, 05:45:35 pm by RoGeorge »
 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6145
  • Country: ro
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #23 on: November 06, 2017, 05:52:49 pm »
4.
Code: [Select]
rogeorge@debian80:~/lxi-tools$ lxi discovery
Error: No IP address specified
rogeorge@debian80:~/lxi-tools$
Failed - Minor inconvenience
Misleading error message. There is a typo in the command name, "discovery" instead of "discover",  not a missing IP.

Offline glarsson

  • Frequent Contributor
  • **
  • Posts: 814
  • Country: se
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #24 on: November 06, 2017, 06:08:01 pm »
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.  |O
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf