Posted Thu, 03 Aug 2023 19:41:42 GMT by Glebov, Boris
I am attempting to load an arbitrary waveform to AFG1022. However, this does not appear to work at all.
AFG1022 version: 1.2.7
Python: 3.9.13 x64
PyVISA: 1.13

The default waveform in EMEM appears to be a parabola, 8192 points long. The waveform I am uploading is a TTL sequence (basically, square pulses, 0 V to 5 V). Channel 1 is set to a sine wave.

Initiating connection to the device goes normally, and I can execute other commands remotely. For example, set amplitude, frequency, etc. In those cases, the device responds as expected.

In the code example below, afg is the objected created in my code, and its property afg._dev is the PyVISA resource object, which allows sending actual commands. The object ttl is prepared by another function, and originally its data type is float64. I proceed like this:
>>> ttl_int = np.array(((ttl - ttl.min()) / (ttl.max() - ttl.min())) * 16382, dtype =  '>u2')
>>> ttl_int.size
500
>>> afg.wvfm_setlen(500)
>>> afg.q_error()
[] # empty list indicates no errors
>>> afg.wvfm_qlen()
500 # EMEM length is 500 points
>>> afg._dev.write_binary_values('DATA EMEMORY,', ttl_int, datatype = 'H', is_big_endian = True, termination = '\n')
1020
>>> afg._dev.write('source1:func:shape emem')
At this point, the AFG1022 shows the waveform on Channel 1 is a parabola (not square), it also notes "Shape emem". A scope hooked up to the AFG also shows the output is a sequence of parabolas.

Also, if I try to query values of various points in EMEM, they all seem to come back as 0, even at positions that should be non-zero:
>>> afg.wvfm_qval(175)
0.0
>>> ttl_int[174]
16382
What is going on here? Am I missing some critical step in setting up the arb waveform?
 
Posted Thu, 03 Aug 2023 19:45:20 GMT by Glebov, Boris

Just wanted to add that the error queue remains empty during these operations.

Posted Fri, 04 Aug 2023 18:53:35 GMT by Teles, Afonso
Hi Boris,

In my script I used source1:function EMEMORY (no :shape) and that seems to work.
I've attached my python script with this post for further reference.
 
Posted Fri, 04 Aug 2023 19:55:31 GMT by Glebov, Boris

Hello Afonso - the situation is very strange. Here is a sequence of operations I performed just now:

  1. Tried uploading my waveform (500 pts). Same result - no error messages, but EMEM waveform remained the same.
  2. Used the waveform from your example (1400 pts). EMEM showed the new waveform.
  3. Updated my waveform to be 1400 pts long. It now successfully uploaded to EMEM, but now I got the "-201" error.
  4. Closed the VISA instance and power-cycled the AFG.
  5. Tested uploading waveforms of 400 pts and 1400 pts. All worked, they showed up in EMEM, but every upload command resulted in the "-201" error.

Also, related to the ticket I had opened earlier (CAS-201972-B4N0M6): commands of the type source1:function USER1 used to result in the "-201" error and not affect the active waveform. This command now appears to function correctly, and does not raise the error.

Can you account for this behavior?

Posted Tue, 08 Aug 2023 17:30:59 GMT by Teles, Afonso

Hi Boris,

I'm not quite sure why you're getting that -201 error, I would assume it has something to do with the commands you sent previously to the AFG which set its state, but I've been unable to replicate it, so I can't explain it. If you could share more of your script/commands I might be able to track it down further.

In terms of the waveform upload issue with 500 pts, I was able to replicate that and I've tracked it down to a problem that happens with waveforms that are roughly a multiple of 250 pts. So the current workaround is just to avoid those lengths, but I will be working with our teams to fix this issue.

Posted Wed, 09 Aug 2023 21:13:13 GMT by Glebov, Boris
About waveforms breaking if they are a multiple of 250 long - I guess I will just add a validation check to handle this for the moment. Hopefully, there might be a firmware release that would fix this?

Sequence of commands that leads to the -201 error. All executed after power cycling the AFG. If afg.q_error() returns an empty list, it means no error messages were in the queue.
>>> afg = tek_visa.AFG1000('2132098')
>>> afg.q_error()
[]
>>> ttl_int.size
1400
>>> afg.wvfm_setlen(1400) # set length of EMEM
>>> afg.q_error()
[]
>>> afg._dev.write_binary_values('data ememory,', ttl_int, datatype = 'H', is_big_endian = True, termination = '\n')
>>> afg.q_error()
[ErrorMsg(code=-201, msg='Invalid while in local')]
>>> afg.wvfm_copy(1, 'EMEM') # copy from EMEM to USER1
>>> afg.q_error()
[]
>>> afg.set_func(1, 'USER1')  # set Channel 1 to USER1 waveform
>>> afg.q_error()
[]
At this point, Channel 1 displays the correct waveform.
Changing the command in write_binary_values to DATA EMEM, produces the same result, error -201.
Posted Wed, 09 Aug 2023 23:49:24 GMT by Teles, Afonso

I've reported that issue and I'll be working with the software team to get it fixed.

A power cycle isn't enough to reset the AFG to default state, instead you should issue the *RST command to default set the instrument and then proceed with your tests. Let me know if that still results in the same error or not!

Posted Thu, 10 Aug 2023 20:39:24 GMT by Glebov, Boris

Running *RST before replicating the above sequence of commands did not affect the outcome (same error, same place, things still actually work).

Posted Thu, 10 Aug 2023 22:09:03 GMT by Teles, Afonso
I'm unable to replicate your issue, would you be able to post the definitions of wvfm_setlen() and q_error()?
The raw SCPI output from that section would also work.

You must be signed in to post in this forum.