Howard Eglowstein

I'll update the thread, as I have a workaround and am talking with the experts at Tek via email.

The command set does include a function 'SOUR[1|2]:PULS:TRANS:LEAD {n}' to change the leading edge rise time and a corresponding 'SOUR[1|2]:PULS:TRANS:TRAIL {n}' command.  The idea is that instead of letting the AFG pick some slope based on your waveform, you can just set it to be whatever time you want with the minimum being 8 nS.  That sort of works and sort of doesn't.  

In our application we have one waveform that for example, has 4000 points that represent 20 mS in time. The rise time on these edges was about 7 uS - *way* too long. The solution was to add a driver layer that saw we were about to write 4000 points, then decide we could duplicate each point 32 times and still fit into the 128K RAM. It builds a new waveform with each point replicated as many times as it can and still fit, then ups the sample rate accordingly.  Using that trick I got the rise time down to 160 nS.

I have to believe that others have run into the same issue, so it seemed reasonable to share our solution so far.

We have a test solution using a 31022 to generate 2 test waveforms while also triggering a 3022 to provide sync to some cameras. The waveforms are using a sample frequency of 1MHz and are a few thousand samples long. It's essentially digital, in that we go from low (0V) to high (4.5V).  The output from the AFG seems to take close to 8 or 9uS to fully transition from 0 to 5.4V. The curve isn't quite a straight line but the scope we tested with shows it to be noisy and almost a straight line- slightly steeper at first and then leveling off for the last uS.  (I'll grab a scope shot and post it as a followup).

To see if this happened on every waveform, I set the unit to run a 20KHz waveform (similar-ish to our test waveform) and watched that on the scope.  That fully transitions from 0 to 4.5V in under a uS but has severe ringing just before it goes high and then afterwards.  The arbitrary waveform doesn't ring.

So this is unexpected and weird, and the slow transition in arb mode is a problem for us.  We're trying to time the response on a device and it's hard to know at what point we should consider low and what point is high.  Microseconds count in this application.

Questions:  ??

1) Is there a setting like output impedance that might matter?  We see this whether the AFG is connected to our test setup or if it's solely connected to a scope through a probe.

2) Is this something which has been seen, reported and fixed so that we should be applying firmware updates?

Thanks!

Thanks Andrea. I did some tests manually and saw that using the sequence feature did work, and I see that the wait and a manual trigger would also work. The company has decided I have more important fish to fry so this is tabled for now - until it becomes a crisis in a few weeks. You know how that goes.  :(

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