AO signal re-generation trigger problem

[John_P1]

Oh ok sounds good.  Be aware of coerced sample clock rates.  The analog output sample clock on the 6211 is divided down from a 20 MHz timebase so you can't get exactly 26kHz.

[cc-ast]

Hi John,

It appears to have some technical obstacles to implement the dummy counter solution. One problem is each counter's output terminal has to be connected to a physical output (PFI4 to PFI7), but I use three of them as static digital output, and one (PFI5) for frequency generation from one counter already. So if I need to use one more counter, I can not find a way to disconnect its output from the physical channel ( I don't use any of the PFI0 to PFI3. I wish I could use the PFI0 to PFI3, but seems impossible). Also I don't know if I can directly access the counter's inputs and output without using the physical I/O name (PFI...).

The other problem is about the cause of the trigger problem. If it is due to the glitch on the edge, since it is generated from one counter, wouldn't it still experience the same issue if I use another counter? I am not clear about which one (input or output) is glitch-fee from the dummy counter.

Here is my existed counter and three static digital outputs configuration,

        //Digital Output
            //Trigger for Lock-in
            strcpy(ch,device);
            DAQmxErrChk (DAQmxCreateCOPulseChanFreq (taskHandleTTL, strcat(ch,"/ctr1"), "", DAQmx_Val_Hz, DAQmx_Val_Low, 0.0, 2975.3, 0.5));
            DAQmxErrChk (DAQmxCfgImplicitTiming(taskHandleTTL,DAQmx_Val_ContSamps,0));
            DAQmxErrChk (DAQmxStartTask(taskHandleTTL));

            //ITC ON control
            strcpy(ch,device);
            DAQmxErrChk (DAQmxCreateDOChan (taskHandleITC_ON, strcat(ch,"/port1/line0"), "", DAQmx_Val_ChanPerLine));
            DAQmxErrChk (DAQmxWriteDigitalScalarU32 (taskHandleITC_ON, 1, 10.0, 0, 0));
   
            //Sample pump ON control
            strcpy(ch,device);
            DAQmxErrChk (DAQmxCreateDOChan (taskHandlePumpSamp_ON, strcat(ch,"/port1/line2"), "", DAQmx_Val_ChanPerLine));
            DAQmxErrChk (DAQmxWriteDigitalScalarU32 (taskHandlePumpSamp_ON, 1, 10.0, 0, 0));

            //Reference pump ON control
            strcpy(ch,device);
            DAQmxErrChk (DAQmxCreateDOChan (taskHandlePumpRef_ON, strcat(ch,"/port1/line3"), "", DAQmx_Val_ChanPerLine));
            DAQmxErrChk (DAQmxWriteDigitalScalarU32 (taskHandlePumpRef_ON, 1, 10.0, 0, 0));

[cc-ast]

Update:

I reduced the frequency of PFI5 by half, so now the AO output (which runs at twice the frequency of PFI5, triggered by PFI5 rising edge) update should be always at rising edge of itself, even if there is a glitch at PFI5 falling edge. But I still encountered the same problem: the AO updates shifts by 180 degree is phase oocationally. So apparently this is not due to the glitch on the edge.

[cc-ast]

Additional detail:

The phase flip (180 degree phase change) problem is not a single event. It will last maybe as long as the regular non-flip situation before it flip back to 0 degree. So it is more likely a software issue. A glitch induced event should behave like a random event.

[John_P1]

Hi cc-ast,

So if the trigger signal is being generated from one of the internal counters, you can actually just use the internal output terminal (e.g. "/Dev1/Ctr0InternalOutput") without having to route the signal back in through a PFI line.  The digital filtering suggestion came from your observation that "That seems the update writing becomes falling edge triggered instead of rising edge triggered".  Digital filtering is a feature of the PFI lines that allows them to ignore pulses less than a certain pulse width--it doesn't matter which counter is used but a counter must be used to enable it on M Series.  However, if you are using the internally generated counter output as your sample clock I would not expect this to be the issue.

You're continuously writing output data that is supposed to remain in synch with the counter output.  However, regeneration is enabled.  What sounds like might be happening is a certain amount of old data is being regenerated before the new data is written.  By default the new samples will be written to the "current write position" which may or may not be at the beginning of the output buffer.  You can change this by setting the following properties before each time the write is made:

DAQmxSetWriteRelativeTo(taskHandle, DAQmx_Val_FirstSample);

DAQmxSetWriteOffset (taskHandle,0);

Best Regards,

[cc-ast]

Hi John,

I added the two functions you suggested (RelativeTo and Offset), but still see the problem. I have about 10 analog inputs and one extra AO writing (AO0, scale writing). Will those AI and AO cause the problem since they may use a lot of buffer? Also it is a little strange because when the problem occurs, the writing is always offset by half (5, the total writing is 10).

Regrads,

Bill

[John_P1]

Hi Bill,

Just to summarize what has been proposed so far in response to your original statement:

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

Noise on the trigger signal would explain a task being triggered on a falling edge instead of a rising edge.  Digital filtering can eliminate this from happening.  This should not happen if using the internal counter output as your trigger source.

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.

If you're updating on-the-fly you really should have regeneration disabled to prevent regenerating old samples.  I was under the assumption that the WriteRelativeTo property would fix this, but I'd have to set up a test to double-check.

So, based off of what has been said I can't really think of any other suggestions.  That doesn't mean there aren't any, I'm just not 100% clear on what the issue is.  Could you elaborate on the statement that "AO updates shifts by 180 degree is phase oocationally".  What is the 180 degrees relative to?  How are you measuring the phase shift, and could you provide screenshots that more clearly illustrate the behavior?

I'd also like to see your code if you have it available.  You've posted bits and pieces but I haven't seen the entire thing put together.  For example, how are you defining the output waveform?  Are you triggering off of the internal output of the counter now?  Are you setting the WriteRelativeTo property before each call to DAQmx Write?

Best Regards,

[cc-ast]

Hi John,

The AO1 writes a waveform of 10 samples (kind of a square waveform) triggered by PFI5 which is the counter output and also at the same frequency as AO1 (~2600Hz). Therefore AO1 and PFI5 is in phase. Measurement of AO1 output is also triggered by PFI5 (all rising edge). Those trigger signals are all internally wired through software. The 180 degree change means the measured AO1 output is out of phase against PFI5. And this is not a problem caused by AO1 output measurement, since the signal (through lock-in amplifier using PFI5 as reference) created by AO1 output control (a modulated laser) indicates that the phase change does take place. The counter is set up only at the beginning of the program without further updating.

I will simply my code later and verify it contains the same problem. Then I will send it to you. Please send me an email so I can send the code. Thanks.

Regards,

Bill

[John_P1]

Hi Bill,

I sent you a PM with my email address.  Looking forward to seeing the code, I'm still a bit perplexed about what exactly might be going on.  If you can send the most simple case that reproduces the behavior that you are seeing I'd very much appreciate it.

Best Regards,

[cc-ast]

I have not heard from John regarding this issue for a few months. Is there any other one familiar with it? Thanks.