Open source lxi-tools v2.7 released

[lundmar]

Hello everyone!

I'm happy to announce the latest release of lxi-tools - see https://lxi-tools.github.io for more details.

lxi-tools is a collection of open source software tools for managing network attached LXI compatible test instruments such as modern oscilloscopes, power supplies, spectrum analyzers etc.

The lxi-tools open source project provides the following key components:

• "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 advanced scripting features
• "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)

Here are some screenshots of the lxi-gui application in action:








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


Installation

GNU/Linux
Install latest stable version using snap:  $ snap install lxi-tools
Install latest development version using snap:  $ snap install lxi-tools --edge

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

Mac OS
Install latest stable version using Homebrew:  $ brew install lxi-tools

Windows
You can install e.g. Virtualbox (see https://www.virtualbox.org) and install a GNU/Linux distribution (e.g. Ubuntu 21.10) in a VM in which you can install and run lxi-tools.

Note: Remember to reconfigure your VMs network interface to use a bridged network adapter (not NAT) else the default instrument search feature will not work.
Note: Soon Windows users will be able to easily install and run lxi-tools via WSL2/WSLg.



Motivation
This open source project is for people who don't care for the proprietary, costly, and often times inferior tools available for managing LXI compatible instruments. The very reason I authored lxi-tools/liblxi is because I want simpler and better tools for managing my test 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!

Thanks to everyone in this forum who are helping to test and improve lxi-tools! 


Call for contributors
Anyone who would like to contribute to this project to help make it better is welcome to join in. All contributions are welcome (bug reports, code, feature ideas, doc, testing, etc.). All source is available on Github here.

P.S: lxi-tools is not in any way affiliated with the LXI consortium. It is a fully independent open source community effort.

[optotester]

Thanks Martin and … good news for MacOS users. Last week I have been working on porting LXI tools to MacOS and I am 99% done (some discussion in progress with one of the GTK4 lead developer as there is some bugs in GTK itself). I will most likely release it this weekend. I will do a merge request on your GitHub on Wednesday to fix some issues and replace avahi by a mdns wrapper library for full compatibility with all OSes if you are ok with that.

[lundmar]

Thanks Martin and … good news for MacOS users. Last week I have been working on porting LXI tools to MacOS and I am 99% done (some discussion in progress with one of the GTK4 lead developer as there is some bugs in GTK itself). I will most likely release it this weekend. I will do a merge request on your GitHub on Wednesday to fix some issues and replace avahi by a mdns wrapper library for full compatibility with all OSes if you are ok with that.

Great! That is excellent news.

For sure I am ok with that.

I'm looking forward to your merge request whenever it is ready. If the mdns wrapper library works well then I expect it will be fine to replace using Avahi directly. We can make it a feature of the next release.

Meanwhile I will start the process of making lxi-tools available via https://flathub.org

[lundmar]

Unfortunately I can't easily distribute a flatpak of lxi-tools in places like flathub.org

The reason is that they do not allow my application ID to reflect my true reverse DNS domain. It is mostly for policy reasons and not so much technical ones. It's all very silly.

So, if you prefer flatpak over snap, you will have to build and install the lxi-tools flatpak yourself. Instructions are available here:

https://github.com/lxi-tools/lxi-tools.flatpak

For now, snap is the way to go and maybe eventually the various distributions will include native packages of lxi-tools.

[Sergeant82d]

Martin, and anyone else who can help me -

I was using the ver 1.21 beta on my Raspberry Pi 4 (4GB) lab computer successfully and enjoyably, connecting and controlling my four late model Siglent machines.

So I was happy yesterday when ver 2.0 was announced, and immediately tried to install it. Key word there is "tried"...

After emailing Martin, I was successful in downloading and installing the updated version, but it doesn't run. The mouse cursor spins in an hourglass for a few seconds, but that is it.

I have "refreshed" the snap several times, and also I removed and reinstalled it, while also doing a --purge on it, to no avail.

I "know" it was installed - here is what I get when checking the version from the terminal:

@raspberrypi:~ $ lxi --version
ERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
lxi v2.0

Can anyone point me in the right direction to fix this?

Thanks,

Brad

(PS - first post on EEVB!)

[lundmar]

@raspberrypi:~ $ lxi --version
ERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
lxi v2.0

Can anyone point me in the right direction to fix this?

Actually, it looks like you are trying to start the native lxi application which must have been attempted installed at some point and maybe never worked.

To start the installed snap version of lxi-tools you should fire the following command:

Code: [Select]

$ lxi-tools.lxi-gui

Likewise, to start the command-line tool:

Code: [Select]

$ lxi-tools.lxi

Give it a try.

[RoGeorge]

The lxi-tools v1 is dead, long live the lxi-tools v2! 

[lundmar]

The lxi-tools v1 is dead, long live the lxi-tools v2! 

Ha ha - true!

[lundmar]

@raspberrypi:~ $ lxi --version
ERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
lxi v2.0

Can anyone point me in the right direction to fix this?

If your problem persists try the fix described here: https://stackoverflow.com/a/50958615

[ve7xen]

Installed via AUR. Looks nice and working well. Thanks! 

[optotester]

Pull request done on lxi-tools and liblxi for macOS compatibility.
liblxi can be easily compiled with meson, but I would advise to use XCode to generate a signed library.

For lxi-tools it is more complex and I did not adapt the meson build files, it has to be build through XCode (you can install the dependencies through brew, except gtk and gtksourceview5).
For gtk, you must compile manually this version: https://gitlab.gnome.org/sumibi-yakitori/gtk/-/commits/wip/chergert/yakitori/macos-fixes
For gtksourceview, you must compile the master version.

Before compiling, do not forget to run:

Code: [Select]

glib-compile-resources --target=lxi_gui-resources.c --generate-source lxi_gui.gresource.xml --c-name=lxi_gui

Before launching for the first time, do not forget to install the config file either:

Code: [Select]

cp data/io.github.lxi-tools.lxi-gui.gschema.xml /usr/local/share/glib-2.0/schemas
glib-compile-schemas /usr/local/share/glib-2.0/schemas
I will release a binary soon.

[lundmar]

Pull request done on lxi-tools and liblxi for macOS compatibility.

Thanks, I'll review the PR as soon as possible.

For building on MacOs I trust you will take care of that. I don't have access to a Mac environment.

I assume MacOs has Brew channels for distributing 3rd party applications.

[probe]

Hi Lundmar,

Many thanks for this fantastic tool!
May I give some feedback? LXI-tools was able to discover 5 devices (Rigol DS1054Z, Siglent SDS2104x plus, Siglent SSA 3021X Plus, Rigol DG1022Z and Rigol DP832, all "hacked" into their more capable versions (e.g. The SSA 3021X plus now thinks its is a SVA1032X) but funnily enough the only device that isn't liberated doesn't show up when running lxi discover, a Rigol DM3068. It is reachable though when I run lxi benchmark -a <IP address>. I'm happy to help out if you want me to help make it discoverable.

More pressing thing, I tried to run LXI-tools V2 on Kali, Ubuntu and Raspberry pi OS. Kali and Rpi don't have the V2 yet, Ubuntu does but when I try to run lxi-gui it gives an error that it can not connect to a screen. I installed V2 on Rpi via snap but also there you get the error that lxi-gui can not start due to a x-window error. I'm posting this from a Mac so can not post the precise error but will try in a separate post.

BTW, building from source on Kali is painful...

[probe]

pi@raspberrypi:~ $ lxi-gui

(lxi-gui:2313): Gdk-ERROR **: 16:44:18.660: The program 'lxi-gui' received an X Window System error.
This probably reflects a bug in the program.
The error was 'GLXBadFBConfig'.
  (Details: serial 2141 error_code 167 request_code 152 (GLX) minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

[lundmar]

Many thanks for this fantastic tool!
May I give some feedback?

Thank you. Of course, feedback is very welcome so we can fix any bugs found!

LXI-tools was able to discover 5 devices (Rigol DS1054Z, Siglent SDS2104x plus, Siglent SSA 3021X Plus, Rigol DG1022Z and Rigol DP832, all "hacked" into their more capable versions (e.g. The SSA 3021X plus now thinks its is a SVA1032X) but funnily enough the only device that isn't liberated doesn't show up when running lxi discover, a Rigol DM3068. It is reachable though when I run lxi benchmark -a <IP address>. I'm happy to help out if you want me to help make it discoverable.

Hmm. I actually have the smaller brother DM3058 sitting right next to me and it discovers fine using the default discovery method. It does not support discovery via mDNS though. Both of these products are LXI certified and they should be discoverable with the current implementation, especially since I believe they share the same firmware codebase. Which discovery method are you using? Default or mDNS? See lxi-gui preferences.

More pressing thing, I tried to run LXI-tools V2 on Kali, Ubuntu and Raspberry pi OS. Kali and Rpi don't have the V2 yet, Ubuntu does but when I try to run lxi-gui it gives an error that it can not connect to a screen. I installed V2 on Rpi via snap but also there you get the error that lxi-gui can not start due to a x-window error. I'm posting this from a Mac so can not post the precise error but will try in a separate post.

BTW, building from source on Kali is painful...

Building lxi-tools with lxi-gui is a bit involved and painful on most distributions right now because lxi-gui requires very recent versions of core components such as GTK4.6.0, libadwaita 1.0.1, etc.

I don't expect lxi-tools to work easily or maybe at all on older distributions, with or without snap.

I think both of your issues may require quite a lot of debug so I would ask you to report your bugs in the Github issue tracker here: https://github.com/lxi-tools/lxi-tools/issues

Then we can continue from there.

Thanks.

[lundmar]

I don't know if it's the bug or how the LXI tools work, but just a remark about the DM3068 and the VXI protocol.
The DM3068 can not be accessed when using device flags at e.g. 'device_write'. I had used the flag 'WaitLock' and the communication was denied. The Rigol DG4000 with old firmware also gives an error message on the screen. Without device flags everything works without problems.

Thanks, that is very useful information. I will have to investigate - right now, I don't remember exactly which flags are in use. This is the first time I ever heard of a LXI certified instrument not being discoverable via my VXI11 discovery implementation.

[probe]

Which discovery method are you using? Default or mDNS? See lxi-gui preferences

Default, see terminal copy/paste below:

pi@raspberrypi:~ $ lxi discover -m
Searching for LXI devices - please wait...

No services found

pi@raspberrypi:~ $ lxi discover
Searching for LXI devices - please wait...

Broadcasting on interface lo
Broadcasting on interface eth0
  Found "Siglent Technologies,SDS2504X Plus,SDS2PDDxxxxxxx,5.0.1.3.9R6" on address 192.168.178.83
  Found "Siglent Technologies,SVA1032X,XXXXXXXXXX,3.2.2.5.0.r8" on address 192.168.178.80
  Found "Rigol Technologies,DG1062Z,DG1ZAxxxxxxxx,03.01.12  " on address 192.168.178.102
  Found "RIGOL TECHNOLOGIES,DP832A,DP8Cxxxxxxxxx,01.01.16" on address 192.168.178.101
  Found "RIGOL TECHNOLOGIES,DS1104Z,DS1ZAxxxxxxxxx,00.04.05.SP2" on address 192.168.178.100

Found 5 devices

pi@raspberrypi:~ $ lxi scpi -a 192.168.178.103 *IDN?
Rigol Technologies,DM3068,DM3O222400340,01.01.00.01.10.00
pi@raspberrypi:~ $
-------------------------

P.S. I can't run lxi-gui atm due to the error described above. Serials replaced by xxxx's

[lundmar]

P.S. I can't run lxi-gui atm due to the error described above. Serials replaced by xxxx's

That's fine. I assumed you were using lxi-gui but it does not matter, it's the exact same mechanism.

Give me some time, I will investigate the flag configuration that PeDre mentioned, it may be related. But first I need to fix a rather big contributed mDNS replacement feature.

[JohanH]

Unfortunately I can't easily distribute a flatpak of lxi-tools in places like flathub.org

The reason is that they do not allow my application ID to reflect my true reverse DNS domain. It is mostly for policy reasons and not so much technical ones. It's all very silly.

What craziness is that? I thought the whole idea of borrowing the reverse DNS d-bus concept was to get unique names/addresses. Can't you just use a made up name then? Now I haven't created any flatpaks (only rpms), so I'm not that familiar with their requirements.

Many distros prefer flatpak over snap nowadays, snap has become almost a Ubuntu thing only (Canonical always try to do their own race and eventually gives up and uses what everybody else does). I certainly prefer flatpaks over snaps, any day.

[lundmar]

Unfortunately I can't easily distribute a flatpak of lxi-tools in places like flathub.org

The reason is that they do not allow my application ID to reflect my true reverse DNS domain. It is mostly for policy reasons and not so much technical ones. It's all very silly.

What craziness is that? I thought the whole idea of borrowing the reverse DNS d-bus concept was to get unique names/addresses. Can't you just use a made up name then? Now I haven't created any flatpaks (only rpms), so I'm not that familiar with their requirements.

Many distros prefer flatpak over snap nowadays, snap has become almost a Ubuntu thing only (Canonical always try to do their own race and eventually gives up and uses what everybody else does). I certainly prefer flatpaks over snaps, any day.

The issue is that I'm using an application ID true to my reverse DNS name, "io.github.lxi-tools.lxi-gui" but it is strongly recommended to not use hyphens in the app ID to avoid some exotic conflicting DBus use case. Flathub is enforcing this notation. Meaning it will have to look like this "io.github.lxi_tools.lxi-gui". I know this is a small detail but it really bugs me because it looks silly and everything works perfectly as it is. I can't believe that the DBus guys did not account for this situation considering they choose to base everything on the reverse DNS notation so why not make it ACCURATE!

Anyway, eventually I will probably change the app ID to agree with the recommendations but I'm not sure I really want to maintain a flatpak. There is a lot of controversy about flatpak vs snap and I have been leaning towards flatpak because I know the NIH history of Ubuntu. However, having now been through the experience of creating both a snap and a flatpak, I must say that snaps seem to be a much more well designed and mature platform and it is much easier to use. Also, there is the fundamental problem of flatpaks only being designed for distributing single binary GUI applications. I want to also distribute my command-line tool so I'm thinking I shouldn't bother with flatpaks. It is also an annoyance for end users when they go to their software store and both a flatpak and a snap turns up - it adds to the confusion.

[JohanH]

The issue is that I'm using an application ID true to my reverse DNS name, "io.github.lxi-tools.lxi-gui" but it is strongly recommended to not use hyphens in the app ID to avoid some exotic conflicting DBus use case. Flathub is enforcing this notation. Meaning it will have to look like this "io.github.lxi_tools.lxi-gui". I know this is a small detail but it really bugs me because it looks silly and everything works perfectly as it is. I can't believe that the DBus guys did not account for this situation considering they choose to base everything on the reverse DNS notation so why not make it ACCURATE!

Ah, yes, I remember now. But this doesn't really matter. AFAIK, the name is only used to identify the flatpak application, so hasn't any connection to a real DNS whatsoever.

I haven't been using snaps lately, but its true that flatpaks are aimed for GUI applications. My personal opinion is that cmd line tools are best coming from the distro repository. I see that lxi-tools are included in Fedora (very nice), but I expect it to take a while as usual before latest version is available.

I built the flatpak and sent a pull request for a small version fix for the flatpak build. (That was fast, I got the notification now it was merged).

The GUI works nicely, thanks!

Here's a screenshot of Siglent SDS1204X-E.

[lundmar]

Ah, yes, I remember now. But this doesn't really matter. AFAIK, the name is only used to identify the flatpak application, so hasn't any connection to a real DNS whatsoever.

I know, it's just that I'm very particular when it comes down to details like this

Anyway, for now, I'll keep maintaining an unofficial flatpak for those who insists on using flatpak.

I haven't been using snaps lately, but its true that flatpaks are aimed for GUI applications. My personal opinion is that cmd line tools are best coming from the distro repository. I see that lxi-tools are included in Fedora (very nice), but I expect it to take a while as usual before latest version is available.

I agree, especially as seen from a performance perspective. The only problem is the package propagation delay. I expect that lxi-tools will eventually be picked up be the various distros but it will take months. With snaps I can literally distribute a new package via the official snap channels in minutes. Even flatpak is much slower than that because it requires human intervention to distribute via places such as flathub (needs human review etc.).

The GUI works nicely, thanks!

Here's a screenshot of Siglent SDS1204X-E.

Great. I once had the exact same model kindly sponsored by Siglent for testing with the lxi-tools project. Unfortunately it broke because someone dropped it when I was moving. R.I.P. 

[JohanH]

Just another comment about the reverse DNS name thing. This is a Freedesktop.org specification, so it isn't really flatpak that requires the strict naming thing, they just follow the specification.

Edit. But well, you could debate why they had to choose the whole naming scheme.

[lundmar]

Just another comment about the reverse DNS name thing. This is a Freedesktop.org specification, so it isn't really flatpak that requires the strict naming thing, they just follow the specification.

Edit. But well, you could debate why they had to choose the whole naming scheme.

I know, the point is they are enforcing something which is strongly recommended but not strictly mandated.

[lundmar]

I have released lxi-tools v2.1

It includes a few new UI features and bug fixes.

For a full changelog see https://github.com/lxi-tools/lxi-tools/releases/tag/v2.1