Boris Glebov

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

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()
[]

In our setup, we are using an AFG to send a trigger sequence (using a burst of a single repetition, activated by software trigger) to another device. The whole setup is integrated into a single Python script, so the overall sequence runs automatically. So I just need to make sure once the script is through the section where the AFG is being set up, that the AFG is actually ready to run. I want the script to block until the AFG is all done and is ready for the software trigger.

I did a couple quick tests. For this, I prepare a waveform that is 7585 points long (so copying will take some real time). Running it in the console looks like this:

>>> if True:
    t0 = time()
    afg.wvfm_copy(1, 'EMEM') # copy from EMEM to USER1
    t1 = time()
    print(f'Elapsed time: {t1 - t0:.3F} sec')

Elapsed time: 0.000 sec
>>> if True:
    t0 = time()
    afg.wvfm_copy(1, 'EMEM') # copy from EMEM to USER1
    afg._dev.query('*OPC?')
    t1 = time()
    print(f'Elapsed time: {t1 - t0:.3F} sec')

'0'
Elapsed time: 0.780 sec

In execution, there is a noticeable delay until `0` prints out.

This looks to me like the AFG won't process the *OPC? command until it has finished copying data. The query method will then wait (up to the VISA timeout limit, which here is 2 sec) for the *OPC? query to return anything, which effectively blocks until completion.

By the way, I have not sent the *WAI command.

Does this make sense and align with what you have been able to test?

That's great - can you expand on what kind of response to expect and how to interpret it?

Is there a command to check whether the AFG has finished processing data and commands? For example, if I upload an arb waveform and then copy it from EMEM to a USER slot, can I programmatically check if this finished and the AFG is ready to start generating the waveform on the specified channel?

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?

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

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?