Labview DAQ Acquisition Delay

[sgo927]

Hello,

Thanks in advance for your advice - I've been teaching myself Labview for the last few months and this forum has been incredibly helpful! 

I have written the following program to continuously sample data and display the data on a waveform chart (the second waveform chart is just for troubleshooting the second channel of data; this is not going to be seen by the user). The user can start/stop saving data by clicking the "start/stop collection" button. I set the number of samples to be read to -1, which seems to have solved my previous problem, where the number of saved data points = (number of samples to be read)/(sampling rate).

However, I noticed that doing so introduced a ~1 second time delay. Does anyone have any insight into what might be causing this and how I can go about fixing it?

Thank you! 

edited 5:29PM - correct code attached

[RavensFan · Accepted solution]

You are only reading 1 sample every loop iteration sampled at a rate of 2400 samples/second.  You are probably falling behind because your loops can't run that fast.

In addition, when you find "trigger" and exit that loop, you have file logging code in the same outer while loop.  Writing to files takes longer than a lot of operations.  So that is keeping you from getting back and collecting more data.

Collect all available data like you said.  Use a producer consumer to pass that data off to another loop that does the file logging for you.

[sgo927]

Hi RavensFan, thanks for your advice.

I should clarify that the delay I'm primarily concerned about is the delay between when I pull on my force transducer and when I see signal on the chart. I expect this to be almost instantaneous, but as you said, the delay is probably due to the fact that I'm reading 1 sample every loop iteration. The reason why I have set to read 1 sample every loop iteration is that when I set it to 240 samples per loop iteration, sampled at a rate of 2400 Hz, my data was being saved at an effective rate of 10Hz (so 10 seconds of data --> 100 data points). When I read 1 sample every loop iteration, I get the expected number of data points (10 seconds of data --> 24000 data points).  

When you are talking about "file logging code" - are you referring to the code where I build my arrays of data, or the code where I save the data to a spreadsheet (last frame in sequence)?

So I suppose my follow-up question is - is the delay I'm seeing between when I activate my device and when I see the signal on the chart due to sampling, file logging, or both?

Thank you!

[RavensFan]

The file logging code I'm talking about is where you actually log the data to the file.  In the last part of the master while loop.

My gut feel is the problem is the way you are sampling it.  You are getting 1 sample at a time, but filling your data buffer in your daq device at 2400 Hz.  So if that first loop run faster than 2400 times per second, then the buffer slowly fills up and it takes a while between when you make a change and it shows up in the buffer, and when you finally get around to reading it.  Imagine you are working on paperwork and grab a paper from the inbox and you can process 1 paper a minute.  But your boss is putting work into that box at a rate of 3 times per minute.  It is going to take a while until you get to whatever piece of paper he just put in.

[sgo927]

Ok. That's what I thought too. 

So as I mentioned previously, this delay was introduced when I changed the number of samples to read from 240 samples to 1 sample. I did this because  it was not saving 2400 samples/second, but did so when the number of samples to read was set to 1. Will implementing producer consumer loops mitigate the saving and sampling issue? 

[RavensFan]

Why was it not saving 2400 sample/sec when you had the number of samples to read at 240?

Implementing producer/consumer will help a lot.  It will at least untangle the two major functions of your code from each other.

[sgo927]

I'm not sure why that was happenning. Now that I think about it, it may be how I "build" my temporary data arrays when I click the button to trigger the collection. 

[RavensFan]

How big are your arrays getting.  If they grow very large, then you might have some problems with the code slowing down if it needs to do some memory management to handle ever-growing arrays.

One thing I see odd is the way you are initializing the shift registers with a single element of the value 0 coming out of the Init Array function.  So your first element will always be zero.  What is normal is to initialize it with an empty array.  That way the first element you build onto the array will be the first element.

[sgo927]

I actually tried using the "Write to Measurement File" vi and it solved all my problems! Thank you for your advice!