| Instrument | Working 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) |
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
I've opened an issue for lxi-tools. Perhaps I'm messing things up when compiling
do you have plans for python bindings?
Might be a stupid question, but what's the difference between LXI and VXI11?
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
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
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:~$
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".
$ 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)
lxi screenshot --adress 192.168.0.40 --model rigol screenhot.png
Saved PNG screenshot image to screenhot.png
- 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?
lxi scpi --raw --address 192.168.0.42 "*IDN?"
RIGOL TECHNOLOGIES,DS1104Z,DS1ZA1234567890,00.04.04.SP3
- 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?
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.
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 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.
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;
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>
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"
lxirogeorge@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$
Passedrogeorge@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 - Cosmeticrogeorge@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 inconveniencerogeorge@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$
rogeorge@debian80:~/lxi-tools$ lxi discovery
Error: No IP address specified
rogeorge@debian80:~/lxi-tools$
Failed - Minor inconvenienceI 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
rogeorge@debian80:~/lxi-tools$ lxi scpi -r -a 192.168.1.3 "CHAN1:DISP?"
1
rogeorge@debian80:~/lxi-tools$ lxi scpi -a 192.168.1.3 "CHAN1:DISP?"
1
rogeorge@debian80:~/lxi-tools$ lxi scpi -a 192.168.1.3 -r "CHAN1:DISP?"
1
rogeorge@debian80:~/lxi-tools$ lxi scpi -ra 192.168.1.3 "CHAN1:DISP?"
1
rogeorge@debian80:~/lxi-tools$ lxi scpi -ra 192.168.1.3 "CHAN1 DISP?"
Command error
rogeorge@debian80:~/lxi-tools$ lxi scpi -a 192.168.1.3 "CHAN1 DISP?"
Error: Read error (timeout)
Error: Failed to receive message
rogeorge@debian80:~/lxi-tools$
Passed
rogeorge@debian80:~/lxi-tools$ lxi screenshot
Error: Missing address
rogeorge@debian80:~/lxi-tools$ lxi screenshot -a 192.168.1.3
Error: Missing model
rogeorge@debian80:~/lxi-tools$ lxi screenshot -a 192.168.1.3 -m rigol
Saved screenshot image to screenshot-000.png
rogeorge@debian80:~/lxi-tools$ lxi screenshot -a 192.168.1.3 -m rigol -f DS1Z_SCR.png
lxi: invalid option -- 'f'
PassedMade 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.
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
I don't think anyone disagrees here to the extend it is possible. Just be mindful not everything can be done in portable code and sometimes non-portable code is required, especially when dealing with hw interfaces.True, but the non-portable code can be located in separate files to make it easier to port to different platforms.
Also, this is one open source project among many that I'm doing in the little spare time that I have available so I don't have the time to put endless rigor into making everything portable in the first go. That being said, anyone is welcome to contribute to the project and fix any issues they might find, including portability issues.I was looking at adding code to sigrok or port lxi-tools to macOS (a certified UNIX with a marketshare larger than Linux) but did get the feeling that contributions to lxi-tools supporting platforms other than Linux was not welcome.
True, but the non-portable code can be located in separate files to make it easier to port to different platforms.True, especially if there is a lot of it. Conditional ifdefs will do fine for smaller code bits, which is the case here.
I was looking at adding code to sigrok or port lxi-tools to macOS (a certified UNIX with a marketshare larger than Linux) but did get the feeling that contributions to lxi-tools supporting platforms other than Linux was not welcome.Any contributions to improve lxi-tools or liblxi are welcome. Yes, it is initially made for and tested on GNU/Linux systems but that is mainly because I don't have the bandwidth nor access to test and support other platforms. In other words, I'm not opposed to supporting other platforms but only if someone would like to contribute/help maintain that support. That being said, not much is required to make it work on most platforms.
Other than not being portable to non-Gnu/Linux systems, I don't see what this does
FWIW I started porting it to Solaris 10 u8. It's actually nicely written code from the little I've looked at. The code I'm using was downloaded from github as a tarball after you started this thread. So I'm not sure how you can call it old. Once I've got it running on Solaris, it will work on MacOS and *nix in general.
if_nameindex() returns all the network interfaces and *is* part of POSIX and on Solaris 10 u8 which is so ancient I keep it off the Internet.
Yes, I'm a grumpy old man. I've supported over 2 million lines of badly written code that other people inflicted upon the world. I'm really tired of seeing the same mistakes made over and over again. IBM created JCL to fix the problem of hard coded filenames. And of course, *everyone* using JCL knew that everything after a space was a comment because that was the 360 assembler convention. Then 10-20 years later the Motif mob hard coded xkeysymdb. After 20+ years I've finally forgotten where. We now have a version of xclock that consumes more memory than most of the computers I've used had available. Your phone needs more horsepower than a Cray YMP. Ain't progress grand!
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$
dpenev@yni:~/lxi-tools/lxi-tools$ lxi discover
Searching for LXI devices - please wait...
Broadcasting on interface lo
Broadcasting on interface eth0
Found "RIGOL TECHNOLOGIES,DS2302,DS2XXXXXXXXXXXXX,00.03.05.SP3" on address 192.168.1.59
Found 1 device
dpenev@yni:~/lxi-tools/lxi-tools$ lxi screenshot -a 192.168.1.59 -m rigol
Error: Read error (timeout)
Error: Failed to receive message
lxi screenshot -a 192.168.1.59 -m rigol-2000 #Works fine now
1. Can there be a option for png instead of bmp? png are smaller.
2. The following doesn't work
dpenev@yni:~$ lxi scpi -ra 192.168.1.59 -m rigol-2000 "CHAN1 DISP?"
lxi: invalid option -- 'm'
dpenev@yni:~$ lxi scpi -ra 192.168.1.59 "CHAN1 DISP?"
Error: Timeout
Error: Failed to receive message
Can I send scpi commands to my DS2000
3. I have Siglent SSA3021X instrument.
lxi screenshot -a 192.168.1.59 #Doesn't work for it. Is it a big deal to add support?
4. Few other test samples
lxi screenshot -m rigol-1000 #doesn't work for DP832.
lxi scpi -a 192.168.1.60 "*IDN?" #OK for my DP832.
It is interesting that for the DP832 If I send wrong scpi command I see "Wrong command" on the instrument display and I can not get any response from now on unless i reboot DP832. Is it a problem of DP832?
In general I think lxi-tools is a very good tool!
I hope soon it will grow to support more instruments.
It can be a backbone for a real lab automation.
I really hate the big NI VISA drivers and stuff ...
Thanks
Dimitar
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.
#include <config.h>
#include <ctype.h>
#include <errno.h>
#include <netinet/in.h>
#include <netinet/icmp6.h>
#include <string.h>
#include <sys/types.h>
(Warning, @Ludmar, not criticizing you although I really hope this can help instill a bit more love for portability!) ;)
By the way I would donate a good red wine for Tio!
Ha ha, well - I'm glad you like tio ;) It's just a small no-nonsense serial tty tool with a simplified interface and a few useful features. Less is more.Speaking of what I might feel inclined to send a bottle of Spanish red wine northwards ;)
Speaking of what I might feel inclined to send a bottle of Spanish red wine northwards ;)
I have tested the rigol_2000_png branch. It produce file with png extension but it is actually a bit map, same size, BMP header.
1. Can there be a option for png instead of bmp? png are smaller.
The image format depends on which formats the instrument supports. PNG is certainly the preferred format but not all instruments support it. The Rigol 2000 series supports PNG for internal storage of screenshots but it is not documented whether it is possible to retrieve PNG remotely. Please try out the '"rigol_2000_png" branch and let me know if it creates a proper PNG for you. If not I'm afraid it is not possible unless the lxi tool itself starts doing BMP->PNG conversion but I think that is a bad idea. I would rather provide the raw material straight from the instrument and then the user can do as they please.
2. The following doesn't work
dpenev@yni:~$ lxi scpi -ra 192.168.1.59 -m rigol-2000 "CHAN1 DISP?"
lxi: invalid option -- 'm'
Correct. The scpi command does not accept '-m'. Only the screenshot command requires this in order to use the corresponding screenshot plugin.
See 'lxi --help' or 'man lxi' to see which options applies to which command.dpenev@yni:~$ lxi scpi -ra 192.168.1.59 "CHAN1 DISP?"
Error: Timeout
Error: Failed to receive message
Can I send scpi commands to my DS2000
Yes, I expect so. Please try without the '-r' option. The raw option is faster but also less reliable because it uses basic RAW/TCP instead of the VXI11/TCP. Perhaps the instrument has crashed maybe due to an invalid command in which case the instrument has a hard time to recover in case of RAW/TCP (handled better by VXI11).
The Siglent SSA3000 programing manual is at http://www.siglentamerica.com/USA_website_2014/Documents/Program_Material/SSA3000X_ProgrammingGuide_PG0703X_E03D.pdf (http://www.siglentamerica.com/USA_website_2014/Documents/Program_Material/SSA3000X_ProgrammingGuide_PG0703X_E03D.pdf)3. I have Siglent SSA3021X instrument.
lxi screenshot -a 192.168.1.59 #Doesn't work for it. Is it a big deal to add support?
If the instrument is LXI compatible, that is, it supports the VXI11/TCP protocol then it should just work.
However, it is not clear to me which Siglent instruments supports VXI11. The documentation for Siglent instruments seem sparse on this topic.
It is possible this instrument does not support VXI11 in which case you might want to try the --raw option instead and maybe in combination with --raw-port if the default port differs from 5555. You might have to do some digging to figure out what port is used (if used at all).
Actually, I've been in contact with Siglent asking if they would like to support the project with some of their instruments for testing so that we can make the tools work with their instruments. Sadly, I haven't heard from them yet. Feel free to write Siglent and ask them to support this project. I think there is a Siglent support thread in this forum where they are listening ;)
4. Few other test samples
lxi screenshot -m rigol-1000 #doesn't work for DP832.
I wouldn't expect it to since the plugin is tailored for the 1000z series scopes.
I took a quick look at the DP800 programmers manual and I couldn't find any evidence that it supports remote screenshot downloads so I'm afraid it is not possible to create a working plugin for this series unless there is an undocumented screenshot feature that I'm not aware of.
lxi scpi -a 192.168.1.60 "*IDN?" #OK for my DP832.
It is interesting that for the DP832 If I send wrong scpi command I see "Wrong command" on the instrument display and I can not get any response from now on unless i reboot DP832. Is it a problem of DP832?
Please try make sure _not_ to use the raw option in this case. We know that Rigol has issues with stalling invalid commands which ends up blocking the RAW/TCP channel. With VXI11/TCP the client tells the instrument that commands are executed under a certain timeout and it handles it accordingly so you can continue to send commands. With RAW/TCP there is no such mechanism.
In general I can't recommend using the --raw option unless you really need performance gain.
I have tested the rigol_2000_png branch. It produce file with png extension but it is actually a bit map, same size, BMP header.
The Siglent SSA3000 programing manual is at http://www.siglentamerica.com/USA_website_2014/Documents/Program_Material/SSA3000X_ProgrammingGuide_PG0703X_E03D.pdf (http://www.siglentamerica.com/USA_website_2014/Documents/Program_Material/SSA3000X_ProgrammingGuide_PG0703X_E03D.pdf)
Some results below which probably answers some of the questions you have defined ?
dpenev@yni:~/lxi-tools$ lxi scpi -a 192.168.1.61 "*IDN?"
Siglent Technologies,SSA3032X,SSA3XXXXXXXXXXXXX,1.2.8.5a
dpenev@yni:~/lxi-tools$ lxi scpi -a 192.168.1.61 ":SYSTem:TIME?"
024429
dpenev@yni:~/lxi-tools$ lxi scpi -a 192.168.1.61 ":SYSTem:DATE?"
20171110
dpenev@yni:~/lxi-tools$ lxi scpi -a 192.168.1.61 "FREQuency:STAR?"
+1.2560000000E+07
dpenev@yni:~/lxi-tools$ lxi scpi -a 192.168.1.61 "FREQuency:STOP?"
+2.2560000000E+07
dpenev@yni:~/lxi-tools$ lxi scpi -a 192.168.1.61 ":MMEMory:STORe"
dpenev@yni:~/lxi-tools$ lxi screenshot -a 192.168.1.61
Error: Missing model
dpenev@yni:~/lxi-tools$ lxi screenshot -a 192.168.1.61 -m rigol-2000
Error: Failed to receive message
dpenev@yni:~/lxi-tools$ lxi screenshot -a 192.168.1.61 -m rigol-1000
Error: Failed to receive message
dpenev@yni:~/lxi-tools$
It seems ":MMEMory:STORe" can capture the screen but not sure if the data can be retreated remotely.
Indeed,
BTW did you get some useful information from silentna about screen capture from their oscilloscopes?
Thanks
Dimitar
Feature request 6.3. - make model optional, and auto identify the model using the IP and *IDN?
$ lxi screenshot --address 192.168.1.210
Loaded rigol-1000 screenshot plugin
Saved screenshot image to screenshot_192.168.1.210_2017-11-10_16:07:48.png
$ lxi screenshot --address 192.168.1.210 --plugin rigol-1000
Saved screenshot image to screenshot_192.168.1.210_2017-11-10_16:08:36.png
Feature request 6.5. - add an option for instrument ID in the filename (can be more than just 1 oscilloscope on the same network, so after a save there is no way to identify where from is the captured screen)
./ssa3000x_print print.pngI hope Siglent will implement a way to transfer a file using scpi command so this script will become unnecessary
3. I have Siglent SSA3021X instrument.
lxi screenshot -a 192.168.1.59 #Doesn't work for it. Is it a big deal to add support?
I have checked your plugin and I saw that you are not using the response from SCPI command or do I miss something?
In case this is a bug please check screenshot_siglent-sds1000x.c as well.
lxi screenshot -a 192.168.1.61 -p siglent-ssa3000x /share/scr3.png
I am sending you the file I get
at my side
lxi discover
Searching for LXI devices - please wait...
Broadcasting on interface lo
Broadcasting on interface eth0
Found "Siglent Technologies,SSA3032X,SSA3XXXXXXXXXX,1.2.8.5a" on address 192.168.1.61
Found 1 device
$ lxi discover --mdns
Hi Lundmar
With the latest liblxi and lxi-tools I get:
root@yni:/home/dpenev/lxi-tools/lxi-tools# lxi discover --mdns
lxi: unrecognized option '--mdns'
root@yni:/home/dpenev/lxi-tools/lxi-tools# lxi discover
Searching for LXI devices - please wait...
Error: Unknown discover type (532306400)
No devices found
root@yni:/home/dpenev/lxi-tools/lxi-tools#
I tried the latest version
"lxi discover" is working for my Rigol DS2000 scope and my Siglent SSA3000 amalyzer
dpenev@yni:~/lxi-tools/lxi-tools$ lxi discover --mdns
Searching for LXI devices - please wait...
No services found
Should I start something on my PC?
Screenshot for SSA3000 doesn't work at my side
lxi screenshot -a 192.168.1.61 -p siglent-ssa3000x scr10.png
I am attaching two files I get with line like the above.
lxi screenshot -a 192.168.1.61
I have added some plugins for Rigol devices, the changed files are in the tar archive.
I can't handle git yet.
Peter
pedre@debian:~/Programme/lxi/bin$ ./lxi screenshot --list
Name Description
keysight-iv2000x Keysight InfiniVision 2000X series oscilloscopes (experimental)
rigol-1000 Rigol DS/MSO 1000z series oscilloscopes
rigol-2000 Rigol DS/MSO 2000 series oscilloscopes
rigol-dg4000 Rigol DG4000 series function generator
rigol-dm3000 Rigol DM3000 series digital multimeter
rigol-dp800 Rigol DP800 series power supply
rigol-dsa800 Rigol DSA800 series spectrum analyzer
rigol-dsa700 Rigol DSA700 series spectrum analyzer
rs-hmo1000 Rohde & Schwarz HMO 1000 series oscilloscopes (experimental)
siglent-sds1000x Siglent SDS 1000X series oscilloscopes (experimental)
siglent-ssa3000x Siglent SSA 3000X series spectrum analyzers (experimental)
tektronix-2000 Tektronix DPO/MSO 2000 series oscilloscopes (experimental)
Edit: tar archiv new uploaded
The DM3068 is simulated, with my own programmed LXI server.
The DSA700 is identical to the DSA800.
The other devices have been tested.
PeterCode: [Select]pedre@debian:~/Programme/lxi/bin$ ./lxi discover[/code]
Searching for LXI devices - please wait...
Broadcasting on interface lo
Broadcasting on interface enp2s0
Found "Rigol Technologies,DG4162,DG4D135100282,00.01.12" on address 192.168.1.54
Found "RIGOL TECHNOLOGIES,DP831,DP8F174900273,00.01.14" on address 192.168.1.55
Found "RIGOL TECHNOLOGIES,MSO2302A,DS2F161650093,00.03.05.SP3" on address 192.168.1.52
Found "Rigol Technologies,DM3068,DM301513679735,01.01.00.01.07.00" on address 192.168.1.37
Found "Rigol Technologies,DSA815,DSA8A143300837,00.01.18.00.02" on address 192.168.1.51
Found "RIGOL TECHNOLOGIES,DS1104Z,DS1ZB161150038,00.04.04.SP3" on address 192.168.1.53
Found 6 devices
pedre@debian:~/Programme/lxi/bin$ ./lxi screenshot -a 192.168.1.54
Loaded rigol-dg4000 screenshot plugin
Saved screenshot image to screenshot_192.168.1.54_2017-11-23_18:53:19.bmp
pedre@debian:~/Programme/lxi/bin$ ./lxi screenshot -a 192.168.1.55
Loaded rigol-dp800 screenshot plugin
Saved screenshot image to screenshot_192.168.1.55_2017-11-23_18:52:03.bmp
pedre@debian:~/Programme/lxi/bin$ ./lxi screenshot -a 192.168.1.37
Loaded rigol-dm3000 screenshot plugin
Saved screenshot image to screenshot_192.168.1.37_2017-11-23_18:52:23.bmp
pedre@debian:~/Programme/lxi/bin$ ./lxi screenshot -a 192.168.1.51
Loaded rigol-dsa800 screenshot plugin
Saved screenshot image to screenshot_192.168.1.51_2017-11-23_18:52:50.bmp
the plugin for SSA3000x is automatically recognized, see bellow
dpenev@yni:~/lxi-tools/lxi-tools$ sudo lxi screenshot -a 192.168.1.61
Loaded siglent-ssa3000x screenshot plugin
Saved screenshot image to screenshot_192.168.1.61_2017-11-23_19:56:10.bmp
The server is programmed in Xojo for Windows and uses VXI-11.
Was only programmed for a test for my screen capture program.
http://peter.dreisiebner.at/rigol-bildschirmkopie-lan/ (http://peter.dreisiebner.at/rigol-bildschirmkopie-lan/)
I don't need to be named as an author.
The DSA700 is identical to the DSA800.
The other devices have been tested.
The DSA800 can also handle screen shots in PNG format, but takes twice as long to do so.
The Rigol devices are fastest with the BMP format.
It is better to change the format when saving.
$ lxi --help
lxi: error while loading shared libraries: liblxi.so.1: cannot open shared object file: No such file or directoryLinux LAB 4.4.0-53-generic #74-Ubuntu SMP Fri Dec 2 15:59:10 UTC 2016 x86_64 x86_64 x86_64 GNU/LinuxLinux Mint 18.1 Cinnamon 64-bit if that floats your goat.Howdy,
I keep running into issues with LXI-TOOLS...
so far support from Lundar has been great. Jet spamming GitHub with issues that might only be my system isn't too great.
I have been following install instructions on this forum jet I got stuck here:
after installing LIB, and TOOLS trying to start the program on the command line.Code: [Select]$ lxi --help
lxi: error while loading shared libraries: liblxi.so.1: cannot open shared object file: No such file or directory
i am runningCode: [Select]Linux LAB 4.4.0-53-generic #74-Ubuntu SMP Fri Dec 2 15:59:10 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
OrCode: [Select]Linux Mint 18.1 Cinnamon 64-bitif that floats your goat.
As solving this issue has many solutions hence I wanted to ask first before fumbling around.
$ LD_LIBRARY_PATH=$HOME/opt/lxi/lib ./lxi --version
v1.12
$ export LD_LIBRARY_PATH=$HOME/opt/lxi/lib
$ lxi --version
lxi v1.12
$ snap install lxi-tools
I realize that many people are not comfortable building and installing stuff from source. Unfortunately it takes quite some effort and time to find package maintainers for the various distributions and even then there is usually a large turnaround time to update packages :(The easy way around that is to pack everything (including libraries) into a distribution independant package like firefox does. A statically linked binary should work well too.
I realize that many people are not comfortable building and installing stuff from source. Unfortunately it takes quite some effort and time to find package maintainers for the various distributions and even then there is usually a large turnaround time to update packages :(The easy way around that is to pack everything (including libraries) into a distribution independant package like firefox does. A statically linked binary should work well too.
$ snap install lxi-tools --edge
snap refresh lxi-tools
snap install lxi-tools
$ snap alias lxi-tools.lxi lxi
Hi lundmar,
Just to confirm that lxi snap and aliasing seem to be working fine on my Ubuntu 14.04 box.
Oh it is not that old actually but yes I had to install snap demon and it doesn't come pre-installed out of the box
$ snap install lxi-tools --edge
$ snap refresh lxi-tools --edge
> /snap/bin/lxi --version
cannot change current working directory to the original directory: Permission denied
> sudo /snap/bin/lxi --version
cannot change current working directory to the original directory: Permission denied
> cd /tmp
> lxi --version
lxi v1.13
> lxi screenshot -p rs-hmo1000 -a scope
Saved screenshot image to screenshot_scope_2017-11-28_19:55:38.png
> file screenshot_scope_2017-11-28_19\:55\:38.png
screenshot_scope_2017-11-28_19:55:38.png: data
'G' 0D 0A 1A 0A 00 00 00 0D89 50 4E the start of the PNG magic...> file qq.png
qq.png: PNG image data, 640 x 520, 8-bit colormap, non-interlacedhmmmCode: [Select]> /snap/bin/lxi --version
cannot change current working directory to the original directory: Permission denied
> sudo /snap/bin/lxi --version
cannot change current working directory to the original directory: Permission denied
> cd /tmp
> lxi --version
lxi v1.13
oh, solved my own problem, posting here for posterity. You get the above error if you run it when your in an NFS mounted directory/path.
oh and screenshot fails on hmo-rs1000 (I have hmo1202)Code: [Select]> lxi screenshot -p rs-hmo1000 -a scope
Saved screenshot image to screenshot_scope_2017-11-28_19:55:38.png
> file screenshot_scope_2017-11-28_19\:55\:38.png
screenshot_scope_2017-11-28_19:55:38.png: data
you can see theCode: [Select]'G' 0D 0A 1A 0A 00 00 00 0D
but we are missingCode: [Select]89 50 4Ethe start of the PNG magic...
snap refresh lxi-tools --edge
$ lxi screenshot -a scope [ sgeorge @ workstation ] - [ /tmp ]
[$]> lxi screenshot -a scope
Error: Read error (timeout)
Error: Failed to receive message
Error: Unable to retrieve instrument ID
Found "Rohde&Schwarz,HMO1202,nnnnnnnnn,05.886"lxi screensscreenshot -p rs-hmo1000 -a scope
Saved screenshot image to screenshot_scope_2017-11-28_21:43:12.png/tmp/snap.1000_lxi-tools_ql0gGm/tmp/drwx------ 3 root sgeorge 4.0K Nov 28 19:50 snap.1000_lxi-tools_ql0gGmCode: [Select][ sgeorge @ workstation ] - [ /tmp ]
[$]> lxi screenshot -a scope
Error: Read error (timeout)
Error: Failed to receive message
Error: Unable to retrieve instrument ID
$ lxi scpi -a scope "*IDN?"
DoingCode: [Select]lxi screensscreenshot -p rs-hmo1000 -a scope
Saved screenshot image to screenshot_scope_2017-11-28_21:43:12.png
does not actually put "screenshot_scope_2017-11-28_21:43:12.png" on disk. not in my home directory, or anywhere...
ok. found them inCode: [Select]/tmp/snap.1000_lxi-tools_ql0gGm/tmp/
which isCode: [Select]drwx------ 3 root sgeorge 4.0K Nov 28 19:50 snap.1000_lxi-tools_ql0gGm
how very strange.
PNG do load correctly tho.
Hmm, strange. I didn't expect it to fail retrieving the ID. Can your please verify that the following command works for you?Code: [Select]$ lxi scpi -a scope "*IDN?"
lxi scpi -a scope "*IDN?"
Rohde&Schwarz,HMO1202,nnnnnnnnn,05.886
Yes, since your home directory is NFS network mounted, the lxi-tools snap can't access your home directory. And when you are in /tmp the security container redirects the files to the tmp of the snap. magic...
Code: [Select]lxi scpi -a scope "*IDN?"
Rohde&Schwarz,HMO1202,nnnnnnnnn,05.886
my home dir isnt nfs mounted. (everything off my ~ is nfs mounted, but ~/ is physical). it works in my home dir. I was actually in /tmp (which is also phsycal), but I guess snap cant run from /tmp for security.
Code: [Select]lxi scpi -a scope "*IDN?"
Rohde&Schwarz,HMO1202,nnnnnnnnn,05.886
Ok good. Then something is different when the ID is retrieved using the screenshot command. I will have to review the code to see if I can spot the bug - I'll get back to you on this tomorrow.
Ok, I've found and fixed the bug. It was a very silly and simple bug :-[
The bug basically truncated the timeout to 1 ms when using the screenshot command which made retrieval of the instrument ID fail in your case.
The fix should be available via the edge channel now. Let me know if it works for you. Thanks.
lxi screenshot -a scope -p rs-hmo1000 works.> lxi screenshot -a scope
Loaded rs-hmo1000 screenshot plugin
hangs.#0 0x00007ffff76b76f0 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:84
#1 0x00007ffff76f14e3 in readtcp (ctptr=0x60a6b0 "\004",
buf=0x60e3d0 "d, Robert Gauthier, Floyd Wilder, Mark Drissel, Kenny Lyons,\n# Paul Dunne, Tirath Pannu, Mike L", len=4000) at clnt_tcp.c:480
#2 0x00007ffff76ea946 in fill_input_buf (rstrm=0x60a770) at xdr_rec.c:567
#3 get_input_bytes (len=4, addr=0x7fffffbecbac "", rstrm=<optimized out>) at xdr_rec.c:586
#4 set_input_fragment (rstrm=<optimized out>) at xdr_rec.c:605
#5 xdrrec_getbytes (xdrs=<optimized out>, addr=addr@entry=0x7fffffbecbfc "\377\177", len=len@entry=4)
at xdr_rec.c:262
#6 0x00007ffff76eab83 in xdrrec_getlong (xdrs=<optimized out>, lp=0x7fffffbecc18) at xdr_rec.c:218
#7 0x00007ffff76f6aab in __GI_xdr_u_long (xdrs=xdrs@entry=0x60a718, ulp=ulp@entry=0x7fffffbecca0) at xdr.c:214
#8 0x00007ffff76e9791 in __GI_xdr_replymsg (xdrs=xdrs@entry=0x60a718, rmsg=rmsg@entry=0x7fffffbecca0)
at rpc_prot.c:135
#9 0x00007ffff76f12ae in clnttcp_call (h=0x60a690, proc=10, xdr_args=0x7ffff7bd07f1 <xdr_Create_LinkParms>,
args_ptr=0x7fffffbecdb0 "\220\246`", xdr_results=0x7ffff7bd0ad1 <xdr_Create_LinkResp>,
results_ptr=0x60a0e8 "\210\v\230\367\377\177", timeout=...) at clnt_tcp.c:287
#10 0x00007ffff7bd01e8 in create_link_1 () from liblxi.so.1
#11 0x00007ffff7bcedb2 in vxi11_connect () from liblxi.so.1
#12 0x00007ffff7bcea0e in lxi_connect () from liblxi.so.1
#13 0x0000000000404339 in rs_hmo1000_screenshot ()
#14 0x0000000000403525 in screenshot ()
#15 0x0000000000402384 in main ()
Code: [Select]> lxi screenshot -a scopehangs.
Loaded rs-hmo1000 screenshot plugin
lxi benchmark -a <ip>
$ lxi benchmark -a 192.168.1.210
Benchmarking by sending 100 ID requests. Please wait...
Result: 19.5 requests/second
Hello,
I got this:
dpenev@yni:~$ sudo snap refresh lxi-tools --edge
snap "lxi-tools" has no updates available
dpenev@yni:~$ lxi -v
lxi v1.13
dpenev@yni:~$ lxi screenshot -a 192.168.1.61
Loaded siglent-ssa3000x screenshot plugin
Error: Failed to receive message
dpenev@yni:~$
Hi Lundmar,
I don't find SCDP command in the SSA3000X programming manual.
I don't find SCDP command in the SSA3000X programming manual.
$ snap info lxi-tools
name: lxi-tools
summary: Open source LXI tools
publisher: lundmar
description: |
Lxi-tools is a collection of open source software tools that enables control
of LXI compatible instruments such as modern oscilloscopes, power supplies,
spectrum analyzers etc.
snap-id: yha3V4dqfwJwpjSWgMFEMViAlQ2iMdL7
commands:
- lxi-tools.lxi
tracking: edge
installed: 1.13 (110) 14MB -
refreshed: 2017-12-01 02:08:58 +0100 CET
channels:
stable: 1.12 (42) 14MB -
candidate: ?
beta: ?
edge: 1.13 (110) 14MB -
$ snap install lxi-tools
Please stop improving this thing. I'm getting tired of compiling it almost every week :-DD
I can highly recommend you install via snap instead - it updates automatically. No need to manually compile stuff anymore ;)I prefer flatpak or old school compile
I can highly recommend you install via snap instead - it updates automatically. No need to manually compile stuff anymore ;)I prefer flatpak or old school compile
hmmmCode: [Select]> /snap/bin/lxi --version
cannot change current working directory to the original directory: Permission denied
> sudo /snap/bin/lxi --version
cannot change current working directory to the original directory: Permission denied
> cd /tmp
> lxi --version
lxi v1.13
oh, solved my own problem, posting here for posterity. You get the above error if you run it when your in an NFS mounted directory/path.
snap install lxi-tools --classic
user@host: /s/l/out $ bin/lxi discover
Searching for LXI devices - please wait...
Broadcasting on interface lo
Broadcasting on interface eth0
Found "Rigol Technologies,DM3058,DM3XXXX,01.01.00.02.02.00" on address 192.168.1.144
user@host: /s/l/out $ bin/lxi screenshot -a 192.168.1.144 screenshot
Loaded rigol-dm3000 screenshot plugin
<I can hear a beep on the multimeter>
<some time after>
Error: Read error (timeout)
Error: Failed to receive message
user@host: /s/l/out $
I do have the latest version built from github.
Hi,
I have a couple of suggestions:
1. a parameter for discover - either the network adress, interface name, etc (when you have many interfaces it takes some time)
$ lxi discover --interface wlan0
For now, to speed things up a bit, you can decrease the timeout. Usually '--timeout 1' is sufficient.2. I'm not able to take a screenshot on DM3058:Code: [Select]user@host: /s/l/out $ bin/lxi discoverI do have the latest version built from github.
Searching for LXI devices - please wait...
Broadcasting on interface lo
Broadcasting on interface eth0
Found "Rigol Technologies,DM3058,DM3XXXX,01.01.00.02.02.00" on address 192.168.1.144
user@host: /s/l/out $ bin/lxi screenshot -a 192.168.1.144 screenshot
Loaded rigol-dm3000 screenshot plugin
<I can hear a beep on the multimeter>
<some time after>
Error: Read error (timeout)
Error: Failed to receive message
user@host: /s/l/out $
Hello Martin (lundmar),
just for your information.
The Rigol DM3068 only works without a waitlock flag. The flag may be set automatically when the VXI connection is established. The waitlock flag is used by many VXI functions as a parameter, e. g. device_read, see parameter Device_Flags.
The DM3058 may not work because of this. I have not received any feedback from anyone about this device and my program.
My VXI-simulator ignores this flag. The Rigol DS6000 and DG4000 with old firmware are also affected.
Peter
Edit:
What I wrote can't be the mistake. The IDN is received by the Rigol DM3058,
so the waitlock flag isn't the problem.
If helps, I updated the firmware to the latest version and same error (timeout).
On MSO1104Z-S, DG4062 and DSA815 screenshot works with no problem.
lxi screenshot -a 192.168.1.59 -m rigol-2000 #Works fine now
1. Can there be a option for png instead of bmp? png are smaller.
The image format depends on which formats the instrument supports. PNG is certainly the preferred format but not all instruments support it. The Rigol 2000 series supports PNG for internal storage of screenshots but it is not documented whether it is possible to retrieve PNG remotely. Please try out the '"rigol_2000_png" branch and let me know if it creates a proper PNG for you. If not I'm afraid it is not possible unless the lxi tool itself starts doing BMP->PNG conversion but I think that is a bad idea. I would rather provide the raw material straight from the instrument and then the user can do as they please.
$ lxi screenshot --address 10.0.0.42 - | convert - screenshot.jpg
Looks like we will have to remove the rigol-dm3000 plugin.
@PeDre , you agree?
I have received feedback from two users that the Rigol DM3068 (Firmware 01.01.00.01.08.00.01 and 01.01.00.01.09.00) with the SCPI command ":DISP:DATA?" and my program works. This applies to the LAN and USB connection.
Peter
I found Wireshark protocols in my records.
The error was the timeout when creating the connection (CREATE_LINK). The timeout could then be used for write or read commands.
Peter
@crispus, Please test latest git or snap and let us know if works or fails. Also, thank you for testing :-+If you refer to https://github.com/lxi-tools/liblxi/commit/12017460e30654e6b10ac99e982bb0d534b9df5e , I tested yesterday and it doesn't seem to work.
Man, I wish I had more instruments so I could create a small lab with various instruments for regression and feature testing.I mentioned that I have also MSO1104Z-S, DG4062 and DSA815-TG. And periodically I could run some regression tests.
@crispus, Please test latest git or snap and let us know if works or fails. Also, thank you for testing :-+If you refer to https://github.com/lxi-tools/liblxi/commit/12017460e30654e6b10ac99e982bb0d534b9df5e , I tested yesterday and it doesn't seem to work.
I will check again this evening and post the results.
Man, I wish I had more instruments so I could create a small lab with various instruments for regression and feature testing.I mentioned that I have also MSO1104Z-S, DG4062 and DSA815-TG. And periodically I could run some regression tests.
$ lxi
Usage: /snap/lxi-tools/220/bin/lxi [--version] [--help] <command> [<args>]
$ lxi screenshot -a 192.168.1.144 -
Loaded rigol-dm3000 screenshot plugin
Error: Read error (timeout)
Error: Failed to receive message
$ lxi discover --timeout 1
Searching for LXI devices - please wait...
Broadcasting on interface lo
Broadcasting on interface eth0
Found "Rigol Technologies,DG4062,DG4xxx,00.01.12" on address 192.168.1.67
Found "RIGOL TECHNOLOGIES,MSO1104Z,DS1xxxx,00.04.04.SP3" on address 192.168.1.149
Found "Rigol Technologies,DM3058,DM3xxx,01.01.00.02.02.00" on address 192.168.1.144
$ lxi screenshot -a 192.168.1.67 - | convert - fg.png
$ lxi screenshot -a 192.168.1.149 - | convert - osc.png
$ ll *.png
-rw-rw-r-- 1 user user 141799 dec 11 22:34 fg.png
-rw-rw-r-- 1 user user 20750 dec 11 22:34 osc.png
Still doesn't work (neither with snap --edge, nor from source files)
Same error (the following output is from snap):Code: [Select]$ lxi
Usage: /snap/lxi-tools/220/bin/lxi [--version] [--help] <command> [<args>]
$ lxi screenshot -a 192.168.1.144 -
Loaded rigol-dm3000 screenshot plugin
Error: Read error (timeout)
Error: Failed to receive message
$ lxi scpi --address <ip> --interactive
:disp:data?
:system:error?
Discover && screnshots works from other instruments:Code: [Select]$ lxi discover --timeout 1
Searching for LXI devices - please wait...
Broadcasting on interface lo
Broadcasting on interface eth0
Found "Rigol Technologies,DG4062,DG4xxx,00.01.12" on address 192.168.1.67
Found "RIGOL TECHNOLOGIES,MSO1104Z,DS1xxxx,00.04.04.SP3" on address 192.168.1.149
Found "Rigol Technologies,DM3058,DM3xxx,01.01.00.02.02.00" on address 192.168.1.144
$ lxi screenshot -a 192.168.1.67 - | convert - fg.png
$ lxi screenshot -a 192.168.1.149 - | convert - osc.png
$ ll *.png
-rw-rw-r-- 1 user user 141799 dec 11 22:34 fg.png
-rw-rw-r-- 1 user user 20750 dec 11 22:34 osc.png
Maybe it is useful to include in version name the git commits id (tools & lib) in order to be sure on what commit is the binary.
SCPI commands seems to work as well.
$ lxi scpi -a 192.168.1.144 --interactive
Connected to 192.168.1.144
Entering interactive mode (ctrl-d to quit)
lxi> :disp:data?
Error: Read error (timeout)
Error: Failed to receive message
lxi> :system:error?
-113,"Undefined header; keyword cannot be found"
lxi> :system:error?
0,"No error"
lxi> :disp:data?
Error: Read error (timeout)
Error: Failed to receive message
lxi> :system:error?
-113,"Undefined header; keyword cannot be found"
lxi> ^C
Yeah, you're right:Code: [Select]$ lxi scpi -a 192.168.1.144 --interactive
Connected to 192.168.1.144
Entering interactive mode (ctrl-d to quit)
lxi> :disp:data?
Error: Read error (timeout)
Error: Failed to receive message
lxi> :system:error?
-113,"Undefined header; keyword cannot be found"
lxi> :system:error?
0,"No error"
lxi> :disp:data?
Error: Read error (timeout)
Error: Failed to receive message
lxi> :system:error?
-113,"Undefined header; keyword cannot be found"
lxi> ^C
I can't see any screenshot related in the programming manual (https://www.batronix.com/pdf/Rigol/ProgrammingGuide/DM3058_ProgrammingGuide_EN.pdf) for DM3058
Btw., did you upgrade to latest firmware?Yes, it seems that already had the latest version. The tricky part though, in the release notes the version contains an additional 02: 1.01.00.02.02.00 on the multimeter versus 1.01.00.02.02.00.02 in the release notes.
Btw., did you upgrade to latest firmware?Yes, it seems that already had the latest version. The tricky part though, in the release notes the version contains an additional 02: 1.01.00.02.02.00 on the multimeter versus 1.01.00.02.02.00.02 in the release notes.
$ lxi screenshot -a 10.0.0.42 - | convert -fill white -draw "font-size 16 text 100,100 '`date`'" -scale 150% - screenshot.jpg
$ lxi screenshot -a 10.0.0.42 - | montage -geometry +0+0 -background white -label "`date`" -scale 150% - screenshot.png
Hi lundmar,
I have tested the latest lxi tool v1.15 and screenshot is working fine on my Siglent SSA3021X
A minor note which would be a bit more convenient for me is if I would able to write directly to my share
At the moment I get an error
lxi screenshot -a 192.168.1.61 /share/scr2.bmp
Loaded siglent-ssa3000x screenshot plugin
Error: Could not write screenshot file (No such file or directory)
Thank you for your work.
Dimitar
$ lxi screenshot -a 10.0.0.42 - | convert - screenshot.png
This way it is the unconfined convert tool that writes the screenshot file and so you can write anywhere you like.$ lxi screenshot -a 10.0.0.42 - > screenshot.png
Just tried to install this unsuccessfully on debian.
I first installed snap as described, and all went well. I then tried
snap install lxi-tools --edge
and got
error: cannot install "lxi-tools": Get https://search.apps.ubuntu.com/api/v1/snaps/details/core?channel=stable&fields=anon_download_url%2Carchitecture%2Cchannel%2Cdownload_sha3_384%2Csummary%2Cdescription%2Cdeltas%2Cbinary_filesize%2Cdownload_url%2Cepoch%2Cicon_url%2Clast_updated%2Cpackage_name%2Cprices%2Cpublisher%2Cratings_average%2Crevision%2Cscreenshot_urls%2Csnap_id%2Csupport_url%2Ctitle%2Ccontent%2Cversion%2Corigin%2Cdeveloper_id%2Cprivate%2Cconfinement: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
snap install lxi-tools
gives the same result.
Any idea what is up?
Thanks.
I'm using
GNU/Linux testing Stretch
and
snap 2.21-2+b1
I've realised that testing with Stretch is now a bit outdated, so have changed just to testing. Having done that, all seems OK. :-+
Oops, spoke too soon. While snap install worked OK, I now get
bash: lxi: command not found
Am I doing something silly?
snap aliases
snap alias lxi-tools.lxi lxi
Hmm
snap aliases
gives
Command Alias Notes
lxi-tools.lxi lxi -
so that does not seem to be the problem.
Neither /var nor /tmp are aliases.
snap version
now gives
snap version
snap 2.27.6-2
snapd 2.27.6-2
series 16
debian unknown
kernel 4.13.0-1-amd64
Any either ideas on how to get this to run? Even trying to run it as root gives permission errors - and it is not on my path...
$ snap refresh lxi-tools --devmode
$ snap refresh lxi-tools --classic
Both of those variants did nothing, just giving
snap "lxi-tools" has no updates available
However the deb files seem to have worked.
Thanks!
I'll try it out with some instruments in the next few days I hope.
Well, findings so far are discovery works for these devices:
Found "Rigol Technologies,DG4062,[serial#]" on address 192.168.1.207
Found "KEYSIGHT TECHNOLOGIES,MSO-X 3024T,[serial#],07.20.2017102614" on address 192.168.1.206
Tried sending *IDN? to both - worked OK.
Captured a screenshot from the Keysight, which resulted in a png file, but when I tried to view it, I got told it was not a png.
Running the file command on it just told me it was data.
The first few bytes of the file look like this:
00000000: 470d 0a1a 0a00 0000 0d49 4844 5200 0003 G........IHDR...
00000010: 2000 0002 0008 0200 0000 f5c9 9fbd 0000 ...............
00000020: 2000 4944 4154 7801 edbd 4dac 2cdb 75df .IDATx...M.,.u.
00000030: 77ce 7df7 f123 fc92 68c1 a114 0e2c 4422 w.}..#..h....,D"
00000040: a297 c086 ded3 e01a a000 3940 3290 022a ..........9@2..*
00000050: 4311 b888 151a be9c 270c e051 8078 1a22 C.......'..Q.x."
00000060: 4090 115f 9217 27b8 8092 a108 5883 0089 @.._..'.....X...
Trying to use the Keysight 2000 plugin didn't help.
Captured a screenshot from the Rigol, which resulted in a bmp file, but when I tried to view it, I got told it had a bogus header.
Running file on it told me it was a jpeg!
Changing the file extension to jpg gave me a correct picture of the screen.
Just out of curiosity, I tried building this on a Mac. Unfortunately, it didn't work as rpcgen does not have a -M argument on MacOS X.
There's definitely something wrong with the way the snap version is working. I just installed a fresh Debian stretch in a VirtualBox VM, did
apt-get install snapd
then
snap install lxi-tools
which all seemed to work OK.
But then any of the commands
lxi
lxitools
lxi-tools
just gives me "command not found".
$ lsb_release -d
Description: Debian GNU/Linux 9.3 (stretch)
$ snap --version
snap 2.29.4.2
snapd 2.29.4.2
series 16
debian 9
kernel 4.9.0-4-amd64
$ su -
$ snap install lxi-tools --edge
$ lxi --version
lxi v1.16
$ lxi-tools.lxi --version
lxi v1.16
$ snap aliases
Command Alias Notes
lxi-tools.lxi lxi -
Write once run anywhere is a noble goal - but seems rather too fragile...
There's the SCPI command:
:HCOPy:SDUMp:DATA:FORMat BMP|JPEG|PNG
:HCOPy:SDUMp:DATA:FORMat?
Well, here is my output
#lsb_release -d
Description: Debian GNU/Linux 9.3 (stretch)
#snap --version
snap 2.29.4.2
snapd 2.29.4.2
series 16
debian 9
kernel 4.9.0-4-amd64
#snap install lxi-tools --edge
lxi-tools (edge) 1.16 from 'lundmar' installed
#lxi --version
bash: lxi: command not found
#lxi-tools.lxi --version
bash: lxi-tools.lxi: command not found
#snap aliases
Command Alias Notes
lxi-tools.lxi lxi -
All looks the same - apart from the fact that lxi is not found...
I've got no idea how it can be working on your system and not on mine.
I've had exactly the same result now on both Debian testing and a fresh Debian stretch. :-//
Thanks. using
su -
instead of
sudo bash
to get a root terminal did the trick (except I still have to be root to use the lxi command).
$ lxi screenshot --address <instrument ip>
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! :)
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.
$ lxi benchmark --address 192.168.1.125
Benchmarking by sending 1000 ID requests. Please wait...
Result: 1123.5 requests/second
$ lxi benchmark --raw --address 192.168.1.125
Benchmarking by sending 1000 ID requests. Please wait...
Result: 1123.5 requests/second
$ 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
$ 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
$ 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
[ 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
just because, why not :P R&S HMO1202 (which seems surprisingly slow...)
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. 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 to know I haven't done something wrong. Will try again later, and report back. Thanks for the rapid responses! :)
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...
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)
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)
Lua support would be a great feature! :-+
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.
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.
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.
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 (https://pyvisa-py.readthedocs.io/en/latest/) 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.
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 (https://pyvisa-py.readthedocs.io/en/latest/) 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.
$ snap install lxi-tools --edge
$ lxi-tools.lxi-gui
I've added a vote in the top of this thread: "What OS platform would you like to see lxi-tools ported to next?"
Feel free to cast your vote. Thanks :-+
I would like to see that you don't divide your resources over multiple platforms. Instead, focus on Linux only.
I would like to see that you don't divide your resources over multiple platforms. Instead, focus on Linux only.
Yeap! There's a missing option that I would like to vote: NONE!!! >:D
How do you compile the lxi-gui?
That worked great. I had to change the Makefile.in for the fedora qmake-qt5. It was defaulting to qmake.
The GUI is really nice. Worked great with my Rigol scope. Testing out the graphing with my DM3068.
Lundmar
Just a quick comment - the GUI is a little inflexible for small screens. I am running all this on a MacBook Air (under VirtualBox) which gives me an effective screen height of just over 700 pixels. As a result, the bottom of the window is cut off, and there is no scroll bar etc to make it visible. Is there any simple way to make the window a bit more friendly to smaller screens?
Thanks for all the good work on this!
Ralph
I had to go back and update the benchmark performance numbers for the Siglent SDS1204X-E because it turns out my network routing tables were messed up so all tests were performed over wifi - arrghhhh! |O
Over cabled network it's not doing ~300 requests/second.... It's doing ~1100 requests/second!!!!
Bam! Thats almost as fast as a Dolorean in overdrive!
With such result there is plenty room to make a poor-mans-datalogger sampling maybe several values at e.g. 100Hz or more.
Oh, and the screenshot live view feature in lxi-gui is now even more smooth hitting about 7 frames/second.
In my case (Linux) the USB capture was the fastest (maximum capture rate is about 1/3 of a second versus about 2 seconds).
I haven't looked into this software for my oscilloscope (1054z), but I wanted to point out two things I learned when testing various software and hardware configurations in an effort to get the fastest screen capture of the 1054z to make videos/GIFs.
The first thing I learned is that, for the 1054z at least, there is a big difference in screen capture speed over ethernet versus USB; and furthermore this difference changes depending on OS. In my case (Linux) the USB capture was the fastest (maximum capture rate is about 1/3 of a second versus about 2 seconds).
So once I settled on the software and the USB screen capture method, I used the Rigol Bildschirmkopie (http://peter.dreisiebner.at/rigol-bildschirmkopie-lan/) software to capture "as fast as possible" (the next fastest option being once per second).
However while this does work, it causes many in-scope computed functions to slow down or cease computing entirely! This includes things like updating the various measurement items at the bottom of the screen; it includes the MATH functionality, and it includes the FFT. In other words, while the oscilloscope trace itself would be correct on every screen capture (every 1/3 of a second), the reported measured values would just freeze and stay the same (on both the oscilloscope and the captured screen). The FFT would freeze. And so on.
I'm aware of the notion that one of the main advantages of these new Siglent oscilloscopes is that they are faster, but I wanted to make sure you keep this in mind when doing tests and make sure to report this kind of behavior if you see it. If you do see it, it may be helpful to report the fastest synthetic test to get screen captures and also report how much slower you have to go, if any, to get all features on the screen to update.
As a corollary to this, since it seems the behavior of the Rigol is to drop updating certain on-screen functions if screenshot requests are made too fast, perhaps the Siglent behaves differently: it may slow down screenshot capture rates if there is much more computation going on. Perhaps this is worth testing too.
In any case, please capture a bunch of screenshots and use some software to string them together into a GIF so you can post it here and show off how pretty it is.
I use the free software GIMP, and the steps are pretty easy:
1. "Open as Layers" all of the captures.
2. Do Filters -> Animation -> Optimize (for GIF)
3. Export as GIF, and be sure to set: export as animation, set a reasonable delay between frames, use delay for all frames, and select combine.
I look forward to seeing some samples of what that scope can do in this regard!
In my case (Linux) the USB capture was the fastest (maximum capture rate is about 1/3 of a second versus about 2 seconds).
Put a USB webcam in front of the scope and you'll get a much higher framerate.
And it doesn't slowdown the scope...
lxi-tools is now on youtube:Already subscribed here. I hope this is the first of many others regardless of lxi-tools. :-+
Looks great, will have a play with my RTB2004 when i get time.
lxi-tools is now on youtube:Already subscribed here. I hope this is the first of many others regardless of lxi-tools. :-+
I can't wait for a Windows version.
I captured a video instead to capture the time correctly:
https://raw.githubusercontent.com/lxi-tools/misc/master/lxi-gui-benchmark-live-view-sds1204xe.webm
It demonstrates the benchmark and live screenshot feature on the SDS1204X-E. It feels quite responsive.
I captured a video instead to capture the time correctly:
https://raw.githubusercontent.com/lxi-tools/misc/master/lxi-gui-benchmark-live-view-sds1204xe.webm
It demonstrates the benchmark and live screenshot feature on the SDS1204X-E. It feels quite responsive.
Really nice, great work!
One question: does the continuous screenshotting via the live feature impact scope performance ? Did you see any slowdown in the responsiveness of the Siglent UI ?
I hooked it up to power one of my embedded Linux development boards and connected it to the network after which it was easily discovered with lxi-tools.Nice!! It has its own LAN port. I would like to setup a USB to Ethernet bridge with a raspberry pi and try to send commands to a KORAD 3005p (Serial and USB ports only) just for fun.
I hooked it up to power one of my embedded Linux development boards and connected it to the network after which it was easily discovered with lxi-tools.Nice!! It has its own LAN port. I would like to setup a USB to Ethernet bridge with a raspberry pi and try to send commands to a KORAD 3005p (Serial and USB ports only) just for fun.
lxi benchmark -a 192.168.0.47 -c 1000
Benchmarking by sending 1000 ID requests. Please wait...
Result: 74.9 requests/second
lxi benchmark -a 192.168.0.47 -c 1000 -r
Benchmarking by sending 1000 ID requests. Please wait...
Result: 140.9 requests/second
I haven't tried logging anything yet, or the GUI.I have done a quick test of the RTB2004 using the "edge" release. Screenshots seem to work well, taking ~1.2s to capture. This is fine for screenshots but way too slow for making a video, best to use the fast web livescreen/remote panel if you need that. Discovery and screenshot plugin autodetect also work.
Benchmark shows the following (2 channels, roll mode - these numbers change significantly depending on how much work the scope is doing):Code: [Select]lxi benchmark -a 192.168.0.47 -c 1000I haven't tried logging anything yet, or the GUI.
Benchmarking by sending 1000 ID requests. Please wait...
Result: 74.9 requests/second
lxi benchmark -a 192.168.0.47 -c 1000 -r
Benchmarking by sending 1000 ID requests. Please wait...
Result: 140.9 requests/second
Thanks for the work on this tool - I look forward to it's continued development!
The live view/control is VERY fast, e.g. see this video:
(skip to 50 min for a nice display of a swept function gen)
Unfortunately the UI could do with some speed improvements, especially when using lots of functions and channels simultaneously (and this is reflected in the LXI numbers as well). While it has a 1Gbit Ethernet interface, I don't think this has much effect as the bottleneck is not the connection (linked video is via WiFi access point I think). It's a shame as otherwise you could do some cool things with 1Gbit of network bandwidth (e.g. 10s of MSa/s streaming, or fast data capture/manipulation on PC). Hopefully manufacturers will start to improve in this area.
I haven't looked properly into how they're doing it, but I don't think it's a hardware encoded video - everything is FPGA based internally so there's no hard IP blocks to do something like that (and no evidence of video encoding artifacts). I've attached the web page source and the "screencam.js" client side code incase it's of interest (the other javascript used is some standard library by the looks of it). I had to add .txt extension because of forum limitation.
I tried to "refresh" the snap version to test, it reported that it was already up to date. Should I remove the snap version and clone/build the git repo?
No change in time for BMP, so the live screen view must be doing something different...
Hi Lundmar, everyone,
I'd like to make an instrument that is controlled by LXI, I'm using an Arduino Due with Ethernet-shield on the Due.
Could you give some pointers on where to begin?
By googling I found some parsers for SCPI-commands (formatted ascii-text) - but I'm not sure what goes on top of the Arduino Ethernet driver to receive LXI commands?
Previously we used Modbus/TCP on the Arduino Due (and found a ready made library for that), but I'd like to move to LXI as modbus seems quite 1980s... ^-^
thanks!
AW
A LXI compatible instrument supports one of the following protocols for communicating SCPI: RAW/TCP, VXI11/TCP, HiSlip/TCP.
You have to decide which communication protocol to go with for your server implementation and then add to that your SCPI parser.
RAW/TCP offers fast communication but is less robust. It is easy to implement as it is just a standard socket TCP server. There are countless examples available online on how to create socket TCP servers.
VXI11/TCP is robust but slow as it introduces a lot of protocol communication overhead. It is more complicated to implement as it is a protocol based on the aging RPC framework. Both VXI11 client and server stubs are defined by this file: https://github.com/lxi-tools/liblxi/blob/master/src/vxi11core.rpcl (https://github.com/lxi-tools/liblxi/blob/master/src/vxi11core.rpcl) and then generated into C code using the rpcgen tool: https://linux.die.net/man/1/rpcgen (https://linux.die.net/man/1/rpcgen) . General guides on how to implement a RPC(gen) server are available, for example: https://docs.oracle.com/cd/E19683-01/816-1435/rpcgenpguide-21470/index.html (https://docs.oracle.com/cd/E19683-01/816-1435/rpcgenpguide-21470/index.html) . However, the specific VXI11 server stub implementation is largely undocumented AFAIK which makes it harder to implement.
A LXI compatible instrument supports one of the following protocols for communicating SCPI: RAW/TCP, VXI11/TCP, HiSlip/TCP.
You have to decide which communication protocol to go with for your server implementation and then add to that your SCPI parser.
RAW/TCP offers fast communication but is less robust. It is easy to implement as it is just a standard socket TCP server. There are countless examples available online on how to create socket TCP servers.
VXI11/TCP is robust but slow as it introduces a lot of protocol communication overhead. It is more complicated to implement as it is a protocol based on the aging RPC framework. Both VXI11 client and server stubs are defined by this file: https://github.com/lxi-tools/liblxi/blob/master/src/vxi11core.rpcl (https://github.com/lxi-tools/liblxi/blob/master/src/vxi11core.rpcl) and then generated into C code using the rpcgen tool: https://linux.die.net/man/1/rpcgen (https://linux.die.net/man/1/rpcgen) . General guides on how to implement a RPC(gen) server are available, for example: https://docs.oracle.com/cd/E19683-01/816-1435/rpcgenpguide-21470/index.html (https://docs.oracle.com/cd/E19683-01/816-1435/rpcgenpguide-21470/index.html) . However, the specific VXI11 server stub implementation is largely undocumented AFAIK which makes it harder to implement.
Thanks for this explanation. I found this vxi-11 implementation on arduino due:
https://www.bankras.org/projects/electronics/instrument-of-things/ (https://www.bankras.org/projects/electronics/instrument-of-things/)
and that code is now here: https://github.com/bankrasrg/colortestkitmeter (https://github.com/bankrasrg/colortestkitmeter)
I will try to get it working and see how far I get.
If it gets too complicated I guess I will just fall back to simple http control only.
AW
Though, it's a shame it is GPLv3.
Though, it's a shame it is GPLv3.
???? :palm:
Though, it's a shame it is GPLv3.
???? :palm:
I would prefer a more permissive license. If you include GPLv3 code in your firmware you are forced to make all your firmware GPLv3.
Though, it's a shame it is GPLv3.
???? :palm:
I would prefer a more permissive license. If you include GPLv3 code in your firmware you are forced to make all your firmware GPLv3.
And what's wrong with that? You use my code, I use your code. Sounds fair to me.
You'd prefer that people can take without giving back?? Doesn't sound fair to me.
I would prefer people take my code and use it in whatever way they want - if they give back fine, if not fine too. I don't really want to put any restrictions like the GPLv3 does.
I would prefer people take my code and use it in whatever way they want - if they give back fine, if not fine too. I don't really want to put any restrictions like the GPLv3 does.
Why is it a shame if somebody wants to put restrictions on the use of his software?
According to you it's a shame if people want to sell software, either open or closed source,
either for money or for giving back your code?
I would prefer people take my code and use it in whatever way they want - if they give back fine, if not fine too. I don't really want to put any restrictions like the GPLv3 does.
Why is it a shame if somebody wants to put restrictions on the use of his software?
According to you it's a shame if people want to sell software, either open or closed source,
either for money or for giving back your code?
Thats not what I said at all.
I would prefer people take my code and use it in whatever way they want - if they give back fine, if not fine too. I don't really want to put any restrictions like the GPLv3 does.
Why is it a shame if somebody wants to put restrictions on the use of his software?
According to you it's a shame if people want to sell software, either open or closed source,
either for money or for giving back your code?
Thats not what I said at all.
You said: "it's a shame it is GPLv3"
I would prefer people take my code and use it in whatever way they want - if they give back fine, if not fine too. I don't really want to put any restrictions like the GPLv3 does.
Why is it a shame if somebody wants to put restrictions on the use of his software?
According to you it's a shame if people want to sell software, either open or closed source,
either for money or for giving back your code?
Thats not what I said at all.
You said: "it's a shame it is GPLv3"
Yes, exactly. For the reasons I stated.
Karel,
Why we should be so literal?
Lets thank lundmar for his great work
And let everyone of us has its own opinion about the open source licenses :)
I would prefer people take my code and use it in whatever way they want - if they give back fine, if not fine too. I don't really want to put any restrictions like the GPLv3 does.
Why is it a shame if somebody wants to put restrictions on the use of his software?
According to you it's a shame if people want to sell software, either open or closed source,
either for money or for giving back your code?
Thats not what I said at all.
You said: "it's a shame it is GPLv3"
Yes, exactly. For the reasons I stated.
So, you say it's a shame if somebody publishes opensource code under a license that requires you to give back your code.
But isn't it a shame if people only want to take and not to give back?
It's a shame that my baker asks money for his bread. This way I can't take his bread without giving him money. My baker is too restrictive... :palm:
To go with the above post, here is an example of the web UI of the RTB2004, which I'm guessing is the sort of thing that lundmar is getting to:
(note that the mouse was hovering over the horizontal scale knob when I captured this - see the arrows that come up)
Unfortunately implementing this isn't something I can do either (in this case due to lack of skill rather than time, though time is lacking as well!)
To be honest, I don't see the point of front panel emulators. If I want to use the instruments front panel, I dont need a computer.
What would be much more useful in my view would be some way of writing simple scripts so I can do something like this
For V = 0 to 3.3 step 0.1
Set the power supply output to V
Tell the meter to read the current I
Save V, I to file
End for
Surely such automation is the real use of LXI, not just having a remote front panel?
Just tested the HMO/RTB screenshot plugin with some other R&S/Hameg instruments.
HMC8043 power supply: works, autodetects correct plugin.
HMC8012 DMM: works, does not autodetect plugin as IDN string returned starts with "HAMEG", not "Rohde & Schwarz", even though the branding is R&S otherwise. First part of returned string is "HAMEG,HMC8012".
HMO3054: works, same issue as HMC8012: IDN string contains HAMEG, not R&S.
Yes, R&S brought Hameg - back around 2005/6 I think. Mine were bought around the time they were switching things over to R&S branding - the HMO3054 is branded as "R&S/Hameg".
The PS and and DMM were bought later and have have R&S branding, which is why it's a bit weird that the DMM id string still returns "Hameg" instead of R&S. However, I doubt any future instruments will return "Hameg" as the manufacturer.
lundmar
I've been following this for some time and I'd like to offer my sincere thanks for your efforts in supporting a wide range of Siglent products. :-+
AFAIK there'll be a couple more for you to check later on this year.
Ok.
I've updated the list of tested instruments and added you to our list of contributors as a thank you for testing.
I know some in Siglent are very aware of your great work and those I speak of are not Hamburg based which I guess is your point of contact. I think you can safely assume further support from Siglent when new products are rolled out.lundmar
I've been following this for some time and I'd like to offer my sincere thanks for your efforts in supporting a wide range of Siglent products. :-+
AFAIK there'll be a couple more for you to check later on this year.
tautech, thank you very much :)
Siglent has been very helpful making it possible for me to add full support for their LXI compatible instruments :-+
I'm very happy to see instrument manufacturers like Siglent put their support behind the open source lxi-tools project. In fact, I'm hoping more instrument manufacturers will do the same. The end goal is to make available free high quality open source instrument software tools which make it easy for users to manage their instruments remotely without having to concern themselves with costly proprietary software which may or may not bring much value.
I hope Siglent will continue to support the lxi-tools project and I'll be looking forward to add support for more of their instruments in the future.
Ok.
I've updated the list of tested instruments and added you to our list of contributors as a thank you for testing.
One note - the HMO 3054 is not discoverable via "lxi discover" and does not claim LXI support.
It also doesn't support VXI-11; it is raw sockets only, defaulting to port 5025. Commands and the screenshots work fine.
The HMC8043/HMC8012 are discoverable if the -m option is used.
Just checked - apparently it does. Using strace confirms lxi is connecting to port 1024 sucessfully. Interestingly, there is no mention of VXI-11 anywhere in the programming manual. It explicitly says to use raw sockets on port 5025. I guess the VXI-11 support is intended for VISA since the VISA address shown in the device info dialog uses ::INSTR.
Ok.
I've updated the list of tested instruments and added you to our list of contributors as a thank you for testing.
One note - the HMO 3054 is not discoverable via "lxi discover" and does not claim LXI support.
It also doesn't support VXI-11; it is raw sockets only, defaulting to port 5025. Commands and the screenshots work fine.
The HMC8043/HMC8012 are discoverable if the -m option is used.
Ok, I've removed the discover feature from the instrument list for HMO 3054.
Are you sure that VXI-11 scpi commands does not work with the HMO 3054?
If the HMO 3054 works with the screenshot plugin that implies that VXI-11 is working since all plugins use VXI-11 to retrieve screenshots at this point.
Just checked - apparently it does. Using strace confirms lxi is connecting to port 1024 sucessfully. Interestingly, there is no mention of VXI-11 anywhere in the programming manual. It explicitly says to use raw sockets on port 5025. I guess the VXI-11 support is intended for VISA since the VISA address shown in the device info dialog uses ::INSTR.
Oh well, at least it works...
To be honest, I don't see the point of front panel emulators. If I want to use the instruments front panel, I dont need a computer.
What would be much more useful in my view would be some way of writing simple scripts so I can do something like this
For V = 0 to 3.3 step 0.1
Set the power supply output to V
Tell the meter to read the current I
Save V, I to file
End for
Surely such automation is the real use of LXI, not just having a remote front panel?
$ lxi run test.luadevice = connect("192.168.0.110")
id = scpi(device, "*IDN?")
print("Instrument ID = " .. id)
disconnect(device)
Excellent - is there some documentation?
but
snap refresh lxi-tools --edge
snap "lxi-tools" has no updates available
:-//
$ lxi run myscript.lua
-- Connect to instrument ip and return device handle
device = connect(ip)
-- Send SCPI command to device and return response if ? command
response = scpi(device, command)
-- Send SCPI command to device and return raw response if ? command
response = scpi_raw(device, command)
-- Sleep ms
msleep(milliseconds)
-- Sleep seconds
sleep(seconds)
-- Disconnect device
disconnect(device)
$ snap install lxi-tools
Nice work... Using it now...
$ lxi run basic-tests.lua
$ diff -u /tmp/SBo/lxi-tools-1.19/configure.ac ./configure.ac
--- /tmp/SBo/lxi-tools-1.19/configure.ac 2018-03-10 18:54:41.000000000 -0600
+++ ./configure.ac 2018-03-18 07:21:43.825850367 -0500
@@ -14,8 +14,8 @@
AC_CHECK_LIB([readline], [readline], [], [AC_MSG_ERROR(libreadline not found)])
AC_CHECK_LIB([lxi], [lxi_connect], [], [AC_MSG_ERROR(liblxi not found)])
-# Check for Lua 5.2
-PKG_CHECK_MODULES([lua], [lua5.2])
+# Check for Lua 5.1 or newer
+PKG_CHECK_MODULES([lua], [lua >= 5.1])
# Handle bash completion
AC_ARG_WITH([bash-completion-dir],
CC libapp_a-lxilua.o
lxilua.c: In function ‘connect’:
lxilua.c:51:26: warning: passing argument 1 of ‘lxi_connect’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
device = lxi_connect(address, 0, NULL, option.timeout, VXI11);
^
In file included from lxilua.c:36:0:
/usr/include/lxi.h:63:5: note: expected ‘char *’ but argument is of type ‘const char *’
int lxi_connect(char *address, int port, char *name, int timeout, lxi_protocol_t protocol);
^
lxilua.c: In function ‘scpi’:
lxilua.c:83:31: warning: passing argument 2 of ‘lxi_send’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
length = lxi_send(device, command, strlen(command), option.timeout);
^
In file included from lxilua.c:36:0:
/usr/include/lxi.h:64:5: note: expected ‘char *’ but argument is of type ‘const char *’
int lxi_send(int device, char *message, int length, int timeout);
^
lxilua.c:92:18: warning: passing argument 1 of ‘question’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
if (question(command))
^
lxilua.c:42:12: note: expected ‘char *’ but argument is of type ‘const char *’
extern int question(char *string);
^
lxilua.c: In function ‘scpi_raw’:
lxilua.c:132:31: warning: passing argument 2 of ‘lxi_send’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
length = lxi_send(device, command, strlen(command), option.timeout);
^
In file included from lxilua.c:36:0:
/usr/include/lxi.h:64:5: note: expected ‘char *’ but argument is of type ‘const char *’
int lxi_send(int device, char *message, int length, int timeout);
^
lxilua.c:141:18: warning: passing argument 1 of ‘question’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
if (question(command))
^
lxilua.c:42:12: note: expected ‘char *’ but argument is of type ‘const char *’
extern int question(char *string);
^
Well, I did get lxt-tools to compile with Lua 5.1.5. No telling if it works or not! :-//
I had to patch configure.ac as follows:Code: [Select]$ diff -u /tmp/SBo/lxi-tools-1.19/configure.ac ./configure.ac
--- /tmp/SBo/lxi-tools-1.19/configure.ac 2018-03-10 18:54:41.000000000 -0600
+++ ./configure.ac 2018-03-18 07:21:43.825850367 -0500
@@ -14,8 +14,8 @@
AC_CHECK_LIB([readline], [readline], [], [AC_MSG_ERROR(libreadline not found)])
AC_CHECK_LIB([lxi], [lxi_connect], [], [AC_MSG_ERROR(liblxi not found)])
-# Check for Lua 5.2
-PKG_CHECK_MODULES([lua], [lua5.2])
+# Check for Lua 5.1 or newer
+PKG_CHECK_MODULES([lua], [lua >= 5.1])
# Handle bash completion
AC_ARG_WITH([bash-completion-dir],
and run autoreconf --force -v --install to rebuild configure.
It built fine but with the following warnings:Code: [Select]CC libapp_a-lxilua.o
lxilua.c: In function ‘connect’:
lxilua.c:51:26: warning: passing argument 1 of ‘lxi_connect’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
device = lxi_connect(address, 0, NULL, option.timeout, VXI11);
^
In file included from lxilua.c:36:0:
/usr/include/lxi.h:63:5: note: expected ‘char *’ but argument is of type ‘const char *’
int lxi_connect(char *address, int port, char *name, int timeout, lxi_protocol_t protocol);
^
lxilua.c: In function ‘scpi’:
lxilua.c:83:31: warning: passing argument 2 of ‘lxi_send’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
length = lxi_send(device, command, strlen(command), option.timeout);
^
In file included from lxilua.c:36:0:
/usr/include/lxi.h:64:5: note: expected ‘char *’ but argument is of type ‘const char *’
int lxi_send(int device, char *message, int length, int timeout);
^
lxilua.c:92:18: warning: passing argument 1 of ‘question’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
if (question(command))
^
lxilua.c:42:12: note: expected ‘char *’ but argument is of type ‘const char *’
extern int question(char *string);
^
lxilua.c: In function ‘scpi_raw’:
lxilua.c:132:31: warning: passing argument 2 of ‘lxi_send’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
length = lxi_send(device, command, strlen(command), option.timeout);
^
In file included from lxilua.c:36:0:
/usr/include/lxi.h:64:5: note: expected ‘char *’ but argument is of type ‘const char *’
int lxi_send(int device, char *message, int length, int timeout);
^
lxilua.c:141:18: warning: passing argument 1 of ‘question’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
if (question(command))
^
lxilua.c:42:12: note: expected ‘char *’ but argument is of type ‘const char *’
extern int question(char *string);
^
I don't know if those warnings are simply due to the older version of Lua I'm compiling against or what. As the compiler didn't error out, I'm inclined to think that Lua support will probably work.
lxi run test/basic-tests.lua
Arghh!
I'm getting tripped up by Lua in updating my SlackBuild script for lxi-tools 1.19. The configure script halts as Lua5.2 is not found and the SlackBuilds.org site has version 5.1.5 available. I presume this version is too old for various and sundry reasons?
I've never used Lua knowingly, but I found when writing a SlackBuild script for Hamlib (someone else contributed Swig Lua bindings). The impression I got is that Lua seems to be rather incompatible between minor versions. I hope I am wrong about that.
I suppose I can try installing Lua 5.1.5 and see if lxi-tools will build and run against it.
Perfectly fine patch :-+
I simply had it fixed at Lua 5.2 but I assume it will work fine with all 5.x. If you feel like it I invite you to create a github pull request to push your change upstream. Or I can apply the patch on your behalf.
and run autoreconf --force -v --install to rebuild configure.
FYI - for convenience, same as running ./autogen.sh
Those are warnings that are yet to be fixed. You can ignore them for now. To test you could start by running the basic Lua test script:Code: [Select]lxi run test/basic-tests.lua
Perfectly fine patch :-+
I simply had it fixed at Lua 5.2 but I assume it will work fine with all 5.x. If you feel like it I invite you to create a github pull request to push your change upstream. Or I can apply the patch on your behalf.
Go ahead and apply it, Martin.
I see that is in the Git repository but not in the 1.19 release tarball. It would be useful to include the test script in the 1.20 release tarball. :-+
Edit:
The basic-test.lua script ran without error using Lua 5.1.5, so it will likely work just fine.
An interesting issue I am seeing has to do with my main Slackware 14.2 desktop which is running the avahi daemon cannot discover the 'scope. However, in a Slackware 14.2 VM where I have avahi installed for building lxi-tools, but not running, I can access the 'scope just fine. :-//
I know that avahi is working as I am using it to play audio over to my MythTV box using PulseAudio. Also the avahi browser utility shows a bunch of mDNS stuff from the network.
I have to admit that I am far from knowledgeable regarding mDNS and even less so in beginning to troubleshoot it.
$ lxi discover
Searching for LXI devices - please wait...
Broadcasting on interface lo
Broadcasting on interface eth0
No devices found
$ lxi discover -m
Searching for LXI devices - please wait...
No services found
$ lxi discover
Searching for LXI devices - please wait...
Broadcasting on interface lo
Broadcasting on interface eth0
Found "Siglent Technologies,SDS1202X-E,SDS1EBBXXXXXXX,5.1.3.13" on address 192.168.X.X
Found 1 device
$ lxi discover -m
Searching for LXI devices - please wait...
Error: Failed to create client: Daemon not running
No services found
Code: [Select]$ lxi discover -m
Searching for LXI devices - please wait...
Error: Failed to create client: Daemon not running
No services found
Obviously lxi does not find the avahi daemon in the VM but raises no such complaint on the desktop.
ACCEPT net:192.168.X.0/24 $FW udp - 111
$ lxi discover
Searching for LXI devices - please wait...
Broadcasting on interface lo
Broadcasting on interface eth0
Found "Siglent Technologies,SDS1202X-E,SDS1EBBXXXXXXX,5.1.3.13" on address 192.168.X.X
Found 1 device
False alarm. It looks like a firewall rule is blocking the reply from the 'scope. :palm:
I thought I had looked in the logs a few days ago but Slackware logs a bit differently than Debian.
As I use Shorewall, I added the following rule to allow the 'scope's traffic to pass through:Code: [Select]ACCEPT net:192.168.X.0/24 $FW udp - 111
All is well now:Code: [Select]$ lxi discover
Searching for LXI devices - please wait...
Broadcasting on interface lo
Broadcasting on interface eth0
Found "Siglent Technologies,SDS1202X-E,SDS1EBBXXXXXXX,5.1.3.13" on address 192.168.X.X
Found 1 device
The key for me figuring this out was working through the liblxi source and seeing that the network braodcast address is obtained and used for the polling. The 'scope replies but since there is no tracking from a SYN packet, the response was blocked (at least that's how I understand it). I found the firewall logging is placed in /var/log/messages and then found the firewall had blocked the 'scope's address. On Slackware dmesg also includes this output.
Carry on! :-+
Take a look here, Siglent wrote a post about LXI Tools :-+Congrats! Keep up the good work :)
Take a look here, Siglent wrote a post about LXI Tools :-+Congrats! Keep up the good work :)
$ lxi discover --interface wlan0
:MEASure:ITEM OVERshoot,CHANnel2 /* Enable the overshoot measurement of CH2 */
:MEASure:ITEM? OVERshoot,CHANnel2 /* The query returns 8.888889e-03 */I was trying to measure VPP on channel 1, but all it does is to show on the scope's screen the measurement...Did anyone tried to use measure item function on a DS1000z?Code: [Select]:MEASure:ITEM OVERshoot,CHANnel2 /* Enable the overshoot measurement of CH2 */I was trying to measure VPP on channel 1, but all it does is to show on the scope's screen the measurement...
:MEASure:ITEM? OVERshoot,CHANnel2 /* The query returns 8.888889e-03 */
The query does not return anything...
$ lxi scpi --address 192.168.1.112 ":MEASure:ITEM OVERshoot,CHANnel2"
$ lxi scpi --address 192.168.1.112 ":MEASure:ITEM? OVERshoot,CHANnel2"
9.9E37
$ src/lxi --version
lxi v1.20
$ src/lxi scpi -a 192.168.1.149 -i
Connected to 192.168.1.149
Entering interactive mode (ctrl-d to quit)
lxi> *IDN?
RIGOL TECHNOLOGIES,MSO1104Z,DS1ZDxxxxxxxx,00.04.04.SP3
lxi> :MEASure:ITEM? OVERshoot,CHANnel2
lxi>
$ src/lxi scpi -a 192.168.1.149 ":MEASure:ITEM? OVERshoot,CHANnel2"
2.306453e-02
Thanks for reply.
As standalone commands it works. I was trying in interactive mode and it doesn't. (build from sources, v1.20)Code: [Select]$ src/lxi --version
lxi v1.20
$ src/lxi scpi -a 192.168.1.149 -i
Connected to 192.168.1.149
Entering interactive mode (ctrl-d to quit)
lxi> *IDN?
RIGOL TECHNOLOGIES,MSO1104Z,DS1ZDxxxxxxxx,00.04.04.SP3
lxi> :MEASure:ITEM? OVERshoot,CHANnel2
lxi>
$ src/lxi scpi -a 192.168.1.149 ":MEASure:ITEM? OVERshoot,CHANnel2"
2.306453e-02
automagicallyThis has been my preferred word for years :-DD. I see that's universal. Why everyone loves automagic solutions?
automagicallyThis has been my preferred word for years :-DD. I see that's universal. Why everyone loves automagic solutions?
./configure; make; make install But there are no configure scripts..../autogen.sh
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/bin/autoconf --force
configure.ac:22: error: possibly undefined macro: AC_ENABLE_SHARED
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:23: error: possibly undefined macro: AC_ENABLE_STATIC
autoreconf: /usr/bin/autoconf failed with exit status: 1
./autogen.sh
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/bin/autoconf --force
autoreconf: running: /usr/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:6: installing './ar-lib'
configure.ac:6: installing './compile'
configure.ac:4: installing './install-sh'
configure.ac:4: installing './missing'
src/Makefile.am:2: error: library used but 'RANLIB' is undefined
src/Makefile.am:2: The usual way to define 'RANLIB' is to add 'AC_PROG_RANLIB'
src/Makefile.am:2: to 'configure.ac' and run 'autoconf' again.
src/Makefile.am: installing './depcomp'
autoreconf: automake failed with exit status: 1
I tried to compile the tools....
First the install steps description in the readmes are not correct, they say:Code: [Select]./configure; make; make installBut there are no configure scripts...
I think i need to use the autogen.sh scripts to generate the configure scripts but they do give errors:
$ snap install lxi-tools
Thanks, i tried (first time) snap and it works.
Thanks dear lundmar!
I trying make console datalogger (https://github.com/shodanx/LXI-Instruments-DataLogger) based on your's liblxi, for my Raspberry Pi.
Low power consumption of Raspberry Pi - is very good for very long measurement's cycle. Now i can do measurement's without my PC.
Your's lib work fine via VXI-11.
I hope share first release on next week, now it testing and debugging stage.
Today I cloned the lxi-tools git repository.
I tried to compile the lxi-gui under windows with QT-Creator.
But I got an error about a missing include file "lxi.h".
It is included from main.cpp and mainwindow.cpp.
I couldn't find it in the project directory tree.
Maybe it is missing in the project?
Best regards,
Martin
Today I cloned the lxi-tools git repository.
I tried to compile the lxi-gui under windows with QT-Creator.
But I got an error about a missing include file "lxi.h".
It is included from main.cpp and mainwindow.cpp.
I couldn't find it in the project directory tree.
Maybe it is missing in the project?
Best regards,
Martin
Hi enz,
The applications in lxi-tools depend on liblxi so you need to go install liblxi first which provides lxi.h.
I hope share first release on next week, now it testing and debugging stage.
First release is published (https://github.com/shodanx/LXI-Instruments-DataLogger/releases).
I also add support of high precision TI TMP117 temperature sensor.
Now i have completed data logger solution with environment temperature measurement.
(3) While lxi-tools reads output fine with from the RSA3000, if I simply telnet to its LXI port, the output is garbled: it seems I just get the first character repeated, rather than the expected string, so for example, if I do *IDN? the output is RRRRRRRRRRRRRRRRRRRRRRRR some large number of times rather than the correct string saying Rigol... whatever. Can you enlighten me as to what the issue is here? Is there anything I can do to make simple telnet output the correct strings instead?
Hi Lundmar
three things, if you are still there and listening:
(1) Discover and SCPI commands seem to work for Rigol RSA3000 series spectrum analyzers :-+ but screen shot does not.
(2) If you have a 4K display, the GUI is too small to read comfortably - is there any chance of scaling it up for high dpi displays?
(3) While lxi-tools reads output fine with from the RSA3000, if I simply telnet to its LXI port, the output is garbled: it seems I just get the first character repeated, rather than the expected string, so for example, if I do *IDN? the output is RRRRRRRRRRRRRRRRRRRRRRRR some large number of times rather than the correct string saying Rigol... whatever. Can you enlighten me as to what the issue is here? Is there anything I can do to make simple telnet output the correct strings instead?
Thank you for the new additions, I'm eager to try them (probably next year, my desktop install just died 2 days ago).
So far the new lxi/GUI looks good by the github pics! :-+
As a feature request, will it be possible to have the LXI GUI as a native install in the repositories, too, same as the lxi-tools, please?
I mean, in the latest Ubuntu 20.04.3 LTS repositories, the lxi-tools can be installed with "sudo apt install lxi-tools", while the GUI can only be installed as a "snap" install. Some users are trying to avoid snap install for various reasons, I don't like snaps mostly because snap installed programs, when launched, are starting visible slower than a native install.
Going from Qt to GTK is definitely not a path well traveled that I've seen. Regardless, good to see you're back to coding again.
$ snap install lxi-tools --edge
$ snap connect lxi-tools:avahi-control
Well, it finds my Siglent SDS1202X-E DSO but nothing else seems to work. I tried the :VERSion? button followed by the Send button and get a "Error: Read error (timeout)" in the terminal from where I started lxi-gui (I've not restarted to allow the snap system to integrate with Gnome).
pkg install liblxi
That means you should be able to send "*IDN?" command to your instrument successfully using the SCPI interface.
Most of the SCPI 1999.0 commands must be used in some combination. Try send ":system:version?" like you see in the screenshots.
":version?" alone is not supported by the standards AFAIK.
I am not familiar at all with the SCPI commands, etc. However, there does seem to be a bit working now as shown by this screenshot:Yes I struggle with this stuff a bit too however we have someone here to thank for your SDS1202X-E definition to use with lundmar's cool program.
I was ready to kindly ask for a new feature request: Python support, only to discover today you already have this on github, wow! :-+
Thank you very much for the new python module "lxi.py": https://github.com/lxi-tools/python-liblxi
- and it's WORKING in FreeBSD :-+, tested it from Python, with "import lxi", and it could "*IDN?" my Rigol DS1054z. Python support is a great feature, thank you!
(also made a pull request to python-liblxi, my first pull-request ever, so please don't whack me if I did something stupid there ;D)
I am not familiar at all with the SCPI commands, etc. However, there does seem to be a bit working now as shown by this screenshot:
I was also able to capture this shot from the 'scope via the program:
A bit off-topic, but as I am using the Snap (only app so far) does it update automatically or is there a command I need to issue to pull an update?
$ snap refresh
$ snap info lxi-tools
$ snap install lxi-tools --edge
Looks good.
I think you're said the script language is Python, but what I see doesn't look like the Python I know. I was guessing it to be LUA which seems to be popular for embedded scripting these days.
Please correct me and explain the syntax.
Please correct me and explain the syntax.
The drawback is that everybody who posted here, won't stay updated with the new thread unless they write something there, in the new thread, a drawback of SMF Forums platform, there is no "subscribe to thread" button.
Just FYI, alternatives to making a new thread by changing the title, could be:
- any OP title can be edited by the OP, either to change it only in the OP message, or to make it change along all the existing replies, along the whole thread.
- at any reply, anybody replying can change the "Subject:" textbox during a reply, for example I've made this post to say v2.0, to bamboozle everyone.
Thank you for lxi 2.0, see you there! :-+