From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, 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: 

Simple Labview code running slow

Solved!
Go to solution

Hello everyone,
I am just starting with Labview. As far I have created a basic VI to read measurements from NI DAQ cards, show results on indicators and save them in a file. The problem is that Labview is executing my routine very slowly. I have used a delay in my loop at 200mSec and I am using a modulo division - comparison to write data every 5 iterations. So, the file should save at 1 Sec intervals. However, it only manages to save every about 6 Sec. I believe that I am making a simple mistake but I can't find it so I would appreciate your help.
Thank you for your time.

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

I don't know what is happening in the missing subVI, or why you are using a dynamic datatype wire to be a simple boolean to the Enable of the Write to Measurement File.

 

Take out the Write to measurement and see if it runs faster.  If it doesn't simplify whatever is happening in the missing subVI.  If it is as simple as you say with a quotient remainder function, I have no idea how you managed to complicate that with a blue DDT wire.

 

Try getting rid of the DAQ Assistant an use regular DAQmx functions.  It's possible the 1 sample on demand is slowing things down.  Why not grab 5 samples at a 5 Hz rate with a continuous acquisition, average, then write to file?

0 Kudos
Message 2 of 10
(3,377 Views)

You did not attach the subVI, so we cannot tell if you are doing your division correctly.

You are creating a new file with each write, not very efficient. If speed matters, open the file once, append in the loop, and close the file once the program stops. If speed matters even more, use a producer consumer architecture and write asynchronously.

Same for the data acquisition. Use lower level functions. (sorry, I cannot inspect your daq express VIs because I don't have daqmx installed here)

 

I would also recommend to chart the loop time to see where things slow down.

 

I would recommend to get away from dynamic data and express VIs. They carry a lot of extra baggage. there are significantly better ways to do a running average than an expanded shift register (How do you expand it to average the last 100 points, for example? Not scalable!) Look at the ptbypt tools for a solution.

Your "5" diagram constants have the wrong representation.

0 Kudos
Message 3 of 10
(3,370 Views)

Hello everyone,

Thank you for the support and your fast responces.

''I don't know what is happening in the missing subVI, or why you are using a dynamic datatype wire to be a simple boolean to the Enable of the Write to Measurement File.''

I have fixed that problem. It was a mistake in the sub-vi. I had used a waveform output block for my output. I changed that to bulean (round LED).

 

''Take out the Write to measurement and see if it runs faster''

I tried that but noticed no difference in speed.

 

''Try getting rid of the DAQ Assistant an use regular DAQmx functions.  It's possible the 1 sample on demand is slowing things down.  Why not grab 5 samples at a 5 Hz rate with a continuous acquisition, average, then write to file?''

I got rid of DAQ Assistant and I am now using (what I believe to be) simpler DAQmx functions. I use the 1 sample on demand because this VI is a test to something larger that I need to create. In the final VI i want to be able to easily change the loop hysterisis therefore the sample rate and number of samples will be affected by loop speed.

 

''You are creating a new file with each write, not very efficient. If speed matters, open the file once, append in the loop, and close the file once the program stops.''

I am creating a new file after 1000 samples. (At least this is what I want to do). I didn't know that the files was closing after itteration. Can you please tell me how to append it?

 

''I would also recommend to chart the loop time to see where things slow down.''

How can I do that?

 

''Your "5" diagram constants have the wrong representation.''

I have changed that so that the red dot no longer appears at the input of the blocks.

So after all that changes there is no significant change in the execution time. Also an other problem that occured is that the produced file has incorect time stamps. The first raw contains the correct date and time but the rest show time:01-01-1904 12:00:00 AM

I am attaching the mising sub-VI with the corrections and the corrected VI.

Once again thank you for the support.


Download All
0 Kudos
Message 4 of 10
(3,308 Views)

Why does it have to be excel? can't you just append to a plain delimited text file instead. Much less overhead. (And, as we said, open it once before the loop and keep appending). (not shown im my example).

 

Your subVI is probably not needed if the code itself is smaller than the subVI icon. 😄 (there is also a =0 primitive and should should increment so the first saving is at iteration five, not zero.

 

Here's a quick rewrite to give you some ideas how to simplify a few things to record the loop time to see what's going on.

 

recording.png

0 Kudos
Message 5 of 10
(3,271 Views)

Thank you for the corrections.

Before reading your post I tryied some things myself. The problem was indeed in the "1 sample on demand" procedure. I changed that to continuous sampling and I am controling the number of samples and sampling frequency. Now the speed of the loop is very good. I can go down to 200mSec dalay with no problems. The problem with the timestamp persists however. I am attaching the improved VI and the measurements file.

Download All
0 Kudos
Message 6 of 10
(3,263 Views)

When attaching a new file, please give it a new name.

0 Kudos
Message 7 of 10
(3,252 Views)

@JohnKon wrote:

Thank you for the corrections.

Before reading your post I tryied some things myself. The problem was indeed in the "1 sample on demand" procedure. I changed that to continuous sampling and I am controling the number of samples and sampling frequency. Now the speed of the loop is very good. I can go down to 200mSec dalay with no problems. The problem with the timestamp persists however. I am attaching the improved VI and the measurements file.


I would assume you need to duplicate the timestamp as many times as you have samples.

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 8 of 10
(3,210 Views)

Hello,

I don't understand the suggestion with the duplication of the timestamp. My problem is that the file doesn't grab the correct timestamp. It shows 0 time for every time step. I have inserted a timestamp indicator in my loop to see if Labview has any problems grabing the timestamp of the computer but it works normally. Here is the latest VI and a coppy of the results fille.

Thank you for your help.

Download All
0 Kudos
Message 9 of 10
(3,172 Views)
Solution
Accepted by topic author JohnKon

And where would it get the timestamp from?  You are giving it an array of numerics with no reference to time.  Change your DAQmx Read functions to output waveform or 1D Array Of Waveform.  For the flow, update the waveform to just be your mean measurement before the Build Array and feed the 1D array of waveforms directly to the Write To File function.


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
0 Kudos
Message 10 of 10
(3,166 Views)