I have an labview application which takes around 50% of CPU usge but wen the same is running throgh code it takes only maximum of 12-16% can any body suggest me what might be the wrong.

[Bhargavsatya]

Dear All,

I have an labview application which takes around 50% of CPU usage but wen the same is running throgh code it takes only maximum of 12-16% can any body suggest me what might be the wrong.

Thanks in Advance

Bhargav

[Balze]

Sorry, I can't. My crystal ball is in repair. ;-) I think you have to describe your problem in detail (maybe you could post the VIs.) Best regards, Balze

[Bhargavsatya]

Actually i have avoided arrays , nested loops,local and global variables, almost i have coded using property nodes..even then i am unable to get the CPU usage less that what actually my code uses while running.. wen i make my code as exe the cpu usage is very high.

Rgds

Bhargav

[Balze]

I've seen a similar behavior at an application that wrotes multiple control captions cyclic. (using property nodes)

I'm afraid, we can't help you without your VIs (or an example VI that shows that behavior.)

Best regards,

Balze

[yenknip]

If you mean to say you have replaced local variables with property nodes; locals are actually faster. However, as you have written property nodes - plural, I would guess there is a better way to structure your code.

As Balze has said, post your VI or an example of the problem and we can help.

[Bhargavsatya]

Dear Balze,

pls find the above zip for the vi i am facing the problem.

Rgds

Bhargav

[smercurio_fc]

Oh dear, oh dear, where do we begin? I knew there would be monsters ahead when you have a main VI that weighs in 4.5 MB! Any VI that is that large SCREAMS of needing to be refactored. And yours is a banshee.

What we have here is another classic example of text-based programming using icons. You have the classic "let's put all the controls and indicators in one place and access everything with property nodes, 'cause that's the way it's done in Visual Basic, so it must be the same way in LabVIEW, right?" Wrong. Property nodes should be used sparingly. Each write to a property node causes a thread swap to the user interface thread. And your VI is swapping so much it has no idea what it's doing anymore. A quick fix (i.e., a band-aid) would be to replace all those Value property nodes with local variables. Assuming, of course, that doesn't create race conditions, which newbies typically create since they don't understand dataflow and try to program LabVIEW ... as if it were a text-based language.

But then, you have other problems with your VI:

• Your diagram is WAY TOO BIG. This isn't an issue just with you - it's an issue for anybode else who tries to modify your code down the road, or to try and, oh, I don't know, help you with a problem that you might be having. 
• Strange constructs. Why do you need to use individual string controls? Why not just use something like a cluster, or even an array that's fixed size and has the index displays hidden. (I rarely suggest using arrays as front panel controls for user interfaces, but in this case it would actually help.)
• Why do you have decorations on the front panel that do absolutely nothing? Their border is transparent.
• Suspicious: during loading the main VI was looking for some ALR_BSxx, where xx seemed to go from 1 to 85 (or something like that). That is very suspicious to me. Why are there so many of this VI. You didn't include the subVIs, so there's no way to know for sure, but I'm wondering if you just can't have one.

I would strongly recommend taking a serious look at programming constructs such as the Application Design Patterns: Producer/Consumer .

[rpodsim]

Wow, I'm amazed you can work on the VI.

Oneof my first sugestions would be if the values of the indicators your accessing through property node don't change then remove the indicators and the property nodes and use a wire.

Second replace the replicant while loops with subvi's or atleast the common logic within the while loops. that will ahlp improve the readability. But I would suggest rethinking th design. smercurio_fc has some good suggestions. I spent about 1 minute looking at the VI and thought "there has got to be a better way." Don't feel discuraged, it's a learning process. My suggestion would be diagram a state chart of your program.

I also noticed that you have some controls that aren't being used, and some that overlap. (overlaping controls and indicators is generaly considered a BAD idea)  Instead of using individual strings for the table layout consider using a table control. (there could be a better represention depending on the data to be displayed.

Just based on the radio button control, you could probably reduce the number amount of processing needed to just the "channels of interest". Without knowing what the missing VI's do, it's possible that some could be combined into a single VI with and input or two for selecting which channel to read?

[Balze]

THAT is the largest VI I've ever seen ! 

I guess smercurio_Fc and rpodsim have said everything worth talking about.

I think you should consider to rewrite this Application.

I would recommend you should read at least this document: http://www.ni.com/pdf/manuals/321393d.pdf#labview_style_guide

Best regards,

Balze

[Coq_Rouge]

What do this monster do. Can you with a few simple word try to explain. To me it looks like your project started out as dog house. But now it has expanded to BIG apartment building. But it still use the dog house foundation wall. But the good news is that it is a very large room for improvments. Perhaps like using a table indicator. And other things. Take som time and write down what you want to do. Then we will be able to help you better.