Labview code slows down significantly

[scottjackson]

I have a .vi that collects EMG data from an external device at 2000Hz, which it then plots and stores the data into a txt file. I also have it collecting keyboard presses and timestamps to make it easier to review specific sections of data. After running it for about a minute, it severely slows down and it gets to the point where 1 second of data collection takes roughly 30 seconds. I am unsure if it is a problem with my computer not being powerful enough to handle it, or if my code is causing it to clog up.

I have attached part of the .vi where most of my work is happening, but have removed the part where the device is connected, as it would not run either way without the device.

Any help would be greatly appreciated.

[RavensFan]

How fast is your inner while loop running?

You are continually growing your array using the feedback loop.  It will consume more and more memory, and slow down every time it needs to find a new larger spaced to store the array and move the data into it.

You should be using a producer/consumer architecture and offload the saving of the data to another loop and not endlessly grow an array.

Some of your code seems Rube Goldberg.  You are decimating an array and rebuilding it.  It seems like you can do what you want with a Reshape Array function.

[scottjackson]

Thanks for the fast response. 

I am unsure how fast my inner loop is running. I haven't put any time constraint on it; I was just letting it run. I'll try making some of those changes!

[altenbach]

---

@RavensFan wrote:

Some of your code seems Rube Goldberg. 

---

Would would go a step further and say most of your code is Rube Goldberg.

• That toplevel event structure makes no sense (I understand what you are trying to do but that's not the way! Think state machine.)
• Replace your sequence structure with proper data flow and error handling. 
• None of your value properties are needed.
• I have some broken wires. What exactly is the single shot array size in a typical run?
• Have you thought about using a single (or maybe two) charts set to "stack plots"?
• What's the point of the marker file? In an inner loop you want to use lowlevel writes and open/close the file outside the loop. You are currently opening and closing the file with with every write (expensive)!
• Before you write the markers, I can think of simpler code in the FALSE case. Adding a value multiplied by zero to an empty array, then appending that empty to the file does not really do anything useful, right? You can also avoid the NOT by swapping the cases.
• What rate is 2kHz (all data? Per channel? What is the calculated loop rate given the typical settings? What is the actual loop rate?
• You can set dt for all charts once using a property node and graph the plain DBL array. No need for all that manipulation and higher datatypes.
• As has been said, don't grow arrays without bounds. You don't need that at all if you would append the new data to the file instead.

[scottjackson]

I am pretty new to using labview, so I am sure most of my code is inefficient. The external device included a sample labview code, which is where most of the structure comes from, and I just expanded until it fit my needs. 

• The broken wires are from connecting my device and setting the sampling rate.
• The marker file is gives me the timestamps so when I recreate the files in MATLAB, I can show where specific events happened.
• I created the case structure so that my marker file was only edited when a button was pushed, instead of the incredibly long file when the time stamps were checked. While I created it, that was the only way I could make it work, but now I have some other thoughts.
• The 2kHz is how often the external device collects data, in which it collects all 16 channels simultaneously. 

I began looking into production/consumer structures and believe queuing and dequeuing is probably the better solution instead of building the array.

[JÞB]

I'll apologize in advance for the lack of punctuation. This stupid Google Speak doesn't work so well. Paragraph. Okay that doesn't work either

I'm assuming by e m g you actually mean egm at which point 2K Hertz is significantly too fast

The body just doesn't have things that operate that fast 256 Hertz is more than sufficient

Now I'm really going to try to get you away from using Matlab and it's events try using a TDMS file and events become events in the t d m s format... yes,that is Test Data Measurement Streaming .  A simple file format for your needs. A and more than happy to operate at those significantly slow speeds that a human body operates at

Moreover since you seam to be using an ni DAQmx device just turn on logging and all of that data goes straight to a tdms file.

So Christian and others can pick parts of Rube Goldberg constructs later you really only need about 3% of that code

[altenbach]

---

@JÞB wrote:

I'm assuming by e m g you actually mean egm at which point 2K Hertz is significantly too fast

---

EMG

[JÞB]

---

@altenbach wrote:

---

@JÞB wrote:

I'm assuming by e m g you actually mean egm at which point 2K Hertz is significantly too fast

---

EMG

---

Still,  256 hz will do.  TDMS would be better and 3ish percent of the LabVIEW code would spin faster. 

[altenbach]

I am still not sure if 2Khz is actually aggregate over 16 channels, i.e. 125Hz/channel. This would be a reasonable rate.

[scottjackson]

The software that came with the external device collects data at a rate of 2kHz. I am trying to mimic this rate within Labview so the data will be comparable.