Hello all, I am a Labview novice and I would like to use my PCIe-6321 to output two AO channels, triggered by an external digital signal. I would like one of the channels to output the same waveform (a sawtooth) and the other to out put different voltage steps during each period of the sawtooth wave. I am able to trigger (& retrigger) the whole sequence of sawtooths and steps (vi is MWE_RetriggeringSameAO, atached), but I would ideally like to trigger each individual sawtooth and voltage step, which I have tried to do in the MWE_RetriggeringDifferentAO vi. When I try to do this I get error 200288, which I have looked up and I have tried stopping the task in each loop to re enable the trigger but I can't seem to get to work. Does anyone have any suggestions as to what I could try, or if what I would like to do is possible with fairly small (<1ms) gaps between each sawtooth and voltage step? Thanks very much, Peter

Multifunction DAQ

Retriggered AO with different waveforms

I do believe I've sometimes been conflating this thread with the other longer-running one related to AO galvo control I linked back in msg 3. The other thread needs AI and the triggering-related needs are different too. Let me regroup and clear my head here.

I have no solid ideas about the distortion of your AO signal. Do all cycles look pretty much the same like that?

I'd revert to some very basic troubleshooting to test the behavior of AO all by itself. One thing that's intriguing is that the amount of extra time seems to correspond to the reduced slope. Extrapolating the initial slope would seem to terminate in time for the next trigger, as expected. It almost looks like there's been a step change reduction in AO sample rate part way through the ramp, though I have no working theory how & why that would happen. I doubt that's the true explanation, but the correspondence feels like some kind of clue.

Looking back at the recently linked code "MWE_RetriggeringDifferentAO - KPmod.vi", I do see something I missed before. The call to DAQmx Write should happen while the task is stopped, *NOT* right after it's started. I'm a little surprised in retrospect that it doesn't error out when the task is started before any data has been written to the task buffer.
It's possible you can accomplish this by *removing* DAQmx Start and setting the auto start input True on DAQmx Write.vi However, I'm not fully sure whether this interacts efficiently with the pre-loop "commit". So the alternative would be to perform DAQmx Write immediately after DAQmx Stop.

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).