topic Re: Stopping a (Begin/End)ReadMultiSample() in Measurement Studio for .NET Languages

Stopping a (Begin/End)ReadMultiSample()

densmore — Mon, 19 Jan 2004 18:44:19 GMT

I have setup a task with AI channels and timing parameters. I've have the timing to read a finite number of samples. I'm using the endreadmultisample(ar) function to read the data back and then check if the task.IsDone to determine if I should call BeginReadMultiSample. See the attached file for the complete code. My question is -- Is there a more effiecient way of stopping retievial of samples after the task has finished?

Re: Stopping a (Begin/End)ReadMultiSample()

nd — Mon, 19 Jan 2004 20:26:12 GMT

Hi densmore,
Do you want to read a continous amount of data or finite ?
I have to admit that i'm a little confused about why you are reading 2 points at a time.
(though this code may just be a snippet of what you want to do...)

imo a more efficient way to do it would be to specify 10 points in the ConfigureTiming call, and then specify 10 points in the BeginRead (not 2). Whenever your 10 points are read, the callback is called...
Since the BeginRead is asynchronous, (and the actual read occurs in a different thread) really the amount of data that u are reading does not matter, in that the UI WILL remain responsive thu out the operation..(if that is a concern).

This way you do not need the myTask.IsDone block and you do not need to call any additional BeginRe
ads (you'll have just one instead of 5).

The AcqVoltageSamples_IntClkAnalogStart example,that ships with MeasurementStudio (MeasurementStudio/DotNEt/Examples/DAQmx/AnalogIn/MeasureVoltage )would be a good reference, without the triggerring of course..

If you want to read a specified amount of points continuously (say 10 points continuously) then you don't need to set the number of samples in the ConfigureTiming. You can set the ConfigureTiming to be Continouos (instead of finite) and then specify the numberOfSamples to read as an argument to the BeginRead..
Hope this helps, if it doesn't 🙂 or if you have any more questions then please feel free to email us again..

Best regards!

Re: Stopping a (Begin/End)ReadMultiSample()

densmore — Mon, 19 Jan 2004 23:27:00 GMT

Thanks for your response. What I want to do is take ~4000 measurements over a time period of between 30-300 seconds. While taking the measurements I want to be able to graph the results and do other various analysis of the signal. So basicly I want to view the results in "real time".

Re: Stopping a (Begin/End)ReadMultiSample()

TonyH — Tue, 20 Jan 2004 16:39:30 GMT

In NI-DAQmx, the data acquisition (measuring the voltages) and the data retrieval (reading the values) operate independently. Task.IsDone determines whether all of the data have been acquired, but when it reports true, it is possible that you have not retrieved all of the data even though the DAQ card has acquired them. Because of this, you should not use Task.IsDone to determine whether to continue reading.

In a finite acquisition, you have set a particular number of data points to acquire. The best way to stop is simply to stop reading once you have retrieved all of the points you set the task to acquire. You can use Task.Stream.CurrentReadPosition to determine how many points you have read, or you can simply keep the count yourself.

What is happening
is that once the task starts, either by calling Task.Start or by doing your first read, the NI-DAQmx driver starts measuring and putting data into a buffer at the rate you request. Whenever you read 2 points, the read asyncCallback will be called and EndRead will return the first two points that you have not yet read. If there are not two points you haven't read, it will wait until there are before calling the asyncCallback for the read.

Incidentally, if you attempt to read again after the task is done, it will simply restart the task.

Let me know if you have any more questions.

Tony H.
Measurement Studio

Re: Stopping a (Begin/End)ReadMultiSample()

nd — Tue, 20 Jan 2004 16:45:21 GMT

From your explanation, what you are doing makes sense..there is a trade-off of course, between efficieny and getting the results in "real-time"..

One way i can think of, that may be a little more efficient, is to still avoid the check for myTask.isDone (the call to the driver).
Instead you can make it a continuous operation, and use a variable to calculate how many points have been read (you are specifying the number of points to read in the Read-use that). Obviously , the bigger chunks you read, the more efficient your operation will be.
When you have read the requisite number of points, you can call a myTask.Stop.
This is of course based on the assumption that quering a variable is quicker than querying the driver, which is a fairly good one
🙂

Hope this helps, please feel free to post again if you have any further queries...

Re: Stopping a (Begin/End)ReadMultiSample()

densmore — Wed, 21 Jan 2004 04:39:40 GMT

Thanks for all your responses, it helps a lot. I have a second question. I setup a task with AIChannels, timing, and a trigger. I start the task, and the board receives the first trigger. It aquire's and process's all the data. Then the board receives a second trigger. Does the task restart? Does the CurretnReadPosition reset to zero? Basically I want to preform the same task multiple times without having to restart my DAQ program.

Also are there any books out for programming in MS using C# and .net framework?

Re: Stopping a (Begin/End)ReadMultiSample()

TonyH — Wed, 21 Jan 2004 16:18:37 GMT

In the case you describe, the task will not start acquiring data again when the trigger occurs again unless you start the task again once you have retrieved all the data from the first run. You can restart the same task as many times as you want without restarting your program.

Starting the task is something that must be done in your application by calling Task.Start or performing a read operation. Once the task is started, it begins watching for the start trigger, if any, and starts acquisition when the trigger occurs. Once all of the samples have been acquired, the task stops and the data remains available for you to retrieve until the task is started again.

Also, if you start the task using Task.Start, it is best to always
use Task.Start to start the task and call Task.Stop when you are done. If you start the task by reading from it, you should always start the Task in that way.

As far as books go, there is nothing specific to Measurement Studio so far, but there are an abundance of good books and websites for .NET programming. For books, look at Jeffrey Richter's "Applied Microsoft .NET Framework Programming" and for websites, MSDN and GotDotNet are good places to start.

Tony H.
Measurement Studio

Re: Stopping a (Begin/End)ReadMultiSample()

densmore — Thu, 22 Jan 2004 17:12:21 GMT

I'm kinda concerned about missing the next trigger, because I'm still reading the data from the buffer. When a task is restarted the currentreadposition is set to zero? Is the data buffer emptied when a task is restarted?

Re: Stopping a (Begin/End)ReadMultiSample()

TonyH — Mon, 26 Jan 2004 19:38:06 GMT

You are correct. When a task is restarted the current read position is set back to zero and the data buffer is emptied to prepare to receive new information. However, there is another way to do what you want.

You can use a counter and a continuous analog input task to guarantee you don't miss any triggers. I've attached code that demonstrates how to do this on a MIO 16XE 50. (If you have a different card, you may need to adjust some terminal names for your hardware, but the overall steps are the same).

I was also able to reproduce the problem you were having with the graph not update. It was due to data being kept in the buffer on your DAQ card and not being transferred to the computer. To force the on-board data
to be transferred to the computer more regularly, you can either force the card to flush the buffer whenever it has the opportunity like this

aiTask.AIChannels.All.DataTransferRequestCondition = AIDataTransferRequestCondition.OnBoardMemoryNotEmpty;

or you can reduce the size of your buffer:

aiTask.Stream.ConfigureInputBuffer(2*count);

where count is the number of points you read each time.

Let me know if you have any problems with this.

Tony H.
Measurement Studio

Re: Stopping a (Begin/End)ReadMultiSample()

densmore — Wed, 28 Jan 2004 07:52:01 GMT

I added the

AIDataTransferRequestCondition.OnBoardMemoryNotEmpty;

property and that solved the problem. Was the card not transfering the data form the fifo to the software buffer fast enough? I was able to use the debuger and see data in the array that I wanted to plot, but it wasn't showing up on the waveform. Thanks for the help. Really GOOD tech support!!!!!!!!!

JMD

Re: Stopping a (Begin/End)ReadMultiSample()

TonyH — Wed, 28 Jan 2004 16:01:21 GMT

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

Re: Stopping a (Begin/End)ReadMultiSample()

densmore — Wed, 28 Jan 2004 17:12:32 GMT

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

JMD

Re: Stopping a (Begin/End)ReadMultiSample()

TonyH — Wed, 28 Jan 2004 17:30:08 GMT

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

Re: Stopping a (Begin/End)ReadMultiSample()

densmore — Wed, 28 Jan 2004 20:15:55 GMT

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

Re: Stopping a (Begin/End)ReadMultiSample()

TonyH — Wed, 28 Jan 2004 20:46:58 GMT

(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