Afonso Teles

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.

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!

Hi Boris,

Yep your test is great and I've also ran similar tests which confirms that *OPC? works to synchronize commands. Specifically, running *OPC? by itself takes 35 ms, doing data:copy is about 1 ms, but if we do both it takes 50 ms, which implies that *OPC? is waiting about 15 ms for data:copy to finish, as expected.

I also tested using other queries like system:err? or data:value? and those had the same effect, which lead me to believe the AFG's programming interface is synchronous, so explicit synchronization with *OPC? is likely not needed.

Hi Boris,

Probably the best explanation of *OPC? is in this programmer's manual: https://www.tek.com/en/sitewide-content/manuals/4/5/6/4-5-6-series-mso-programmer-manual
Essentially, you'd wait until you read 1 from *OPC? and that would tell you that your OPC operations are done. I've attempted to try it out on the AFG1k but haven't been able to confirm it works.
The *WAI command might also be of interest to you.
Also, a lot of our signal sources are synchronous, making it unnecessary to query *OPC?. I'm still trying to confirm if this is the case for the AFG1k or not.

Do you have a specific setup which has been giving you synchronization problems?
 

Hi Boris,

It's not documented, but the instrument does reply to an *OPC? query. I haven't tested it thoroughly on this instrument, but does how one would usually do synchronization through SCPI.

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.

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.
 

Hi Avital,

In addition to what Daniel said, you can also:
1) If your chirp width is 2 MHz or less, you can use the Modulation mode with FM to do complex chirps as you wish.
2) use ArbBuilder, ArbExpress or your own script to create arbitrary waveforms.

Hi Daniel,

I've attached the letter of volatility with this post.

Hi Anandkumar,

I would suggest following the troubleshooting tree on page 4-22 of the service manual.
If that doesn't resolve the issue, your next option would be to send it in for repair.