From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Vi will work in highlight execution but not in normal

Solved!
Go to solution

Description pretty much sums it up. The Vi will write to file in highlight mode but not in normal

0 Kudos
Message 1 of 10
(3,102 Views)

Hi Blue,

 

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?

 

Suggestions:

- 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

 

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 2 of 10
(3,098 Views)

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.

Message 3 of 10
(3,097 Views)

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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 4 of 10
(3,077 Views)

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?  

0 Kudos
Message 5 of 10
(2,815 Views)
Solution
Accepted by topic author BlueRecluse

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.

 

altenbach_0-1575997420921.png

Message 6 of 10
(2,805 Views)
Solution
Accepted by topic author BlueRecluse

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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 7 of 10
(2,797 Views)

@crossrulz wrote:

Your current data rate (3 Samples/second) is not fast enough.


That's the control default here. No way of telling what the user selects later. 😉

Message 8 of 10
(2,792 Views)

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

0 Kudos
Message 9 of 10
(2,731 Views)

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

Message 10 of 10
(2,675 Views)