Problem with external sample clock and sample rate

[nicky15]

I'm using PCI 6251(M series) and PCIe 6351(X series) and connected both with RTSI cable. (terminal block : BNC-2120)

I need to acquire sample point using external sample clock which clock source is made by analog variable frequency sine signal.

On attached image you can see the idea. 

I put variable frequency analog signal at Aux channel and 100Hz sine signal at Main channel.

Because I use external sample clock(variable frequency), 100Hz sine signal has to be sampled with unequal dt point. 

also sample rate has to be chosen by external sample clock. 

But the result was it has an equal dt point and sample rate was chosen by rate that I put. 

Also when I increase sample rate, the data shows more then 100Hz.(which shows more data)

I don't understand why...(Is it because of my DAQ card? or Am I mistaken?) 

please help..  (also I attach vi that I use)

[Kevin_Price]

It looks like you're in good shape with the harder stuff (use of RTSI and driving one board's acquisition with the analog trigger detector of another).  But there are a couple more fundamental things you're missing.  They aren't really *obvious* things, just things that people usually learn about before the harder stuff.

1. The waveform as a datatype is fundamentally limited to represent data that's sampled at a constant rate.  There is only one scalar value available to represent the time interval between samples, and this *CANNOT* accurately represent data that's sampled at a variable rate.

2. When you define a sample clock source terminal to be any signal other than one of the known internal timebase clocks, DAQmx does not and *CANNOT* know about the timing between samples.  All it can do is believe whatever you wire in and tell it about the sample rate.   That's why the waveform you read is plotted AS IF samples were taken at the constant rate specified when you called DAQmx Timing.

   A good rule of thumb is to tell DAQmx the highest feasible sample rate because the value you wire may be used to help determine the buffer size. 

If you need to know the actual sample timing, you'll need to add a counter task that does buffered period measurement of the AnalogComparisonEvent.  You can generate an array of relative times with a cumulative sum of these periods.  And then you'd need to use an XY Graph to display your analog data vs this time data.

   Advanced note: the behavior of period measurement differs for M-series and X-series boards.  With the M-series, the 1st value represents a randomish time from starting the task until the 1st AnalogComparisonEvent.  It'll be meaningless and you can replace it with a 0 for relative time.  With the X-series, the 1st value represents the actual interval from the 1st to the 2nd AnalogComparisonEvent.  You'll measure one less interval than the # of AnalogComparisonEvents that occur.  When you create your time array, you should prepend a leading 0 value to the beginning of the array

-Kevin P

[nicky15]

Thank you for your help!

I made vi that using counter input period, but I have problem about using an AnalogComparisonEvent signal.

As you can see the photo, AnalogComparisonEvent signal is terminal signal and Counter input signal has to be counter source which is ctr0.

Is the way that I can match them together? 

[Kevin_Price]

Can you post the actual vi?   If it's in version 2019 or 2020, please save back to 2016 or 2018 from the menu File->Save for Previous Version...

Then I can edit in-place and add comments rather than have to recreate everything.

-Kevin P

[nicky15]

thanks!

I attached vi.

[Kevin_Price]

Not many changes were needed, here are highlights:

1. I added a DAQmx Channel property node to the CI task to configure it to measure periods of the AnalogComparisonEvent

2. I changed the order of task starts to make sure the AUX task that *generates* Analog Comparison Events starts *last*.

3. After the AUX task runs to completion, I queried for # available samples from the tasks that depend on AnalogComparisonEvent for sampling.  We don't know how many there will be.  (And from the previous note I made, the # for the CI task may or may not be 1 less than the # for the AI task.)

4. I added compensation for the first period measurement depending on X-series vs M-series.  Right now it's a GUI selection, but there are ways to query DAQmx properties to figure it out programmatically.

5. I added the cumulative sum to generate an array of relative time to be used for the XY graph.

-Kevin P

[nicky15]

I really appreciate your help.

The vi that you made for me works very well in my DAQ card and very Thankful.

But still have one more question about synchronization.

My final goal is to make a Main signal sample point match at the exact same time at the AUX signal Falling or Rising edge.

Which Main signal(red) sample points have to be made by falling edge at Aux signal(white) at same time.

(In the picture, the sample points doesn't match at Aux signal Falling edge and also, the signal in the XY graph and trigger0 signal in AUX graph are same signal, but it shows different.)

To solve this problem, I changed vi by referring to the analog input-synchronization example. You can see the picture below.

The example only shows using one kind of DAQ card (M or X series). However, I use M(PCI) and X(PCIe) series. I changed vi like that and when I hit the play button, the error code 89131 came out.

In this case, I have no idea what to change to remove error. Can you help me again? 

(I attached vi that I changed)

[Kevin_Price]

I made just a few mods to the vi you posted, give it a try.

1. I fixed a subtle error I introduced when changing the order of task starts and removing extra sequence structures.  If you examine the task wires closely in my previous posted code, you'll find that what *looks like* a task ref coming out of the output terminal is actually connected to the input terminal side of the wire.  Same for a couple of the error wires.

2. Your new error seems to be caused by the new stuff you added when looking up that example.  The Ref Clock and Master/Slave Sync things aren't useful for this app so I removed them.  (Note: I've only rarely needed to configure Ref Clocks and I think I only dealt with Master Slave Sync one time ever and it was a special-purpose PXI board.  I think a lot of boards won't support it.)

3. I saw that you added triggering to your Main AI task.  I hadn't anticipated needing that because I didn't expect the AUX AI task to generate any AnalogComparisonEvent signals before it was started.  And since it was started last, the other tasks should be ready for the first ACEvent.

   I'm not around hardware to test and am kinda surprised if it was *necessary* to add triggering to the Main AI task.  I'd want to investigate that a little more, but in the meantime and just in case, I also added an Arm Start trigger to the CI task.  (Counter input tasks can't use a regular start trigger, only an "arm start" trigger.  Dunno why, it's just always been that way for the 20+ years I've dealt with counters on NI devices.)

Note also that the GUI boolean to select M-series or X-series is only relevant to the CI task.  They have different behavior for the first period they measure in a buffered task and that effects how their timing data needs to be processed.

-Kevin P

[nicky15]

Thanks again.

I try it with your vi and the result is picture down below.

It seems that signal in the XY graph and Trigger0 signal in the AUX graph are the same.

But the problem is sample points in the XY graph still do not fit in the rising or falling edge. 

(In picture i did with rising edge)

Also, trigger0 signal in Aux graph will change to TTL signal because of Analog comparison event and this TTL signal will make sample point at rising or falling edge depending on what I use. So, it has to be make a single sample point at rising or falling part of trigger0 signal at AUX Graph. But in XY graph, there is a lot sample points. In this case, I don't understand. 

I am a little confused about the trigger. 

What I think of the Trigger property node in AUX AI, this will use the criteria of Analog comparison event that makes TTL signal.

(I found this information at DAQ X series user manual.)

Also this Trigger node works as the start point when to get the signal.

If this is right, I have to match the same trigger edge COUNTER, Main VI and AUX VI to start them at the same time. If AUX VI is falling and Main VI, COUNTER is rising, there is a time gap between falling and rising edge, so it won't start at the same time.

Is this right?

[Kevin_Price]

1. Re: Trigger Polarity

    The "Analog Comparison Event" is a TTL signal that asserts high when the triggering condition is met.  In your case, that's when the analog signal has a falling slope passing through your "level" setting, which is 0.1 V.   It will remain high until the analog signal rises above "level" + "hysteresis", which is 0.1 + 0.1 = 0.2 V, making the A.C.E. go low.  And so on.

    But note that a *falling* edge on the original signal results in a *rising* edge of the Analog Comparison Event!   That's why I set the Main AI sample clock and the CI Period tasks to sample on the rising edge of the A.C.E.

2. Triggering

    I still suspect you don't need to trigger the Main AI task or the CI task.  I suspect that the AUX AI task won't be generating any A.C.E.'s until you start the AUX task, thus no need to make the Main AI and CI task's wait to be triggered.

    Try an experiment where you never start the AUX task.  Instead, in that same sequence frame, just wait for a little bit of time.  Based on your graphs,  100 msec would be plenty.  Then use debug probes or indicators to show the result of the "AvailSampPerChan" properties.  I expect both to be 0 because I expect no A.C.E.'s will be generated from an AUX task that isn't started.  If so, you don't need Main AI or CI to be triggered.

3. Too many XY points

    Here I would troubleshoot by more closely examining the individual periods being measured by the CI task, with special attention paid to the minimum measured period (unless it's the very 1st one on an M-series board). 

    I'd also try to look at the Trigger0 signal on a scope.  It may be the case that the analog trigger detection circuitry operates much faster than your present 10 kHz sample rate and is properly catching some signal dynamics that happen between the samples you capture.

-Kevin P