LVOOP Performance Issues on an RT Desktop

[NJC-EE]

Hello,

I am currently using LabVIEW 2010's LVOOP on a desktop RT system. I am designing a model which uses multiple objects in a time critical loop which inherit from one base object. I have approximately 40 objects total running through a shift register in a Time Critical Loop with a period of 1 ms. The desktop is a 3GHz Core 2 Duo; I would imagine that the computer should be able to handle this, but the CPU cannot finish what it needs to within 1 ms. I think I might be doing something wrong.

Even though I can not describe my project in detail, I was wondering if anyone has run into performance problems with LVOOP on an RT Desktop and has an advice. Is it a bad practice to run a time critical loop with shift registers for objects? I am somewhat new to LVOOP, so any advice no matter how simple would most likely help.

Thanks for any help,

NJC

[cirrusio]

Hey NJC,

Can you describe what you are actually trying to do in the loop that is not finishing on time (don't have to be specific, but are you trying to do a lot of computations, are you attempting to access data on all forty objects, etc)?  The objects themselves should just have an impact on the memory footprint, however if you are jumping in and out of a lot of VIs (i.e. for accessing data in the objects), you may be getting a lot of performance its that cause the loop overrun.  Are you taking advantage of the parallelism in LV?

Cheers, Matt

[Ben]

SR's should be OK after the fist iteration (to get the dynamics loaded) but a big No-No is forking the class wire. Forking to a sub-VI may require a data copy...

Ben

[Been bitten by LabVIEW]

Sorry Ben, what does SR stand for?

A

[Ben]

SR = Shift Register

[Been bitten by LabVIEW]

Of course. 🙂

[NJC-EE]

Thanks for the comments guys.

Since I originally posted, I have managed to get my code to run on a number of cores more efficiently, thus solving the performance problem. I will definately take another look though to see if I can optimise the code further with the suggestions you all had.

A bit more information:

Within the loop, each object has 3 member VIs called each cycle, I do not do any spliting of objects except within the member VIs, the branches are only used with unbundle by name to access the data from the object. One of the VI's allows some of the parameters in the object to be changed, the other two mostly contain logic. The logic is not overly complex, thus why I am suprised that the system is performing so poorly. I also do not have significant memory usage.

Thanks for all the help,

NJC