| Products > Test Equipment |
| Rigol DS1000Z series buglist continued (latest: 00.04.04.04.03, 2019-05-30) |
| << < (44/74) > >> |
| Karel:
--- Quote from: lundmar on October 28, 2017, 10:57:45 pm ---That being said, the best way to fire SCPI commands to any LXI enabled device is to use tools that use the VXI11 protocol to communicate/handle the commands. --- End quote --- I don't agree. The fact that the TCP-socket implementation of the Rigol is buggy, doesn't make the VXI-11 protocol necessary better in general. You could only say that it's a workaround for the buggy Rigol. Unfortunately, VXI-11 creates more overhead and is slower. I quote: --- Quote ---VXI-11 or TCP sockets: Which should you use? VXI-11 is used exclusively if you are accessing GPIB instruments through a LAN-to-GPIB gateway like the Agilent E5810A or if you are using a PC as a gateway. However, many native LAN instruments support both VXI-11 and TCP socket communication. Which is the better option? Often, it is a matter of preference. However, VXI-11 is the more complex (higher-layer) protocol. Consequently, direct socket communication will provide better performance in many situations, especially if the actual measurement time is short and you conduct many individual transactions. Furthermore, as the examples in this document will show, sockets are considerably easier to use. Therefore, if they are supported by the instrument, sockets are the recommended approach for native LAN instruments. --- End quote --- literature.cdn.keysight.com/litweb/pdf/5989-6717EN.pdf |
| lundmar:
--- Quote from: Karel on October 29, 2017, 09:31:09 am --- --- Quote from: lundmar on October 28, 2017, 10:57:45 pm ---That being said, the best way to fire SCPI commands to any LXI enabled device is to use tools that use the VXI11 protocol to communicate/handle the commands. --- End quote --- I don't agree. The fact that the TCP-socket implementation of the Rigol is buggy, doesn't make the VXI-11 protocol necessary better in general. You could only say that it's a workaround for the buggy Rigol. Unfortunately, VXI-11 creates more overhead and is slower. --- End quote --- True, issuing SCPI via raw TCP-sockets is faster but you compromise as you don't get any timeout management which is key to handling troublesome SCPI commands or when doing production optimization etc. - whether you need it or not depends on your use case of course. Even then, the performance difference for doing basic stuff is negligible. However, when you start transferring large amounts of SCPI data at higher network speeds thats when you really start to suffer the overhead. This is why new LXI enabled instruments are now replacing VXI11 with HiSlip which is basically as fast as using raw TCP-sockets but it comes with the same basic protocol mechanisms for controlling e.g. command timeout - its just a more modern message protocol. I'm planning to implement this protocol for liblxi so we can have first class open source HiSlip support on Linux. Here is an interesting raw TCP vs.VXI vs. HiSlip comparison made by R&S: It is speculation of course, but I don't think it is the TCP-socket of the Rigol that is actually failing. I think it is simply the internal command error handling or interpreter for this specific command that fails and it ends up blocking the single command channel which is mapped to port 5555. Likely Rigol does not enable any timeout handling for commands coming in on this port and that is why it stays locked up when a command stalls. For the VXI channel(s) stalling commands are handled as every command call (RPC call) includes a timeout defined by the caller and it seems the Rigol complies with that part of the protocol. |
| RoGeorge:
--- Quote from: lundmar on October 29, 2017, 09:19:55 am ---If you do take lxi-tools for a test spin please install the latest versions of liblxi and lxi-tools from https://lxi.github.io --- End quote --- I just did, then sniffed the actual LAN data packets using Wireshark. First, lxi-tools is a very nice and useful tool, thank you for making it available. :-+ Second, I found it very hard to install, even if I'm familiar with Linux. By familiar I mean able to follow README instructions, and able to use the command line, but not being a Linux developer. The problem was that there were no binary, so I need to compile from sources. In the README file it says "./configure", "make", "make install", which won't work, because there is no "./configure". By looking inside various files I realized that I should generate the ./config file myself, then after a lot of googling I found out about autoreconf and so on. :horse: This is probably trivial for any Linux developer, but it was not for me. IMHO the build and installation instruction should have been something like these: --- Code: ---cd ~ mkdir lxi-tools cd lxi-tools/ git clone https://github.com/lxi/liblxi cd liblxi/ su apt-get update apt-get install automake apt-get install autogen autoconf libtool ./autogen.sh ./configure make make install cd .. git clone https://github.com/lxi/lxi-tools cd lxi-tools/ ./autogen.sh apt-get install libreadline-dev ./configure make make install export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/lib" lxi --- End code --- For my Debian 8, some of the build tools were not installed by default. Third, the lxi-tool is using a different protocol, VXI-11, and different ports. lxi-tools is not using TCP/5555, I guess that is why the hang is not reproducible when using VXI-11. TBH, the DS1000Z specifications are "Conform to LXI CORE 2011 DEVICE class instrument standards", and I couldn't find any mention in the Rigol DS1000Z manuals about using TCP and port 5555, like in a remote SCPI sent by Telnet or Netcat/TCP. Unless LXI CORE 2011 requires SCPI to work over a raw TCP socket (it might require, but at a draft look I couldn't find any required feature about plain SCPI text sent over LAN), I guess SCPI text sent over a raw TCP socket is just an undocumented feature, so even if the TCP hangs when using netcat, then we can not file a bug about it. |
| Karel:
--- Quote from: RoGeorge on October 29, 2017, 03:15:42 pm ---Unless LXI CORE 2011 requires SCPI to work over a raw TCP socket (it might require, but at a draft look I couldn't find any required feature about plain SCPI text sent over LAN), I guess SCPI text sent over a raw TCP socket is just an undocumented feature, so even if the TCP hangs when using netcat, then we can not file a bug about it. --- End quote --- Why not? For Rigol it makes no difference if some feature is documented or not. If they feel like fixing it they'll fix it. If they don't feel like fixing it, then they don't. For example, the USB max packet size is clearly documented but they don't feel like fixing the USB max packet size bug in their firmware... There are also three bugs still open for the DS6000 series which have been reported and confirmed by Rigol long time ago and they don't care... Edit: According to Keysight it is: --- Quote ---In 2000, the VXIplug&play Alliance added support for LAN-based instruments to its VISA specifications. Two popular methods of instrument control via Ethernet were adopted by VISA: VXI-113 and “direct” TCP socket communication --- End quote --- |
| lundmar:
--- Quote from: RoGeorge on October 29, 2017, 03:15:42 pm ---First, lxi-tools is a very nice and useful tool, thank you for making it available. :-+ --- End quote --- I'm glad you like it. I try hard to make it a simple to use tool and library :D I hope some people in this forum might contribute some screenshot plugins so that the lxi tool can include screenshot support for more instruments. I've made it pretty easy to write a new screenshot plugin for the lxi tool but I don't have the instruments to do it myself. For those interested in trying to add a screenshot plugin for their particular instrument they can find inspiration in the code for the Rigol 1000z screenshot plugin here: https://github.com/lxi/lxi-tools/blob/master/src/plugins/screenshot_rigol.c --- Quote from: RoGeorge on October 29, 2017, 03:15:42 pm ---Second, I found it very hard to install, even if I'm familiar with Linux. By familiar I mean able to follow README instructions, and able to use the command line, but not being a Linux developer. The problem was that there were no binary, so I need to compile from sources. In the README file it says "./configure", "make", "make install", which won't work, because there is no "./configure". By looking inside various files I realized that I should generate the ./config file myself, then after a lot of googling I found out about autoreconf and so on. :horse: --- End quote --- Sorry about that. I'm actually working on pushing lxi-tools and liblxi into the most popular GNU/Linux distributions. It is currently being packaged for Fedora/RHEL and soon I hope Debian/Ubuntu packages will be ready so that most people can avoid installing from source. I know the source install instructions are very generic but that is only because it assumes that the user knows how to deal with configure/make stuff. In your case you made the mistake of using the github repository which never includes a configure file. Only the public released tarballs include the configure script. The tarballs download links are available at https://lxi.github.io Don't worry, many still makes the mistake of using the raw git repos in which case they will need to know all the ins and outs of using autogen.sh ;) --- Quote from: RoGeorge on October 29, 2017, 03:15:42 pm ---Third, the lxi-tool is using a different protocol, VXI-11, and different ports. lxi-tools is not using TCP/5555, I guess that is why the hang is not reproducible when using VXI-11. --- End quote --- That is correct. Actually, the VXI protocol uses port 111 to initiate communications but all subsequent communication is performed using arbitrary ports. In case you use wireshark to inspect the packages I suggest you just filter by IP src and dst to see what is going on. As I mentioned earlier in this thread, all SCPI commands fired via VXI are defined by a RPC call which includes a timeout definition which is used by the receiving instrument for timeout handling. In case of using raw TCP on port 5555 you don't define any timeout per SCPI call and nor does the Rigol seem to use a default timeout via this channel, hence the stalling command ends up blocking the command channel mapped to TCP port 5555. At least that is what I speculate is happening. --- Quote ---Unless LXI CORE 2011 requires SCPI to work over a raw TCP socket (it might require, but at a draft look I couldn't find any required feature about plain SCPI text sent over LAN), I guess SCPI text sent over a raw TCP socket is just an undocumented feature, so even if the TCP hangs when using netcat, then we can not file a bug about it. --- End quote --- You can safely file a bug for that specific command sequence failing to respond. I think it is the command which is failing and not the communications channel, regardless of it being RAW/TCP or VXI/TCP. |
| Navigation |
| Message Index |
| Next page |
| Previous page |