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

[marmad]

looking more like pixels, Display shows my patch write of of large block with Hex '11'

Ok, thanks! It's looking more and more like the file types which the Rigol saves are perhaps not equivalent to the display memory data it sends over USB/LAN. I'll have to experiment more with that later.

[Teneyes]

the file types which the Rigol saves are perhaps not equivalent to the display memory data it sends over USB/LAN.

@Marmad,   
 Looking at the wfm data , which is scales, starts and intervals in time and voltage ,
then at the end is the 8 bit data for each point

I am thinking that maybe the format USB gets,
 is a bunch of parmeters and then all the 8bit for the memory Pts. 
The wfm files has a big Block before the data block 140 pnts of data (5nS.div)
Is there any way I can get the USB Data,  , does rigread save any data ?
If Rigread is reading the data, I'll try to sniff it out.

[Teneyes]

I'll try to sniff it out.

@marmad
I sniffed the USB data, when your Rigol Read Memory program was reading140 points , from DSO set at 5nS/div and just single shot , zero line displayed

Is this the data what you wish to know the format of??
I think there are 3 messages and I show by colours

02 14 eb 00 04 00 00 00 01 00 00 00 31 34 30 0a
02 1b e4 00 09 00 00 00 01 00 00 00 49 44 4c 45
2c 31 34 30 0a 7f 02 1d e2 00 98 00 00 00 01 00
00 00 23 39 30 30 30 30 30 30 31 34 30 7f 81 80
80 7f 80 80 80 7f 80 80 7f 7f 80 80 7f 7f 80 7f
7f 7f 80 80 7f 7f 80 80 80 7f 80 80 7f 7f 80 7f
7f 7f 80 7f 7f 80 81 80 80 7f 80 7f 80 7f 80 7f
7f 7f 80 80 80 7f 80 80 80 7f 80 80 80 7f 80 80
80 80 81 80 80 7e 80 7f 7f 7f 80 80 7f 7e 80 7f
7f 7f 80 7f 7f 7f 80 80 80 7f 80 7f 7f 7f 80 7f
7f 7f 81 80 7f 7f 80 80 7f 7f 80 7f 7f 7f 80 80
7f 7f 80 7f 7f 7f 80 7f 7f 7f 80 80 7f 7f 80 7f
7f 7f 80 7f 7f 7f 80 7f 7f 0a

I then shifted the vertical position up 2 divisions and read this

02 22 dd 00 04 00 00 00 01 00 00 00 31 34 30 0a
02 29 d6 00 09 00 00 00 01 00 00 00 49 44 4c 45
2c 31 34 30 0a 34 02 2b d4 00 98 00 00 00 01 00
00 00 23 39 30 30 30 30 30 30 31 34 30 af b0 b0
b0 af af af b0 ae af af b0 ae af af b0 af af af
af af af af b0 af af af af ae af ae af af af af
b0 af af af b0 af af af af af af af af ae af af
af ae af af b0 ae af af af af af b0 b0 ae af b0
b0 af af af b0 af af af af ae af af b0 af af af
af ae af b0 b0 af af af b0 af af af af ae af af
b0 af af af b0 af af af b0 ae af af b0 ae af af
b0 af af af b0 af af af b0 af af af af af af af
b0 af af b0 b0 af af af b0 0a

This kinda shows this is 8 bit data of screen at the end of the message.
But as with CSV first bytes are probably parmeters for the data
My guess  offset, scale , time interval......
looks like just before the data is 140 ASCII

Is this the memory data you wanted??

[Teneyes]

Memory read for both channels , with ch1 center and ch2 down 2 div

02 75 8a 00 03 00 00 00 01 00 00 00 37 30 0a 30
02 7c 83 00 08 00 00 00 01 00 00 00 49 44 4c 45
2c 37 30 0a 02 7e 81 00 52 00 00 00 01 00 00 00
23 39 30 30 30 30 30 30 30 37 30 7f 80 7f 7f 7f
80 7f 7f 7f 80 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f
80 7f 7f 7f 7f 7f 7f 7f 7f 7f 80 7f 80 7e 80 7f
7f 7f 80 7f 7f 7f 80 7f 80 7f 80 7f 7f 7f 80 7f
80 7f 7f 7f 80 7f 7f 7f 80 80 80 7f 80 7f 7f 7f
80 0a 02 04 fb 00 03 00 00 00 01 00 00 00 37 30
0a 30 02 0b f4 00 08 00 00 00 01 00 00 00 49 44
4c 45 2c 37 30 0a 02 0d f2 00 52 00 00 00 01 00
00 00 23 39 30 30 30 30 30 30 30 37 30 4b 4a 4a
49 4a 49 4b 49 4a 4a 4b 4a 4a 4a 4b 49 4b 4a 4b
4a 4b 4a 4b 4a 4b 4a 4b 49 4a 49 4b 4a 4b 4a 4b
4a 4a 49 4a 4a 4b 4a 4b 4a 4b 4a 4b 4a 4b 49 4b
49 4b 4a 4b 4a 4b 4a 4a 4a 4b 49 4b 49 4b 4a 4b
49 4a 4a 0a

[marmad]

I am thinking that maybe the format USB gets,
 is a bunch of parmeters and then all the 8bit for the memory Pts. 

No, only an 11 byte header at the beginning of the block - and a single byte for the end of block: 1412 bytes in total. From the Rigol Programming Guide:

"The data returned contains 2 parts: the TMC data description header and the waveform data: #900000ddddXXXX... Wherein, dddd denotes the number of the effective waveform points in the data stream.
When reading the internal memory data, the waveform data returned each time might be the data block in one area of the buffer. Each data block has a TMC description header similar to #9XXXXXXXXX, wherein XXXXXXXXX denotes the number of the waveform points in this data block. Waveform data in two adjacent data blocks are consecutive. The waveform data read can be converted to the voltage of each point of the waveform on the screen according to the method below.
The figure below shows the waveform data read. First, select "View as hexadecimal only" from the dropdown list at the right of Buffer; at this point, the waveform data read is displayed in hexadecimal format; the first 11 figures denote the number of bytes that the "Denoter" holds in the internal memory; the figures following are the waveform data on the screen and users can convert the waveform data read to the voltage of each point of the waveform on the screen using the formula (ox63 - vertical reference position in Y direction) × VerticalScale-OFFSet. For the vertical reference position in Y direction, refer to the :WAVeform:YREFerence? command, for the VerticalScale, refer to the :CHANnel<n>:SCALe command and for the OFFSet, refer to the:CHANNel<n>:OFFSet command."

All I was trying to figure out was why 1400 bytes per channel - instead of 700 (as per pixels on screen). Perhaps they representing line segments from point a to point b?

BTW, you can easily test and see the data using Rigol's UltraSigma and sending the following SCPI commands to the scope:
:WAV:SOURce CHAN1
:WAV:MODE NORM
:WAV:DATA?
Use tab to view response to last query, go to 'Advanced mode' and view as hexadecimal.

[Teneyes]

DS2072  1.00.02
Ok, Now on to normal read, chan 1


02 73 8c 00 52 00 00 00 01 00 00 00 23 39 30 30
30 30 30 30 30 37 30 b2 b2 b2 b2 b2 b2 b2 b2 b2
b2 b3 b2 b3 b3 b3 b3 b3 b4 b3 b4 b3 b3 b3 b3 b2
b2 b2 b3 b2 b2 b3 b2 b2 b3 b2 b3 b3 b3 b3 b3 b3
b3 b3 b3 b2 b3 b2 b3 b2 b3 b2 b3 b2 b2 b2 b3 b3
b3 b3 b3 b4 b3 b3 b3 b3 b2 b3 b2 b2 b3 0a

I only get 70 bytes on a normal read??

Chan 2 normal read

02 7d 82 00 52 00 00 00 01 00 00 00 23 39 30 30
30 30 30 30 30 37 30 50 50 50 50 50 50 50 50 50
50 50 50 50 50 50 50 50 4f 50 4f 4f 50 4f 50 50
50 50 50 50 51 50 51 50 50 50 50 50 51 51 50 50
51 50 50 50 50 50 51 51 50 50 50 50 50 4f 50 4f
50 4f 50 4f 50 50 50 50 50 50 50 50 50 0a

[Teneyes]

reading ch1 norm
 but DSO  on 10nS , should be 140 data points
I did a Max read and got 140 data points
so  I did a norm read and then got the read only got 140 points

02 1b e4 00 98 00 00 00 01 00 00 00 23 39 30 30
30 30 30 30 31 34 30 b3 b3 b3 b3 b3 b2 b3 b3 b3
b4 b3 b3 b3 b3 b3 b2 b2 b3 b2 b2 b2 b3 b3 b2 b3
b2 b3 b3 b3 b3 b3 b3 b3 b3 b3 b2 b2 b3 b2 b3 b2
b3 b3 b2 b3 b2 b3 b3 b3 b3 b3 b3 b3 b3 b3 b2 b2
b3 b2 b3 b2 b3 b3 b2 b3 b2 b3 b3 b3 b3 b3 b3 b3
b3 b3 b2 b2 b3 b2 b3 b2 b2 b3 b2 b2 b3 b3 b3 b3
b3 b3 b4 b3 b3 b3 b2 b3 b2 b2 b3 b2 b2 b2 b2 b2
b2 b2 b2 b2 b2 b2 b2 b2 b2 b2 b2 b2 b2 b2 b2 b2
b3 b3 b3 b3 b2 b3 b3 b3 b4 b3 b3 b3 b3 b3 b2 b2
b3 b2 b2 0a

[Teneyes]

Testing Normal read
with DSO set for 200nS and 2800 Pts

here is start portion of a Max read and get 2800 byte data
Note Max read puts DSO out of auto into Stop
Stopping the DSO is reasonable if , need to capture /and transfer a big Data block

02 59 a6 00 f4 01 00 00 00 00 00 00 23 39 30 30
30 30 30 32 38 30 30 42 43 42 42 42 43 43 43 42
43 43 43 43 44 43 44 44 44 44 44 44 44 44 44 44
45 44 45 45 44 45 45 45 45 45 45 45 46 45 46 46
46 46 46 45 46 46 46 46 47 46 47 47 47 47 47 47
47 48 47 47 48 47 48 48 48 48 48 48 48 48 48 48
48 49 48 48 49 49 49 49 4a 49 49 49 49 49 4a 4a
4a 4a 4a 4a 4a 4a 4a 4a 4a 4a 4b 4a 4b 4b 4b 4b
4b 4b 4b 4a 4b 4b 4b 4b 4c 4c 4c 4c 4c 4c 4c 4c
4d 4b 4d 4c 4d 4c 4c 4c 4d 4d 4d 4d 4d 4d 4d 4d
4d 4d 4e 4e 4d 4e 4e 4e

Then doing a Normal read , only get 1400 Bytes
But seems to be interpolated from the 2800 pts
 
here is start portion of normal Read and get 1400 byte data

02 60 9f 00 f4 01 00 00 00 00 00 00 23 39 30 30
30 30 30 31 34 30 30 42 43 42 43 42 43 42 43 42
44 43 45 43 44 44 45 44 45 44 45 45 44 45 46 46
46 46 46 46 47 46 47 47 47 47 48 48 48 48 48 48
49 48 49 4a 48 49 49 49 4a 4a 4a 4a 4a 4a 4a 4b
4c 4b 4c 4b 4c 4c 4c 4c 4d 4c 4d 4d 4e 4d 4d 4d
4d 4e 4e 4e 4f 4e 4f 4e 4f 4f 4e 50 4f 50 4f 50
51 50 51 51 51 51 52 51 52 52 51 52 53 51 52 52
53 53 53 53

Note the red data point in the 2800 block is Hex "4C" after 128 bytes
but   the red data point in the 1400 block is Hex "4C" after   64 bytes
2800 bytes seems to be compressed down to 1400 bytes
I wonder if the 1400 pts and the average of Multiple scans or a snapshot??

Norm read would not read any more than 1400,  DSO set to 7000 pts

[marmad]

I wonder if the 1400 pts and the average of Multiple scans or a snapshot??

Norm read would not read any more than 1400,  DSO set to 7000 pts

The Programming Guide states:
NORMal : return the number of waveform points currently displayed (1 - 1400)
MAXimum : return the maximum number of effective data points under the current state. Return the number of data points displayed on the screen when the instrument is in run state and the number of data points in the internal memory in stop state.
RAW : It is only available when the instrument is in stop state. You can use the :WAVeform:POINts command to set the desired number of data points in the internal memory.

[zlabsoft]

I just got my DS2102, which hardware version is 1.0 software version 0.0.0.1, then I download the firmware version 1.0.0.5 from the board and then try the boot installation as told.  I press the power button and then "help", it light up with only the "SINGLE" button.  I insert the USB drive which contain the update file "DS2000Update.GEL" in the root directory. The "ch1" flash for a while then a lot of buttons light up and stay that way ... seen last forever as captured screen.  I re-power up the scope after half an hour and try the utility update method to update the firmware, it seen work and the it reboot itself, O.. all option is gone!  I don't want them anyway. It read the USB drive again and detect the "same version 1.0.0.5", it seen work but actually it doesn't, the system Info still report 0.0.0.1 and of course the X-Y bug does not fix. Does anyone kind enough to give me a hand?

[marmad]

The "ch1" flash for a while then a lot of buttons light up and stay that way ... seen last forever as captured screen.

You had already updated your firmware after this. If you had just re-booted here - you would still have your options

...and try the utility update method to update the firmware

This is when you lost your options.

Read the bottom of this post to find out how to see your real firmware version.

[zlabsoft]

Thanks, I try the boot installation again several time, with the special method and show software version 1.0.0.5 finally.  The utility, system, system info still show 0.0.0.1.

[marmad]

I start the scope as usual, the utiliity, system, info still show the software version 0.0.0.1, X-Y bug still here. Do I have to upgrade to 1.0.0.2 then 1.0.0.5? please give me a link to 1.0.0.2.

1) You're not reading the post which I linked to. There is no FW 0.0.0.1 - you're not seeing your full FW number. Go back to this post (https://www.eevblog.com/forum/reviews/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158659/#msg158659), scroll to the bottom, and read the section titled:

To get detailed version info about the DSO, follow these instructions:

2) X-Y bug is present in EVERY firmware - including FW 01.00.02 and 01.00.05.

3) In the future, please post hardware/firmware problems, etc. in this thread:
https://www.eevblog.com/forum/reviews/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso

This thread was started for user-software and tips for the Rigol UltraVision DSOs. Thanks!

[zlabsoft]

Got it, thanks anyway, I just though that the update is as easy as show in video "EEVblog #369 - Rigol DS2000 Oscilloscope Playing Around"

[marmad]

A small program (requested) you can use which runs in background and checks every XX seconds for BUS options. If it finds them, it beeps PC and displays message box with date and time.

[Teneyes]

A small program (requested) you can use which runs in background and checks every XX seconds for BUS options.

  Thanks MArmad, works just right
  And remember to have Visa DLLs with RTO

[EV]

A small program (requested) you can use which runs in background and checks every XX seconds for BUS options. If it finds them, it beeps PC and displays message box with date and time.

No problems here either!

[Salas]

Thanks to Marmad for RUU from here too. Works and grabs .png screens alright. Here is one I saved with signal from the Instek Arb gen.

[marmad]

Uploaded a huge major new version of the RUU software (2.0). There is so much changed - and so many new features - that there is too much to describe in detail. But here are some notes (and images) to start with (and I'll respond to any questions as/if needed).

RUU auto-scrolling in Zoom mode - using 10 division full ADC graphing plus 1s persistence:



#1: RUU is now a standalone program - running without the DSO connected. That means you MUST press the 'Connect' button if you want to communicate with the DSO (you can also press it again to disconnect). The reason for this is because RUU can now load previously saved Frame Arrays (there are two sample .fra files in the Data [now the default directory instead of 'Images'] directory to play with). These files can be played back in RUU just like playing back recorded frames on the Rigol - but with added features that the Rigol doesn't have - such as plotting the frames as either 3D, 2D, or intensity bitmap images. There are many many settings for the Frame Arrays - with a non-modal window devoted to them. Play around with these and ask questions as needed.

Frame array settings window:


One setting which requires a bit more explanation is the 'Z Scale: Frame #' vs. 'Frame Time' choice. As mentioned in this post here, the Rigol doesn't allow you to easily recognize the time difference between frames when playing them back on the DSO. When you select 'Frame #', all plotting and playing back is done based solely on the frame number (i.e. equidistant divisions between frames). But selecting 'Frame Time' means that the division will be based on the real time difference (from the time tag) between adjacent frames. This setting affects both, plotting, playing back, and even the delay times per frame when creating animated GiFs of the frame array. You can play around with the sample 'glitch.fra' file included to see the effect.

2D plot of glitch using 'Frame #' (equidistant) setting:


2D plot of glitch using 'Frame Time' setting:


Normally, the '@ XX ms' box in RUU sets the playback speed for frame arrays - the fastest possible setting is 15ms - or about 65 FPS. When you use the 'Z Scale: Frame Time' setting in the Frame Array Settings window, the '@' symbol will change to 'Zx', and RUU will play all frames scaled from the 'XX ms' setting as the minimum. So if you have it set to 15ms - and a 40us frame is the fastest frame time in your frame array, then it will play at 15ms - but a 100us frame will play at 37.5ms (2.5 x 15ms).

Keep in mind - since you can now be playing back frames or saving files from either the DSO or RUU itself - you MUST choose which you are targeting with the 'DSO / FrA' radio buttons - you'll notice that the title of the Play and Save groupboxes will reflect which is currently active. For example, if you just made a plot which is gorgeous and you want to save it - make sure 'FrA' is selected before choosing 'Display' -> 'Bitmap' -> and 'Save'.

2D and 3D plots are rather self-explanatory, with the following note: when doing 3D plots I do NOT extrapolate data - if it exists, I plot it - otherwise it's empty space. For best results, use at least 350 frames for 3D plots - even more if you want more detail. Also, to create the 3D plot at the normal 1x scale, the 700x400 waveform bitmap is mapped to a 350x200 cube. This can result in a loss of data because of scaling (see images) - so the best 3D plots will be achieved when you use a larger display scale (as mentioned below) then let RUU auto-scale to 800p afterwards if you want to save the resulting bitmap.

Square wave with missing portions because of waveform scaling:


Square wave re-plotted at higher-res, than scaled down after:


Note: the 'Start Frame' and 'End Frame' boxes in the Play groupbox set the span of frames which will be plotted (when FrA is checked).

For intensity bitmaps, a map is created just one time for a given frame array (unless you change the window scale or number of vertical divisions as mentioned below) - with a count of pixel crossings for every point at the current display scale. Once the map is created, subsequent changes to color, transparency, etc, are almost instantaneous - in fact, if you use the Z offset sliders, you can alter the map color/transparency real-time without needing to re-click 'Plot'.

3D plot of sweep:


2D plot of the same sweep:


Intensity bitmap of the same sweep:


You load .fra files from the Frame Array window - and you can also load the CLUTs (Color Lookup Tables - Photoshop standard .act file) there - select .ACT from the file type pull-down menu - which can be used for generating the plots. The default CLUT is named 'color_lookup_table.act' and MUST reside in the Data directory - it's loaded by RUU at startup. It's a false color table with white as both 00 and FFh - to denote clipping of the ADC (see image). There is also another sample CLUT to play around with (black body) - and others can be easily created in Photoshop.

Plotted noise using default CLUT. Note the white dots at the top and bottom where the waveform has clipped the limits:


You'll notice the animated GIF check-box is missing if you used earlier versions of RUU - in it's place is now a check-box called 'Compile' - which indicates saving just one 'compiled' file for a group of frames - as opposed to individual ones.

Currently there are 3 types of 'Compile' saves:

Compiled CSVs = a single CSV file with individual tables for each frame (with frame and time tag entries).
Compiled Bitmaps = an animated GIF of either Rigol screen grabs of frames (DSO checked), or RUU FrA playback (FrA checked).
Compiled FrA =  a compilation file of all the raw display and voltage data from a group of frames. These files are my own creation - and are 2816 bytes per frame + 48 bytes overhead. The speed at which the data for these can be extracted from the Rigol is pretty fast - about 1400 FPM for single channel / 1100 FPM for dual channel - this is currently the fastest method for getting frame data out of the DSO. In later versions of RUU, it will be possible to convert these files to/from CSV and WFM files - and also to edit, stack, and re-save them.

Whenever you save a compiled FrA file, RUU automatically generates a plot of it after saving (using the current plot settings).


#2: The display in RUU has been completely changed; I finally had a chance to sit down and write some real-time display code for the scope. As of now, the only thing I'm updating regularly are the waveforms (and the zoom window and markers in Delayed Sweep), but the next version will add ALL the other screen data (trigger levels, numbers, arrows, etc. that are normally displayed on the Rigol screen). Keep in mind, the speed at which I can update the waveform is wholly dependent on the Rigol - which will NEVER slow itself down or interrupt what it's doing to send data to the PC (I guess Rigol learned their lesson after the DS1000 - which I was able to glitch spectacularly by asking for data too quickly). On my PC, using a USB connection, I'm able to get about 25 FPS with a single channel - about 17 FPS with two channels enabled. Your mileage may vary - check the built-in FPS counter.

Also with the display:

- You can set the color of channel 1 and channel 2 waveform data from the Frame Array Window - just click the color bars and choose a new color.

- There is a persistence slider built into RUU. It works on both the real-time display from the Rigol or playback of FrA files.

- You can click 'Full ADC' and get 10 vertical divisions with almost the entire data set from the ADC (03h - FCh = 250 points scaled, instead of 200) mapped to the display - for real-time display from the Rigol - or playback and plots of FrA data (which saves the data set unlimited).

- You can set the screen to 1x, 1.5x, or 2x scale - so 800x600 (700 w/full ADC), 1200x874 (1024 w/full ADC), or 1600x1114 (1314 w/full ADC). This is especially handy for plotting 3D files as mentioned above. Plotting to higher resolutions and saving to 800p (as mentioned below) will give you the best results.

Screen scale set to 1.5x normal for a 3D plot (this image has been scaled down):


- When running at higher scales than 1x, ALL bitmap saves - either from the Rigol or RUU itself - will be saved at the current screen size - unless you have '@ 800p' checked - which will constrain bitmap saves to 800 pixels wide. So if this is unchecked, screen grabs from the Rigol will be scaled up.

- There is a 'Fill Disp' check-box which makes it easy to snap the RUU window to any monitor. If you drag RUU onto a connected 800 x 600 LCD and click the box, it will fill the full screen without borders - giving a pseudo-SVGA output.

Example of running RUU on a SVGA monitor at 800x600:


- Use 'CLR DISP' to clear plots, bitmaps, etc. back to currently selected DSO or FrA display.


#3: The Zoom Markers Mode has had a major overhaul:

It no longer needs to get a bitmap image from the Rigol for display - and so is much faster entering and exiting.

The Tracking feature is greatly improved - no need to look at the PC screen when using it - just turn the multi-function knob to adjust the cursor and you will see the Rigol's display grid disappear when a marker is ready to be dropped. Then just either keep moving the cursor to the desired position or - if in position - just move the Zoom Window and a marker will be left at the spot you last left the cursor - and the grid will reappear. Rinse and repeat, then just turn off Tracking when done dropping markers. You can use either the Tracking OR Auto-Scroll (mentioned below) - but not both simultaneously.

Clicking the 'Left' markers label, 'Total', or 'Right' are shortcuts which will send the Zoom window respectively to the left, center, and right of the screen.

An Auto-Scroll feature has been added allowing you to start the zoom window scrolling left or right at an adjustable rate, dropping markers as it moves (if desired). Turn on the feature and then use the Left / Right Arrow buttons (or keyboard keys) to stop and start the scroll (and the trackbar to adjust Horizontal window movement). If you want super-smooth scrolling on your Rigol's display (and don't care about updates on the RUU screen), just click 'No Update' and RUU won't refresh itself while scrolling the Zoom window. Smoothest scrolling happens with a stopped DSO - if the Rigol is triggering while in Delayed Sweep, any adjustments will cause it to 'blink' as it refreshes the display. Markers can be dropped using the 'D' (changed from last version's 'S' = Set) or 'Insert' keys on the keyboard (make sure the display has focus) while the Zoom Window scrolls - regardless of whether you have 'No Update' checked or not.


Ok, that's all for now - there's much more I could write - but not enough time. As I mentioned, if there seems to be a desire for more doc, I'll see what I can do. Enjoy AND PLEASE GIVE FEEDBACK 

[scummos]

Hey,

this looks very cool, so many pretty colors -- I love colors!

I think I already asked this once but I forgot -- any chance of getting it on non-windows platforms? What language / framework is it written in? Do you have the source code for download somewhere?

Cheers,
Sven

[marmad]

I think I already asked this once but I forgot -- any chance of getting it on non-windows platforms? What language / framework is it written in? Do you have the source code for download somewhere?

You did ask before and the answers remain the same - no, .NET, and no. I may release the source at some point, but it would be at a later date. As of now, I've put in many many hours of work into this - and some portions of the code may be used in some commercial work.

[dougg]

I think I already asked this once but I forgot -- any chance of getting it on non-windows platforms? What language / framework is it written in? Do you have the source code for download somewhere?

Its VB dot_net! Maybe even MS won't support it soon.

There is mono but I suspect that RUU is several bridges too far for it. I tried another approach: virtual box on Ubuntu 12.10 running VMs for XP and W8. RUU 1.51 failed on both: NI-VISA couldn't find my DS2202. The Rigol USB device was fed through VBox but it obviously wasn't enough. RUU 1.51 did work on W7 native but not particularly well, my DS2202 became unresponsive and remained that way for a while, even after the USB cable was removed. Perhaps I was doing something wrong. Hopefully RUU 2.0 goes better.

[marmad]

RUU 1.51 did work on W7 native but not particularly well, my DS2202 became unresponsive and remained that way for a while, even after the USB cable was removed.

Ha, ha...  so my software was able to influence your Rigol - even when unplugged? Wow, it's even more powerful than I imagined.   It sounds like you're having VISA/connection problems that are unrelated to my software. Have you tested other SCPI-based software on it?

But honestly, you downloaded and tried the FREE software offered here - had problems but didn't bother posting any bug reports or details when it happened - but now come back and whine about it in retrospect - so please DON'T bother downloading and trying my software.

[scummos]

There is mono but I suspect that RUU is several bridges too far for it. I tried another approach: virtual box on Ubuntu 12.10 running VMs for XP and W8. RUU 1.51 failed on both: NI-VISA couldn't find my DS2202. The Rigol USB device was fed through VBox but it obviously wasn't enough.

Nah, it's gonna be a lot of trouble to get that work to a satisfying extent. Looks like we'll have to leave this to the windows people then.
Running peripherials through virtualbox or emulators never worked well, and I doubt it will in near future.

[dougg]

RUU 1.51 did work on W7 native but not particularly well, my DS2202 became unresponsive and remained that way for a while, even after the USB cable was removed.

Ha, ha...  so my software was able to influence your Rigol - even when unplugged? Wow, it's even more powerful than I imagined.   It sounds like you're having VISA/connection problems that are unrelated to my software. Have you tested other SCPI-based software on it?

But honestly, you downloaded and tried the FREE software offered here - had problems but didn't bother posting any bug reports or details when it happened - but now come back and whine about it in retrospect - so please DON'T bother downloading and trying my software.

I saw several strange things including the Rigol USB connection presenting as a FTDI serial device. Hard to imagine that the length or quality of my USB cables caused that. NI-VISA doesn't mention W8 support. Does anyone have RUU working on W8? And are there XP users of RUU? And no I haven't tested other SCPI-based software on it.

So what is the difference between a bug report and a whine? I did my testing yesterday and it was reasonably obvious from the threads on this subject that you were busy working on a new release. Sounds like you have been working too hard on that release