Author Topic: How do I take advantage of the 16M option of the Rigol DG-1022z over LAN?  (Read 348 times)

0 Members and 1 Guest are viewing this topic.

Offline Ben321Topic starter

  • Frequent Contributor
  • **
  • Posts: 894
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.
 

Online Kean

  • Supporter
  • ****
  • Posts: 2099
  • Country: au
  • Embedded systems & IT consultant
    • Kean Electronics
Re: How do I take advantage of the 16M option of the Rigol DG-1022z over LAN?
« Reply #1 on: February 15, 2024, 03:41:37 pm »
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
 

Offline Ben321Topic starter

  • Frequent Contributor
  • **
  • Posts: 894
Re: How do I take advantage of the 16M option of the Rigol DG-1022z over LAN?
« Reply #2 on: February 18, 2024, 05:48:26 am »
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.
 

Online Kean

  • Supporter
  • ****
  • Posts: 2099
  • Country: au
  • Embedded systems & IT consultant
    • Kean Electronics
Re: How do I take advantage of the 16M option of the Rigol DG-1022z over LAN?
« Reply #3 on: February 18, 2024, 06:38:04 am »
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
Quote
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
Quote
Write a string message to the device followed by values in binary format.

The write_termination is always appended to it.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf