How do I take advantage of the 16M option of the Rigol DG-1022z over LAN?

[Ben321]

I would like to program my DG-1022z over LAN, and set up a large buffer with a very complex waveform, taking advantage of the 16M option (16 million samples are allowed). Yet I can't find any technique that supposedly allows this. Looking in the programming guide. I've looked at both the :DATA:DAC and :DATA:DAC16 commands. However, they only support up to 16 thousand data points each (more specifically, they support up to 16384 points). This is far smaller than the 16M data points allowed with the 16M option that I paid lots of money for (and I hope to get my money's worth out of it).

Now the :DATA:DAC16 command sounds like it should be able to be extended, with multiple uses of the command (using the CON flag for all but the last use, and the END flag for the last use), as long as you don't exceed the 16384 data limit for each time the command  is sent. Theoretically this would let you send it a large amount of data total, well above the normal 16384 limit. However, from experience, it seems that if the total data from all the uses of the command adds up to more than 16384 samples, then the command still fails.

Also, the programming guide doesn't seem to indicate properly what line-end character(s) it's expecting after a command. Does it expect CR, LF, or CR+LF? Also, when used in the context of a data buffer (binary data block it's called in the manual, which has a specific format for sending), after sending the indicated number of bytes, does it expect a line-end character? And when using multiple sends of the :DATA:DAC16 command, does it expect a line-end character only after the last one (the one with the END flag)? Or does it expect a line-end character after each sending of the command? Or (since the data block format already has a way to determine the length of the data to be sent) does it not expect any line-end character after the data is sent?

I can't find anything about that in the programming manual. They leave a lot of important info out, and just seem to expect you to figure it out on your own, by experimenting with different syntaxes until it just works. I hope somebody here who's got experience with controlling this function generator over LAN, while it's equipped with the 16M option, will comment here, and let me know exactly how to format the commands for sending it the data in large amounts that takes advantage of the 16M option.

[Kean]

There is example code and some extra tips posted on the Rigol support site

https://rigol.my.site.com/support/s/article/creating-long-arbitrary-waveforms-with-python-and-a-dg1000z

[Ben321]

Are you aware if the commands that send data via the data block format for the Rigol DG-1022z require a CR and/or LF character after the end of the data block? Or should the command just end immediately after the last byte of the data block? I can't find this info in the official Rigol DG-1022z programming guide. Is anybody here either a Rigol employee, or otherwise have experience in this topic? If so, please reply.

[Kean]

Are you aware if the commands that send data via the data block format for the Rigol DG-1022z require a CR and/or LF character after the end of the data block? Or should the command just end immediately after the last byte of the data block?

I personally have no experience with it, but it isn't that hard to find a conclusive answer.

If you read the above linked support article and the example, it states the following

Here is the end of the first buffer (note the 0D 0A bytes that end the entire transmission)

And if you look at the source code for pyvisa, the write_binary_values function declaration has this comment

Write a string message to the device followed by values in binary format.

The write_termination is always appended to it.

[Ben321]

Are you aware if the commands that send data via the data block format for the Rigol DG-1022z require a CR and/or LF character after the end of the data block? Or should the command just end immediately after the last byte of the data block?

I personally have no experience with it, but it isn't that hard to find a conclusive answer.

If you read the above linked support article and the example, it states the following

Here is the end of the first buffer (note the 0D 0A bytes that end the entire transmission)

And if you look at the source code for pyvisa, the write_binary_values function declaration has this comment

Write a string message to the device followed by values in binary format.

The write_termination is always appended to it.

There also seems to be a required delay after sending a buffer. I found myself when writing my own software to do this, that each command you send for sending a buffer (actually a partial buffer of the much longer actual buffer) requires a wait time for the device to process the command. The last of these partial buffer commands must have a flag to specify it's the last one, but even the ones that are non-last buffer commands can't be chained together with zero delay between them, as apparently they are handled asynchronously. In other words, the funcgen doesn't process them synchronusly (append the commands to a queue and then process them as it gets the chance to do so). Instead it discards additional commands it receives while processing the current command. I have found no way to change this behavior, nor to be able to have a way to tell if the scope is done processing a command so that it is ready for the next one. There doesn't appear to be any way to obtain the status of whether or not the device is still processing a command, based on everything I've read from the official documentation.

Instead I've needed to handle this situation in a kinda hacky way. I have my program add an artificial delay after sending a command, before it sends the next one. This is why I was asking for help from a Rigol employee (if there's one on these forums), or other person with in-depth knowledge about the operation of this device, when I asked for help with setting up a long buffer that takes advantage of the 16M option.

Otherwise I get a situation where maybe the full buffer of the long waveform needs small buffers 1 through 8, but only small buffers 1, 2, 4, 5, and 8 are actually processed by the device and put together in the large buffer. In this example the small buffers (parts of the large buffer) 3, 6, and 7 got dropped. Therefore the final buffer is not the correct waveform, and the output is useless.