Software & tips for Rigol DS2072 ( DS2000 / DS4000 / DS6000 UltraVision DSOs )

[andrewfernie]

01.00.05 Firmware

Same File as I got (hex compared Identical)

Thank you!

[marmad]

01.00.05 Firmware

http://rapidshare.com/files/2813177036/DS2000Update.GEL

Thanks studio25!

For those planning to use the upgrade file:

Do the upgrade ONLY during bootup - not from the GUI/Menus/OS asking for file/etc. or you will lock up the scope - losing any trial options you have remaining - and requiring you to do the upgrade again anyway using the method listed below:

You do this by using two hands when booting up - one thumb on the 'Power On' switch - one thumb on the 'Help' button. When you press 'Power On', all of the scope LEDs will light for ONE SECOND - during that brief period, you must PRESS AND LET GO of the 'Help' button. It can be a little tricky, but if it works, bootup will stop before the Rigol logo with the 'SINGLE' button lit (if it doesn't, turn off power and try again until you get it). Then insert the USB stick with the file on it.

[Teneyes]

This utility provides three basic functions:
When you start the software, it will reflect the current state of the DSO and it's variables, i.e. if you are in Record Open mode, the Open button will be 'On', etc. If you change one of the variables in RUU, it will alter it on the scope, so the settings in RUU will normally override the DSO settings. But sometimes you might want to use, for example, the Navigation Knob on the scope to set the current frame - or set a variable using the Rigol's menus. If you want to have the DSO settings override RUU, click the 'READ' button in either the 'Record' or 'Play' group to have the respective settings of that group loaded from the scope.
In general, all of the buttons and settings function the same as they do on the Rigol - with the following exceptions:

DS2072 FW1.00.02    RUU 1.1
Hi, I am not sure if I understand that RUU is able to do  'Record Open' .  Does it??

trying to use  'single quotes' for RUU and  "double quotes" for DS2072 naming

when I click on the RUU 'Open' the DSO displays "Input invalid!" at center bottom


If I start the DSO into "Open" Record
oh the DSO displays "max =62"  , and RUU  'record read' displays '63 as max'
Normal trigger and record some frames ie 46 in 62

If I click on RUU 'Open'  the DSO resets the recorded frames from "42" back to "0" and displays "Input invalid!" at center bottom

If I click on RUU 'Record'  the DSO switches from "Open" to "Record" mode; which is different recording

Note the DSO "Open" record mode is controlled with "run/stop"

[marmad]

Hi, I am not sure if I understand that RUU is able to do  'Record Open' .  Does it??

Absolutely! It's the first feature I made in the software - for getting quickly in and out of Record Open without menus.

when I click on the RUU 'Open' the DSO displays "Input invalid!" at center bottom

Hmm... this is the first time I heard of this bug. I wonder if 01.00.02 uses the outmoded SCPI command "Keep" - which is what Rigol was first calling it instead of "Open". Can you please try the attached software below and tell me which button works for you, "Open" or "Keep"? And thank you for the bug reports! (EDIT: BTW, if the software won't start, you may have to run it in the same folder you have RUU - if it needs to find VISA dlls).

If I start the DSO into "Open" Record oh the DSO displays "max =62"  , and RUU  'record read' displays '63 as max'

This is correct behavior - you'll notice on the Rigol that in "Record" mode, the maximum frames is always one more than in "Open" mode (I think it has to do with the looping). Switch back and forth with the menus and you'll see what I mean.

If I click on RUU 'Open'  the DSO resets the recorded frames from "42" back to "0" and displays "Input invalid!" at center bottom

This is mostly correct behavior (except the "Input invalid!  ). Since Record Open is loop recording, every time you tell it to start Open recording, it resets to 0 and starts again. The DSO does the same thing when you RUN and STOP "Open".

If I click on RUU 'Record'  the DSO switches from "Open" to "Record" mode; which is different recording

This is correct behavior.


Attached here is simple test software for entering and exiting Record Open mode - using either SCPI command "Open" or "Keep" (mentioned in Rigol Prog. Guide). Users with 01.00.02 firmware can test if the "Open" command works on their DS2000s.

[Teneyes]

Attached here is simple test software for entering and exiting Record Open mode - using either SCPI command "Open" or "Keep" (mentioned in Rigol Prog. Guide). Users with 01.00.02 firmware can test if the "Open" command works on their DS2000s.

I tried  RigRec.exe and
 Yep,   1.00.02 uses  "Keep" to start Open Record.

Now what to do now ? 
maybe I stay with 1.00.02 to test RUU. on 1.00.02 if you want.

Can RUU read FW version and do different functions to accommodate North American Users or is that too much  extra Work

I guess all  NA user's can update to 1.00.05 ,  on this thread and "Impressions"

[marmad]

I tried  RigRec.exe and
Yep,   1.00.02 uses  "Keep" to start Open Record.

Now what to do now ? 
maybe I stay with 1.00.02 to test RUU. on 1.00.02 if you want.

Can RUU read FW version and do different functions to accommodate North American Users or is that too much  extra Work

No problem... I will add small code to test for < 01.00.05 and use "Keep" command instead. It will be in the next update - hopefully later tonight (with video instructions) - or tomorrow.

EDIT: Fixed in v.1.4.

And yes please, continue to test. But I think that was the only command I use which was different in Programming Guide (so different firmware) so the rest should be the same for you.

[marmad]

@Teneyes - you can just use normal Record to test recording, playing back, saving files and creating animated GIFS.

[Teneyes]

@Teneyes - you can just use normal Record to test recording, playing back, saving files and creating animated GIFS.

Yes the record function works 1-62 frames for 1.4Mb depth

Not sure about Playback. the frame count increments and the DSO goes thur each frame at RUU interval speed, BUT nothing is dispalyed on RUU 'Display' just grid

The RUU does display each frame when the RUU is saving the frames to files and .GIF

I can save to bitmap , Anim.gif    see att.  for the funny effect I got by changing the "End Frame" while playback /saving
Not sure  what RUU could do when frame number is jumping around,
maybe Prompt , 'STOP FRICKING WITH THE DSO WHILE SAVING FRAMES'    

[marmad]

Not sure about Playback. the frame count increments and the DSO goes thur each frame at RUU interval speed, BUT nothing is dispalyed on RUU 'Display' just grid

Yes, it takes ~2 - 2.5 seconds to get a bitmap image from the Rigol - so I only do it when you are saving frames. Later version will hopefully have real-time 'SVGA'-like display - but it requires writing an 'engine'.

Not sure  what RUU could do when frame number is jumping around,
maybe Prompt , 'STOP FRICKING WITH THE DSO WHILE SAVING FRAMES'    

  Yes, there are many things I can't control from RUU - since the owner also has control over the DSO from it's buttons. Two things trying to control the same device! But one problem with Rigol SCPI implementation is that it's missing a way for the DSO to communicate 'at' the software (like an interrupt - or a button press). It's a simple one-way protocol - you send a command to the scope and it sends back data. You could do much more with it if the scope could notify you directly of events - than the PC could be more easily programmed to act like added 'features' of the DSO without requiring human intervention, Right now I have to 'poll' the scope for changes - not very efficient (that's why the 'READ' buttons).

[marmad]

Rigol Read Memory Test

This is a small utility for testing if your Rigol DS2000 series scope can have it's sample memory read correctly by the PC.

Directions: First try button #1 - if it works, then try button #2 with different memory depth settings - if they work successfully, your DSO has passed the test (lucky you  ). If it doesn't you can try button #3 (use "Break" if stuck in a loop - but for memory depths <= 140k, the loop will usually end with a successful read after a few times).

1) "Rigol Display Memory Read - NORM Mode"
This button attempts to read only the display memory (1400 bytes per channel) using the Rigol technique as described in the programming manual. When finished, "Total bytes read" should equal the sample size shown up above (except in ASCII mode). This should work on all Rigol scopes.

2) "Rigol Full Sample Memory Read - MAX/RAW mode":
This button attempts to read the full sample length (56 bytes to 56MB per channel - depending on Acquire/Record settings) using the Rigol technique as described in the programming manual (perhaps it's outdated - that's one thing I'm trying to determine). When finished, "Total bytes read" should equal the sample size shown up above (except in ASCII mode). This doesn't appear to work on Rigol scopes with firmware v.01.00.05.

3) "Wait Until Bytes Read >= Sample Memory Size"
Forces the routine to keep trying to read data until bytes read >= memory depth size (ignoring IDLE command from Rigol unless followed by "0"). This usually works for small memory depths (<= 140k) on my scope.

4) "Break"
Breaks out of reading memory. Click once and wait.

5) "Channel 1 / 2 "
Selects channel(s) to read.

6) "Byte / Word / ASCII -> [] Show"
Selects format for memory read - and shows the data if ASCII selected and Show is checked (careful when using this for > 1.4MPts mem. depths).

7) "MAX / RAW"
Selects Rigol command to use for memory 'type'.



Please report back your results. Any strange results can be copied and pasted here from the output window.

NOTE: The VISA session is set to timeout after 3 seconds - so don't worry if there is a couple of seconds of inactivity - in case of a non-response from the Rigol firmware, the software will automatically timeout and break. The Break button is used for exiting when reading large memory depths - or when forcing the reading using button #3.

There is definitely a bug in the IDLE -> READ response sequence - which is the final response for the final packet when reading memory. You can see how this works by setting your memory depth to 14MPts, then running my software and clicking "Rigol Full Sample Memory Read - MAX/RAW mode". The PC will read the entire memory - but fail on the final packet.  Unfortunately, for small memory depths (< 14MPts in non-ASCII mode), there is only one packet - so read attempts at 14kB and 140kB and 1.4MB fail using Rigol's technique. Using my "Wait Until Bytes Read >= Sample Memory Size" button will usually force my DSO into finally sending the final packet at smaller memory depths (<= 140k) - but it's a wonky workaround.  It seems like it might be a timing issue.

It's very easy to check if Rigol's reading sequence works on your DSO - just:
Set Memory Depth to 14kPts.
Run my software.
Click "Rigol Full Sample Memory Read - MAX/RAW mode"
If you get "Total bytes read: 0" - it didn't work. If you get "Total bytes read: 14000", the bug is not present in your scope.
Then try the same thing again with a few other memory depths.

EDIT: This download is without VISA runtime or DLLs! If you haven't installed NI-VISA on your system, get the DLLs from the RUU download.

[larsie]

Is the newest software posted in the first post? Or is there some other post I should use (for the general utility that you showed screenshots of in the other thread).

[marmad]

Is the newest software posted in the first post? Or is there some other post I should use (for the general utility that you showed screenshots of in the other thread).

I don't have the documentation done for the latest version - too many other things coming up (new bugs in the Rigol firmware discovered, etc). I hope to have it posted soon - I'll let you know 

[Sparky]

Just a quick comment on the current RRU v1.1:

I tried it out and I think its really great --- Record, Record Open, and saving the data is working very well.  I tried saving Display, Waveform and Frames, as both CSV and Bitmap, and animated GIF and everything worked as expected.  I could load the CSV files directly in Excel and plot the data (and it looks just like on the scope as expected!) 

At this moment, I have just one little suggestion --- not a bug, but something I thought was a little odd, but didn't cause any problems.  It is, when using the "Save" button, and if I choose different things to save (Waveform, or Frames) and chose a type (CSV or Bitmap), the "Save As..." dialog box always indicates "Save as type: PNG (*.png)".  Thus it is a bit confusing when selecting to save as CSV and seeing the file type as PNG.  I ignored it and type the base filename, and then the software works as expected and saves a .csv file, but I thought it would be nice if the "Save as type" was updated depending on the what was selected for saving (animated GIF, CSV, or bitmaps). 

Working excellent so far -- hope Rigol will fix the deep memory reading bugs!

[marmad]

Just a quick comment on the current RRU v1.1:

I tried it out and I think its really great --- Record, Record Open, and saving the data is working very well.  I tried saving Display, Waveform and Frames, as both CSV and Bitmap, and animated GIF and everything worked as expected.  I could load the CSV files directly in Excel and plot the data (and it looks just like on the scope as expected!) 

At this moment, I have just one little suggestion --- not a bug, but something I thought was a little odd, but didn't cause any problems.  It is, when using the "Save" button, and if I choose different things to save (Waveform, or Frames) and chose a type (CSV or Bitmap), the "Save As..." dialog box always indicates "Save as type: PNG (*.png)".  Thus it is a bit confusing when selecting to save as CSV and seeing the file type as PNG.  I ignored it and type the base filename, and then the software works as expected and saves a .csv file, but I thought it would be nice if the "Save as type" was updated depending on the what was selected for saving (animated GIF, CSV, or bitmaps). 

Working excellent so far -- hope Rigol will fix the deep memory reading bugs!

Thanks Sparky! And thanks a lot for the encouragement and appreciation - it's really helpful sometimes when coding for hours. And yes, thanks for reminding me about the File Type 'bug' - it was a shortcut I used when banging out code but I will fix it for CSV and WFM file types.

EDIT: Fixed in v.1.4.

[marmad]

Posted a revamped version of the Read Memory test above.

[Teneyes]

Posted a revamped version of the Read Memory test above.

DS2072  w/ 1.00.02
Hi , just woke Up, remember I am @ west coast, that is PST , that is GMT  -8:00

ok at 14.0Mpts I get :
for Read Display
-------------------------
WAV:FORM BYTE
:WAV:SOURce CHANnel1
:WAV:MODE NORMal
:WAV:DATA?
Total bytes read: 1400----------------------------------

for Read Full Max
--------------------------------------
.
.
.
READ,1396736
:WAV:DATA?
Bytes read: 1396736:WAV:STATus?
READ,126976
:WAV:STATus?
:WAV:STATus?
READ,126976
..
.
.
---------------------
which  loops until I used break

Bytes read: 634880
Max.packet read: 1396736
Total bytes read: 11808744:WAV:END

=======================
for 56Mpts
RRN shows '56000000 Smples'

results the same with looping at 13896736
++++++++++++++++++
starts
:WAV:FORM BYTE
:STOP
:ACQuire:MDEPth?
56000000
:WAV:SOURce CHANnel1
:WAV:MODE MAX
:WAV:RESet
:WAV:BEGin
:WAV:STATus?
READ,126954
.
.
READ,1396736
:WAV:DATA?
Bytes read: 1396736
:WAV:STATus?
READ,126976
==================================
looks the same as 14Mpts

hope this helps

Below is dso display,
 PS Don't laugh at my 52 year old tube oscillator , mb time to replace old tubes
     looking @ DGxxxx?
PS 

[marmad]

@Teneyes:

First of all, thank you so much for helping me out with this - I really appreciate it.  But because you used large memory depth settings, it's not clear whether the PC would have finished the memory read correctly since you broke out before it was done (it takes quite awhile to read 14MB or 56MB from the DSO).

But you only need to try with the small settings to make it crystal clear whether the bug exists in v.00.01.00.02, so can you please do the following (it will only take a few seconds)?

Set Rigol Memory Depth to 14kPts.
Click "Rigol Full Sample Memory Read - MAX/RAW mode"
Set Rigol Memory Depth to 140kPts.
Click "Rigol Full Sample Memory Read - MAX/RAW mode"
Then copy and paste the output window here.

That's all I need to know.

[Teneyes]

UPDATE
  I let MAx read run
and after 40 Loops ( scanned and counted them

RRM stops with
-------------
READ,1269760
:WAV:STATus?
READ,1396736
:WAV:DATA?
Bytes read: 1396736
:WAV:STATus?
READ,126976
:WAV:STATus?
IDLE,130582
:WAV:DATA?
Bytes read: 130582
Max.packet read: 1396736
Total bytes read: 56000000:WAV:END
======================
Is the 56000000 just your program counter??

By the way to save one 56Mpts waveform to USB stick took me 17+ minutes , a little less to Load

[marmad]

Bytes read: 130582
Max.packet read: 1396736
Total bytes read: 56000000
:WAV:END
======================
Is the 56000000 just your program counter??

It's how many bytes the PC got from the Rigol - and you managed to get a correct 56MB read! Congrats! Now can you test the two small memory settings (14k / 140k)? If you get both of those correctly - your firmware does NOT have the reading bug - and I have to start thinking seriously about downgrading to v.00.01.00.02 

[Teneyes]

@Teneyes:

Set Rigol Memory Depth to 14kPts.
Click "Rigol Full Sample Memory Read - MAX/RAW mode"
Then copy and paste the output window here.

:WAV:FORM BYTE
:STOP
:ACQuire:MDEPth?
14000
:WAV:SOURce CHANnel1
:WAV:MODE MAX
:WAV:RESet
:WAV:BEGin
:WAV:STATus?
IDLE,14000
:WAV:DATA?
Bytes read: 14000
Max.packet read: 14000
Total bytes read: 14000
:WAV:END

[Teneyes]

Set Rigol Memory Depth to 140kPts.
Click "Rigol Full Sample Memory Read - MAX/RAW mode"
Then copy and paste the output window here.

:WAV:FORM BYTE
:STOP
:ACQuire:MDEPth?
140000
:WAV:SOURce CHANnel1
:WAV:MODE MAX
:WAV:RESet
:WAV:BEGin
:WAV:STATus?
IDLE,140000
:WAV:DATA?
Bytes read: 140000
Max.packet read: 140000
Total bytes read: 140000
:WAV:END

Looks good for 140K

[marmad]

Damn! This bug DOES appear to be v.00.01.00.05 bug. This might explain why Rigol is not passing out v.00.01.00.05 firmware freely.

BTW, the Rigol will transfer a maximum of 2031600 bytes per packet - so 56000000/2031600 requires a minimum of 28 packets.

[Teneyes]

USing  RRM for 1.4Mpts
------------------------
WAV:FORM BYTE
:STOP
:ACQuire:MDEPth?
1400000
:WAV:SOURce CHANnel1
:WAV:MODE MAX
:WAV:RESet
:WAV:BEGin
:WAV:STATus?   READ,126950   :WAV:STATus?   READ,126950   :WAV:STATus?  READ,126950
:WAV:STATus?   READ,253926   :WAV:STATus?   READ,253926   :WAV:STATus?  READ,253926
:WAV:STATus?   READ,380902   :WAV:STATus?   READ,380902   :WAV:STATus?  READ,380902
:WAV:STATus?   READ,507878   :WAV:STATus?   READ,507878   :WAV:STATus?  READ,507878
:WAV:STATus?   READ,634854   :WAV:STATus?   READ,634854   :WAV:STATus?  READ,634854
:WAV:STATus?   READ,634854   :WAV:STATus?   READ,761830   :WAV:STATus?  READ,761830
:WAV:STATus?   READ,761830   :WAV:STATus?   READ,888806   :WAV:STATus?  READ,888806
:WAV:STATus?   READ,888806   :WAV:STATus?   READ,1015782 :WAV:STATus?  READ,1015782
:WAV:STATus?  READ,1015782  :WAV:STATus?   READ,1015782 :WAV:STATus?  READ,1142758
:WAV:STATus?  READ,1142758  :WAV:STATus?   READ,1142758 :WAV:STATus?  READ,1269734
:WAV:STATus?  READ,1269734  :WAV:STATus?   READ,1269734 :WAV:STATus? 
IDLE,1400000
:WAV:DATA?
Bytes read: 1400000
Max.packet read: 1400000
Total bytes read: 1400000
:WAV:END

looks good for 1.4Mpts

[marmad]

Sheesh... does anyone happen to have a copy of v.00.01.00.02 firmware around? I believe the bootloading sequence (at least for now) allows downgrading.

[Teneyes]

Downgrading,  mmmm  if 1.00.02 was first  , got to go to Rigol
I'll ask here is USA,
Cannot slow production of RRU


Should we check the captured data,
iie RRM outputs to a file , that I send to you

I'm ready for new test program

Oh I'm notified  on most of the DS2000 EEVBlogs