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

[AndersAnd]

Is there no support for DS1000Z scopes?

Marmad answered this question just 2 weeks ago: https://www.eevblog.com/forum/projects/software-tips-and-tricks-for-rigol-ds200040006000-ultravision-dsos/msg388703/#msg388703

[MatCat]

Is there no support for DS1000Z scopes?

Marmad answered this question just 2 weeks ago: https://www.eevblog.com/forum/projects/software-tips-and-tricks-for-rigol-ds200040006000-ultravision-dsos/msg388703/#msg388703

And now it got answered again just yesterday .

[MatCat]

I was going to go ahead and work on adding DS1000Z support but then I noticed I can't find source anywhere, is this not open source?

[mrflibble]

I was going to go ahead and work on adding DS1000Z support but then I noticed I can't find source anywhere, is this not open source?

I'm not 100% (can't find the post right now on this subject), but I recall Marmad saying he's not releasing the source. Or at least for now. Or something.  Probably best to send him a PM.

[MatCat]

I was going to go ahead and work on adding DS1000Z support but then I noticed I can't find source anywhere, is this not open source?

I'm not 100% (can't find the post right now on this subject), but I recall Marmad saying he's not releasing the source. Or at least for now. Or something.  Probably best to send him a PM.

I may do that... was a bugger but I got it working so I can communicate with my DS1074Z-S just fine (Using Visual Studio 2013 and the newest 5.4 version of the VISA drivers). 

[cybermaus]

I think Marmad mentioned he was already working on the DS1000Z, so much of what you would do is probably already in his alfa/beta code.

However, if you have a development environment setup: Could you make a (command line) utility that emulates sweep on the signal gen for the DS1000Z-S (and probably also the other Rigol -S ranges) by rapidly sending SCPI :SOUR:FREQ commands?

[mrflibble]

However, if you have a development environment setup: Could you make a (command line) utility that emulates sweep on the signal gen for the DS1000Z-S (and probably also the other Rigol -S ranges) by rapidly sending SCPI :SOUR:FREQ commands?

You might not need to emulate that, depending on the sweep range you're after. You can do an FM modulation with a ramp as the modulation source.

[cybermaus]

I actually tried that a while ago.
Can't remember what it was, but I could not get it to work, I think the ramp frequency was out of range or something, or FM would not go low enough. Something like that.

[Rigby]

I got it working so I can communicate with my DS1074Z-S just fine (Using Visual Studio 2013 and the newest 5.4 version of the VISA drivers).

Source available?  Not to co-opt your efforts, I just want to tinker a bit.

[MatCat]

I got it working so I can communicate with my DS1074Z-S just fine (Using Visual Studio 2013 and the newest 5.4 version of the VISA drivers).

Source available?  Not to co-opt your efforts, I just want to tinker a bit.

I don't have much in the way of source yet, all I have is a basic concept that lets you send and receive data, and display a waveform on chart, the trick to getting a .net project to work properly with the current VISA drivers (The 5.4 version) is to set your app.config as follows:

Code: [Select]

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
  </startup>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="NationalInstruments.Common" publicKeyToken="DC6AD606294FC298" culture="neutral"/>
        <bindingRedirect oldVersion="13.0.40.188" newVersion="13.0.40.190"/>
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

From there all other source examples out there work just fine, I.E. Here is a snippet to read IDN:

Code: [Select]

try
            {
                mbSession = (MessageBasedSession)ResourceManager.GetLocalManager().Open("your visa address");
            }
            catch
            {
                MessageBox.Show("Problem Opening Device");
            }
            string strWrite = "*IDN?";
            mbSession.Write(strWrite);
            string strRead = null;
            strRead = mbSession.ReadString();
            MessageBox.Show(strRead);
            mbSession.Dispose();


[MatCat]

Now one odd thing I discovered is that on-screen waveform data either does not come back correctly, or there is some odd signing thing with the data because anything above the center graticule gets screwed up on the return data, quite weird.

[mrflibble]

Now one odd thing I discovered is that on-screen waveform data either does not come back correctly, or there is some odd signing thing with the data because anything above the center graticule gets screwed up on the return data, quite weird.

2's complement? Subtract centerpoint value? Usually some silly combination of those two.

[MatCat]

Instead of byte data just using scientific notation data works a treat.

[Rigby]

I was able to get the byte data this way:

Code: [Select]

using Ivi.Visa.Interop;

...

namespace ConsoleApplication1 {
    class Program {
        static void Main(string[] args) {

            String dutAddr = "TCPIP::192.168.0.75::INSTR";
           
            ResourceManager rm = new ResourceManager();
            FormattedIO488 device = new FormattedIO488();

            device.IO = (IMessage)rm.Open(dutAddr, AccessMode.NO_LOCK, 2000, "");
            device.IO.Timeout = 3000;

            device.WriteString(":WAV:SOUR CHAN1");
            device.WriteString(":WAVeform:MODE MAX");
            device.WriteString(":WAVeform:FORMat BYTE");
            device.WriteString(":WAV:DATA?");

            System.Threading.Thread.Sleep(100);

            byte[] header = device.IO.Read(11);
            Int32 dataCount = Int32.Parse(System.Text.Encoding.ASCII.GetString(header).Substring(2));

            byte[] values = device.IO.Read(dataCount);

            foreach (byte val in values) {
                Console.WriteLine(val);
            }
               
            device.IO.Close();
        }
    }
}


[Rigby]

I think Marmad mentioned he was already working on the DS1000Z, so much of what you would do is probably already in his alfa/beta code.

However, if you have a development environment setup: Could you make a (command line) utility that emulates sweep on the signal gen for the DS1000Z-S (and probably also the other Rigol -S ranges) by rapidly sending SCPI :SOUR:FREQ commands?

Yes.  I worked on something like this last night.  I have never used a proper digital signal generator so I don't know how well emulating the sweep compares, but I was able to sweep in both frequency and amplitude full scale.

[cybermaus]

Nice!

[Rigby]

the responsiveness of the scope depends on how fast you can feed it commands and how fast it can interpret them and change configuration to suit.  I don't know how many steps a proper signal generator would use to go from one frequency to another in one second, but I'm betting that the way I did it last night uses fewer coarser steps to make it happen.

I did my work last night over TCP/IP, today I'll try over USB to see if the performance is better.  Last night I was easily able to load the command queue in the scope and watch it continue to process commands well after my app had finished sending all those commands.  Several seconds between the time my app finished sending and the time my scope finally worked through the command queue. 

Maybe USB will be better.

[marmad]

Maybe USB will be better.

As mentioned in the very first post in this thread, USB communication is approx. 2.5x faster (or ~40%) - unless the DS1000Z is much different than the DS2000 (which I doubt).

[Rigby]

Yeah faster is one thing, but the scope still has to process all the commands and act on them.

In this regard it performs the same as it does over TCP/IP.  This means it takes longer for the scope to act on a command than it takes to receive it, for the commands I'm sending.  That in and of itself isn't good or bad, but it limits the number of steps the function gen can make in a single second, which puts a hard limit on the granularity of the sweep.

[cybermaus]

Soooo..getting to several sweeps a second is out, more like several seconds to a sweep, and a fairly "blocky" sweep too.
Ok, Guess i need to make due with what I have, and if I really need it for some future project, I should buy a real signal gen.

Thanks for testing anyway.

[Rigby]

Soooo..getting to several sweeps a second is out, more like several seconds to a sweep, and a fairly "blocky" sweep too.
Ok, Guess i need to make due with what I have, and if I really need it for some future project, I should buy a real signal gen.

Thanks for testing anyway.

Several sweeps per second is definitely possible, but they'll be very, very granular.  I can make about 30-40 changes to the waveform per second.  This is due to the ~25-30ms time it takes for the scope to process the command and actually make the change to the waveform.

[cybermaus]

Well, I'll take anything you can make, whatever specs it has.

I could have used it a few weeks ago, right now not so much, but hey, if you can make a nice little utility I'll just put it in the tool drawer. You can never have enough tools 

[MatCat]

I built a little program to sweep from 1Hz to 25MHz, takes about 5 minutes, program just sets frequency, reads max voltage to calculate bode plot for an LC Filter project of mine.  I found that you can get an average of about 10 calls a second, not fantastic but good enough.

[Rigby]

Well, I'll take anything you can make, whatever specs it has.

Ok, I'll put something together and let you know when it is ready.

[bennybubble]

Hi Marmad,

Since you are not planning to release the source (yet), are you willing to incorporate a DSA815 into the software?
It would be nice to store waterfall diagrams of a frequency domain unit.
I think you would make a lot of people happy with that!

-ben