Products > Test Equipment

Open source lxi-tools and liblxi v1.0 released for GNU/Linux

<< < (19/67) > >>

lundmar:

--- Quote from: BloodyCactus on November 29, 2017, 03:55:26 am ---
--- Code: ---lxi scpi -a scope "*IDN?"
Rohde&Schwarz,HMO1202,nnnnnnnnn,05.886

--- End code ---

--- End quote ---

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.


--- Quote from: BloodyCactus on November 29, 2017, 03:55:26 am ---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.

--- End quote ---

Ok, got it. Then the problem is not too bad then, except it is of course annoying for your use case that you can't have it write directly to your NFS share. Some say that it is possible for a snap to write to an NFS share if you use the 'mount --bind <location of nfs> <some mount dir in your home>' command to basically map/mount your NFS share into your home and this way the snap will see it as a normal dir.

lundmar:

--- Quote from: lundmar on November 29, 2017, 04:19:40 am ---
--- Quote from: BloodyCactus on November 29, 2017, 03:55:26 am ---
--- Code: ---lxi scpi -a scope "*IDN?"
Rohde&Schwarz,HMO1202,nnnnnnnnn,05.886

--- End code ---

--- End quote ---

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.

--- End quote ---

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.

BloodyCactus:

--- Quote from: lundmar on November 29, 2017, 02:16:38 pm ---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.

--- End quote ---


--- Code: ---lxi screenshot -a scope -p rs-hmo1000
--- End code ---
works.


--- Code: ---> lxi screenshot -a scope
Loaded rs-hmo1000 screenshot plugin

--- End code ---
hangs.

no change when using IP. still hangs.

with gdb, I get (but probably not much good to you).


--- Code: ---#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 ()

--- End code ---

lundmar:

--- Quote from: BloodyCactus on November 29, 2017, 10:37:42 pm ---
--- Code: ---> lxi screenshot -a scope
Loaded rs-hmo1000 screenshot plugin

--- End code ---
hangs.

--- End quote ---

Fixed!

New snap available.

What happened is that the automatic screenshot plugin detection first connects to the device to obtain the device ID which is used to automatically match which plugin to load and then it disconnects before it connects again later to retrieve the screenshot but someone forgot to disconnect |O and that obviously causes a hang for instruments that only support 1 active connection.

Thanks for the testing/debug :-+

This is exactly the type of testing I'm looking for - the more instruments tested the better so we can catch and eliminate bugs like this.

Btw. I've added a new benchmark command which can be useful for comparing the VXI-11 request/response performance of instruments:


--- Code: ---lxi benchmark -a <ip>

--- End code ---

Example:

--- Code: ---$ lxi benchmark -a 192.168.1.210
Benchmarking by sending 100 ID requests. Please wait...
Result: 19.5 requests/second

--- End code ---

dpenev:
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:~$

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod