VI execution speed

[pschmal]

Hello all,

Right now I am working on a system simulation in LabVIEW. The process flow is Generate input signals -> Process time domain signals -> Display on FP.

Once the hardware prototypes come in and work I can replace Generate input signals with a real signal acquired from a digitizer.

I am trying to run the simulation in 'real time', where my simulation step and elapsed time coincide. My goal is 50ms per step. It may be unrealistic.

Basically I have 16 channels in this incoming signal. I generate a Gaussian noise signal 32 times per step (1024 points), to add to the generated signal. I then FFT all 16 channels using the N-channel FFT that outputs mag and phase. Right now it seems to be running at 250ms-300ms per step, but its hard to measure since 'elapsed time' seems to only measure whole second increments.

Is there a better way to generate noise? I generate twice for both thermal noise and 1/f noise. Is there a vi that generates noise in the f domain and I could just add it after the fft? If its the FFT that is taking the most time, is this the correct block to use? I like that it outputs the f domain in a way that I can directly push to display with having to mess with it too much. But its weird that each block does only a maximum of 9 channels (such a weird number...).

An unrelated question: Is it possible to do an intensity graph on a polar plot? I could implement it myself but it would surely be computationally slow.

[Gary Rubin]

Can you post example code? There are many tricks to make LV run faster, but we'd have to see what you're doing to know what might be slowing things down.

[pschmal]

It turns out I was generating each target 16 times, when they only have to generate once.

Any hints or directions how I can do a polar intensity plot? A good analouge is a weather radar.

[Gary Rubin]

It turns out I was generating each target 16 times, when they only have to generate once.

Any hints or directions how I can do a polar intensity plot? A good analouge is a weather radar.

I've done my own using sines and cosines to convert from rectilinear to polar coordinates. It's slow, like you indicated. I have no experience with picture controls - there might be a smarter way to do it there, but it seems you still have the same remapping issue.

[pschmal]

I've done my own using sines and cosines to convert from rectilinear to polar coordinates. It's slow, like you indicated. I have no experience with picture controls - there might be a smarter way to do it there, but it seems you still have the same remapping issue.

I have found a faster way than pixel by pixel polar to rect. This would cause the for loop to run about 200,000 -- obviously way too much. I experimented with filled arcs, but the for loop would still have to run around 20,000 times -- more if a finer resolution signal was desired.

So now I have tried replacePixelLine.vi. Each line is drawn with one end at the center of the picture, while the end of line coordinates sweeps around in a circle. Each channel becomes the pixel color. As I sweep past x amounts of degrees, I switch to a different channel and start coloring with that data. The for loop now runs for 1,000 times each time step, which is not a noticable slowdown on my computer (I think my wait command is still the main contributor!)

However, there is a semi-strange behavior with replacePixelLine. When doing a diagonal line (most lines in polar plot!) the stair stepping behavior is not what I expected. Instead of (x,y) -> (x+1, y+0) -> (x+0,y+1), it does (x,y) -> (x+1,y+1). This means at 45 degree angle, the amount of pixels colored is only ~71%. To further distort the plot, instead of scaling the pixel values to the line length, replacePixelLine.vi just drops off the unused pixels. Therefore instead of a polar intesity plot, I get this bizarre cross between cartesian and polar, where my angular bins do get smaller as they regress to the origin, but the data makes square shape!

Any advice, or will I have to create my own replacePixelLine.vi (which will be slow )

PS: The edit post function is really buggy

Edited December 23, 2009 by pschmal