New Rigol DS1054Z oscilloscope

[SparkyM8]

Thanks skander36

I didn't think to try that. The command needed is

:SYST:OPT:UNINSTALL

SCPI is not case sensitive, as bitseeker pointed out. By convention in documentation the lower case parts are supposed to be optional.
So unless this is a bug and :SYST:OPT:UNINST used to work on previous FW releases the manual is wrong and should say

:SYSTem:OPTion:UNINSTALL

Which is pretty unusual since the parts of SCPI commands are not more than 5 characters in general

[bitseeker]

Perhaps engineering wanted to be sure you really mean it when you enter the command. I guess the documentation writer didn't get that memo.

[metrologist]

Thanks skander36

I didn't think to try that. The command needed is

:SYST:OPT:UNINSTALL

SCPI is not case sensitive, as bitseeker pointed out. By convention in documentation the lower case parts are supposed to be optional.
So unless this is a bug and :SYST:OPT:UNINST used to work on previous FW releases the manual is wrong and should say

:SYSTem:OPTion:UNINSTALL

Which is pretty unusual since the parts of SCPI commands are not more than 5 characters in general

There is a 999 page SCPI conformance document that defines SCPI syntax and style, originally authored by the SCPI Consortium, now under control of the IVI Foundation. It specifies that short form SCPI commands are to be 4 characters long, unless the 4th character is a vowel, in which case the short form is then to be 3 characters long, unless the long form would be 4 characters long anyway.

Meaning MODE and SWEep...

I always expect anything in between to throw a syntax error.

Therefore, the proper forms of the command should be

:SYSTem:OPTion:UNINstall

or

:SYST:OPT:UNIN

and no period.

[skander36]

Indeed , if someone (like me) read the manual carefully , will found :
Command Abbreviation
All the commands are case-insensitive and you can use any of them. If abbreviation is used, all the capital letters in the command must be written completely. For example, :MEASure:ADISplay? can be abbreviated to :MEAS:ADIS?.
Thx !

[RoGeorge]

SCPI standard specifications (far all SCPI instruments and all manufacturers):
http://www.ivifoundation.org/docs/scpi-99.pdf

[Karel]

Lets say that Rigol is not a prime example of scpi implementation...

[Fungus]

Lets say that Rigol is not a prime example of scpi implementation...

You'll probably find it works perfectly if you send an SCPI newline instead of copying/pasting with a Windows newline.

[Karel]

Lets say that Rigol is not a prime example of scpi implementation...

You'll probably find it works perfectly if you send an SCPI newline instead of copying/pasting with a Windows newline.

There's no such thing as a "windows newline". windows uses a carriage return and a newline (linefeed).

https://en.wikipedia.org/wiki/Newline#Representations

I don't know if the Rigol accepts a carriage return + linefeed, I don't use windows...

[RoGeorge]

Oh sure, it's always the user's fault, except for when some commands freeze the instrument, or at least hangs all SCPI communication until the next power cycle, or when a firmware update changes the SCPI response or disable TCP port 5566 without documenting the change, or the instrument's registers are not described in the instrument's SCPI manual, or when commands or options are totally missing from the manuals, or when they return incomplete or misaligned raw data, and so on.
 

These are just a few I remember to bother me the most in the past, but they are not all. Almost each time I wanted to use Rigol SCPI, I bumped into something that it was either unreliable to use, or simply not working according to SCPI specs, or according to the instrument's Programming Guide/User Manual. It's a delicate balance between the SCPI standard and various Rigol implementation quirks, and it's always shifting from one firmware to another.

Here is a tutorial about how to write software for Rigol's SCPI:

[SparkyM8]

SCPI in the DS1054Z does need a bit more work in a few areas.
But it is way better than the Siglent scopes, which are dreadful.
I was planning on a SDS2000X at 3.5x the price of the DS1054Z, but programming was a total showstopper.
Probably a discussion for another thread.

[Fungus]

I don't know if the Rigol accepts a carriage return + linefeed

But you posted anyway.

[RoGeorge]

The correct answer would be "It depends of the FW version, sometimes it even works without any LF or CRLF at all."

Never mind, this is a new one I bumped into:

NEW BUG (Software 00.04.04.SP3, Board 0.1.1): When a bad SCPI command is followed by another command, then query the error queue using ":SYST:ERR?", the SCPI will become unresponsive until the next power cycle.
Note: This will not happen for any bad command, so far I found that commands that make the oscilloscope to display "Function Limited!" or "Invalid Input!" will trigger this kind of bug.

Steps to reproduce:
1. Connect a Rigol DS1054Z to LAN, then start Netcat by typing in a terminal:
nc 192.168.1.3 5555

3. In the NetCat, type
:WAV:STAR 0

4. Now type at least one more SCPI command, good or bad, for example
:WAV:STAR 1

5. SCPI apparently is still working, until you type:
:SYST:ERR?

6. Now the oscilloscope won't respond to any other SCPI command, and it won't accept new TCP connections until the next power cycle.

Rigol, please fix it.
 



Example

Code: [Select]

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

:WAV:MODE NORM
:syst:err?
0,"No error"

:WAV:MODE STAR 1201
:syst:err?
-220,"Parameter error"
:syst:err?
0,"No error"
So far all good, as expected.

Now, try this:

Code: [Select]

:WAV:STAR 1201
:WAV:STAR 120
:syst:err?
That's it, SCPI hangs until the next power on.

[frozenfrogz]

NEW BUG (Software 00.04.04.SP3, Board 0.1.1): When a bad SCPI command is followed by another command, then query the error queue using ":SYST:ERR?", the SCPI will become unresponsive until the next power cycle.

Could you please post your findings to the DS1000Z buglist (cont.) thread as well?
Also a "short" description to be included into the buglist (OP) would be nice. This would help me to keep the OP clean and updated, will then hopefully append your findings this weekend.

Regards, Frederik

[RoGeorge]

Done.
Not sure about the short description request, it has 'Steps to reproduce', example, and description instead.

[metrologist]

The OP has a short list in his first post, like a ToC: maybe something like SCPI Syntax Error Handling Bug?

[CustomEngineerer]

It would be more interesting to know wether they fixed the design problems with the PLL circuitry.

Why, what problem is it causing?

[Fungus]

Why, what problem is it causing?

Beats me    but some people can't sleep at night thinking about it.

[tautech]

It would be more interesting to know wether they fixed the design problems with the PLL circuitry.

Why, what problem is it causing?

A few but Fungus doesn't really want to answer this fully.

Members MarkL and Bud are those that narrowed it down to design problems with the PLL and then Dave did a vid on it.
https://www.eevblog.com/forum/blog/eevblog-683-rigol-ds1000z-ds2000-oscilloscope-jitter-problems/

Then Bud started looking hard at his own DS2000A, which he documented in full:
https://www.eevblog.com/forum/projects/project-yaigol-fixing-rigol-scope-design-problems/

So yes, if there is a new revision MB it will be interesting to see if these things have been addressed,

[Karel]

I was planning on a SDS2000X at 3.5x the price of the DS1054Z, but programming was a total showstopper.

Can you elaborate on that?

[borjam]

It would be more interesting to know wether they fixed the design problems with the PLL circuitry.

Why, what problem is it causing?

A few but Fungus doesn't really want to answer this fully.

Members MarkL and Bud are those that narrowed it down to design problems with the PLL and then Dave did a vid on it.
https://www.eevblog.com/forum/blog/eevblog-683-rigol-ds1000z-ds2000-oscilloscope-jitter-problems/

Then Bud started looking hard at his own DS2000A, which he documented in full:
https://www.eevblog.com/forum/projects/project-yaigol-fixing-rigol-scope-design-problems/

So yes, if there is a new revision MB it will be interesting to see if these things have been addressed,

At the very least it can increase noise.

And no, I am not in the Rigol or Siglent bashing business. I actually own a DS1074Z and a SDS1202X-E and both have proven really useful and worthy despite their limitations.

[Fungus]

It would be more interesting to know wether they fixed the design problems with the PLL circuitry.

Why, what problem is it causing?

A few but Fungus doesn't really want to answer this fully.
Members MarkL and Bud are those that narrowed it down to design problems with the PLL and then Dave did a vid on it.

And... then what happened?

It looks like a few people don't want to tell the whole story, they prefer to keep on hating. 

For anybody wondering:
3) Rigol issued a firmware update.
4) Now it all works perfectly.

Dave even did another video to confirm it but I guess you lost the URL to that one, right?

[RoGeorge]

If anybody knows where I can find the steps to reproduce the PLL/jitter problems, please tell me, and I'll give it another try.

I just tested my DS1054Z for jitter, and it's rock solid, no jitter at all.
In the pic is more than 10 minutes of run with infinite persistence for either sinus and square waveform.

[tautech]

It would be more interesting to know wether they fixed the design problems with the PLL circuitry.

Why, what problem is it causing?

A few but Fungus doesn't really want to answer this fully.
Members MarkL and Bud are those that narrowed it down to design problems with the PLL and then Dave did a vid on it.

And... then what happened?

It looks like a few people don't want to tell the whole story, they prefer to keep on hating. 

For anybody wondering:
3) Rigol issued a firmware update.
4) Now it all works perfectly.

Dave even did another video to confirm it but I guess you lost the URL to that one, right?

You can find it easy on Daves site:
https://www.eevblog.com/episodes/
https://www.eevblog.com/2015/01/05/eevblog-699-rigol-ds1054z-oscilloscope-jitter-fix-testing/

Anyway all this stuff is in this thread for anybody to find.

If anybody knows where I can find the steps to reproduce the PLL/jitter problems, please tell me, and I'll give it another try.

I just tested my DS1054Z for jitter, and it's rock solid, no jitter at all.
In the pic is more than 10 minutes of run with infinite persistence for either sinus and square waveform.

You won't reproduce it unless you roll back to very early firmware...........that's if you can. Sometimes there's firmware locks to prevent this.
IIRC at the time there were doubts the jitter issue could be masked with firmware but it was bad enough that I think a new record was set for the fastest FW release. 

[SparkyM8]

I was planning on a SDS2000X at 3.5x the price of the DS1054Z, but programming was a total showstopper.

Can you elaborate on that?

Probably best in another thread but briefly:-

One programming manual for all the scopes they ever made with many errors and omissions and user expected to work out what parts apply to there model.
Many commands are missing.
Could not show download of all 140Mpts.
Totally inconsistent return format not conforming to any standard.

e.g. query timebase reply TDIV 5.00E-03S  or TDIV 1.00E-03ms
       query delay      reply TRDL 0.00us

You get upper case, lower case, suffices and mixed up units all of which don't meet SCPI.
That is just the tip of the iceberg.

[RoGeorge]

You won't reproduce it unless you roll back to very early firmware...........that's if you can. Sometimes there's firmware locks to prevent this.
IIRC at the time there were doubts the jitter issue could be masked with firmware but it was bad enough that I think a new record was set for the fastest FW release. 

Since the bug is not present in my oscilloscope, I thought that maybe I didn't used the correct settings/signals to reproduce it, so I asked for more detailed steps to reproduce.

Looking at the PLL's spectrum in the Dave's video, it seems that the PLL jitter bug was fixed (not only masked) long time ago, so no further questions. I have no intention to reproduce fixed bugs, thank you.

To answer the question from a couple of days ago, yes, the PLL jitter was fixed.