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,795 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,791 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,790 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,770 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
(3,508 Views)
Solution
Accepted by topic author BlueRecluse