what is the array being returned by the DAQmx counter READ? How do I know the data flow of two DAQmx READ functions in the same WHILE loop?

[dav2010]

I have a question about the order of execution.  In the WHILE loop, I have two things being measured, period and voltage using the DAQmx READ functions for voltage and counter.  Ultimately, I want to collect these data points as nearly simultaneously as possible, as a pair, and then send them together to another piece of code (not shown here) that will translate them into some kind of command for a motor.  That would be one execution, and then, I want to collect the voltage and period again at a time later, and do the same thing.

1.) I am a bit confused about what the counter READ function is returning because it is an array.  What is it an array of?  I was thinking it was returning the value of individual periods between rising edges.  Actually, the output of the Counter 1D DBL is an array. How many elements are in that array, and what determines the size of that array?  Are the elements of the array the individual periods between edges?  How many values are being stored in the array per execution?   We are taking the MEAN of the last 15 elements, but, not sure if we are throwing away some of the data or what.  How do I understand the composition of that array?  How can I modify the composition of that array?  Is it possible to measure only one period at a time, e.g. the time between only TWO edges?

2.)  Will this WHILE loop execute such that it collects one voltage value, and one "period array" (yet to be understood by me) per WHILE loop execution?  In particular we want the value of the voltage paired with the value of the MEAN of the "period array" so we can use both pieces of data to create subsequent control commands each time the two values are reported.  Will the structure in the attached vi deliver the data in pairs like that?  I want to understand that one of the READ functions does not race ahead of the other READ function in the WHILE loop.  I want the "Period Mean" and the "Strain (Volt) collected at the same rate. Will this vi do it?

Thanks,

Dave

[JasoNI]

Hello,

If you want to synchronize tasks, you can use this example as a template: https://decibel.ni.com/content/docs/DOC-8231

1)     Because you have CI Period selected, the returned values will be an array with each element being period of the signal that is wired into the CI Period Terminal. I suggest looking at this example to learn more about period, frequency, pulse width, and two edge separation. Not all hardware supports all of these functions, so that could be a source of error: https://decibel.ni.com/content/docs/DOC-25244

2)     In the attached VI, you are writing the counter array, and the averaged counter array to a file. In order to control the number of samples taken, the 1000 wired into the DAQmx sample clock can be changed. I have modified the code inside the loop in order to be closer to what you want to do.

I hope this helps!

Regards,

Jason D

Applications Engineer

National Instruments

www.ni.com/support

[dav2010]

Hi Jason,

Thanks for the feedback.  Are you saying that the 1000 samples is the array.i.e., ..that the array is 1000 elements, each being one  period measurement?  If I change that to 1, will that give a single period measurement?  If it is set to "1", will it still be an array data type, or will it change to DBL or something like that?  I"m trying to understand what the size of the array from the DAQmx READ function is, and how I can choose its size.  By the way, I am using cDAQ 9174 chassis and 9401 module.

Thanks for the suggested code inside the WHILE loop.  I'll experiment with that and see if I can make it work.

Dave

[JasoNI]

Hi Dave,

Yes, having 1000 wired in means that you will have an array of 1000 period measurements. If you wire 1 in, you will  get an array with 1 element. If you want just a single double, you will have to change the read VI to be 1 sample instead of multiple samples.

Regards,

Jason D

Applications Engineer

National Instruments

[dav2010]

Thanks, Jason.

[dav2010]

Jason,

I was reviewing my vi, and I noticed that the voltage reader portion does not have a DAQ START function, but, the portion of code that does the period measurement does have a DAQ START task.  I wrote the voltage reader a long time ago, and I am wondering if the START should be added or not.  What is your opinion of whether to include the START task in the voltage reader?  I think it works without the START.

Thanks,

David

[JasoNI · Accepted solution]

Hi David,

I would suggest including the DAQmx Start Task function. If it does not start before the loop, it will start in the loop and work fine, but it will not be as fast and efficient. In the Task State Model, the task wiill go from Running to Verified every loop iteration, and then need to go back from Verified to Running when it starts again.

Task State Model: http://zone.ni.com/reference/en-XX/help/370466V-01/mxcncpts/taskstatemodel/

Regards,

Jason D

Applications Engineer

National Instruments

[Kevin_Price]

I agree with Jason -- start your tasks outside your loop.  I can't open your code b/c I'm on LV 2010, but here's a couple other thoughts that came to mind while reading the thread:

- the counter period data is likely timed implicitly by the signal itself.  This will generally mean that you have a variable sample rate that isn't synced in any way to the sample clock of the AI task.  It can be fine that they aren't, depending on your app, but it IS important that you understand this.

- if you specify a # of samples to read from each task, there's a good chance you will often be retrieving stale data from one or both of them.  Jason's screenshot leaves those inputs unwired, which tells those tasks to do the default thing which is to return all available samples.  His method makes sure that each read will give you all the data you haven't previously read, including the freshest data

- it sounds like you have a control loop in mind for your final app where you will command a motor differently depending on the AI and counter data.   You'll probably want to do what you can to make the loop time as consistent as possible.  Jason's screenshot has a file write inside the data acq loop, and that's fine because he was illustrating acquisition & logging.   However, if you *do* need more consistent timing for a control loop, you should take that out.

- again, if doing a control algorithm, you may want to massage the acquisition data before acting on it.  For example, you might want to put more weight on the fresher data from the arrays you read.  The data will be in order from oldest to freshest, so you'd pay more attention to data toward the end of the array than data at the beginning. 

-Kevin P

[dav2010]

Hi Jason,

One final inquiry about this vi.  I have been studying your comments and the links you sent me, and experimenting with my system and I have a better handle on things now.  Please take a look at the inside of the WHILE loop in the attached vi.  Obviously, it is not wired to execute, but, is the general architecture shown here a legitimate way to force the execution flow? In other words, I want the values of the voltage and period to be measured "simultaneously", and then sent to the FOR loop where they are processed and converted to a command that flows to the case structure.  The case structure then outputs a control command, and the WHILE loop starts over again.  Is the embedded FOR loop the best way to do this, or do I not need the FOR loop at all?

The sequence I am trying to achieve is the following:

Voltage/period data  -> FOR LOOP calculation --> FOR LOOP outputs command to CASE STRUCTURE -->  CASE STRUCTURE command outputs--> Voltage/period...

I basically want the case structure string to output before the next voltage/period pair are collected.

Do I need the FOR loop?

Thanks,

Dave

[dav2010]

Jason,

Regarding the 1000 samples per channel on the DAQmx Timing vi, I am still uncertain what is happening here.  Inside the WHILE loop, we take array elements 0-15, and average them.  So, does that mean we are throwing away 984 other elements for each execution of the WHILE loop?  If so, is it the oldest or newest 984 elements that are being thrown away?   I know that based on the speed of my encoder shaft, there is no way we are collecting 1000 periods each time the WHILE loop executes; that would be about 10 revolutions, and we are executing the WHILE loop several times per revolution, so, the 1000 number is very confusing to me.

What I would like to do is measure a small number of periods, like less than 100, average them, and then pair that average value with the voltage value measured at the "same" time, so, I do not want old data.  I want new data as much as possible.  How do I configure it so that old data is simply thrown away?  I assume that "buffered period measurment" means that the period data is stored in a buffer and then released later....how do I get rid of old data, and only use new data... I don't care to maintain anything in the buffer for later use.

Lastly, another source of confusion for me is that there are " Samples per channel" on both the DAQmx Timing vi, AND the DAQmx Read Counter vi.  Which one controls the number of periods that are actually measured and written into the array output of the DAQmx Read Counter vi?  What happens, for example, if you set the DAQmx Timing vi to 1000, and the DAQmx Read Counter vi to 15?  How many elements will be written to the array before new data begins to be collected and written to the array in the subsequent execution of the WHILE loop?  I'm really confused about what the "samples per channel" function actually does.

"If you want just a single double" .......... what does "single double"  mean???  My original vi is posted again here for your convenience in LV2010; this does not include the changes you suggested earlier.

Thanks,

Dave