Rigol DS1000Z series buglist continued (latest: 00.04.04.04.03, 2019-05-30)

[metrologist]

I'm not sure what to make of it. The example has a 20Vp-p signal with the graticule set to show 16V, 2V/div, but DSRemote has the graticule set to show 20Vp-p. Perhaps the bug is DSRemote not using the same display range as the scope? Of course, then you could argue that it would be using 1.6V/div, which also does not match the scope.

What would DSRemote display with the 4000 series? What happens at the 16V graticule line? Does it clip there as it would on the scope display?

I guess since the data is there and can be moved into view, that is considered display data and is used for the measurements, and is therefore still 8 bits. You just don't get to see them all at once. That introduces some uncertainty since I generally try to maximize my signal for best accuracy, so do I now need to maximize it beyond the display region go get the highest accuracy?

[Karel]

Perhaps the bug is DSRemote not using the same display range as the scope?

There's a setting in DSRemote where you can change this behaviour. You can select to let DSRemote show exactly the same
as the scopes display with the same number of vertical divisions.
With DSRemote you simply have the option to show more divisions and the complete waveform.

What would DSRemote display with the 4000 series? What happens at the 16V graticule line? Does it clip there as it would on the scope display?

The 4000 and 6000 series show the complete waveform. At least they specify 32 steps per vertical division.
So, with eight vertical divisions, there are 256 steps on the scopes display. Exactly what fits in one byte and what should come out of the adc.
For obvious reasons, DSRemote shows exactly the same with the 4000 and 6000 series. There's no option to extend the vertical range.

[metrologist]

So DSRemote only shows 8 divisions with the 4/6000 series? The complete waveform would be clipped on the display, if you set it the same way as the 1054.

[bitseeker]

Correct. The 4000/6000 series scale the 256 values to fit into 8 divisions. The 1054Z, on the other hand, clips values above and below the 200 that will appear on the screen. In other words, it's as if the screen had 10 vertical divisions, but the top and bottom division are simply not visible on the device.

As Fungus said, it's as if the 1054Z was permanently zoomed in. So, you can pan the view port up and down by one division to see the data that is out of view.

[Karel]

Correct. The 4000/6000 series scale the 256 values to fit into 8 divisions. The 1054Z, on the other hand, clips values above and below the 200 that will appear on the screen. In other words, it's as if the screen had 10 vertical divisions, but the top and bottom division are simply not visible on the device.

As Fungus said, it's as if the 1054Z was permanently zoomed in. So, you can pan the view port up and down by one division to see the data that is out of view.

Correct. Ofcourse there can be debate whether or not this is a bug. It could be very well that, like Fungus wrote before, it's a hardware limitation i.e Rigol cut some corners to keep the price acceptable and this is all done by purpose.

I just wanted to bring it up here and will let it up to others if it should be added to the buglist or not.

[TD-Linux]

I wouldn't think it's to avoid quantization error from fitting 256 values across 400 pixels. Scopes aren't so accurate for that to matter so much anyway.

Yeah, normally this would be nonissue - you increase precision when downsampling memory for display, or averaging for persistence, and can utilize it when drawing lines on the display and often you have at least 1 lsb of noise anyway. One possible reason is that they may be really trying to cheap out on the math - nearest downsampling, or quantizing the output of their filters back to 8 bits before processing for display. You'd think in this day and age that sparing a few extra bits in your adders and multipliers would be cheaper than throwing away 10% of your expensive ADC's dynamic range... alas, after seeing that pitiful FFT, maybe there's a stock shortage of multipliers at Rigol.

[bitseeker]

My vote is that it's simply a consequence of minimizing cost (i.e., by design).

I'm just glad to know that there's more data above and below the display that I can access. Thanks for the revelation, Karel.

[frozenfrogz]

I am going to keep it in the bug list and sort the issues later. I think it belongs into the "oddities" category, meaning »things you need to know about your scope« such as that the math / decode / ... functions use the screen data instead of the recorded memory.

[bd139]

I think that’s my biggest annoyance. In the math functions it defaults to using the display as a source. So if I want any resolution in the math functions, I have to change the memory depth and frig the math source every bloody time and then set it back to auto when I’m done.

[RoGeorge]

I am going to keep it in the bug list and sort the issues later.

I wouldn't mix the 'bugs list' with the 'wish list', because this will make the rest of the real bugs to look less credible. 8 divisions on the vertical screen is not a bug.

Even more, do I want a grid of rectangles instead of squares, or fuzzy reticles, or a slower display because of the required interpolation? Probably not.

[frozenfrogz]

I wouldn't mix the 'bugs list' with the 'wish list'

That is what I meant with the OP needing some sorting out and reformatting.

The bug list will be reorganized by severity / urgency and quirky feature issues that are not real bugs have to be moved into a separate list - maybe as wish list items (that I had not touched yet )

[Karel]

8 divisions on the vertical screen is not a bug.

That was not the issue. Nobody here, including me, cares about the number of vertical divisions.
The issue is/was that the scopes display isn't showing the complete waveform as captured by the adc,
i.e. the dynamic range is (unnecessary) limited.

[lundmar]

Now, try this:

Code: [Select]

:WAV:STAR 1201
:WAV:STAR 120
:syst:err?
That's it, after the last ':SYST:ERR?' SCPI hangs, and no other SCPI commands will work until the next power on.

Later edit:
It would be useful if anybody else can reproduce this, please. Does your DS1000Z hangs, too?

I can confirm that this sequence of SCPI commands results in the ":syst:err?" command hanging. I can also confirm that the hanging command ends up blocking the telnet/nc connection on port 5555.

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. In case of the hanging command, using the VXI11 protocol simply results in the command timing out and then you can continue sending commands - no need to restart the instrument. As demonstrated here using the wonderful/fantastic/amazing lxi-tools:

Code: [Select]

$ lxi scpi --address 192.168.1.210 --timeout 5 --script crash-test.scpi
Connected to 192.168.1.210
Running script crash-test.scpi

:WAV:MODE:NORM
:syst:err?
-113,"Undefined header; keyword cannot be found"

:WAV:STAR 1201
:WAV:STAR 120
:syst:err?
Error: Read error (timeout)
Error: Failed to receive message

*IDN?
RIGOL TECHNOLOGIES,DS1104Z,DS1ZA171206207,00.04.04.SP3

With nc/telnet you don't get any timeout management etc. - it is less robust and it results in locking up your instrument when you hit buggy commands.

[RoGeorge]

8 divisions on the vertical screen is not a bug.

The issue is/was that the scopes display isn't showing the complete waveform as captured by the adc,
i.e. the dynamic range is (unnecessary) limited.

"8 divisions" is just a bad name I choose in order to refer to your findings, I understand the complain is about why keeping some margins outside the viewing area. Sorry about the bad name I used. What I am trying to say is that it's not a bug.

A bug is something unintended, a side effect that the designer didn't planed for. Your findings is not something unintended by design. It was intentionally designed and implemented to be exactly how it is now, so not a bug.

...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. In case of the hanging command, using the VXI11 protocol simply results in the command timing out and then you can continue sending commands - no need to restart the instrument.
...
With nc/telnet you don't get any timeout management etc. - it is less robust and it results in locking up your instrument when you hit buggy commands.

That's a very interesting finding, thank you for testing the hang!

AFAIK it should work without VXI, so I will try your code in order to see what are the main differences introduced by using VXI11.

[lundmar]

That's a very interesting finding, thank you for testing the hang!

AFAIK it should work without VXI, so I will try your code in order to see what are the main differences introduced by using VXI11.

No problem. I just upgraded to the latest 1000z firmware and I wanted to test the updated LXI module to make sure it is ok. Luckily nothing is really broken. It's just missing error handling that makes some specific commands hang - still something for Rigol to fix though.

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 - the latest versions contains new features and many bug fixes but it is now in a pretty good state. I'm quite happy with how it works. Finally we have a solid commandline tool for Linux to talk to our various instruments.

[Karel]

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.

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:

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.

literature.cdn.keysight.com/litweb/pdf/5989-6717EN.pdf

[lundmar]

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.

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.

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]

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

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.
 
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: [Select]

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

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.

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:

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

[lundmar]

First, lxi-tools is a very nice and useful tool, thank you for making it available. 

I'm glad you like it. I try hard to make it a simple to use tool and library 

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

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.
 

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

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.

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.

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.

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.

[RoGeorge]

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

Thank you for pointing to that, I'll further look into it.
TBH, I'm still confused about the precise requirements and the relationship between different specification protocols like LXI, VXI, VISA, SCPI and so on.

I hope some people in this forum might contribute...
...
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

Yep, I would like to contribute, but most of all I would like to see a generic implementation that does not require to install a few GB of closed source drivers, like e.g. NI-VISA for Windows does now. All the best wishes with that. It's pretty lame that a lot of people are wasting their time to implement their own software for sending SCPI commands (including myself, which I'm not a programmer), instead of just using some open source established library.

Regarding my personal hassle with the installation, I'm glad that I made the mistake of starting from the github repo, because that led me to new insights about building from sources. 

Thank you for all the other clarifications as well, it all makes more sense now.

I noticed that you opened a topic about lxi-tools and liblxi: https://www.eevblog.com/forum/testgear/open-source-lxi-tools-and-liblxi-v1-0-released-for-gnulinux/
Since other questions related to lxi-tools might become offtopic here, would the above link be the right place for further eevblog talks about lxi-tools and liblxi?

[lundmar]

Yep, I would like to contribute, but most of all I would like to see a generic implementation that does not require to install a few GB of closed source drivers, like e.g. NI-VISA for Windows does now. All the best wishes with that. It's pretty lame that a lot of people are wasting their time to implement their own software for sending SCPI commands (including myself, which I'm not a programmer), instead of just using some open source established library.

Yes, and installing GBs of data just to communicate with your instruments seems even more ridiculous as the lxi-tool and liblxi is only about 30k in total

I also find it silly that standardizing organizations like the LXI consortium do not provide open source tools that implements their open standards. I guess it takes developers like me to step up and do the work if we want better tools. sigh.

By the way, there are various ways to contribute to a open source project like lxi-tools. I'll be happy to write the screenshot plugin for any instrument people might have but I need their help to test it.

Regarding my personal hassle with the installation, I'm glad that I made the mistake of starting from the github repo, because that led me to new insights about building from sources. 

Thank you for all the other clarifications as well, it all makes more sense now.

No problem. Learning new stuff is often fun.

I noticed that you opened a topic about lxi-tools and liblxi: https://www.eevblog.com/forum/testgear/open-source-lxi-tools-and-liblxi-v1-0-released-for-gnulinux/
Since other questions related to lxi-tools might become offtopic here, would the above link be the right place for further eevblog talks about lxi-tools and liblxi?

Yes, besides the github issue tracker, https://www.eevblog.com/forum/testgear/open-source-lxi-tools-and-liblxi-v1-0-released-for-gnulinux/ is a good place to discuss lxi-tools.

Also, just to help clarify. LXI (LXI Core etc.) is simply the standard that dictates that LXI certified instruments are required to communicate SCPI commands using communication protocols like RAW/TCP, VXI11/TCP, and HiSlip/TCP.

[TinkeringSteve]

I just installed the lates firmware on mine, thinking, they probably got most of the kinks out of there.

Well. I just wanted to try the FFT function, played around with the options, and when I set
Mode to "Memory", the thing froze, none of the controls (e.g. channel buttons) worked, had to reset.

Can someone else confirm this?
(could have had a bad download, who knows... Although they hopefully do CRC or so on those files...)

[frozenfrogz]

No problems using FFT in memory mode.
Does your scope freeze every time / is it reproducible?
If it is persistent: Please try re-uploading the firmware as you already mentioned and if the error still remains, please share the extended system info for reference.

[Karel]

Try resetting the scope: switch it off and then on again and press repeatedly the 5th grey button on the left.
The language will change to chinese but that's easily fixed in the menu at the left.