Poll

What OS platform would you like to see lxi-tools ported to next?

Windows
macOS
Other
Don't port it - Linux is the future for all!

Author Topic: Open source lxi-tools and liblxi v1.0 released for GNU/Linux  (Read 89588 times)

0 Members and 3 Guests are viewing this topic.

Online RoGeorge

  • Super Contributor
  • ***
  • Posts: 6146
  • Country: ro
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #25 on: November 06, 2017, 06:12:14 pm »
5.
Code: [Select]
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

Online RoGeorge

  • Super Contributor
  • ***
  • Posts: 6146
  • Country: ro
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #26 on: November 06, 2017, 06:28:09 pm »
6.
Code: [Select]
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'
Passed

Feature request 6.1. - add an option to specify the filename
Feature request 6.2. - add a shorter syntax, like "scr" for "screenshot"
Feature request 6.3. - make model optional, and auto identify the model using the IP and *IDN?
Feature request 6.4. - add an option for datetime-stamp in the filename
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)
Feature request 6.5. - add an option to immediately open the captured screenshot - for making multiple screen captures (manually) until the best waveform is captured
« Last Edit: November 06, 2017, 06:44:44 pm by RoGeorge »
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #27 on: November 06, 2017, 08:22:44 pm »
Made 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.

Thanks.

Don't worry, I'm always looking for constructive feedback so we can steadily improve the tools and squash any bugs found.

Thank you for your thorough testing. Let me comment on your findings accordingly:

1. Check.

2. I believe the way the commandline is described is fairly conventional. Yes, strictly speaking <command> is optional. However, you can't really do anything without the commands. I think it will only confuse users more if we make everything optional. Popular tools like git is described in a similar way.

3. Good catch. I've pushed a commit that should fix the issue. This is exactly why I need someone with multiple instruments to test :) I only have a single LXI instrument to test with :(

4. To be fixed. Update: FIXED

5. Check.

6.1 Already implemented,   "screenshot [<options>] [<filename>]  Capture screenshot" . If no filename is provided it will autoresolve it.

6.2 Sorry no. I'm not a fan of shorthand expressions like scr. To help lazy people the tool features full bash autocompletion ;) Try e.g. 'source <prefix>/share/bash-completion/completions/lxi' to load completion
manually.

6.3 Seemingly a good idea. Assuming ID strings are consistent then it is possible. I think it should be added to the TODO list as a possible feature in the future. It is something that the screenshot plugin framework should be modified to support.

6.4 Hmm, you win. However, we don't want an option for it. I'll just add date-time by default :) Update: FIXED

6.5 Appending the ID is a bit more tricky since you don't want to include the full string in the screenshot filename. This is something that each screenshot plugin needs to handle because only it will know what to strip from the ID strings of the instruments it supports. This can work if ID strings are consistent, if not it will be troublesome. Add it to the TODO list. As an alternative and simpler solution we could append the model and IP to the filename.

6.6 A good idea but I think this feature should be reserved for a separate graphical screenshot tool to be included in lxi-tools. Something to put on the TODO list too. A simple QT or GTK application would do the job.

Btw. feel free to register a github account and submit any issues you find in the lxi-tools issue tracker: https://github.com/lxi/lxi-tools/issues . Using github issues makes it easier to track and manage issues.
« Last Edit: November 07, 2017, 01:42:07 am by lundmar »
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #28 on: November 06, 2017, 08:25:56 pm »
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.

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.
« Last Edit: November 06, 2017, 08:55:11 pm by lundmar »
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline glarsson

  • Frequent Contributor
  • **
  • Posts: 814
  • Country: se
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #29 on: November 06, 2017, 09:08:34 pm »
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.
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #30 on: November 06, 2017, 09:57:35 pm »
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.

If you want to help make lxi-tools and liblxi work on macOS I welcome it  :-+
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #31 on: November 07, 2017, 12:02:56 am »
Other than not being portable to non-Gnu/Linux systems, I don't see what this does

vxi11_discover() iterates through the broadcast addresses of all available network interface. For each iteration it calls discover_devices() using the broadcast address to find the instruments.

Using getifaddrs() etc. is technically not portable code as it is not blessed by posix, it is however available on most platforms, including Linux, macOS, *BSD, and even Solaris 11+.

If you are not satisfied I invite your to contribute a variant of vxi11_discover() that works on your platform. Making it 100% portable is likely not possible since platforms like Linux are fading away their IOCTL support for retrieving network interface information (broadcast addresses etc.) in favor of a more efficient netlink mechanism.

By the way, you are looking at some old code there. See https://github.com/lxi/liblxi for latest.
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline rhb

  • Super Contributor
  • ***
  • Posts: 3476
  • Country: us
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #32 on: November 07, 2017, 01:45:07 am »
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. It's the last Sun released version before it became So Larry's. So as a rough guess, 10 years old.  But nothing can match the Sun/Forte debugger.  Everything else is "flint knives and stone axes".  And I've used probably a dozen different *nix  debuggers.

At the moment I've got lxi_discover() commented out while I deal with other Gnuisms.   Once I've got it to run, I'll fix lxi_discover().

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!
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #33 on: November 07, 2017, 02:26:15 am »
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. 

Sounds good  :-+

Sorry, I meant old as in 5 days old ... the code your are looking at is from before I did some rearrangements to support configurable communication backends (VXI11/TCP vs. RAW/TCP).

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, however, getting interface names is not the problem. The problem is going from an interface name or index to actually retrieving the broadcast address in a portable way. I can't find any APIs for this except doing using ioctl() requests which is fine but not really well supported on recent Linux kernels anymore. From the little digging I've done this far I expect we need to do platform handling for this piece of code. I don't recall but I think this is the very reason I did what I did when I wrote this 2-3 years ago, I went with the seemingly most portable implementation.

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!

Well, I guess you earned your right to be grumpy ;)

Please bear in mind that I'm doing this open source project among quite a few other open source projects that I maintain in the little spare time I have available, so don't expect everything to be perfect. I simply don't have the time to put the same rigor in this as I do in my professional software projects. That being said, I think it is in a fair shape and with the help from your guys (contributors) I'm sure we can steadily improve it and maybe add some interesting features along the way.

Also, I think we have more views in common than you might think. For example, I share your lack of enthusiasm for perl and python. This is one of the very reasons I created lxi-tools/liblxi - I wanted a proper implementation in C for my LXI instrument control needs.
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #34 on: November 07, 2017, 06:41:29 pm »
There have been lots of changes and bug fixes recently so I'm pushing new releases which are available for download at https://lxi.github.io

For a summary of changes see:

https://github.com/lxi/lxi-tools/releases/tag/v1.6
https://github.com/lxi/liblxi/releases/tag/v1.4
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #35 on: November 08, 2017, 12:23:37 pm »
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$

Question, does the rigol screenshot plugin work with these two instruments?

Fun fact, after looking at the screenshot SCPI commands offered by various instruments I have to say that Rigol is by far the one with the most well structured / cleanest SCPI command syntax.  Instruments from the big manufacturers like Tektronix, Keysight, etc. have such cumbersome and illogically named commands. In other words, their syntax is influenced by too much legacy stuff that makes no sense in 2017. They could all do with a good cleanup.
« Last Edit: November 08, 2017, 01:28:57 pm by lundmar »
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline dpenev

  • Regular Contributor
  • *
  • Posts: 183
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #36 on: November 08, 2017, 10:08:39 pm »
Hello,

I built lxi-tools from git. I get the following error.
What can be wrong?
 
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


Thanks
Dimitar
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #37 on: November 08, 2017, 11:07:30 pm »
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

Thanks for the bug report. Apparently retrieving screenshots from the 2000 series scopes differs slightly from the 1000 series.

To solve this I've made separate plugins for each series.

Try update to the latest lxi-tools git and use the "rigol-2000" model.

Let me know if it works or fails. Thanks.
« Last Edit: November 09, 2017, 12:30:23 am by lundmar »
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline dpenev

  • Regular Contributor
  • *
  • Posts: 183
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #38 on: November 09, 2017, 08:39:41 am »
Hi Lundmar,

Thank you for the fast update

lxi screenshot -a 192.168.1.59 -m rigol-2000 #Works fine now

I have following extra questions. Not sure which are important taking the current development plan in mind

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   
« Last Edit: November 09, 2017, 08:44:13 am by dpenev »
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #39 on: November 09, 2017, 10:55:11 am »
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.

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 the performance gain.

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

Thank you. Yes, I think you can get a long way with lxi-tools for convenient commandline operations. liblxi can also be quite useful if you are in need of a simple programmers API for your LXI instrument control needs. Hopefully it can grow into something useful for people who don't like the proprietary and often inferior tools. The very reason I authored lxi-tools/liblxi is because I wanted better tools for my GNU/Linux system. Also, I agree, stuff like NI VISA drivers etc. are just too bloated for my taste and not really open source friendly. I think we can do better. After all, LXI is an open standard so why not make some proper open source tools to support it  :)
« Last Edit: November 10, 2017, 06:44:41 pm by lundmar »
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline borjam

  • Supporter
  • ****
  • Posts: 908
  • Country: es
  • EA2EKH
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #40 on: November 09, 2017, 11:12:53 am »
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.

(Warning, @Ludmar, not criticizing you although I really hope this can help instill a bit more love for portability!) ;)

I bear your pain, dude.

And some Linux militant attitude certainly doesn't help. This week I sent a pull request to the OpenVSwitch project. A really stupidest, trivialest portability issue that certainly won't make me win an ACM Turing award.

What really annoyed me was the comment by the developer who accepted the pull request: "Ugh, another place that FreeBSD makes builds gratuitously fail."

A source file included <netinet/icmp6.h>, which, as usual, needs definitions from <sys/types.h>.

The original source looked like this:

Code: [Select]
#include <config.h>
#include <ctype.h>
#include <errno.h>
#include <netinet/in.h>
#include <netinet/icmp6.h>
#include <string.h>
#include <sys/types.h>

And it barfed on FreeBSD because <sys/types.h> is not included from <netinet/icmp6.h>. On Linux it is, it seems. What I
find really curious is that useless <sys/types.h> after <string.h> given that it's been included from <netinet/icmp6.h>.
<netinet/icmp6.h> actually includes <string.h>, <sys/types.h> and so on.

The fix for FreeBSD, OS X and presumably other *BSD derived networking code (anything but Linux, despite being *BSD
derived but sometimes seemingly butchered for the sake of it) was trivial, hence my shiny ACM Turing award. Just moving the <sys/types.h> to a position before <netinet/icmp6.h>. It always makes sense to put the #include lines more or less in a generalistic
to specialized order, so I moved it after <errno.h> (should have been ctypes.h but I was in "let's make this just work" mode and
I didn't give it a second thought).

Now, in the Linux world it seems to be customary to have system include files include themselves everything they need. I know
that lots of #include lines are annoying, but even if you are careful with #ifdef barriers and such I find it much better to have the programmer add the proper includes in the right order, so that you won't find portability surprises. But the Linux folks decided to somewhat hide all this...

Anyway what I found really annoying was the "Hey, FreeBSD breaking stuff" attitude. Linux manierism zealots don't help open source software at all, which is a pity.
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #41 on: November 09, 2017, 12:14:39 pm »
(Warning, @Ludmar, not criticizing you although I really hope this can help instill a bit more love for portability!) ;)

I don't want to :horse: but let me make it clear anyway since this topic keeps popping up. I'm fully aware what it takes to make portable programs and I'm all for it. However, one has to start somewhere and in my case it means starting out making it work on the most popular platform and the one that I'm using - thats why I put the GNU/Linux stipulations on the projects. Since this is a project I'm doing in my sparse spare time I wanted to focus on features rather than portability to begin with. That being said, I welcome anyone who would like to contribute to the project by improving the code, and that includes fixing any portability issues also. I expect eventually we will remove the GNU/Linux stipulations once the portability issues have been addressed (the few that there are).

It's always easier to criticize than actually do ;)
« Last Edit: November 09, 2017, 12:23:32 pm by lundmar »
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 
The following users thanked this post: dr.diesel

Offline HoracioDos

  • Frequent Contributor
  • **
  • Posts: 344
  • Country: ar
  • Just an IT monkey with a DSO
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #42 on: November 09, 2017, 12:51:51 pm »
I think you shouldn't give away your work, code it your own way and sell it.
Microsoft, Oracle, IBM have a proven business model. (We do what we want and not what you need and we charge for it)
PD: You should include a "Call Home" feature and sell usage stats. By the way I would donate a good red wine for Tio!
« Last Edit: November 09, 2017, 01:02:25 pm by HoracioDos »
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #43 on: November 09, 2017, 01:13:49 pm »
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.
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline borjam

  • Supporter
  • ****
  • Posts: 908
  • Country: es
  • EA2EKH
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #44 on: November 09, 2017, 01:23:36 pm »
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 ;)
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #45 on: November 09, 2017, 01:32:19 pm »
Speaking of what I might feel inclined to send a bottle of Spanish red wine northwards ;)

Guys don't send me that much red wine as I'm not much of a wine drinker. However, I'll accept some of that fine Argentinian beef and Spanish chorizo ha ha :D
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline dpenev

  • Regular Contributor
  • *
  • Posts: 183
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #46 on: November 09, 2017, 07:11:58 pm »

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.
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. 

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).

Yes without -r I seems to get better results, thank you.

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 ;)
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. 

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.

I see

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 see

Thank you
Dimitar
« Last Edit: November 09, 2017, 07:25:41 pm by dpenev »
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #47 on: November 09, 2017, 07:53:05 pm »
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. 

Ok. Then it does not look like it is possible to download a PNG screenshot. BMP will have to do for the 2000 series.

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. 

I did a quick scan through the manual and it does not seem like there is any documented ways to download a screenshot. Yes, you can store screenshots in the local memory subsystem but there are no ways to download that file remotely either. It's a bit silly they don't support such useful feature. Also, the description of each SCPI command is quite lacking. So, unfortunately it seems it will not be possible to create a screenshot plugin to support this Siglent instrument. I guess the only positive thing here is that sending scpi commands to the instrument works fine.
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline dpenev

  • Regular Contributor
  • *
  • Posts: 183
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #48 on: November 09, 2017, 08:14:14 pm »
Indeed,

BTW did you get some useful information from silentna about screen capture from their oscilloscopes?

Thanks
Dimitar
 

Offline lundmarTopic starter

  • Frequent Contributor
  • **
  • Posts: 436
  • Country: dk
Re: Open source lxi-tools and liblxi v1.0 released for GNU/Linux
« Reply #49 on: November 09, 2017, 08:19:44 pm »
Indeed,

BTW did you get some useful information from silentna about screen capture from their oscilloscopes?

Thanks
Dimitar

No useful details. SDS1000X/SDS2000X are claimed to support screenshots but without instruments to test on I'm going to focus on other features and instruments.
« Last Edit: November 10, 2017, 01:29:52 pm by lundmar »
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf