Trigger DAQmx Data Acquisition after counter reaches defined value

[anhd]

Hey there,

I have a Stepper-Motor that is sending a TTL-pulses on every step.
Is there a way to configure the counter of my PCI-6115 DAQ board in that way, that it will fire some kind of event every time it has counted e.g. 10 steps. I want to use this event then to start a data acquisition.
If i  use a while loop whithin LabView 7.1 to poll the Counter-Value  it misses some Values, so i cant use this method.

Any ideas?

Thank you.

[Kevin_Price]

Can the motor's direction change?  If so, what behavior would you want when the motor goes 18 steps in one direction, then 22 more in the other direction:

1. Generate "event" every 10 steps regardless of direction.  This places events at positions 10, 16, 6, and -4.

2. Generate "event" at absolute positions that are multiples of 10.  This places events at positions 10, 10, and 0.  The # of steps between events would be 10, 16, 10.

If behavior #1 is acceptable, you could simply set up a counter to generate a continuous pulsetrain.  Use the step signal as an external Source (timebase) signal with a total pulse period (low time plus high time) set to 10 Ticks.  All this will happen in hardware so you don't need to worry about software polling, etc.

Method #2 probably can't be done in hardware with your board.

Method #1 should also be fine if direction doesn't need to change.

-Kevin P.

[anhd]

Hello Kevin,

thanks for your answer, that helped me a lot.

The problem that i still have is, that i have to take a measurement  about every 2 millisecs. using the pulse train generated with your hint above as start trigger. I tried to use the
DAQmx-Acquire_N-Multi-Analog_Hardware_Trig_Using.vi
Excample, but somehow it is running to slow to get all the measurments (it misses about 50% of the trigger pulses).
Is there any better way to do this acquistion without running it in a while loop with all the start-task und stop-task vi's?

I also tried to acquire my signal continiously with 10 MS/s for 1 second giving me 10 MS of data. If i could acquire the value of my counter at the same rate also giving me 10 MS of data, i could campare the two arrays and find out my points of interests (every time the counter reaches some multiple of 10) and then read the corresponding index of the Signal-data-array.

But I don't know how to "sample" the counter-value at 10 MS/s giving me an array of 10 million counter-values. It complains about not having a external source all the time O_o

Thanks for your time.

Message Edited by anhd on 06-20-2006 03:43 AM

[Kevin_Price]

---

Is there any better way to do this acquistion without running it in a while loop with all the start-task und stop-task vi's?

But I don't know how to "sample" the counter-value at 10 MS/s giving me an array of 10 million counter-values...

---

1. Yes, there is definitely a better way.  The classic approach that lets the hardware do the work is to configure and start the task 1 time before entering the loop and stop and clear the task 1 time after exiting the loop.  Inside the loop, I prefer an approach a little different than what most of NI's examples show.

  The NI examples will call DAQmx Read asking for some fairly large # of samples.  The loop must then stop and wait for that # of samples to accumulate.  If they don't accumulate within the specified timeout period, you'll get a timeout error which is often wired to cause the loop to terminate.

  I prefer to first query a DAQmx Read property node for the # of samples available.  This will return a value immediately with no risk of a timeout error.  My code can then easily decide whether to read them or wait a bit longer for more samples to accumulate.  There are some other methods too such as specifying # to read == -1.  This returns all available samples, whatever the # happens to be.

2. Counter values can definitely be sampled in sync with analog acquisition, but not in the MHz range.  The available speed is system-dependent, but seems to top out in the 100's of kHz.  The main reason is simply that the data acq board's hardware data buffer for counters is very very small while the one for analog acq is relatively large.  While trying to transfer data across the PCI bus, the counter tasks have very little tolerance for missed opportunities.

Also, I *think* that perhaps you're mixing up the meaning of "trigger" and "sampling clock".  If you want to take a sample of 1+ analog channel EVERY 2 msec based on a ~500 Hz pulse train, you need to treat that pulse train as a "sampling clock" not a "trigger."  There are shipping examples that use the abbreviation "Ext Clk" or similar to denote that the sampling clock is an external signal.

-Kevin P.

[anhd]

Helle Kevin,

thanks again for your explanation on the counter - soooo this wont work in my case.

---

@Kevin Price wrote:

Also, I *think* that perhaps you're mixing up the meaning of "trigger" and "sampling clock".  If you want to take a sample of 1+ analog channel EVERY 2 msec based on a ~500 Hz pulse train, you need to treat that pulse train as a "sampling clock" not a "trigger."  There are shipping examples that use the abbreviation "Ext Clk" or similar to denote that the sampling clock is an external signal.

-Kevin P.

---

@nope, i need the signal as some kind of trigger, as i don't want a single sample every 2 msescs, but to start sampling 50 samples @ 2,5 MS/s every 2 msecs.

Luckily i found an Excample that does this:
Multi-Function-Ctr Retrigg Pulse Train Generation for AI Sample Clock.vi
This one also uses the method u mentioned above: Asking for the number of valid samples available before reading them.

But there's a little Problem with this excample:
@I don't get all the samples needed. When i want to have 50 Samples @ 2,5 MS/s at every pulse of my stepper motor, i should get 50000 samples when i drive 1000 steps. But i get only 49984, meaning that there are missing 16 samples.
When I drive 100 steps, i get 4992 samples, 8 samples missing.
@in another thread I found a hint on the "pipeline-problem" of the S-Series boards (NI-DAQmx Help -> Device Considerations -> Timing -> S-Series). But then i would be missing pipeline-depth samples. How can it then be 8 samples missing @ 100 steps but 16 Samples Missing @ 1000 steps O_o.
According to the specifications the pipeline depth should be 4 Samples?

Type of ADC
Resolution
NI 6115 .................................... 12 bits, 1 in 4,096
NI 6120 .................................... 16 bits, 1 in 65,536
Pipeline
NI 6115 .................................... 4
NI 6120 .................................... 0

The second problem is that at the beginning of each 50-Sample package, the first few samples (maybe Sample-Depth number of Samples)  seem to be invalid - they don't fit into the curve when acquiring a sine for excample:
"There is also a finite amount of time a sample can be held in the pipeline before it starts to degrade and lose measurement accuracy. This time limit imposes a minimum sampling rate that must be met to achieve the measurement accuracy specified for the device. Although you can sample slower than this minimum recommend sampling rate, the accuracy specifications for the device are not guaranteed. Refer to the specifications for your device to determine the recommended minimum sampling rate."

Could this be the reason, as there is a pause of about 2 msecs between every "sample-burst", or am I getting something wrong here?
Thanks for your time again.

Andreas

Message Edited by anhd on 06-21-2006 03:09 AM

[Kevin_Price]

Glad you found the example on setting up a retriggerable finite acquisition.  Dunno why you're missing a few samples.  How exactly are you querying for # available samples and then how are you reading them?  It's gonna be important to resolve this issue b/c once you collect your data, there's really no way to determine which samples were missing (unless you have another available DAQ board with an available counter...)

As to the S-series and minimum sampling rates, I can't comment usefully.  I haven't used the S-series board before.  It sounds fairly reasonable that if there IS a minimum sampling rate, that the ~2 msec between sampling bursts may be an issue.  Perhaps you could take 60 samples per trigger and plan to ignore the first 10 of every group of 60 in your post-processing?

-Kevin P.