Start Trigger for Analog and ArmTrigger for Counter task necessary?

[ekcireg]

Hey guys,

I am currently trying to aquire data from an analog input task (pressure sensors conncected to a NI 9205) and a counter input task (measuring flange for angle measurements on a NI 9411) in sync. I use the ai timebase of my analog task as a source for the sample clock of the counter input task for that. Since the counter input task is an optional feature of the data aquisition the syncing might be questionable but that is a topic for another day and the aquisition seems to be working fine for that.

Now i have a reference signal for my measuring flange, which will send a signal per revolution and want to start my measurement of the analog and counter task, when the signal has been detected. What I've done is using a start trigger with the DAQmx Start Trigger API for the analog task and a ArmTrigger for the counter using the PFI line the trigger is sent to.

However when doing this the tasks do not seem to start at the same time, since the samples in the buffer for both tasks differ immensely and when writing the data to a tdms file the number of samples for a rate of 40 kHz differ by ~6000 samples.

Now i am unsure if this is a problem with my QMH Framework or if I am misunderstanding how syncing the tasks actually works when working with triggers. 

Currently I do not make sure that the Counter Tasks starts before the Analog task which was propositioned by Kevin [here], however I am unsure if this will fix the problem entirely, since when looking into it, it seems to me that the counter starts before the analog task. Thats why I wanted to ask if i even need the ArmTrigger for the counter task, if I use the timing source of the analog task and the trigger to start it and make sure the counter starts before the analog task?

Or if it is better to use the ai/StartTrigger source for the ArmTrigger to not have a delay?

Sorry if my wording is confusing, since I am not a native speaker.

Thank you in advance and I'll hope you'll be able to help me,

ekcireg

[Kevin_Price]

Going back off grid in a couple minutes until next week. 

In the meantime,  it's probably a good idea to listen to that Kevin guy -- he sounds like he knows his counter timer stuff pretty good.

-Kevin P

[santo_13]

Kevin is one of DAQmx experts on this forum, I would heed to his recommendations.

[Kevin_Price · Accepted solution]

Several things to start, and expecting discussion to continue.

1. Using the analog task's timebase as a source from which to derive your counter task's sample clock is probably a more complicated approach than necessary, and easier to get subtly wrong.  I see that my old msg you linked may have steered you in that direction though.  What I *didn't* elaborate on in that old msg is that a timebase is often shared implicitly and indirectly rather than explicitly and directly.  My main emphasis was intended to be that all tasks should ultimately derive their timing from one and only one master timing source.  Quite often that can be the (derived) sample clock from a designated master task which is shared and used by the dependent tasks as their own sample clock.

    In such an arrangement, all tasks ultimately derive their timing from the timebase used to set the master task's sample clock.  Thus they "share" the timebase.

2.  Lack of sync for your triggering situation *could be* a case where the AI task and the Ctr task are being triggered on different revs of the 1-per-rev signal.  This can be fixed, but there are other possible causes too.  One is that the 9205 uses a Delta Sigma converter for AI, which puts a filter delay into the AI data stream.

3. A first relatively simple approach to try:

- continue to configure the AI task to use the 1-per-rev signal as a Start trigger

- for now, don't bother setting up an Arm Start trigger for the counter task

- configure the counter task to use the AI task's *Sample Clock" (not the timebase) as its own sample clock.

- yes, be sure to start the counter task *before* starting the AI task

Neither task will sample until the AI task is triggered, starting up the AI Sample Clock.  The first counter sample is likely to be non-zero, tracking movement from the time the counter task is started until the AI task generates its first sample clock pulse.  It's likely that the first AI sample represents an AI signal value from a short time in the past due to the Delta Sigma filter delay.  You can compensate for this if you need to, but your post suggests that's not a big concern.  At least not yet.

-Kevin P

[ekcireg]

Hey Kevin,

first of all many many thanks.

At some point I strive to be as knowledgeable about all things regarding NI as you 😉

And many thanks for giving such an in depth explanation even with the limited shared information and code from my side.

Regarding 1:

Thank you for the explanation. That does make a lot of sense actually and I've learned a bit on how to set up clocks.

Regarding 2:

I think as you've mentioned the problem is that the counter task received its trigger at a different point in time than the analog task due to how i set it up with the ArmTrigger. Which is why i removed it.

The delay i have been aware of and actually have looked into for my task with the Property DAQmx.AIConvert.Rate... but it didn't account for all the values missing only least from my calculations. Though you might be correct that it might be a mix of that and the trigger and some other stuff.

What I've just now began to wonder:

If the clock of my counter is derived from the analog task is the interchannel delay still visible in the clock and sampling of my counter?

Regarding 3:

I'll try that and already implemented your suggestion and will update when I've been able to test again on the teststand.

Probably will be at the end of the week.

That the counter doesn't start at zero I've seen when testing. 

Though i wasn't quite sure why. I've read somewhere that counters do not have a buffer and just start reading anyway until some trigger occurs. Though i am not sure why one thing leads to another.

And you are correct that the filter delay isn't much of an issue. Though it might be for another application I'll have to develop further down the road (and where we thought about buying a new module).

Should i make another topic about that?

Or do you have some information to point to, since i couldn't find anything rn, though to be honest i haven't looked that deeply into it.

Kind regards and many thanks again,

ekcireg

[Kevin_Price]

---

The delay i have been aware of and actually have looked into for my task with the Property DAQmx.AIConvert.Rate... but it didn't account for all the values missing only least from my calculations.

What I've just now began to wonder:

If the clock of my counter is derived from the analog task is the interchannel delay still visible in the clock and sampling of my counter?

---

    Until or unless you get deep into the details of timing and sync, AIConvertRate and interchannel delay considerations won't really be a consideration for your counter samples.  AIConvertRate refers to the multiplexing clock used to share a single A/D converter among multiple AI channels.  In DAQmx's terminology, 1 sample refers to 1 sample per channel in the task.  If you have 4 AI channels in your task, 1 sample consists of 1 pulse of the sample clock, 4 pulses of the convert clock, 4 total A/D conversions, 1 A/D sample per channel for all channels in the task.  Essentially, each sample clock pulse triggers the convert clock to produce a finite pulse train meant to accomplish 1 sample per channel before the time comes for the next sample clock pulse.

    When you share the AI sample clock with your counter task, the counter only samples its count value on the sample clock pulse.  It doesn't see or receive the convert clock pulses at all.

---

I've read somewhere that counters do not have a buffer and just start reading anyway until some trigger occurs. Though i am not sure why one thing leads to another.

    Here's a basic fundamental fact about counter operation: once a counter task is armed, active edges at the Source terminal will make the count register increment by 1. By default, arming occurs when you start the task.  But if you've configured an Arm Start trigger, arming occurs when the trigger signal asserts.  The active edge is typically rising by default, but can be configured to be falling.  Incrementing by 1 happens by default, but you can configure to decrement by 1 instead.

    A very important concept when dealing with counters is to draw a clear distinction between counting and sampling.  Counting is what goes on deep inside the device in the count register.  Sampling is when an instantaneous count value is latched in preparation for DAQmx to make it available to your application.

    When you think it through, you'll see that this is very analogous to analog sampling.  An AI sample captures one instantaneous voltage value from an analog signal that might be constantly changing.  A Ctr sample captures one instantaneous count value from a count register that might be constantly changing.

    As to your question about filter delay, that should probably be a new post.  The spec sheet for any Delta Sigma device will have a formula for calculating the delay.  What I've always found in practice is that at the modest sample rates I typically dealt with (rarely beyond 10's of kHz), the delay is dominated by the digital filter stage.  The delay from a digital filter amounts to a specific # of samples, regardless of sample rate.  (Note that the spec sheets express it as a ratio that involves the sample rate, but when you work through your units you find that the ratio reduces down to a simple # of samples.)

    There's also a relatively short delay from an analog filter stage which is expressed in units of pure time.  In the modest realm of sample rates I dealt with, the analog delay was a much smaller contributor.

-Kevin P

[ekcireg]

Hey Kevin, 

thanks again for elaborating on the questions I've asked. I appreciate it!

---

@Kevin_Price wrote:

When you share the AI sample clock with your counter task, the counter only samples its count value on the sample clock pulse.  It doesn't see or receive the convert clock pulses at all.

That's good to know and does fill some gaps from my assumptions i got from the LabVIEW Help. 

    A very important concept when dealing with counters is to draw a clear distinction between counting and sampling.  Counting is what goes on deep inside the device in the count register.  Sampling is when an instantaneous count value is latched in preparation for DAQmx to make it available to your application.

    When you think it through, you'll see that this is very analogous to analog sampling.  An AI sample captures one instantaneous voltage value from an analog signal that might be constantly changing.  A Ctr sample captures one instantaneous count value from a count register that might be constantly changing.

---

Thanks for clarifying. That does make a lot of sense and I feel like something clicked.

The analogy btw is really great!

I'll post the question about filter delay on another day then (when I am 100% sure what is actually needed in the application), but thanks for the quick overview.

As for the solution to my problem:

Your suggestion with removing the trigger for the counter seems to work. Will mark your post before as solution therefore.

Many thanks again,

ekcireg