MEan value in one second from a series of signals from DAQ board

[poorinLabVIEW]

Hi,

I am trying to average the signals in one second from my DAQAssistant.I am using a shift register to add all the signals in one second interval and then diving the output of the shift register by the number of iterations of my while loop(which I thought should be the total number of samples per second-1).But when I investigated the value of i of the inner while loop by placing an indicator it always returns a value which is equal to my (sampling rate of DAQAssistant)/Samples to read.Then it means the mean value that I am getting is wrong althought he mean value seems in the range of signal that I get.

 I wanted to use an array to store all the signals  in one second but I might have to increase the samples to read value in that case it wont be very efficient way to store 500 data in an array.

Any help regrading how to get mean value over one cycle would be greatly appreciated.

 Thanks

[RavensFan · Accepted solution]

That's because one iteration of the loop returns a dynamic data type which is underneat the hood an array of 100 samples.  The loop runs 10 times because you are stopping the loop after 1 second, it runs for 1/10 of a second because that it the 1000 Hz divided by 100 samples.  That is why i +1 equals 10.

Now you have 10 arrays (buried in the dynamic data type) summed together.  Divided by 10 gets you the average of those 10 arrays.  But that average is still an array (buried in the DDT)  But when you wire it up to the Mean indicator, it is only returning the average of the first sample of that averaged array which is why your mean looks basically fine.  However the averages of the other 99 data points (x 10 loop iterations) are lost.

You would be better off getting away from the DDT.  Just work with arrays.  Append the 10 arrays to each other.  Now you will have a thousand element array which you can just wire to the Mean function from the Statistics palette.  You won't have to worry about counting loop iterations, summing and dividing. 

Message Edited by Ravens Fan on 08-13-2009 11:37 PM

[poorinLabVIEW]

It seemed to work quite well until I found that there is some delay between the data that I get  when it is written to a text file and the actual data(I am using a well-known behavior sample and my DAQ board is giving the shear force signal.We know the values of signal as a fuction of time for our set up).I thought it might be because of conversion from dynamic data type in each iteration of the loop.So I built a new VI using merge signal function in stead but I am not sure if it is performing the same operation to give me the mean value per second.Does it seem corect?The values that I am getting are substantially different so any suggestions where I might be wrong would greatly be appreciated.

 I cant use the smaples to read equal to smapling frequent to avoid using the inner while loop because that slows down the main vi a lot where this vi will be used as a subVI.

Thanks

[RavensFan]

Yout don't want to use merge signals.  That function basically takes 2 different dynamic data type wires and turns them into one wire.  But it is like building a 1-D array.  If you combine two single signals, you wind up with a single wire with two channels on it.  If a wire has 2 channels and another wire has 3, now you have one wire with 5 channels.  They are all distinct from each other.  Any math operations such as mean will act on each channel individually.  The math operations won't be able to act on the data like it was some sort of combined data group.

---

poorinLabVIEW wrote:

 I cant use the samples to read equal to smapling frequent to avoid using the inner while loop because that slows down the main vi a lot where this vi will be used as a subVI.

---

I don't know why you say this.  As it is now, your inner while loop doesn't end until you've accumulated one second's worth of data.  You are just iterating it 10 times and taking 1/10 of a second at a time.  You might as well just run the function one and collect the entire second.  Either way, this inner loop of code is going to take 1 second to run.  If this is a subVI that causes other problems in a main VI, the problem will be the same either way.  You will have to do something different with your program's architecture.  We can't comment on the overall architecture since this is the only piece of code you posted.

---

poorinLabVIEW wrote:

It seemed to work quite well until I found that there is some delay between the data that I get  when it is written to a text file and the actual data(I am using a well-known behavior sample and my DAQ board is giving the shear force signal.We know the values of signal as a fuction of time for our set up).

---

I don't know why you say this either.  Your VI doesn't show any file I/O anyway.  What delay are you talking about?  You can't write data to a file until you collect it, so there will always be some sort of delay.  But even then, what does it matter?  A file is intended for long term storage of the data.  If it takes a fraction of a second to get the data and write it, or it takes 10 seconds, who cares?  As long as it gets to the file.  No other program can really use the data in the file anyway until the LabVIEW program is done writing it.

[poorinLabVIEW]

Ok here is my problem,we have a stage moving back and forth and the stage changes it direction in every one second and we need to get the mean shear force from the contact per second from the stage.Now as there is a delay when we stop the measurement we actually lose some later part of the data.Also I think the delay is inherent to the fact that the loop iteration more time than 1 second so even when the stages have changed direction and running another cycle the daq board are not actually collecting data from the stage rather the loop being busy with the conversion from ddt and writing to file to complete the current iteration.In other words the finish of the loop iteration and the stage direction change is not happening even simultaneously but there is a delay which wont give us an accurate result.And the problem is stage motion control and data acquisiton is run by two different loops.

Do you think the if I use "Append Signal express VI" it would work?I attached my VI here(I have incorporated  the daq subVI part in the program in the lowest loop although I wish to use it as a subVI to decrease the number of parallel loops running as I have a dual processor only).

Also the slow down of the main VI goes away with using less number of samples to read(It might be due to other reasons from the main program but thats what I noticed).

Thank you very much.

[Alain_S]

I took a quick look at your large, very large vi

A lot of things things aren't right here, so it will be a rather long post  

Your biggest problem is that you have three loops that runs independently from each other. There's no synchronization at all. So every one is doing what he want/like and you try to synchronize them with some timings Not good, definitely not good

Allow me to summarise some things:

• You have a stage that goes back and forth in 1 second. Is this a fixed time or can it be changed in the future?
• You need to acquire data during the movement of the stage. Is that during both movements or only during back or forward?
• After acquiring data you need to process and save the data. Is that after every movement, back - forward, or after one complete cycle back & forward?

I think you should brake up your process into specific states and use a state machine in your program.

Don't forget the buffer on the DAQ card, it can store samples for you

Now you setup your DAQ task "Continuous sample" - 300 samples to read - sample rate 1kHz.

And then there's the Elapsed time that stops the DAQ, curious, very very curious construction
Why such strange construction ?

I mean, you know the travel time of the stage 1s, you have a sampling rate of 1kHz. So during one movement you expect 1s * 1kHz = 1000 samples.

So define a finite acquisition of 1000 samples no more no less.

You can also make a triggered acquisition that starts once the motor starts.

Search the examples for a triggered acquisition:  Help\Find examples\Hardware Input and Output\DAQmx\Analog Measurements\Voltage\Acq&Graph Voltage-Int Clk-Dig Start.vi would be a good place to start

During the movement of the stage the processor has nothing to do except process the data from previous movement and save it to file.

It has 1 or 2 seconds to do that, plenty of time if you ask me.

You should place a button used in the Event Structure in the event state of that button instead of having it "floating" around your vi.

You should use less local variables and more property nodes or a cluster with a shift register to bundle all your variables.

Finally I'm pretty sure that everything can be handled in one loop with a well defined state machine.

A measure sequence could be something like this

• Start the motor, acquisition will start automatically due to the triggered acquisition
• Process & Save data from previous movement
• Wait for one second, or if you can read the motor position during movement, check it or check arrival status, or ......... I don't know your motor drive
• Read the buffer from the DAQ card
• Start all over again if needed

Like I said, rather long post but I hope it helped you a bit.

Message Edited by Alain S on 08-15-2009 10:50 AM