Open source lxi-tools v2.7 released

[WaveyDipole]

Yes, it seems you are correct, although that does not surprise me:

Code: [Select]

$ cat /etc/os-release
NAME="Linux Mint"
VERSION="20.3 (Una)"
ID=linuxmint
ID_LIKE=ubuntu
PRETTY_NAME="Linux Mint 20.3"
VERSION_ID="20.3"
HOME_URL="https://www.linuxmint.com/"
SUPPORT_URL="https://forums.linuxmint.com/"
BUG_REPORT_URL="http://linuxmint-troubleshooting-guide.readthedocs.io/en/latest/"
PRIVACY_POLICY_URL="https://www.linuxmint.com/"
VERSION_CODENAME=una
UBUNTU_CODENAME=focal

Code: [Select]

$ cat /etc/upstream-release/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu Focal Fossa"
So yes, it is using an older repo which perhaps explains why so many packages are so far out of date...

[WaveyDipole]

Looks like it needed both:

Code: [Select]

flatpak install org.gnome.Sdk
flatpak install org.gnome.Platform

and selecting version 43 for each.

After running both installs, the build command finally worked. A bit of searching in the flatpak docsindicated that I could do:

Code: [Select]

flatpak run io.github.lxi-tools
and indeed, the GUI runs. I will test the the oscilloscope with it later.

[JohanH]

Code: [Select]

flatpak run io.github.lxi-tools
and indeed, the GUI runs. I will test the the oscilloscope with it later.

On my system (Gnome/Fedora) I can also press the Win key, type "lxi" (and it will find the app from the installed applications and show the icon), press Enter and it runs.

[JohanH]

Looks like it needed both:

Code: [Select]

flatpak install org.gnome.Sdk
flatpak install org.gnome.Platform

and selecting version 43 for each.

I forgot that I had installed these in the past (the platform certainly for some other application). I will update my previous post to include this if someone else finds the post.

[WaveyDipole]

Thanks for taking the trouble to update your post.

Unfortunately, having got this far, it seems that lxi-gui won't grab a screenshot from the MSO5074. The oscilloscope is correctly detected by the Search feature. However clicking Grab Screenshot returns Failure handling image format. The oscilloscope responds just fine to SCPI commands such as *IDN? and :SYSTem:VERSion? which shows there is communication over TCP/IP. Curiously, grabbing screenshots works fine when using the older 1.21 version of the command line tool so it seems a bit odd that the later version appears to  have problem with the image format. On the other hand its no listed as a supported device on the Github so please let me know if there are any diagnostics I can do. I would be happy to provide any data you require to help get this scope added to the list of supported devices.

I also tested the DS1054Z with version 2.4. This both responded to SCPI commands as well as requests top grab a screenshot and returned images. Version 2.4 seems to work OK with the DS1054Z.

Is it possible to run the lxi CLI tool from within the flatpak? I was thinking to check whether it is possible to grab a screenshot with this newer version via the command line.

[RoGeorge]

A very first test I would try would be to change the format of the screenshot, from the oscilloscope settings (if MSO5000 has such option, try BMP, PNG whatever MSO5000 has).

If you want to properly debug, install Wireshark and look at the LAN data packets sent by the v1.21, then compare that with what SCPI commands the GUI version sends (and the answer from the oscilloscope) while trying to get a screenshot.

[WaveyDipole]

RoGeorge, checking the display format was my first idea but I can find no option to change that on the scope. The only display setting there seems to be is to turn the HDMI display on and off and to set its resolution. I don't see any settings to change the format of the image data sent via SCPI. Of course, this may be possible even if via SCPI comands so I will check the manual.

The Wireshark capture was a good idea and I have done a capture of network traffic during a screen grab for each of the two versions. A cursory glance shows that both versions:

send - *IDN?
receive - RIGOL TECHNOLOGIES 5074,serial number,00.01.03.00.03
send - display:data? on,0,png

after which comes the image data.

[RoGeorge]

Not over SCPI, IIRC the setting is the one for when saving it on a USB drive.  Probably at page 349 of 372 (I've searched for 'jpg' inside the pdf, I didn't read properly so please double check, I don't have a MSO5000):
https://www.rigol-uk.co.uk/pdf/Rigol-MSO5000-User-Guide.pdf


So both the GUI and the command line are using the same SCPI?

Code: [Select]

:display:data? on,0,png
If yes, then it should work.  Try setting the image format to PNG in oscilloscope.  I don't know what to advice more without digging in the sources, sorry.

If you think you found a bug, please post it on github, so the devs will try to fix it.


LATER EDIT:
------------------
By looking at the programming guide for MSO5000, it says the returned format for the SCPI command ':display:data?' is BMP, and doesn't show the additional parameters 'on, 0, png', see page 88 of 282 in https://int.rigol.com/Images/MSO5000ProgrammingGuideEN_tcm7-4051.pdf

Yet you say the download screen works from the old command line 'lxi' but not from GUI, though both GUI and the command line are sending the same SCPI command.  That's contradictory, maybe you hit a bug, don't know what to advice further. 

Ask lundmar here, or open a bug on github https://github.com/lxi-tools/lxi-tools

[WaveyDipole]

Thanks. I also had a poke around in the programming manuals for both the DS1054Z and the MSO5000. The DS1054Z manual contains a little more detail and shows the format of the image header. Both oscilloscopes are returning similar bitmap (BMP) headers, the only difference being is that the data length on the MSO5000 is larger since its screen has a higher resolution. I suspect that the 'on,0,png' parameter is just ignored by the scope.

The MSO5000 has several format options for saving data to USB including *.png, *.bmp, *.jpg and *.tif. By default, *.png is selected.

To confirm, yes, the download screen works from the old CLI command 'lxi' but not from the new version 2.4 GUI, though both GUI and the command line are sending the same SCPI command. I agree this sounds contradictory so I have now logged an issue for this at lundmar's GitHub repository as suggested.

[RoGeorge]

Yes, the TMC format is standard to exchange binary with SCPI (which otherwise are plain text messages).  TMC header stays the same even between different brands.

I doubt an incorrect SCPI will be ignored, but it could be an undocumented format of the command, or an incomplete programming guide (it happened before with my DS1054Z).

So, have you tested with each image format (by changing the image format in the oscilloscope), and none of the bmp/png/jpg/whatever format is understood by the GUI screen capture?

[WaveyDipole]

Sorry, yes, I tested selecting each image format in Save Image->Format:. The result was always the same: Failure handling image format.
I also sent the command manually and it always returned the same header (#9001843254BM6....) regardless of image format selected, in other words, the image size always remained the same at 1,843,254 bytes. I agree, the part specified after the '?' might be an undocumented feature of the command. I hadn't considered that. The MSO5000 programming manual has very little to say on the subject of the DISPLAY:DATA? command and the DS1054Z manual diuscusses the command in more detail but does not mention any parameters.

[RoGeorge]

#9001843254BM6....

The #9 means the next 9 characters (001843254) will tell the length of the following binary data block.  BM6 are the first bytes from the screenshot (in text representation), BM6 means the picture format is .bmp, which is an uncompressed image format, so it will always have the same length for a given picture size.

If that always stays BM6 no matter the oscilloscope format settings, it means it always sends a .bmp, while the application expects a .png (judging by the SCPI command containing a png request).  Sounds like a bug.

The receiver GUI would be able to detect the encoding by looking at the first data bytes, though I don't know if format detection is the pillow lib's job (or whatever other library the GUI may use), or if the format detection must be dealt with in the GUI code before converting it with a lib.  Maybe the SCPI command for MSO5000 must be changed, too, so the GUI will not assume a PNG, and look at the first bytes of the data to properly identify the format.

Seems clear what is happening, but I'm not familiar with that part of the code so I can not tell the proper fix. 

[WaveyDipole]

You appear to be on the right track though. I captured a Wireshark dump of the same command being run on the DS1054Z to determine what actually IS being returned from this scope, as opposed to what the manual says. This is what appears in the output (partial packet contents extracted as printable text):

Code: [Select]

#9000031650PNG

IHDR àÒe¢tEXtAuthorRIGOLÒe¢tEXtSourceDSZ seriesÒe¢)tEXtDescriptionDSZ_Printing equipment outputÒe¢tEXtCopyrightRIGOL TECHNOLOGIESÒe¢z×IDATxí½/¼#W+P A
So it seems that on the DS1054Z, the 'n,0,png' is valid (as well as apparently undocumented) and does cause the image data to be returned in PNG format. The MSO5000 does not respond to those parameters and is sending the data in BMP format. It would seem that those parameters are either not implemented on the MSO5000 or perhaps take a different form. However, this still does not explain why lxi version 1.21 works...

I have updated the issue that I logged earlier with this additional information. I will also look into whether the format of the data being sent via SCPI can be changed on the MSO5000.

[RoGeorge]

My guess is lxi v1.21 properly looks at the answer and detect the format, while the newer ones wrongly assume the returned image is what was requested by the SCPI command, a PNG.  Or maybe the v1.21 is using some older libs format image manipulation, and those older libs were properly detecting the format by looking at the first data bytes, while the newer libs do not autodetect the format.

These are just guesses, only the devs can tell for sure, or yourself if you look at the github sources and compare the two versions.

[WaveyDipole]

With the kind support of the lxi-tools developer, this now appears to be fixed and lxi-gui can now grab screenshots from my MSO5074.

https://github.com/lxi-tools/lxi-tools/issues/63

The problem seems to have affected only the flatpak build.

[RoGeorge]

Good to hear it's now fixed, well done for reporting the bug, and thank you devs for the fix! 

[lundmar]

Good to hear it's now fixed, well done for reporting the bug, and thank you devs for the fix! 

No worries. Happy holidays everyone!

[lundmar]

lxi-tools v2.5 has been released:

https://github.com/lxi-tools/lxi-tools/releases/tag/v2.5

Changes since lxi-tools v2.4:

 * Add new screenshot plugins

   Add screenshot plugins to support:

    * Tektronix MSO 5 series
    * Rohde & Schwarz RTH series (hand help oscillopes)

 * Add code for backwards compatibility with lua 5.0/5.1

Twilight-Logic:

 * Updated rigol-2000 plugin to allow screenshot capture on MSO5000

[Neuromodulator]

Can the liblxi be used to develop LXI devices?

I know, that lxi tools was developed as a LXI host, to connect with LXI devices. But I thought, that liblxi contains all the functionality to support both the host side as well as the device side. So, would it be possible to expose ADCs/DACs on a Raspberry Pi (maybe from a HAT) as an LXI instrument, with the liblxi?

That would be very good, to one central LXI host and device code base.

I'm on the same boat, I want to add VXI-11 connectivity to a device that I'm developing. What libraries did you end up using?

[lundmar]

FYI - lxi-tools v2.6 is available and it now supports macOS via Homebrew:

Code: [Select]

brew install lxi-tools


Changes since lxi-tools v2.5:

    Update postinstall.py to use gtk4-update-icon-cache

    Use gtk4-update-icon-cache instead of gtk-update-icon-cache which is
    only for gtk3.

    Add Rigol MSO4024/4054 to list of supported instruments

    Add screenshot support for Rigol DS4000 series

    Add screenshot plugin support for Rigol MSO5000 series

[lambcutlet]

Hi Lundmar,

Could you help with some lxi-tools script syntax?
I don't want to double post so here's a link, thanks
https://www.eevblog.com/forum/testgear/lxi-tools-tti-pl303qmd-p-connection-help-required/

[lundmar]

Hi Lundmar,

Could you help with some lxi-tools script syntax?
I don't want to double post so here's a link, thanks
https://www.eevblog.com/forum/testgear/lxi-tools-tti-pl303qmd-p-connection-help-required/

Sure - I'll take a look.

[lundmar]

FYI - lxi-tools v2.7 is released.

See https://github.com/lxi-tools/lxi-tools/releases/tag/v2.7

[lundmar]

FYI - we are aware there are some issues with the Homebrew package if you are trying to run lxi-gui on MacOS.

An updated Homebrew package which fixes any issues should soon be available.

[lundmar]

FYI - lxi-tools v2.7 is now available for MacOS too:

https://formulae.brew.sh/formula/lxi-tools

This new Homebrew formula should install fine without any workarounds.