06-14-2021 09:43 AM
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.
06-14-2021 09:56 AM
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.
06-14-2021 10:04 AM
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!
06-14-2021 10:43 AM
@RavensFan wrote:
Some of your code seems Rube Goldberg.
Would would go a step further and say most of your code is Rube Goldberg.
06-14-2021 11:33 AM
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.
I began looking into production/consumer structures and believe queuing and dequeuing is probably the better solution instead of building the array.
06-14-2021 11:45 AM - edited 06-14-2021 11:49 AM
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
06-14-2021 11:57 AM
@JÞB wrote:
I'm assuming by e m g you actually mean egm at which point 2K Hertz is significantly too fast
06-14-2021 12:21 PM
@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
Still, 256 hz will do. TDMS would be better and 3ish percent of the LabVIEW code would spin faster.
06-14-2021 12:32 PM
I am still not sure if 2Khz is actually aggregate over 16 channels, i.e. 125Hz/channel. This would be a reasonable rate.
06-14-2021 01:04 PM
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.