That was the main reason I started writing my software = so that you could save all of the data from the frames (but, of course, I can't force the Rigol to reload it). As of now, my software can save frames as images, animated GIFs, CSVs (and WFM is coming soon) - but because of another serious bug I posted about a couple of days ago (which no one else has yet confirmed), you can only read display memory from the scope - not the entire sample length - so the CSV and WFM files are currently limited to 1.4kPts each.
Okay, I gave it a shot and I can confirm this doesn't work correctly. I set the memory depth to 5.60k points (:ACQuire:MDEPth? returns 5600) and then acquire some data and then run each of the SCPI commands from Ultra Sigma.
When I send the :WAV:STATus? it returns IDLE, 1400 to say the read operation is idle and there are 1.4k points to read. When running the next command (:WAV:DATA?) it returns #9000000000 which seems bogus (last 4 zeros indicate no data). On a fifth execution of this command, it returned #9000001400xxxx.... which indicates it is sending 1400 points, and the xxxx's are the data. Then I run :WAV:STATus? again and it indicates IDLE, 1400 so I try and read another 1.4k points with :WAV:DATA? but system returns #9000000000 again...and after a few attempts it succeeds and sends #90000014007xxxxx again. So, even on second, third or forth attempts to read data, when it eventually does send data, it seems to be sending the exact same first segment of data as was returned from the beginning, rather than the
next 1400 points of data.
So, does not seem to be working correctly, even for small memory depth (5.6k points) when trying to read 1400 points at a time.
EXTRA INFO: I should add that even when doing the step :WAV:MODE RAW to set the waveform to RAW mode, :WAVeform:POINts? still returns 1400, which is the normal maximum number of points to read. That is, the number of points to read doesn't automatically update to the maximum possible allowed in RAW mode. Thus, in a second test, I subsequently send :WAVeform:POINts 5600 to set the number of read points to 5600, and WAV:STATus? now returns IDLE, 5600. Then, after a bunch of failed :WAV:DATA? it eventually succeed and returns all 5600 data points. So, this seemed to work fine (despite initial fails to read data).
I then did another test, with memory depth 280k points. :WAV:STATus? returns IDLE, 280000. And, on second attempt at read, :WAV:DATA? succeeds and this time returns 126948 data points, and not the full 280k points asked for.
I then tried the MATLAB programming example in the DS2000 series programming guide, and that fails also. The request for data ([data,len]= fread( ds2000, 2048 )
times out before the operation completes. This happens even when the input buffer size is 1400 points.
This is possibly the worst bug so far --- no ability to read out the complete memory to PC for further analysis. Really hoping this bug can be fixed!
Has this one been forwarded to our friend
drieg?
Edit note: Since my original post, I read a bit more about setting the number of waveform points to read, and so I subsequently performed additional tests and included results above.