LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

for and timed loop timing accuracy

Hi there,
 
I am using labview (8,0 on windows xp) to measure signals (EEG) from an universal amplifier.
My idea is to synchronize the samplerate of the amplifier with the reading samplrate of labview. For EEG measurements a samplrate of 500 hz would be enough.
The measured data is transfered from the amplifier to the PC through USB.
 
To read the signals out of the amplifier a VI was included with the amplifier. I placed this VI in a for loop so each time the amplifier gives out a new data point a loop is run, but i couldn't get a higher samplerate then 125 hz. The VI I used is attached as  Test.VI.
 
After thinking about it I made a VI to test the timing of loops, the used VI is attached as timing.VI. Now it was clear for me that I could not reach an reliable samplerate of 500hz in a fo or timed loop in labview and windows.
Does anyone have experience with this problems or am I missing something?
 
Please help,
 
Best Regards,
Jens Dassen
 
Ps. I hope I explained it well enough to understand the problem 🙂
Download All
0 Kudos
Message 1 of 3
(2,917 Views)
 
I don't quite understand why you need to get one point at the time and use software timing. Can't you grab an array of successive data from the device with each read operation?
 
OK, your VIs are full of problems that casue performance issues.
 
Timing.vi
You are autoindexing at three output tunnels, creating arrays of potentially infinite size with mostly useless information. LabVIEW does NOT know the final size, so several expensive memory reallocations will occur. Then you only look at the first and last point, respectively! Turn off autoindexing at the "time" tunnels and save the first time in a shift register (Or better grab it right before the loop starts).
 
You run two loops (regular and timed) in parallel. I would only test one at a time.
 
TestingForum.vi
You don't initialize the shift registers on the very left, thus the arrays will grow for each run of the subVI. Simply delete the shift registers and use an autoindexing output tunnel.
 
One of the slowest ways to read/write values is via a property nodes. Get rid of them all, they are not needed. Get rid of that useless stacked sequence (it just makes the code hard to debug) and line up your subVIs horizontally.
 
Don't update indicators in the loop unless you need to and use the correct representation. Currently the "array 2" indicator is DBL while the data is SGL causing coercion.  Place a small wait inside the loop to make the rate predictable.
0 Kudos
Message 2 of 3
(2,902 Views)

Hi Altenbach,

thx for your reply, I finally get it. Each time the device spits out a value each time the subvi reads this value, in that way i don't need to worry about the timing.

Also thx for the programming tips, I tuned the program a bit up using your hints and tips. Its much faster now.

 

Best Regards,

Jens Dassen

0 Kudos
Message 3 of 3
(2,879 Views)