Products > Test Equipment
Open source lxi-tools v2.0 released
lundmar:
--- Quote from: PeDre on February 04, 2022, 04:32:05 pm ---I don't know if it's the bug or how the LXI tools work, but just a remark about the DM3068 and the VXI protocol.
The DM3068 can not be accessed when using device flags at e.g. 'device_write'. I had used the flag 'WaitLock' and the communication was denied. The Rigol DG4000 with old firmware also gives an error message on the screen. Without device flags everything works without problems.
--- End quote ---
Thanks, that is very useful information. I will have to investigate - right now, I don't remember exactly which flags are in use. This is the first time I ever heard of a LXI certified instrument not being discoverable via my VXI11 discovery implementation.
probe:
--- Quote --- Which discovery method are you using? Default or mDNS? See lxi-gui preferences
--- End quote ---
Default, see terminal copy/paste below:
pi@raspberrypi:~ $ lxi discover -m
Searching for LXI devices - please wait...
No services found
pi@raspberrypi:~ $ lxi discover
Searching for LXI devices - please wait...
Broadcasting on interface lo
Broadcasting on interface eth0
Found "Siglent Technologies,SDS2504X Plus,SDS2PDDxxxxxxx,5.0.1.3.9R6" on address 192.168.178.83
Found "Siglent Technologies,SVA1032X,XXXXXXXXXX,3.2.2.5.0.r8" on address 192.168.178.80
Found "Rigol Technologies,DG1062Z,DG1ZAxxxxxxxx,03.01.12 " on address 192.168.178.102
Found "RIGOL TECHNOLOGIES,DP832A,DP8Cxxxxxxxxx,01.01.16" on address 192.168.178.101
Found "RIGOL TECHNOLOGIES,DS1104Z,DS1ZAxxxxxxxxx,00.04.05.SP2" on address 192.168.178.100
Found 5 devices
pi@raspberrypi:~ $ lxi scpi -a 192.168.178.103 *IDN?
Rigol Technologies,DM3068,DM3O222400340,01.01.00.01.10.00
pi@raspberrypi:~ $
-------------------------
P.S. I can't run lxi-gui atm due to the error described above. Serials replaced by xxxx's
lundmar:
--- Quote from: probe on February 04, 2022, 05:35:03 pm ---P.S. I can't run lxi-gui atm due to the error described above. Serials replaced by xxxx's
--- End quote ---
That's fine. I assumed you were using lxi-gui but it does not matter, it's the exact same mechanism.
Give me some time, I will investigate the flag configuration that PeDre mentioned, it may be related. But first I need to fix a rather big contributed mDNS replacement feature.
JohanH:
--- Quote from: lundmar on February 02, 2022, 12:46:21 am ---Unfortunately I can't easily distribute a flatpak of lxi-tools in places like flathub.org
The reason is that they do not allow my application ID to reflect my true reverse DNS domain. It is mostly for policy reasons and not so much technical ones. It's all very silly.
--- End quote ---
What craziness is that? I thought the whole idea of borrowing the reverse DNS d-bus concept was to get unique names/addresses. Can't you just use a made up name then? Now I haven't created any flatpaks (only rpms), so I'm not that familiar with their requirements.
Many distros prefer flatpak over snap nowadays, snap has become almost a Ubuntu thing only (Canonical always try to do their own race and eventually gives up and uses what everybody else does). I certainly prefer flatpaks over snaps, any day.
lundmar:
--- Quote from: jukk on February 04, 2022, 06:14:57 pm ---
--- Quote from: lundmar on February 02, 2022, 12:46:21 am ---Unfortunately I can't easily distribute a flatpak of lxi-tools in places like flathub.org
The reason is that they do not allow my application ID to reflect my true reverse DNS domain. It is mostly for policy reasons and not so much technical ones. It's all very silly.
--- End quote ---
What craziness is that? I thought the whole idea of borrowing the reverse DNS d-bus concept was to get unique names/addresses. Can't you just use a made up name then? Now I haven't created any flatpaks (only rpms), so I'm not that familiar with their requirements.
Many distros prefer flatpak over snap nowadays, snap has become almost a Ubuntu thing only (Canonical always try to do their own race and eventually gives up and uses what everybody else does). I certainly prefer flatpaks over snaps, any day.
--- End quote ---
The issue is that I'm using an application ID true to my reverse DNS name, "io.github.lxi-tools.lxi-gui" but it is strongly recommended to not use hyphens in the app ID to avoid some exotic conflicting DBus use case. Flathub is enforcing this notation. Meaning it will have to look like this "io.github.lxi_tools.lxi-gui". I know this is a small detail but it really bugs me because it looks silly and everything works perfectly as it is. I can't believe that the DBus guys did not account for this situation considering they choose to base everything on the reverse DNS notation so why not make it ACCURATE!
Anyway, eventually I will probably change the app ID to agree with the recommendations but I'm not sure I really want to maintain a flatpak. There is a lot of controversy about flatpak vs snap and I have been leaning towards flatpak because I know the NIH history of Ubuntu. However, having now been through the experience of creating both a snap and a flatpak, I must say that snaps seem to be a much more well designed and mature platform and it is much easier to use. Also, there is the fundamental problem of flatpaks only being designed for distributing single binary GUI applications. I want to also distribute my command-line tool so I'm thinking I shouldn't bother with flatpaks. It is also an annoyance for end users when they go to their software store and both a flatpak and a snap turns up - it adds to the confusion.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version