Howard Eglowstein

Thanks for the clarification. It's funny that the old 3022 we have is far more likely to start at the beginning of the waveform than the 31022. I think I should be able to make this do what we need now.<br> <br> &#160;

Afonso, that makes perfect sense. I'm puzzled about your referring to a 'Run' key. On the panel there are buttons to set the run mode to continuous, burst, etc.&#160; I don't see any way to then effectively start and stop generation properly from the panel but the SCPI commands make a lot of sense. I'll go try that.<br> <br> For other aplications here where we won't have the SEQ option, does that command still work on a basic 31022?<br> <br> Thanks!

Thanks Andrea.&#160; I'm not looking for a single output. I want continuous output when I enable CH1, but I need it to start at the beginning of the waveform. I guess what I *want* is in addition to an internal and external clock mode, I want one that says &quot;be internal, but stop when CH1 is output is disabled and start a fresh waveform when CH1 is enabled again&quot;.&#160;<br> <br> Do you think it might work if I set the clock to external when I disable CH1, then enable CH1 first before setting the clock to internal?&#160; That's the experiment I was going to try in the lab today.<br> <br> Howard

Another 31022 riddle...<br> <br> In our test application we generate a waveform that has a burst of 10 pulses. The pulses begin at the beginning of the waveform and are followed by 0s. The whole waveform is repeated at some frequency (let's say 60Hz).&#160; We load the waveform into CH1 of the AFG and when we want output we enable the output of CH1.&#160; Sometimes we get the 10 pulses repeated in groups as desired, but sometimes we get fewer than 10 in the first grouping.&#160; (image attached)<br> <br> Before we enable the output it's clear the internal timebase is still counting off the 60Hz. The trigger output is neatly sending out a square wave every 16.67mS.&#160; What I *think* is happening is that when I enable the output, the AFG doesn't wait until the next rising edge of trigger out to start outputting, but rather it simply starts at whatever point it would have been in during that cycle. So if the bursts take 10 of the 16mS and it's 5 mS into the 16mS cycle when I enable, I'll see the last 5 of the 10 pulses in the first group.&#160; Does that make sense? Am I analyzing this correctly?<br> <br> What I need to happen is that when I enable CH1 (press the button physically or via software), I want the AFG to begin sending the waveform in its entirety and not lop off the beginning to keep up with ongoing pulse train from the Trigger out. I would actually prefer that Trigger out simply stop when CH1 is disabled and start a new 16.67 time cycle when it's enabled.&#160; I can't use an external trigger but I believe I have the trigger source to be internal.&#160; I dont' see a setting that says &quot;clock internally but wait to start until I send you a start command&quot;.<br> <br> Is there a command sequence to do what I need to do? Am I properly interpreting the evidence or should it be working correctly and the AFG is just confused?&#160; I've tried it on two units and they behave similarly, but differently. Firmware versions 1.6.1 on each and they both have the SEQ option.<br> <br> Thanks!<br> <br> Howard<br> <br> <br> &#160;

Someone is going to find this thread eventually so i wanted to document the fix. Thanks Afonso and the other folks at Tektronix who took the time to look at this and come up with a solution!<br> <br> The issue appears to be the AFG getting confused between advanced and basic modes. We have an application that will sometimes need a waveform more than 128K points, so we wrote a bunch of code (see the other thread) to take the large files, break them up strategically into chunks, write those out and control the whole mess with the sequencer. It's sad that was necessary but that's another topic...<br> <br> The code we wrote was on top of the NI driver for the 31K. We spew out a bunch of viWrite() commands with SCPI stuff, then at the end we did the &quot;OUTP1:STAT ON&quot; followed by a &quot;SEQC:RUN:IMM&quot;. If there's no sequence involved we didn't think the SEQC command could hurt anything. Apparently that's not true. The AFG is weird and it reponds by lighting the buttons and doing nothing.<br> <br> After an incredibly cool conversation with Afonso and others at Tek, I moved things around rather than trying to have the code decide if there's an actual sequence. So if I send the &quot;SEQC:RUN:IMM&quot; first, followed by an &quot;OUTP1:STAT OFF&quot; and an &quot;OUTP1:STAT ON&quot; it works a treat! I'm stil testing and I need to verify all of my sequencing code but it looks like a fix.

I've been emailing with Tektronix and they think it has to do with the sequencing module. A trigger or something, perhaps. I captured the traffic with the AFG and the NI driver sends dozens of commands to get the state of just about everything. Even when we don't specifically use the sequence features the driver does hit a few commands.&#160; I've attached the capture if that helps.<br> <br> Howard

Thanks for looking at this Afonso. Can I ask if the unit you have has the sequencing option? Tek's tech support asked me about the option (which we have) as they think that might have something to do with it. I'll have to get a capture of the whole sequence but essentially we download a waveform into EditMemory1, set up the arbitrary mode to use that, then send &quot;OUTP:STAT ON&quot; through the updated NI 31K driver. I can see it in the USB capture and it looks pretty much just like that. When the AFG receives the command the CH1 button lights. Nothing comes out but if I press the button to shut it off and then again to turn it back on, the button lights but there's output. So the current theory I'm exploring is that somehow there's a sequencer issue where it's waiting for something that it's not seeing. If I don't specify any sequence elements, I assume I don't need to do anything else to stay in basic mode? Am I missing something? Thanks! Howard

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.