Is it possible to decrease the time needed to run this VI?

[cvinyard]

I am a biologist with limited LabView programming experience.  I have written the attached VI to manipulate 10 channels of raw electromyographic (EMG) data.  (The raw EMG data appears in the upper window when you run the VI using the attached 'example'.)  The VI essentially takes the root mean square (making all data positive) and averages across a sliding window (reducing the complexity of the waveform).  If left running for awhile, the manipulated output data will appear in the lower graph.  The programs runs and calculates these manipulated data correctly.  There are two issues, however, that I would like to improve upon in the VI, but do not have sufficient experience/know-how to accomplish.  These are:

1) The VI takes a significant amount of time (sometimes into the hours) to complete the calculations.  I have tried to increase the speed of the VI, but nothing has worked.  (The attached example is a very short sequence due to attachment size limitations for the forum). I would appreciate any suggestions/ideas on how to increase the speed of the VI.

2) Sometimes the VI will produce a string of repeated manipulated data in a single file.  In essence, sometimes the output file will be two or more linear repeats of the output data.  I do not understand how this happens and why it is occurring only some of the time. 

Thanks in advance for all suggestions/ideas.

Take care,

chris

[Jason King]

Hi, Chris.  While I can't comment too much on what might be slowing you down, I do have a few comments on your VI.

1) It's never going to stop.  You're only reading the value of the stop button once, before you even enter the outer loop (and you must have a MUCH larger monitor than I 🙂

2) Your code is just screaming for use of SubVIs.  The code that you have duplicated for processing the data sets and computing the RMS in the sequence structure could be moved into a subVI for readability. It takes the dataset as input and outputs an array of doubles.

3) I doubt this is the root of any performance problem, but you're needlessly re-computing a lot of values.  Computations like RMS Window * RMS conversion factor should be moved outside of the loop as it's essentially a constant value.

I hope that helps at least a little bit...

J

[Kenny_K]

It looks like it is a fairly simple (in theroy) vi that just has to do some calculations.

One thing that will determine how fast your vi run sis the speed of the computer that you are running this one.  I ran the vi with your Example data and averaged about 6 sec before it asked me what file to read again.  I have a computer that is 3.2 GHz with 1 gb of ram.  Another issue could be the ram itself.  If you are opening very large files and performing calculations on the files with 128-256 mb of ram, it will definatly take some time to do the calculations.

But it appears that you have pretty much simplified the vi.  I would suggest though that you move the Stop control into the while loop in order or make sure that it is polled, otherwise once you start the vi, you will not be able to stop it unless you use the Abort button.  I would also suggest that you put in a wait ms.vi with at least a 50 wired as a constant into, otherwise you can run into a race condition.  Plus it allows your cpu to do some other calculations, which may speed up your time.

Kenny

[Kenny_K]

Another item that I would suggest is to try to get rid of a bunch of the local variables.  Each variable takes up more memory that could be used for more calculations.

Kenny

[Jonnie_5]

You're doing ALOT of the same operation over and over again - so you should think LOOP.  Also, there's lots of needless conversions.  Here's a quick LV8 cleanup of your code (and yes, it should be modularized, but it's late on Friday ).

And yes, it runs much faster.  Your biggest time killer should be in the file opening section (text to number conversion can be time consuming).  For VERY large data sets, start thinking about chunking it out.

Here's a GREAT link:
https://forums.ni.com/t5/Example-Code/Managing-Large-Data-Sets-in-LabVIEW/ta-p/4100668

[Joe_H]

I have made a lot of modifications to your VI. Mostly in how the arrays were handled. When i compare mine against yours mine is about 5 times faster. We could also probably improve this If i could figure out what you are trying to do in the for loop (See diagram of my VI)

Another thing move the stop button inside the loop or just remove the loop. Local variables should not be used in this scenario just use wires. Also if you still get a slow down read in your data in chunks so that the arrays do not get so big or initialize the array at the begginning.

You will have more questions no doubt just let me know.

[Jonnie_5]

whoopsy on mine - forgot I'd hid the output, had a bit of a race condition, and inverted the freq on the BP. 

You'll notice that me and Jhoskins did nearly the exact same things - that's why it's good programming practice
Although y'all seem to forget the old skool filtering vi's were all using DBL types - saves on conversions!

Man... it is friday..

Message Edited by Jonnie 5 on 08-04-2006 04:20 PM

[altenbach]

That's a new one and deserves a Rube Goldberg award!

https://forums.ni.com/t5/BreakPoint/Rube-Goldberg-Code/m-p/399999?jump=true

You are basically imitiating FOR loops with stacked sequences containing N identical code fragments!

Just replace each with a FOR loop containing a single instance of the code and autoindex the 2D array into it (transpose if needed).

[Joe_H]

Good job Jonnie 5

you just beat me to the punch.

[altenbach]

Actually, cvinyard posted in LabVIEW 7.0, so won't be able top open any of your demos.

Here's my quick attempt in LabVIEW 7.0. 😄

It probably has bugs....

There is no reason for any of the locals.