Retriggered AO with different waveforms

[p_quicke]

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

[ingram.weeks]

Hi Peter,

Do you still have an issue with this? If so, could you save a version of the VIs in LV 2014?

Thanks,

Ingram

[Kevin_Price]

I'm currently involved in a pretty similar thread that it may help you to check out.  Granted, it takes a while before discovering that the app is similar to yours, but we get there eventually.

I made a few minimal changes to your "Different AO" code to make it run without error on a similar X-series board.   Main highlights:

- explicitly "commit" the task before the loop.  This makes the stops and restarts in the loop execute much faster.  For more info, search on "DAQmx State Model".

- use the "DAQmx Wait Until Done" to know when it's time to stop your task.  Note: I cautioned *against* this function in the linked thread, but the other poster had another mechanism to know when 1 line's worth of samples had completed

- it's no longer necessary to be "retriggerable".  The task itself restarts, so a plain old non-retriggerable trigger works the same.

The attached code is a minimal modification to get you a step closer.  Other fine tuning could be done if needed, but let's wait and see if it *is* needed.

-Kevin P

[p_quicke]

Hi Kevin,

Thanks for your reply - this looks very helpful! I shall test it out on my system and let you know how it performs.

Best wishes,

Peter

[p_quicke]

Hi Kevin,

Restarting the task works Ok at lower frequencies, however as I try to increase the frequency of the triggered wave, I start seeing distortions in the waveform (as in the attached picture), and the waveform period is larger than the command waveform. My first thought was that my sampling rate was too low, but I use a fixed number of samples no matter what the period is. Do you have any suggestions to where this bug could come from?

Thanks,

Peter

[p_quicke]

Hi Ingram,

Sorry for the late reply - I have a good start on the solution from Kevin, below, but any input is always welcome. I have tried to save the vis for LV 2014, but never done it before so let me know if they have worked!

Thanks,

Peter

[Kevin_Price]

Don't know where to start b/c I don't know what code was used to run that, don't know what settings were used, don't know if that's a graph of "data on wires" in the block diagram or a graph of an AI capture of a real world signal.  And honestly, I'm kinda confused by your description of things.

Trying to help, so here's how you can help me help you:

- in the Edit menu, choose "make current values default" on the vi that produces that graph, save it under a new name, and post it

- I'm looking for more detail and clarity in the description.  Dunno what's meant by "the waveform period is larger than the command waveform", dunno what you're implying with the comments about low sample rate and fixed # of samples -- I don't see the specific connection and reasoning  behind your thoughts here.

The graph has one short and one long section of flat, constant signal value.  If that's what your AO task is doing, then those flat sections are either part of the calculated waveform due to bugs in 'GenerateRasterWaveforms.vi' or areas where the task has stopped and is holding its last value.  Looking at the complicated tangle of wires in the waveform generation subvi, I'm casting a suspicious eye in that direction.

-Kevin P

[p_quicke]

Hi Kevin,

Sorry for not fully specifying the problem. Initially I was monitoring the output on an oscilloscope when I noticed the unexpected output. In order to show you this I connected the output to an AI channel and modified the VI to read  and display some samples (attached). The graph is what I read on the analog input port when I connect it to the analog output port, and is representative of what I see when I monitor the output of the VI on an oscilloscope.

Addressing your final paragraph first, the graph consists of a flat section at 1.0V followed by a ramp from -1.0V to 1.0V with a short flat section within the ramp. There is another flat section at 1.0V after the ramp has finished.

The initial and final flat sections are due to the task having stopped and the output is holding its final value. This is expected behavior, although I would like to be able to trigger another ramp more quickly after this one has finished than the VI is currently able to.

The problem I was referring to was the short flat section within the ramp, which is not present within the command signal (i.e. the data which is being plotted in 'waveform graph 2' and which is the input into the daqmx write VI. The output signal I am aiming for is a linear ramp as in the attached picture.

When I increase the control 'frame rate', increasing the ramp gradient, the output waveform becomes distorted compared to the command signal. This distortion changes from ramp to ramp but consists of either a flat section within the ramp or that the ramp consists of two sections with different gradients.

When I was referring to the period in my previous posts I was referring to the length of time spent on the 'ramp' section of the attached graph. This time should be the same amount of time as the sawtooth in the command signal (displayed on 'waveform graph 2'), however as I decrease the period of the command voltage, the period of the measured output diverges from the command period.

I agree the subvi wires are a bit of a tangle and so would normally look there first but I am plotting the output of that vi (which is the input to daqmx write) and the waveform distortion is not present in the input.

I hope this clears up what I was talking about, let me know if I can further clarify anything.

Thanks very much,

Peter

[Kevin_Price]

I made just a few modest tweaks and one bigger one.  I did an actual AI measurement of the AO output signal using the special internal signal "_ao0_vs_aognd".  Occasionally I saw distortions from an ideal ramp as well.  See the attached pic.  (I also did a "save as default" on the graph itself.  When you open it up, the same data is in there until you run it.)  What I saw was considerably less dramatic than your pic, but I have no good explanation for it. 

The big tweak was to simply let the loop run 5 times to stop and restart AO before querying the AI just once for all its data, then stopping everything.  I thought this would give a better visual for the flat time between AO stop and AO restart.  In my runs, it tended to be around 150-300 microsec.

AO timing isn't entirely clear to me and I didn't do much to pursue it.  Just wanted to look at whether I could replicate the flat spots.  I saw a much milder version of your mid-ramp flat spot (mine was just a short region of shallower slope), and the flat spots at the top were drastically shorter.

I suspect an incompatibility in your code's loop timing where the AI reads represent considerably more time than the AO output.  The AO gets done then holds at the top of the ramp while the AI is still waiting to gather all the requested samples.  My big tweak was an attempt to troubleshoot against that theory, and I believe it shows that the AI timing *is* the major contributor to those long flat spots on top.

-Kevin P

[p_quicke]

Hi Kevin,

I think my inclusion of the AI has slightly confused the issue, I don't want to do that in my final vi, I just wanted to be able to easily show you the signal I was seeing. I observed the unexpected behaviour of the AO signal using an external oscilloscope running the original vi you uploaded with no modifications to your code. 

I attach a picture of the oscilloscope trace i measure of AO0 using your original MWE_RetriggeringDifferentAO - KPmod.vi with the default settings (i.e. the ramp period should be 6.25ms). I am sending a trigger signal to PFI0 every ~7.04ms to trigger a single sweep of the ramp (I am also monitoring the trigger signal on the bottom trace). In this case if the AO stop/restart time is <300 microsec I would expect to be able to trigger a ramp every 6.25 +0.3 ms = 6.55ms, but this is clearly not the case.

As you can see the ramp period is longer than it should be (~8ms instead of 6.25ms), leading to the long flat section as the task is being triggered again only on the second pulse after the initial trigger.

What trigger frequency are you using when you are running the VI? If I use a lower trigger frequency (i.e. 10ms) the ramp is triggered on every pulse, but I still get changes in gradient within the ramp. This isn't an effective workaround as I need to be able to change the ramp period and currently this doesn't seem to change when I change the command signal period.

Do you have any ideas about the possible source of the distortion of the  AO signal with respect to the command signal? Let me know if I am unclear on any point.

Best wishes,

Peter