Howard Eglowstein

First, thank you all for the help on the waveform download question some weeks back.&#160; With your help we did get code in place to break large waveforms into pieces, sequence them (after buying licenses for the truckload of new AFGs we bought) and we can see they download properly as long as the waveform pieces start and end with zeroes. It's still weird that the device is that finicky about the specifics of the data - and that it fails without returning errors, but we can live with that.<br> <br> So now, we have in our application a situation where we have a single waveform. It's basically binary, so it's composed of 0 and 8191 so that it's a waveform referenced to 0 and goes as high as V+.&#160; The code sends it just fine and we can see it sitting, ready to go. The code then sends the output enable command. The channel 1 and 2 buttons light up but there's no output. If I press the buttons to turn off the output and then again to turn it on, I get the output.&#160; The device doesn't report anything in status that it's waiting for anything.<br> <br> I also tried putting the double button push in code to Band-Aid over this. After the waveforms are downloaded and the output enabled, I added two more output commands - a disable and an enable spaced 1 second apart. The lights behave as you'd expect but there's no output. It seems like the physical button push is required to get the output.<br> <br> Any theories?&#160; Is this something that might be known and is waiting for a firmware fix?<br> <br> Thanks!<br> <br> Howard

Part of the issue, I think, is that the AFG3100 seems to be finicky about the waveform itself. I'd still like to see a clear set of documentation that shows the SCPI commands that work, but the examples above and elsewhere on the forum (thanks to Andrea and Afonso for that!!) got my code sending data the AFG likes. But here's the weird thing:
This program segment produces a buffer of chars that when sent to the AFG properly produces one sine wave cycle in 360 points, or 720 bytes:
float angrad, outsine, outcos;
outcount = 0;
for (i=0; i<360; i++)
{
angrad = (float)i / 180.0 * 3.14159;
outsine = 8192.0 + 8191.0 * sin(angrad);
outcos = 8192.0 + 8191.0 * cos(angrad);
val = (int)outsine;
val = (int)outcos;
outbuff[outcount++] = (char) (val & 0xff) // low byte
outbuff[outcount++] = (char) (val >> 8) // high byte
}
The buffer is surrounded by appropriate commands and sent via NI_VISA viWrite commands from CVL/LabWindows.&amp;nbsp; The AFG properly displays a sine wave cycle and it comes out the output jack as expected.
I then change the commented line so the value written is the cosine wave (starts high, goes to 0, then negative, then back to 0 and ends high) the treats it as all zeroes:
float angrad, outsine, outcos;
outcount = 0;
for (i=0; i<360; i++)
{
angrad = (float)i / 180.0 * 3.14159;
outsine = 8192.0 + 8191.0 * sin(angrad);
outcos = 8192.0 + 8191.0 * cos(angrad);
val = (int)outsine;
val = (int)outcos;
outbuff[outcount++] = (char) (val & 0xff) // low byte
outbuff[outcount++] = (char) (val >> 8) // high byte
}
if I change the code again so that it smashes the beginning and end of the waveform to be 0, the AFG displays it properly (the beginning and end is 0 though)
float angrad, outsine, outcos;
outcount = 0;
for (i=0; i<360; i++)
{
angrad = (float)i / 180.0 * 3.14159;
outsine = 8192.0 + 8191.0 * sin(angrad);
outcos = 8192.0 + 8191.0 * cos(angrad);
if ((0 == i) || (359 == i)) outcos = 0.0;// smash both ends to 0.0 instead of 1.0 if the angle is 0 or 359 degrees
val = (int)outsine;
val = (int)outcos;
outbuff[outcount++] = (char) (val & 0xff) // low byte
outbuff[outcount++] = (char) (val >> 8); // high byte
}
Finally, if I only smash the beginning to 0 it fails to show anything but if I only smash i=359 with “if (359 == i) outcos = 0.0” to 0 but leave the first point set to 1.0 I get the waveform but the beginning has the dip, not the end.
It looks like there some undocumented and (dare I say) buggy requirement that the waveform ends with a voltage near 0. My original test data set was a sample of audio which is constantly changing data. I think this 'feature' was preventing my old test code from generating anything. I tried a variety of SCPI command variations and many of them seem to work, but the data itself seems to matter. The 3022 didn't have these limitations.
 

*sigh*  It works as I expected it would, yet the same calls from C just don't seem to do the job.  I'm going to try and install Python on this machine (it's off-network so it's hard to install stuff) and see if I can just get this example to run verbatim. Then I can watch it on the USB analyzer and see if it sneaks any extra SCPI commands that aren't clearly spelled out here.

I appreciate the help and your patience.  I do offer beer/pizza money for useful suggestions so we can arrange some if you'd like. Again, I really appreciate your and Andrea's help with this.

Thanks Andrea!  I see a few things that are different than the examples in the manual, and what I captured with the USB analyzer from ARBExpress.  In general, do extra letters and upper/lower case matter as much as the manual suggests?  Line 128 in your code would be "SOUR1:FUNC EMEM1" if it were treated strictly. If the device doesn't care...

The money line that transfers the data is line 145.  ARBExpress sends a command that looks like "TRACE:DATA EMEM1,#3200", where there's no leading colon, the hash tag is present, then the 3200 means there are 200 bytes that follow and there are 3 characters in the number 200.  Your example doesn't send a length. Does AFG.write_binary_values format that line for you? The PyVisa doesn't mention it and I'd think it's critical, no?

It's frustrating since each of these sources seems to document something different than ARBExpress does, yet if I have my program emulate ARBExpress I can't get that to work either. Then if I switch back to 3022 commands and send them to the 3022, that works fine.  This is really weird.  I need to get arbitrary waveforms working first and then I can try out the really useful looking sequence code you shared.  I installed the trial option and our purchasing people are working on buying up a whole boatload of licences for all of our new 31022s.

Howard

No joy. I can't figure out a way to do this without it expanding to HTML and showing the HTML formatting...  Browser dependent maybe?  I'm using Chrome.....

I can't seem to find a way of pasting a screen of text without it converting to HTML.  :(  

Since I can't easily share my C program for downloading waveforms, does anyone have a sample, tested program that works?  (any language is fine).  I tried replicating the BASIC program in the manual but so far I've found 3 different versions of the manual that have different programs and the command sequences don't seem to work.

Thanks!

Thank you Andrea!  That's really helpful, and I'll check to see if we licensed that feature. We wanted this specific unit because of the ability to send large waveforms but didn't know they had to be sequenced. We probably didn't buy that option because you know how purchasing people are - they see an extra cost and skip it to save money.

Is it the case that a sequenced waveform has to go to channel 1 and you can't have two of them going to channels 1 and 2 at the same time? I think there's a lot of questions we should have asked before choosing this instrument that we didn't ask first.

Howard

Yesterday I started exploring this sequencing thing, and now it appears that I'm unable to send ARB data at all.&nbsp; When I asked about the programming example a few months ago we puzzled over why the program in the manual only sent out one byte per data point. That didn't make any sense.&nbsp; I though the manual I had might have been buggy (early printing) and I found two other versions on the web that appear to be newer. In the latest one the BASIC example does indeed show two bytes per point, the high byte of a word before the low byte.&nbsp; So that made more sense.<br> <br> I'm working in LabWindows/CVI and I had a working test program that did a great job downloading waveforms to a 3022.&nbsp; I'm trying to update it for the 31022 and it looks something like this:&nbsp; (the functions are essentially wrappers around the VISA functions provided by NI)<br> <br> &nbsp;&nbsp; &nbsp;error = AFG_Init();<br> &nbsp;&nbsp; &nbsp;if (error &lt; 0)<br> &nbsp;&nbsp; &nbsp;{<br> &nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;sprintf(strtemp, "I can't init the AFG. Error = %d. Should I try again?\n", error);<br> &nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;userchoice = ConfirmPopup("Can't init the AFG!", strtemp); &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;<br> &nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;// 1 = yes, 0 = no &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<br> &nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;if (0 == userchoice)<br> &nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;goto Error;<br> &nbsp;&nbsp; &nbsp;}<br> &nbsp;&nbsp; &nbsp;error = AFG_Command("*RST\r");<br> &nbsp;&nbsp; &nbsp;// squirt out a waveform<br> &nbsp;&nbsp; &nbsp;unsigned short wave1[128*1024]; &nbsp;// 128K points<br> &nbsp;&nbsp; &nbsp;<br> &nbsp;&nbsp; &nbsp;// call a function that opens a data file of numbers between 0 and 16382, writes<br> &nbsp;&nbsp; &nbsp;// each value into the array 'wave1' and returns the number of lines it read<br> &nbsp;&nbsp; &nbsp;// (the number of values) into 'linesread'<br> &nbsp;&nbsp; &nbsp;error = ReadWFMfile("mytestfile.dat", &amp;linesread, &amp;wave1);<br> <br> &nbsp;&nbsp; &nbsp;// Format a string so it looks something like "DATA:DATA EMEM1,#6128000" without a terminator<br> &nbsp;&nbsp; &nbsp;sprintf(str1,"%d", linesread);<br> &nbsp;&nbsp; &nbsp;sprintf(ourcommand, "TRACE:DATA EMEMORY1,#%d%s", strlen(str1), str1);<br> &nbsp;&nbsp; &nbsp;// Send that part of a command<br> &nbsp;&nbsp; &nbsp;error = AFG_Command(ourcommand);<br> <br> &nbsp;&nbsp; &nbsp;for (i=0; i&lt;linesread; i++)<br> &nbsp;&nbsp; &nbsp;{<br> &nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;// Send each of the integer values as two bytes, high endian<br> &nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;error = AFG_Word(wave1[i]);<br> &nbsp;&nbsp; &nbsp;}<br> &nbsp;&nbsp; &nbsp;// Send a terminator for the DATA:DATA command<br> &nbsp;&nbsp; &nbsp;error = AFG_Command("\r");<br> <br> &nbsp;&nbsp; &nbsp;error = AFG_Command("FUNCTION EMEM1\r");<br> &nbsp; &nbsp; error = AFG_Command("FREQUENCY 8K\r");<br> &nbsp;&nbsp; &nbsp;error = AFG_Command("OUTPUT ON\r");<br> <br> ------------------------------------------------<br> <br> The AFG resets and changes states just fine but no variation of the TRACE command seems to make a difference. I wondered if there could have been firmware updates so that maybe my device doesn't properly interpret these commands?&nbsp; The manual shows words like EMEMory in upper and lower case where the lower case characters are for clarity and can be eliminated - yet the example shows the commands spelled out fully.&nbsp; I have firmware 1.6.1 installed if that matters.<br> <br> Any suggestions?&nbsp; Is that code above (which worked well on the 3022 with slightly different commands) fundamentally wrong somehow?<br> <br> Thanks!

Thanks!  That's exactly the leg up I was looking for. There other things to consider as well, like what kind of sync signal we'll get out of the unit but I'd like to experiment and see what we can do.   Yes, the delay as the waveform chunks switch from one to another might be a problem.  We'll see.

Thanks again!

Howard

Alfonso, we're well into our implementation now and I'd like to explore the sequencing to get in larger waveforms. Can you direct me towards a block diagram, an implementation of some sort or just a description of what commands I might send and in what order?

I assume it's using TRAC to send sections to EMEM, then I have to transfer those to files in drive M:?  or P:?  Then use the SEQ comnmand somehow?  The documentation isn't as clear as I'd like it to be.

Thanks in advance!

Howard