AO signal re-generation trigger problem

[cc-ast]

Hi,

I am using USB6211 to generate AO1 continuusly (10 samples in total), triggered at rsing edge of PFI5 clock (~2600Hz, 50% duty cycle), with sampling rate 10 times of PFI5 clock rate. So AO1 generates a waveform containing 10 samples at the same frequency as PFI5 and both are sychronized. I also need to change the waveform slightly during the task. Due to the using of a lockin amplifier, I can not stop and run the AO task, so I can only modify the waveform while it is running. When updating, 10 new samples are written into AO1.

The problem is, occationally the AO signal phase changes suddenly after the update, introducing a 180 degree deference in phase related to PFI5 clock. That seems the update writing becomes falling edge triggered instead of rising edge triggered. It may also be possible (? strange though) only 5 samples from the newly update was written first, then the other 5 samples is combined with the next update data for next writing event.

I tried to change the buffer size manually to 10 (the task is supposed to automatically allocate the buffer size) and still have same problem. Larger than 10 buffer size setting appears to get other additional errors.

In addition, I got warning 200015 every time I wrote data to AO1. The data written returned by the AO write function is always 10 as requested.

Labwindows/CVI is used.

[Jake_H]

I'm wondering if your error and the 180 degree phase difference are related. It looks like you might be running into some buffer problems, which are described in this post here. If I misunderstood this situation, please let me know and I can look into it some more.

[cc-ast]

Hi Jake,

Thanks for looking at my issue. I agree that it may be an issue of the buffer. In my case, I can not use the non-regeneration mode, since I need to do other AI, AO tasks as well and can not put all the resource to just generating AO1 signal. And I just need to write 10 samples every time (in a loop, which runs ~ 2 second per loop).

Is there a way to either write all 10 samples or none at all? Or just dump those unwritten undated samples after the first AO function written operation, so they don't get mixed with later updated samples?

Regards,

Bill

[Jake_H]

If we could identify a pattern for when the signal becomes out of phase, the problem might be easier to see. Is there anything you see with your waveform that might cause it to act like this? Are you just using a control to adjust the frequency of the waveform while the program is running?

You could try specifying the number of samples using the DAQmx Property Nodes.

[cc-ast]

Hi Jake,

It is very hard to find out the pattern when the problem appears. In average, it may happen once every few thousand updates. But sometimes more often than the other time. I only change frequency after the first update. After that, only the valtage values are updated. And there are not proterty nodes in CVI/Labwindows, only attributes. My call functions are,

(1) Configuration:

            DAQmxCfgSampClkTiming (taskHandleAO[1], "", 2975.3*2, DAQmx_Val_Rising, DAQmx_Val_ContSamps, current_points);
          
            strcpy(ch+1,device);
            ch[0]='/';
            DAQmxCfgDigEdgeStartTrig (taskHandleAO[1], strcat(ch,"/PFI5"), DAQmx_Val_Rising);

            DAQmxStopTask(taskHandleAO[1]);
            DAQmxSetTimingAttribute (taskHandleAO[1], DAQmx_SampClk_Rate, *frequency*current_points);
            DAQmxGetTimingAttribute (taskHandleAO[1], DAQmx_SampClk_Rate, &freq_AO_Samp_Clock, 0);
            *frequency=freq_AO_Samp_Clock/current_points;
            freq_DO=*frequency;
            DAQmxSetChanAttribute (taskHandleTTL, "", DAQmx_CO_Pulse_Freq, freq_DO);

(2) Updating:

           DAQmxWriteBinaryI16 (taskHandleAO[1], current_points, 1, 10.0, DAQmx_Val_GroupByScanNumber, ao_vout_D, &written, NULL);

Where frequency value is about 2.9kHz after configuration; current_points=10 and ao_vout_D is an array[20].

Also I am wondering why every time I got the warning that the data are not written at once. What exactly the meaning is it? Is something really happened or just having a chance to take place? If it is latter, is there a way to find out when it is really happening?

Regards,

Bill

[John_P1]

"That seems the update writing becomes falling edge triggered instead of rising edge triggered."

I'll bet what's happening is that you have a small glitch on your trigger signal such that the falling edge is occassionally being registered as a rising edge (there is no hysteresis).  Here's a crude rendition in MS Paint:

       

On the bright-side, the 6211 does have PFI Filters (see manual) which you should be able to use correct the behavior assuming this is the problem. 

The caveat is that software support only allows configuring the filtering as part of a counter input task on the 6211.  So, you'll have to set up a dummy counter input task to enable the filtering on the PFI line.  Here's a LabVIEW example, but the code should be very similar in the C API:

DAQmxCreateTask

DAQmxCreateCICountEdgesChan

DAQmxSetCICountEdgesTerm

DAQmxSetCIPeriodDigFltrEnable

DAQmxSetCIPeriodDigFltrMinPulseWidth (valid values include 125*10^-9, 6.425*10^-6, and 2.56*10^-3)

DAQmxClearTask

I'd start by setting the filter to the 6.425 us setting.  This will reject any pulses (i.e. glitches) that are less than 6.4 us, and will pass any pulses that are longer than 6.425 us. 

Best Regards,

[John_P1]

"I am using USB6211 to generate AO1 continuusly (10 samples in total), triggered at rsing edge of PFI5 clock (~2600Hz, 50% duty cycle), with sampling rate 10 times of PFI5 clock rate. So AO1 generates a waveform containing 10 samples at the same frequency as PFI5 and both are sychronized."

You might already be aware of this, but I wanted to point out that the analog output is continuous and is only triggered once at the start.  The AO clock is being generated internally and is not synchronous with your external clock--you could see drift over time.

I'm not clear on what you need to do overall so I can't give specific advice, but maybe you'd rather use a retriggerable counter output for your AO clock?

[cc-ast]

Hi John,

Thanks for your replies. I will try out your suggestion. I don't have any external clock. Only internal clocks are used. So I assume there is no problem for drifting as all the clocks are derived from the 80MHz.

The application is to generate a cuurent using the AO voltage control. Since the system has drift over time, we measure the real time current and change the AO voltage accordingly so the current keep constant (20ppm). As we use a lock-in amplifier using PFI5 as reference, we can not stop the AO output (which runs at a fix frequency) since it will ruin the lock-in output signal. A lock-in amplifier will take some time to settle when the frequency is changed or signal is re-starting.

Regards,

Bill

[John_P1]

Is the ~2600 Hz trigger signal coming from an external source?  What I meant was the sample clock on the DAQ device will drift relative to the external trigger if you are running it continuously without re-synching to the trigger.

Best Regards,

[cc-ast]

No, the trigger source PFI5 is generated internally.