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 ofand
, but no
, 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.
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.
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.
True, but the non-portable code can be located in separate files to make it easier to port to different platforms.
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.
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 tioIt'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
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).
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
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