you set a samplerate of 3S/s and request 180 samples. This will take 180S / 3S/s = 60s (yes, simple math!).
In "normal" execution mode you will most likely run into a TimeOut error of DAQmxRead because by default it will only wait for 10s. Is there any error message?
- set a fixed number of samples at DAQmxRead. I recommend 1/10 of the sample rate (round to next positive integer)…
- rethink the sample rate and number of samples values
- usually you want to save all measurement data, so place the WriteFile function inside the loop.
- you can OR the stop boolean directly with the error output of DAQmxRead
Usually when I see a question like this, it is a case of local variable abuse and a lack of understanding of dataflow. So opening your VI, I'm surprised to see it is none of those things.
I can't see any reason why your VI would work in highlight execution and not in normal operation. Actually I would expect the opposite that you would get buffer overflow errors in highlight execution. Are you getting any errors on your error wire?
Your VI is setup to only output the last set of data since your Write to File is placed outside the loop. Is that what you intended? Normally, you open a file before the loop, write to it inside the loop, and close it after the loop so that you get all the data. Doing this with real LabVIEW file primitives instead of an Express VI is better.
I think you are just hitting the loop wrong. You are reading all available samples at a very fast rate. But your DAQ is only acquiring 3 Samples/sec = 1 sample every 333ms. You can get a lot of "no data" readings in that time. So your chances of reading actual data when you stop the loop and then log that 1 samples is very small. So some changes I would make for the immediate issue:
1. Get rid of the Samples Per Channel on the DAQmx Timing VI. You are just limiting the buffer and it not really needed when using Continuous mode.
2. Change the DAQmx Read to be in the Multiple Channels->Single Sample. This will make the DAQmx Read wait until at least 1 sample is in the buffer.
Sorry it took so long to respond, I have made some changes to the vi it is working for the most part writing the data to file now but randomly it decides to lose data its almost like it freezes then goes from 16KB of data in the excel file to 0 and starts over again doesnt always happen at 16K and its random sometimes it works just fine. any ideas?
You need to decouple the file writing from the DAQ loop using a produce/consumer architecture. Does it have to be excel? Does it have to be waveforms?
On a side note, your indexing out of the five waveforms, multiplying each, then building back into an array is unnecessary. Just multiply the array of waveforms with an array of numerics.
I would stop using the Write To Measurement File and use the built-in File IO functions to write a text file. Make it tab delimited and Excel will still open it up with no issues. Your current data rate (3 Samples/second) is not fast enough for me to worry about going Producer/Consumer, but you still might want to consider it. The other option would be to set up DAQmx to stream your data to a TDMS file. This is by far the simplest route for writing the data, but reading will need the TDMS plugin for Excel to read it in Excel. That plugin is included in the LabVIEW installer.
Thank you for your input hopefully I will get some time yet today or tomorrow to try some of the suggestions out. I am just a lowly lab tech and have a lot of other duties only get to work with labview in my spare time and normally about once a year an engineer comes up with a test requiring me to do so.
Thanks again for the help
Well I think I got it finally, thanks to all of the suggestions
changed the write to xlsx file to TDMS and implemented the bit of code posted you posted
now I just have to wait for the engineer to come over and see if she can break it again
Thank you again