Stopping a (Begin/End)ReadMultiSample()

[TonyH]

The problem was that the data was not being transferred from the FIFO often enough when acquiring small amounts of data. What happened is that when the FIFO finally got half full and forced the transfer, it was already several times the number of points you wanted in one read. Then, the next several reads completed instantaneously out of the software buffer, causing the apparent jerkiness in the graph update. Basically, the driver, by default, is tuned for faster acquisitions of more points than you were acquiring. You are going slow enough to force more frequent transfers from the FIFO without problems. (Don't worry, you will get an exception if something isn't keeping up. Let us know if that happens and t
here are a few other things you can do.)

Tony H.
Measurement Studio

[densmore]

One last question. Is the Trigger channel interrupt driven or is it checked by the processor every so often? Thanks

JMD

[TonyH]

The trigger detection is handled completely on the DAQ card. Once the task is started, the board starts listening for the trigger, then the trigger is detected and data acquisition is started completely independently of the computer's processor.

If you are worried about missing triggers, use the code sample I posted. It reroutes a retriggerable counter output to be used as the sample clock for the analog input and will not miss any triggers.

Tony H.
Measurement Studio

[densmore]

Thanks, My advisor is grilling me about how the card works and what the software is doing.

The code sample that you posted, I'm not sure if I understand what it's doing.
(1) The card receives a digital start trigger on "/dev/pfi1".
(2) a pulse train starts with with a frequency of "rate", this is going to be used as the clock for the AItask.Timing. Do I need to connect "/dev1/ctr0" to "/dev1/ctr0Out"?
(3) AItask is going to aquire continuous data at a rate "rate". As long as there is signal on the clock channel.
(4) This is where it gets iffy,
(a) starttrigger.retriggerable = true, creates a pulse when a trigger is received. What does this do and where does the pulse go?
(b)
When the nth trigger is received, the COtask task starts the pulse train, and AItask starts to aquire data?

After thinking about it for awhile I think I might understand whats happening. I would have never thought to do this. Thanks for you help.

JMD

[TonyH]

(1) The card receives a digital start trigger on "/dev/pfi1".
(2) a pulse train starts with with a frequency of "rate", this is going to be used as the clock for the AItask.Timing. Do I need to connect "/dev1/ctr0" to "/dev1/ctr0Out"?

No, the counter's output is always directed to the "/dev1/ctr0out" terminal. You don't have to do anything special.

(3) AItask is going to aquire continuous data at a rate "rate". As long as there is signal on the clock channel.

Right. And there will only be a signal on the clock channel for count points after receiving each trigger. Note that in this case, the rate you set on aiTask is just a hint to the driver.
The rate set on coTask actually controls when data are acquired.

(4) This is where it gets iffy,
(a) starttrigger.retriggerable = true, creates a pulse when a trigger is received. What does this do and where does the pulse go?

Setting the start trigger to be retriggerable basically says that the task should automatically re-arm and start waiting for another trigger immediately each time it finishes generating its pulses. Ideally, you would just set this property on aiTask, but that is not supported directly. The hardware can only do it on counter tasks. Each time a trigger is received, coTask will generate count pulses which cause count samples to be acquired by aiTask.

(b) When the nth trigger is received, the COtask task starts the pulse train, and AItask starts to aquire data?

When a trigger is received, the counter generates its pulses. When it is done with its pulses, it immediately begins waiting for another trigger. aiTask is always
sitting around waiting for a pulse on the counter output to tell it to get a data point. It knows nothing about triggers in this case.

Tony H.
Measurement Studio