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

[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 ~1100 requests/s via TCP/VXI11:

Code: [Select]

$ lxi benchmark --address 192.168.1.125
Benchmarking by sending 1000 ID requests. Please wait...
Result: 1123.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 1000 ID requests. Please wait...
Result: 1123.5 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,141s
user    0m0,004s
sys     0m0,024s

Only ~0.14 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 if it works for you.

[ralphrmartin]

Thanks. The ID string from the meter is
Keysight Technologies,34461A,<serial number here>,A.02.17-02.40-02.17-00.52-03-02
but apparently the ID string is user changeable to also make it look like an Agilent or HP unit, for backwards compatibility.

I tried
snap refresh lxi-tools --edge
to get your latest version, but it told me
snap "lxi-tools" has no updates available

snap list
reports
Name       Version  Rev   Developer  Notes
core       16-2.30  3748  canonical  core
lxi-tools  1.17     478   lundmar    -

Did I do something wrong? How should I get the new plugin?

[lundmar]

Thanks. The ID string from the meter is
Keysight Technologies,34461A,<serial number here>,A.02.17-02.40-02.17-00.52-03-02
but apparently the ID string is user changeable to also make it look like an Agilent or HP unit, for backwards compatibility.

I tried
snap refresh lxi-tools --edge
to get your latest version, but it told me
snap "lxi-tools" has no updates available

snap list
reports
Name       Version  Rev   Developer  Notes
core       16-2.30  3748  canonical  core
lxi-tools  1.17     478   lundmar    -

Did I do something wrong? How should I get the new plugin?

Good - the new plugin should match your ID.

Unfortunately it seems the snap build service is currently down and the ETA is unknown. Hopefully it will soon be available again so that a new snap will be built.

EDIT: It's because of the whole spectre/meltdown thing the build service is down.

[ralphrmartin]

Good to know I haven't done something wrong. Will try again later, and report back. Thanks for the rapid responses!

[lundmar]

This is how I think the new lxi GUI (lxi-gui) is going to look:



To make it really simple, all features in the listed tab views (SPCI, Screenshot, Benchmark, etc.) operate on the instrument selected in the instrument list.

Currently instruments are automatically added to the list via the search feature but I expect to add the option of also adding instruments manually in case an instrument does not support discovery.

I think the structure of this GUI is very user friendly.

[Karel]

 

[lundmar]

Good to know I haven't done something wrong. Will try again later, and report back. Thanks for the rapid responses!

The lxi-tools snap is now up to date.

The snap build service is finally up and running again after they patched their build servers with Spectre/Meltdown fixes.

[ralphrmartin]

Great!  I now managed to snap refresh lxi-tools, and can confirm that the Keysight screenshot works as intended.

The UI looks good too. Will it be possible to have multiple windows open, so you can send commands to more than one device at once? E.g. you might want to send frequency commands to an AWG, and measurement commands to a scope...

[lundmar]

Great!  I now managed to snap refresh lxi-tools, and can confirm that the Keysight screenshot works as intended.

Good - I've added it to the list of tested instruments. Thanks for testing 

The UI looks good too. Will it be possible to have multiple windows open, so you can send commands to more than one device at once? E.g. you might want to send frequency commands to an AWG, and measurement commands to a scope...

Well, yes and no. You can open multiple instances of the application and this way control multiple instruments through different windows.

However, the tab views you see will only support one instrument at a time - namely the one selected.

The feature you are describing is something that I hope to eventually support in a script feature which might become part of lxi-gui.

Meaning, you will be able to use lxi-gui to build a script which contains various action items such as SCPI commands managing one or more instruments.

Each action item will be written in Lua which is a simple, fast, and powerful scripting language.

Lua will make it possible to create scripts looking like this (example):

Code: [Select]

inst0 = connect("vxi11://10.0.0.42")
inst1 = connect("vxi11://192.168.0.21")

scpi(inst0, ":source:frequency 10000")

sleep(1000)

voltage = scpi(inst1, ":measure:voltage:dc?")
if (voltage < 10.5) then fail() end

disconnect(inst1)
disconnect(inst0)

Or, a slightly different but object oriented variation of the same:

Code: [Select]

inst0 = connect("vxi11://10.0.0.42")
inst1 = connect("vxi11://192.168.0.21")

inst0.scpi(":source:frequency 10000")

sleep(1000)

voltage = inst1.scpi(":measure:voltage:dc?")
if (voltage < 10.5) then fail() end

disconnect(inst1)
disconnect(inst0)

Each section in this script can be a separate item in a graphical representation of the script.

The script can be saved/loaded from the application and there will be "play", "pause", "stop" buttons. When you press play it will run the script and each action item will be marked red or green depending on if they fail or succeed.

I think it will work quite nicely. Even though I don't have any plans to add an elaborate GUI for handling graphical scripting blocks I'm making it so it will be possible to add in the future. Ultimately, having Lua scripting support will make it possible to do some of the graphical programming that application such as BenchVue supports.

[nctnico]

Lua support would be a great feature! 

[lundmar]

Lua support would be a great feature! 

I think so too. Of all the scripting languages Lua is quite beautiful/straightforward and it has all the basic language features that are required for logic control. It helps keep the script syntax simple.

[alm]

If you develop this into an instrument control GUI and scripting language, would it not make sense to use an abstraction like VISA rather than interfacing with LXI directly? Otherwise developing a script while having an instrument without LXI in the mix (USBTMC/GPIB/RS-232) becomes a pain, while in VISA you would only change the connection string.

[lundmar]

If you develop this into an instrument control GUI and scripting language, would it not make sense to use an abstraction like VISA rather than interfacing with LXI directly? Otherwise developing a script while having an instrument without LXI in the mix (USBTMC/GPIB/RS-232) becomes a pain, while in VISA you would only change the connection string.

I understand what you are saying but I'm afraid adding a VISA abstraction is beyond the scope and resources of this project.

As you said, VISA abstracts various interfaces such as VXI11/USBTMC/GPIB/RS-232. However, since this is lxi-tools the focus is exclusively on the interfaces supported by the LXI standard (VXI11/HiSLIP etc.) so for this project there are no plans to support other interfaces nor add a full blown VISA API in e.g. Lua.

What you are suggesting is something which would be an excellent feature for a future open source visa-tools project

[nctnico]

If you develop this into an instrument control GUI and scripting language, would it not make sense to use an abstraction like VISA rather than interfacing with LXI directly? Otherwise developing a script while having an instrument without LXI in the mix (USBTMC/GPIB/RS-232) becomes a pain, while in VISA you would only change the connection string.

A better approach would be to add support to send commands to USBTMC or a COM port (both are pretty similar). VISA is way too bloated.

[lundmar]

If you develop this into an instrument control GUI and scripting language, would it not make sense to use an abstraction like VISA rather than interfacing with LXI directly? Otherwise developing a script while having an instrument without LXI in the mix (USBTMC/GPIB/RS-232) becomes a pain, while in VISA you would only change the connection string.

A better approach would be to add support to send commands to USBTMC or a COM port (both are pretty similar). VISA is way to bloated.

I agree, if you look at the general syntax and features of VISA you either love it or hate it.

The interface that I plan to support in Lua will be much simpler - just a basic interface for sending SCPI commands, handling responses, and reporting failed test cases.

If this Lua interface proves itself to be useful/efficient/successful , one could consider expanding and adding support for non-LXI interfaces but I think that is something which should be reserved for another project.

[alm]

A better approach would be to add support to send commands to USBTMC or a COM port (both are pretty similar). VISA is way to bloated.

I was not suggesting to use the NI-VISA implementation, but abstracting the protocol used to access an instrument. For example, there is a Python implementation that is pretty light weight. When I was controlling a DSO that could either controlled through RS-232 or GPIB, I made my own abstraction that would call either ibconfig(), ibwrt() etc for GPIB, or tcsetattr(), write() etc for RS-232, so I did not have to sprinkle conditionals all through my code.

But obviously in a volunteer project the decision on what direction to go is entirely on the developers doing the work.