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

[marmad]

@EV

Now I'm not sure if the problem is coming from RUU; I'm wondering if you have NI-VISA installed correctly. Have you used any other VISA software to communicate with the scope? Rigol's Ultra Sigma, MATLAB, LabVIEW, etc? I think you better test first that you can communicate with your scope - use Ultra Sigma to open a USB session and send *IDN? to the Rigol.

[EV]

@EV

Now I'm not sure if the problem is coming from RUU; I'm wondering if you have NI-VISA installed correctly. Have you used any other VISA software to communicate with the scope? Rigol's Ultra Sigma, MATLAB, LabVIEW, etc? I think you better test first that you can communicate with your scope - use Ultra Sigma to open a USB session and send *IDN? to the Rigol.

I have not used any other programs on your list and I installed NI-Visa first time today. I install and try Ultra Sigma tomorrow.

[Sparky]

@marmad: Hope you don't mind me posting this here; I thought it was the most relevant thread.

Update on DS2000 series IVI drivers:

I heard similarly as marmad from Rigol NA regarding availability of IVI driver; i.e. it hasn't been released yet.  But, Rigol suggested to me to try DS6000 series IVI driver, and that "I should be able to use most of the basic commands" from that driver. 

I have tried a few things in MATLAB R2012a 64-bit, namely:
1. http://www.mathworks.com/help/instrument/examples/reading-waveforms-from-an-oscilloscope-using-ivi-c-class-compliant-interface.html
2. http://www.mathworks.com/help/instrument/examples/reading-waveforms-from-an-oscilloscope-using-a-quick-control-oscilloscope-object.html

But have not been successful, and errors from MATLAB were not particularly helpful. 

I am running Windows 64-bit and initial problems seem to be that Rigol's IVI driver installs its software modules in:
C:\Program Files\IVI Foundation\IVI\Bin\rgds6k_32.dll

Which appears inappropriate for a 32-bit DLL on a 64-bit operating system.  Instead, it should have installed to:
C:\Program Files (x86)\IVI Foundation\IVI\Bin\rgds6k_32.dll

with a 64-bit version in: C:\Program Files\IVI Foundation\IVI\Bin\
but the Rigol package does not contain 64-bit versions of the DLL files.

I found MATLAB's "Test & Measurement Tool" (tmtool) not that helpful in checking/modifying the IVI driver configuration (e.g. hard to know if 32 or 64-bit DLL versions are being loaded, and from what directories etc.). 

I did notice MATLAB lists: IVIRootPath = 'C:\Program Files\IVI Foundation\IVI\' which seems fine for 64-bit system, except that is where Rigol put the 32-bit DLL...

I tried copying (what I deemed appropriate) files from C:\Program Files\IVI Foundation\IVI\ to C:\Program Files (x86)\IVI Foundation\IVI\
but found no way to configure MATLAB to look for 32-bit IVI drivers in this directory, in fact, I'm not sure if 64-bit MATLAB will work with the 32-bit IVI drivers provided by Rigol.


The National Instruments "Measurement & Automation Explorer" (MAX) seems a more helpful; it seems to read and write the same IVI configuration file (an XML file) as MATLAB does, and it points out two different paths for 32-bit and 64-bit DLL files. (see attachment) So, NIs MAX seems a better way to do the IVI configuration than MATLABs tmtool.

I haven't tried setting things up the IVI configuration entirely within MAX, and then seeing how MATLAB works, but that would be a next step.


Most of my problems seem to be because of 32-bit and 64-bit differences between Windows/MATLAB and the Rigol IVI driver package.  If someone has a 32-bit only setup, they may have more luck.  I'm interested to hear how that turns out.


If you wish to try the IVI driver stuff, you also need to install the NI IVI Complicance Package:
http://joule.ni.com/nidu/cds/view/p/id/3065/lang/en

And, IVI Shared Components:
http://www.ivifoundation.org/shared_components/Default.aspx

[EV]

I think you better test first that you can communicate with your scope - use Ultra Sigma to open a USB session and send *IDN? to the Rigol.

I installed UltraSigma and tried it. It looks to work correctly (picture). I tried also RUU after UlraSigma installation. There is no change. It does not work.

Edit:Serial number destroyed

[marmad]

I installed UltraSigma and tried it. It looks to work correctly (picture). I tried also RUU after UlraSigma installation. There is no change. It does not work.

Ahh... I know what the error with RigRead2 is. I mentioned in a previous post (which I think you didn't read) that these small test programs (RRM, RigRead, etc) are without the needed DLLs that come with RUU (if only I could read Finnish) - you must run RigRead2 in the same folder where you have RUU. Please test RigRead2 again from RUU folder. Thanks.

BTW, RUU won't work for you until I post a bug fix - that's why we have RigRead(2).

[EV]

Ahh... I know what the error with RigRead2 is. I mentioned in a previous post (which I think you didn't read) that these small test programs (RRM, RigRead, etc) are without the needed DLLs that come with RUU (if only I could read Finnish) - you must run RigRead2 in the same folder where you have RUU. Please test RigRead2 again from RUU folder. Thanks.

BTW, RUU won't work for you until I post a bug fix - that's why we have RigRead(2).

Sorry, you are right, I have not read all the earlier posts. RigRead and RigRead2 give both the same message, which is in the picture.

[marmad]

Sorry, you are right, I have not read all the earlier posts. RigRead and RigRead2 give both the same message, which is in the picture.

Great! So I think I have found the bug - and the fix will be incorporated in the next version of RUU. Please let me know if it doesn't work. Thanks!

[marmad]

I heard similarly as marmad from Rigol NA regarding availability of IVI driver; i.e. it hasn't been released yet.  But, Rigol suggested to me to try DS6000 series IVI driver, and that "I should be able to use most of the basic commands" from that driver. 

Strange, I would think that the DS4000 series IVI driver would be closer to the DS2000. I thought it was released after the DS6000, and it's specs were more similar.

[marmad]

Since I have the animated GIF option as a kind of compiled version of the screen images - I'd like to do the same for the CSV output. Does anyone know if you can make a database file that is in CSV format? So it could be opened in Access or another DB program?

Also, since I have the animated GIF option as a kind of compiled version of the screen images - I'd like to do the same for the CSV output. Does anyone know if you can make a database file that is in CSV format? So it could be opened in Access or another DB program?

To what purpose? A relational database isn't really appropriate for this sort of data I don't think. Though most database engines I'm familiar with can import CSV fairly easily (Postgres, MySQL and Oracle all can).

Have just ordered my DS2072 thanks to this thread and particularly your posts marmad. Thanks for the info and software, I'm sure I will be satisfied. Waiting anxiously for a shipment notification so I can play .

To what purpose? A relational database isn't really appropriate for this sort of data I don't think. Though most database engines I'm familiar with can import CSV fairly easily (Postgres, MySQL and Oracle all can).

Well, I'm not sure - maybe we can discover a purpose later. But originally the idea was just as a possible solution to an organizational problem - if you want a voltage record of each waveform stored in a 100 different frames, the DS2000 doesn't allow you to save any files when in Record mode. But my software can pull out that voltage record from each frame and save it as a CSV file, but then you have a 100 (or whatever) separate CSV files. I thought it might be handier to have it stored in a single file, as a database of frames connected via their relationship to time. Anyway, just trying to think of more efficient ways to save recorded data for possible analysis or processing later.

Well, I'm not sure - maybe we can discover a purpose later. But originally the idea was just as a possible solution to an organizational problem - if you want a voltage record of each waveform stored in a 100 different frames, the DS2000 doesn't allow you to save any files when in Record mode. But my software can pull out that voltage record from each frame and save it as a CSV file, but then you have a 100 (or whatever) separate CSV files. I thought it might be handier to have it stored in a single file, as a database of frames connected via their relationship to time. Anyway, just trying to think of more efficient ways to save recorded data for possible analysis or processing later.

I see what you mean, maybe something a little more elegant than a bunch of timestamped text files is required... Maybe a simple XML format? Unless you're planning on writing a 'waveform management system' as well though (and I'm sure many would be happy if you were!), this might be one to leave as an exercise to the reader.

BTW, in the interest of pushing the software I'm writing on more owners   it takes the Rigol 15 seconds to write a PNG file to a USB stick - and then, of course, there's the time needed to transfer the stick to a computer and read the file. It takes the Rigol UltraVision Utilities 2.3 seconds (using USB) to transfer the data to the PC and save it 

Works like a charm.

In addition to it being faster you also get the opportunity to enter a (hopefully meaningful) name for the file as you save it.

Thank you for the work you have put into the application - much appreciated.

Andrew

Copied and pasted from HW thread.

[marmad]

To what purpose? A relational database isn't really appropriate for this sort of data I don't think. Though most database engines I'm familiar with can import CSV fairly easily (Postgres, MySQL and Oracle all can).

I thought of a use for compiled CSV/WFM frame files - and easy to generate in RUU as well: an intensity gradient - which is analogous to a thermal color gradient where high intensity areas are colored red and low intensity areas are colored blue - for example:



It goes on the future feature list 

[Teneyes]

Also, since I have the animated GIF option as a kind of compiled version of the screen images - I'd like to do the same for the CSV output. Does anyone know if you can make a database file that is in CSV format? So it could be opened in Access or another DB program?

I found this and I would work on automating ,with Excel program , we could work on a Functional specs.
 IE , Combine all files with "ABC*.csv" into one Access database using file date & time as a Key.
any other suggestions , Anyone else willing to help?

[larsie]

What do we want to do with the data when it's in a db? As you indicate, putting a csv into Excel/Access should be 'relatively' easy. Is it for graphing, data-manipulation, mathematical functions?

[Teneyes]

Easy to Watch Generator Frequency Drift (copied from other thread)
  While Playing with an Old Generator ,
 I used the DS2072 to scan a 90Mhz signal at 100uS/div and then Zoom to the last part (700usdelay)
 The zoom was set to 5.0ns 20,000x zoom to see the waveform drifting left and right
I use a bit of holdoff to to get a smooth drifting
and set interval to get a regular sweeping.
As you can see after a delay at about 700us the signal is drifting 10ns.
The stats show 89.28-90.91 Mhz , ( yes 70Mhz scope is still good for this test)
Now I used Marmad's RUU to capture frames,
I chose "Open Record" so I could stop at the highest frequency, most drift to the left, then did RUU "Stop"
With RUU in "Play mode", I changed the Start Frame  and and could easily see frame 24 was best frame to start a Loop
I saved the Animated .GIF below
Very Easy, and simple to document tests 10 minutes . and 3 mintues was the RUU saving Data (see time clock on the frames , bottom right
Thanks again marmad, Great Tool already

[marmad]

Uploaded new version of the RUU software. Two bug fixes, one enhanced feature (#1), and two new features (#2, #3 - although #3 is not fully implemented yet). Some explanation here and all of the details in the first post.

#1: When in Play mode (paused or stopped), the Up/Down Arrow keys on the computer keyboard will now jog the DSO forward/backward a frame.

#2: An auto-name/save feature has been added - allowing even faster screen grabs to the PC (a single click), as well as auto-saving after recording a set amount of frames (determined by the Record End Frame setting) - with automatic repeat - if the Loop box is checked.

#3: The ability to add markers while in Zoom (Delayed Sweep) Mode is now enabled. There are still two main unimplemented portions of this feature (as explained below) but since I'm currently travelling and won't be able to do any further development while away from the DSO for the next 2.5 weeks (except perhaps minor bug fixes), I thought I'd release it as 'beta' for now - and see if bugs/problems are discovered.

The two unfinished sub-portions of this feature are:

a) The real-time display of the waveform on the PC screen while moving around in Zoom Mode. I'm still working on this, so although you can drop markers and jump back and forth between them, you currently still need to do the actual examining of the waveform on the DSO screen. Eventually the zoomed waveform (as well as all of the parameters, such as main and zoomed scale settings, etc) will be updated continuously in RUU's window.

Also, because of the IDLE memory read bug in FW 01.00.05 which inhibits SCPI deep memory reads, I have to reproduce the image of the main timebase (i.e. the entire waveform sample) by using a portion from a captured bitmap image of the screen - so it's not possible to refresh that element at a usable speed (until the IDLE problem is resolved). As of this version, the only screen elements being updated continuously are the zoom window (the blue bars) and the markers themselves.

b) The other feature to be added later, also once the IDLE bug has been fixed (or a workaround is found), is a Store/Load Sample & Search function, which will allow you to either store a sample of the waveform currently displayed - or load a sample from a previously saved CSV/WFM file (or one created with AWG software) - and then search through the entire current DSO memory for occurrences.

[EV]

OK, RUU v.1.5 starts now and looks to work correctly. The animated gif is gray, but I have not read the instructions yet. Maybe I must do something to use it and I did not find it.

Thanks Marmad!

[EV]

Animated gif works.

[marmad]

OK, RUU v.1.5 starts now and looks to work correctly.

I'm happy to hear that, EV    Let me know what you think of it - or if you have any feature suggestions.

[EV]

Let me know what you think of it - or if you have any feature suggestions.

I have problems with "Zoom Markerrs". If I click it I get a window as in the picture. If I click "Continue", nothing works there. Maybe I am doing something wrong?

Google translation from the window:

Unhandled exception in the application. If you click Continue, the application will ignore the error and attempt to continue operations. If you select Quit, the application will close immediately.

The conversion from a string 5.000000e-04 to Double is not valid.

[marmad]

I have problems with "Zoom Markerrs". If I click it I get a window as in the picture. If I click "Continue", nothing works there. Maybe I am doing something wrong?

Thanks for the bug report. I'm sure you don't do anything wrong - it's certainly my software 

I have to say, I am a little lazy with type conversions - I just expect the software to handle them fluently. And VB.NET is kind of a pain since it doesn't generate these exceptions while I'm testing - but seems to have problems later based on individual computer settings.

Anyway, it's a little complicated right now since I can't test changes (I'm thousands of kms from the DSO) - but I'll see if I can find the problem and post a bug-fix for you soon.

[jahonen]

Maybe you could change your windows regional settings so that decimal separator is comma "," to see if the problem shows up to speed up testing? I have found out that there exists plethora of software which also stumbles on this. I have no Rigol scope but just a thought.

Regards,
Janne

[marmad]

Maybe you could change your windows regional settings so that decimal separator is comma "," to see if the problem shows up to speed up testing? I have found out that there exists plethora of software which also stumbles on this. I have no Rigol scope but just a thought.

That's likely the problem - as it was with an earlier version of RUU. I thought I had made certain that all of the Type Conversions were Culture Invariant - but I think I must have missed one when adding the new Zoom Marker utility.

[EV]

That's likely the problem - as it was with an earlier version of RUU.

That is the problem. I changed decimal comma to decimal point in Windows, and there is no error message.

Thanks to Jahonen!

[marmad]

That is the problem. I changed decimal comma to decimal point in Windows, and there is no error message.

Good to know for certain! Now I just have to track down the place in the software where I forgot to use CultureInvariant during a type conversion - so that the decimal setting will make no difference.

[Chalky]

Marmad, sounds like you need to get your 'option strict' enabled or specified at top of your VB file.  It will improve your life.  Cheers.

[marmad]

Marmad, sounds like you need to get your 'option strict' enabled or specified at top of your VB file.  It will improve your life.  Cheers.

Thanks - I'll give that a go. Being a hardcore assembly-language programmer for the last 35 years, I just muddle through at the high-level