EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: lundmar on March 31, 2016, 04:09:45 am
-
Hi guys,
I've just made available two open source projects, lxi-tools and liblxi, that are useful for controlling LXI enabled instruments on GNU/Linux systems:
http://lxi.github.io (http://lxi.github.io)
* lxi-tools provide a simple commandline tool for discovering LXI instruments and sending SCPI messages.
* liblxi is a C library which provides a high level API for basic LXI operations.
Also included in lxi-tools is a small screenshot capture tool for Rigol 1000Z series oscilloscopes. More tools like this can be added in the future for other instruments.
The software is still early stages (beta) but works pretty well already.
It's open source so feel free to test, help, contribute features, improvements etc.. Please use github for reporting issues or creating pull requests.
Also, if you feel inclined to create a cool tool for your instrument based on liblxi feel free to have it included in lxi-tools.
The motivation for creating these two projects is that I feel GNU/Linux systems have been in lack of good and simple open source software for controlling our LXI enabled instruments.
Happy hacking :-+
Br, Martin
-
How is this different from "vxi-11" that works well for SCPI control from python?
https://github.com/python-ivi/python-vxi11 (https://github.com/python-ivi/python-vxi11)
Do you have plans for python bindings?
Found a page that talks about the difference between VXI-11 and LXI but not sure I understand what it says...
http://www.lxistandard.org/about/vxi-11-and-lxi.aspx (http://www.lxistandard.org/about/vxi-11-and-lxi.aspx)
-
How is this different from "vxi-11" that works well for SCPI control from python?
liblxi is a simple C library that high level abstracts the VXI11 RPC protocol which is used by LXI certified instruments for communication.
Hence liblxi is mainly targeted for developers writing C/C++ applications to control their instruments.
I don't have any plans for python bindings but it could easily be done. Any contributions are welcome ;)
-
How is this different from "vxi-11" that works well for SCPI control from python?
liblxi is a simple C library that high level abstracts the VXI11 RPC protocol which is used by LXI certified instruments for communication.
Hence liblxi is mainly targeted for developers writing C/C++ applications to control their instruments.
I don't have any plans for python bindings but it could easily be done. Any contributions are welcome ;)
so again, how is it different from the vxi11 library, I've used that to talk to my lxi tools without issue. its as simple as vxi11_send + vxi11_receive.. how much more abstraction do you need? works perfect for me under linux.
open device, send/recv, close device.. that is a pretty thin api layer. what does your library give me extra?
I looked briefly over it, looks a little nicer setup than the older vxi11 from Steve Sharples / applied optics.
-
so again, how is it different from the vxi11 library, I've used that to talk to my lxi tools without issue. its as simple as vxi11_send + vxi11_receive.. how much more abstraction do you need? works perfect for me under linux.
open device, send/recv, close device.. that is a pretty thin api layer. what does your library give me extra?
Feature wise, sure, yes they are pretty much the same in the sense they both allow communicating commands to your instrument in a simple manner.
But to reiterate, liblxi is a C library while vxi-11 is a python library.
I realize that might not make much of a difference to some but not everyone needs nor prefers python and if you are creating a C/C++ application it does not make much sense to depend on some python class and whatever else python stuff gets pulled in. Also, not to forget are potential messy issues with different python versions behaving differently on different systems. Compared liblxi is a much smaller more self contained entity with no dependencies so less hassle.
Also, ultimately it will be possible to make liblxi perform better than any python solution. While I don't think the current version of liblxi is particularly optimized it certainly holds the potential. For some performance is quite important, especially when retrieving those big waveform data. In production, every second counts.
There is one "extra" feature which liblxi provides and that is automatic discovery of LXI devices on your network. I don't see python-vxi11 provides that but they could easily add it.
I really didn't want this to turn into a python vs. C discussion but there you go :)
Anyway, liblxi is only half the part of what is released. lxi-tools is also quite useful and I hope some interesting features will be added in the future (maybe added UI tools and support for more instrument specific tools for features such as screenshot and waveform capture/presentation/analysis).
-
But to reiterate, liblxi is a C library while vxi-11 is a python library.
what? the original is a C library from 2006, from here http://optics.eee.nottingham.ac.uk/vxi11/ (http://optics.eee.nottingham.ac.uk/vxi11/)
its now migrated to here https://github.com/applied-optics/vxi11 (https://github.com/applied-optics/vxi11)
look under library. https://github.com/applied-optics/vxi11/tree/master/library (https://github.com/applied-optics/vxi11/tree/master/library)
vx11_user.c is the entire library. there is a python wrapper but its a proper C library.
doing a make install nets you the libvxi11 + header which is all you need.
-
But to reiterate, liblxi is a C library while vxi-11 is a python library.
what? the original is a C library from 2006, from here http://optics.eee.nottingham.ac.uk/vxi11/ (http://optics.eee.nottingham.ac.uk/vxi11/)
its now migrated to here https://github.com/applied-optics/vxi11 (https://github.com/applied-optics/vxi11)
look under library. https://github.com/applied-optics/vxi11/tree/master/library (https://github.com/applied-optics/vxi11/tree/master/library)
vx11_user.c is the entire library. there is a python wrapper but its a proper C library.
doing a make install nets you the libvxi11 + header which is all you need.
The vxi-11 that you referred is still a python library. Wrapper or not.
Yes, I'm quite familiar with your source links - liblxi include that same module as described in the liblxi README.
In fact, if you dig deeper, the origin is the asynDriver EPICS module found here: http://www.aps.anl.gov/epics/modules/soft/asyn/index.html (http://www.aps.anl.gov/epics/modules/soft/asyn/index.html)
It is still maintained.
liblxi is a higher level abstraction which does away with some of the intricate details of the vxi11 C module.
-
The vxi-11 that you referred is still a python library. Wrapper or not.
there is a python file as an example on how to call it, but its not a python library. well, I guess in a sense it is, since any C library is callable from python.. or ruby.. or lua.. or perl..
hey, that makes yours, also a python library! cool no? :clap:
liblxi is a higher level abstraction which does away with some of the intricate details of the vxi11 C module.
how is it higher, how will it make my life better if I switch my code over? I mean, libvxi11 gives me all I need to communicate with a vxi/lxi device.... open, send/recv, close.. what intricate details does it do away with in libvxi11?
I'm trying to get you to explain why its better than the well known pre-existing library, but I need more than a vague 'intricate details' answer.
say we want to connect to rigol scope, grab its identifier string, send say 10 other commands to setup channel 1, turn it on whatever, some bunch of arbitrary calls then quit.
with libvxi11, I open device, send the commands, read data etc, close device. those are the core steps. as basic as it gets.
how would that change with yours? do I not need to open the device? send/recv? close?
just trying to find out what makes it better/easier?
(I mean, I have a large project using it as the core to talk ethernet over gpib, if its better, I'll switch in a heart beat! https://www.eevblog.com/forum/projects/a-fancy-gpib-psu-front-end/ (https://www.eevblog.com/forum/projects/a-fancy-gpib-psu-front-end/)) Im asking because I want to know, not because I want to be an ass about it :)
-
there is a python file as an example on how to call it, but its not a python library. well, I guess in a sense it is, since any C library is callable from python.. or ruby.. or lua.. or perl..
hey, that makes yours, also a python library! cool no? :clap:
Sorry, there is some miscommunication going on here. When I write "vxi-11" I meant the python library you mentioned - I simply continued the terminology you started there.
But you are right, "libvxi11" is a C only implementation.
liblxi is a higher level abstraction which does away with some of the intricate details of the vxi11 C module.
The vxi11 C module I'm talking about here is the C source auto generated (via rpcgen) from vxi11.x in case of libvxi11 or vxi11core.rpcl in case of liblxi. This code is much more low level and include all the intricate details I referred.
how is it higher, how will it make my life better if I switch my code over? I mean, libvxi11 gives me all I need to communicate with a vxi/lxi device.... open, send/recv, close.. what intricate details does it do away with in libvxi11?
I'm trying to get you to explain why its better than the well known pre-existing library, but I need more than a vague 'intricate details' answer.
Well, comparing libvxi11 and liblxi they are similar so I won't make a fuzz about the API detail differences. Also, liblxi is certainly less tested at the moment. So for those two reasons alone I would not recommend you to switch at this point.
However, liblxi does offer automatic discovery of devices which is quite useful (maybe not in your case, but for commandline tools such as 'lxi' from lxi-tools it is a required feature). Also, both liblxi and lxi-tools are distributed using classic autotools scripts (configure, make etc.) which I think is much preferred over manual makefiles for easy installation. liblxi is simply a bit more GNU/Linux centric and clean cut in that way. I also plan to add man pages for liblxi once the API is finalized (still beta) and if I can find the time I might also make the communication backend configurable so that you can choose between VXI11 and RAW, the latter which will be very fast for some scenarios and instruments.
So, they might not be very different but by the end of the day I myself will prefer liblxi on my GNU/Linux system because of the above mentioned details.