need help with speeding up a VI i built...

[p27182]

Ok, here's the deal so far:

I have a sparkfun IMU that spitting out XYZ accelerometer info over a serial connection @ 57600 baud. I have it hooked up to the COM1 port and in general, it works (drops out though after a lil bit, but thats another problem!)

my problem that seems like a doozie to me is the display of the data. I want a 3d display and I have that, it looks and functions beautifully excluding it's ssslllooottthhhh like nature. of course I guess it could be the activeX stuff thats hogging resources or maybe its the time domain integration im trying to do on the data... my buddy here at school is helping outsource some of the number crunching labors and the serial data acquisition to DLLs. does this sound like im on the right track??? will using DLLs significantly reduce the resources required by labview? enough to run smoothly?

someone also mentioned the idea of decimating the incoming data stream... spose i could do that too...

I'm still googling and reading for possibilities, but i wanted to hear your suggestions, i imagine there are some serious veterans on here that really know their stuff.

thaanks for any help/suggestions

-pat

p.s.- attached my vi . . . like i said, she's a resource hog for obvious reasons...

[Ton Plomp]

I'm not really and expert on this, but maybe you should lower the speed of your calculations to 25 Hz instead of 200 Hz (no-one can see that anyway).

So gather you data at the current speed (200 Hz), and do the calculations and displahy at 25 Hz, or at a even lower speed.

Ton

PS your format string implicits 14 bytes, but you read 18 why?

[p27182]

QUOTE(tcplomp @ Aug 25 2007, 03:43 PM)

I'm not really and expert on this, but maybe you should lower the speed of your calculations to 25 Hz instead of 200 Hz (no-one can see that anyway).

So gather you data at the current speed (200 Hz), and do the calculations and displahy at 25 Hz, or at a even lower speed.

Ton

PS your format string implicits 14 bytes, but you read 18 why?

haha oh man, I didn't even see that! thanks for pointing it out, 200Hz.... lol

the 14/18 bytes idea.... what about the spaces? I might be wrong because the program seems to jump out of synchronization and starts chopping up the packets, trying to read them after cutting them in half and it doesnt recover either... I'm not at school at the moment, but I'll take a gander at it again as soon as I get in.

thanks a lot for the help!

it's much appreciated.

-pat

[Ton Plomp]

QUOTE(p27182 @ Aug 26 2007, 03:13 PM)

haha oh man, I didn't even see that! thanks for pointing it out, 200Hz.... lol

the 14/18 bytes idea.... what about the spaces?

Well first I was gonna should

Use a wait statement, but at the very last moment I saw the 5 ms

Ton

[Neville D]

I would open up the express VI's you have for integration, and extract out only the functionality you need for your calculations. Avoid the blue dynamic data type wires if you want speed.

Better yet, write your own integral VI, that should be pretty trivial for someone who is fresh with all the math. Or you might use the pt-by-pt integral VI.

Use the "defer panel updates" property to not redraw every single iteration.. maybe once or twice a second might be good enough.

You can selectively make visible or invisible the different UI elements to see which of them is contributing to your slow behaviour. This should help you to figure out if its the calculations or the display that are causing the slowdown.

In general going to a dll won't buy you more speed, as compared to well-written LabVIEW code. Optimizing LabVIEW code should give you a speed increase equivalent to C-code. If you are bent on using C, use a formula node and type C-code into it. It is equivalently fast, without the hassles of debugging the dll in a different environment.

Also to speed up certain calculation sections, change the VI's priority to "high" (or even subroutine for certain fast, repetitive calculations), and disable debugging on everything; using a built executable will also buy you a slight increase in speed since this removes the diagrams, disables debugging, and removes all unnecessary parts of the application.

You could also do a simple decimate for the display (display only every alternate pt).

Neville.

[p27182]

QUOTE(Neville D @ Aug 27 2007, 01:04 PM)

I would open up the express VI's you have for integration, and extract out only the functionality you need for your calculations. Avoid the blue dynamic data type wires if you want speed.

Better yet, write your own integral VI, that should be pretty trivial for someone who is fresh with all the math. Or you might use the pt-by-pt integral VI.

Use the "defer panel updates" property to not redraw every single iteration.. maybe once or twice a second might be good enough.

You can selectively make visible or invisible the different UI elements to see which of them is contributing to your slow behaviour. This should help you to figure out if its the calculations or the display that are causing the slowdown.

In general going to a dll won't buy you more speed, as compared to well-written LabVIEW code. Optimizing LabVIEW code should give you a speed increase equivalent to C-code. If you are bent on using C, use a formula node and type C-code into it. It is equivalently fast, without the hassles of debugging the dll in a different environment.

Also to speed up certain calculation sections, change the VI's priority to "high" (or even subroutine for certain fast, repetitive calculations), and disable debugging on everything; using a built executable will also buy you a slight increase in speed since this removes the diagrams, disables debugging, and removes all unnecessary parts of the application.

You could also do a simple decimate for the display (display only every alternate pt).

Neville.

thanks for the advice, it is much appreciated.

I tried the non-express integration but I must have been using it wrong, despite reading the help file cause I kept getting all zeros.

The dissapointing part is that the computer Im trying to do this on isnt exactly a workhorse either. I'm finishing up a computer I'm building that will hopefully give me a lil better results, I suspect having more than half a gig or ram would help no?

time will tell I guess...

thanks again for the help

-pat

[Neville D]

QUOTE(p27182 @ Aug 28 2007, 04:13 AM)

I tried the non-express integration but I must have been using it wrong, despite reading the help file cause I kept getting all zeros.

thanks again for the help

-pat

Save a copy of your original VI.

* Right-click on the Express VI, and select convert to VI. This operation cannot be reversed (hence back up original)

* Now comb through the Express and remove all the stuff that is unnecessary for your application.

* Save this VI with a different name.

* Make sure it is re-entrant since you have 3 copies of it running in parallel in the loop.

Your done.

Again, try to work with what you have instead of jumping off in all different directions. Forget dll's and better hardware for now. Analyze where your performance is poor and improve that area. A few days work should get you all the performance you need.

If you do a search for integration on LAVA, you should pull up posts of people writing their own integration routines using Rectangular or Trapezoidal rule.

Neville.

[orko]

QUOTE(p27182 @ Aug 28 2007, 04:13 AM)

I suspect having more than half a gig or ram would help no?

Wow. Half a gig seems so small now, it's almost depressing. But if you're running on anything that rhymes with "Wind Blows" than yes, a gig is the minimum that I run with now. Makes a huge difference in XP.

[LAVA 1.0 Content]

Your situation is fairly common; you have a data stream that is faster than can be handled in real time. You need to simultaneously offload the communications buffer before it fills AND process the data. This is where LabVIEW queues and parallel execution become useful.

Your program can be split into two loops; one to capture the RS-232 data, and the other to post-process and display the results. I've attached a modified version of your program; the upper loop reads the RS-232 data as quickly as possible, and places it in a queue. The lower loop periodically flushes the queue, selects the last element and converts it to coordinate data as before.

Adjust the wait-next-multiple input in the lower loop to determine the display quality. If the VI still runs slowly, then you will need optimize other parts of your code. I'm curious to know if this alone will improve your performance (I'm guessing it will :thumbup: )

http://forums.lavag.org/index.php?act=attach&type=post&id=6794 (LV 8.2)

[Rolf Kalbermatter]

QUOTE(LV Punk @ Aug 29 2007, 06:26 AM)

Your program can be split into two loops; one to capture the RS-232 data, and the other to post-process and display the results. I've attached a modified version of your program; the upper loop reads the RS-232 data as quickly as possible, and places it in a queue. The lower loop periodically flushes the queue, selects the last element and converts it to coordinate data as before.

Adjust the wait-next-multiple input in the lower loop to determine the display quality. If the VI still runs slowly, then you will need optimize other parts of your code. I'm curious to know if this alone will improve your performance (I'm guessing it will :thumbup: )

Since you plan on throwing away any but the last data anyhow a notifier may be better than a queue in this particular situation.

Rolf Kalbermatter

[p27182]

QUOTE(LV Punk @ Aug 29 2007, 07:26 AM)

Your situation is fairly common; you have a data stream that is faster than can be handled in real time. You need to simultaneously offload the communications buffer before it fills AND process the data. This is where LabVIEW queues and parallel execution become useful.

Your program can be split into two loops; one to capture the RS-232 data, and the other to post-process and display the results. I've attached a modified version of your program; the upper loop reads the RS-232 data as quickly as possible, and places it in a queue. The lower loop periodically flushes the queue, selects the last element and converts it to coordinate data as before.

Adjust the wait-next-multiple input in the lower loop to determine the display quality. If the VI still runs slowly, then you will need optimize other parts of your code. I'm curious to know if this alone will improve your performance (I'm guessing it will :thumbup: )

http://forums.lavag.org/index.php?act=attach&type=post&id=6794''>http://forums.lavag.org/index.php?act=attach&type=post&id=6794'>http://forums.lavag.org/index.php?act=attach&type=post&id=6794 (LV 8.2)

wow. thanks! unfortunetly my partner has the IMU right now but as soon as I get it in my hands I will be sure to run it and see how much quicker it is. - I guess my noob-status still stands, I'm still interpreting the changes you made haha, I've never actually used anything off the que pallette.

thanks a lot for the help, I really do appreciate it, unfortunetly I don't know of anyone here that really knows labview this well...

I'll let you guys know how it tirns out!

-pat

[Eugen Graf]

I am working with data monitoring for IMUs. But I newer try to integrate or differentiate a signal under Windows.

1. And if I should do it, I need a TIMESTAMP for EVERY sample or I need to know the sampling frequency.

2. I would say integrate or differentiate every 25th or 50th sample is a wrong way to reduce CPU load. This way means, that you loose some important informations about the signal. The right way would be to integrate every sample and buffer them. After them you can show data with e.g. 10 or 5 Hz. So you will dont get more than 5% CPU load.

3. To log data on HD you can use the right sampling frequency, it doesn't need some CPU.

Eugen

P.S. AND I AM SURE that LV is not much slower than C/C++ or other programming languages. You have only right use it.

[p27182]

hmmmm.... she doesnt seem to be working... either that or I'm totally missing something (not unlikley). The bottom (calculation) loop seems to get started too early, then it acts like it comes to a halt, and changing the ms wait value doesnt seem to influence the result... I feel like theres something real dumb im missing.... maybe I'll get later or something.

I spoke to a buddy of mine here who's a grad student, turns out he's working on something really similar, and actually handed me some matlab code for taking IMU data and extracting low-noise info. it's basically numerical integration with a threshold, he laughed at me when i told him i wanted to crunch out double integrals to get displacement data... lol then he proceeded to show me loads of graphs that represented displacement by standard integration, and man, they were freakin ugly ... half the graph turned out to be way off...

so now im wondering if I can use anything from this matlab code IN labview.... how close is matlab's language to mathscript? is this a dumb question? ... shit for all I know it could be the same...

I've never used the mathscript tools in labview- anyone have any experience?

thanks for all the help guys...

much appreciated!

-Pat

[Neville D]

QUOTE(p27182 @ Aug 29 2007, 03:07 PM)

how close is matlab's language to mathscript? is this a dumb question? ... shit for all I know it could be the same...

I've never used the mathscript tools in labview- anyone have any experience?

thanks for all the help guys...

much appreciated!

-Pat

It should be very close.. why don't you try typing it in and running it?

N.

[LAVA 1.0 Content]

QUOTE(Neville D @ Aug 30 2007, 12:43 PM)

It should be very close.. why don't you try typing it in and running it?

You could also http://zone.ni.com/devzone/cda/tut/p/id/3256#toc1' target="_blank">import the m file into a Mathscript node after placing it on the block diagram...

I experimented a while back with using a customer's Matlab scripts in a node; the main problem was extracting all the UI related commands. I was told by my NI rep that I should keep the number of lines to between 20 and 100 for performance purposes; if there are more than that I was told to break the logic into parts and pass data between the nodes using LabVIEW wires.

Good luck!