Uninitialized array\cluster takes CPU power

[tst]

We've encountered a fairly annoying problem in LabVIEW RT (both 6.1 and 7.0) for windows - reading an uninitialized array that's partially hidden causes LV to take a lot of CPU resources, even 100%. This makes it harder to build interfaces. The attached example VI is for LV 7 and has an array of LEDs hidden by a button. When trying to read the array the meter goes up, a state that's solved by initializing, hiding the button, scrolling off or stopping the read loop. Any help would be greatly appreciated.

[Joe_Guo]

The CPU takes all the time to refresh the front panel (especially the displayed array which labview is very pool at when there are lots of elements shown). You can reduce it by display only the neccessary elements you need to see, or do not update it so frequently.

Joe

[tst]

I'm sorry, but your answer doesn't help. If you'll download the VI attached to the previous post, you'll see that it doesn't have a lot of elements, only an array and a button. You can also see that the problem only happens when the button hides the array. We've seen the problem in LabVIEW RT, but we don't know if it exists in standard LV, so if anyone can tell us if it does, we'd appreciate that as well.

[Joe_Guo]

With the downloaded VI when the button hides array, the CPU jumps. Is there any reason the button must hide the array?

Joe

[Shea C]

Hello tst,
Thank you for your inquiry regarding CPU usage when using an array covered by a control. After running the VI I understand the problem that you are having and this problem does exist in standard LabVIEW 7.0. It takes a lot of resources to update a front panel when controls/indicators are layered on top of each other. I�m not sure exactly in what situation you might need to place controls on top of each other and I assume that you need all of the features that you mentioned resolve the problem. One possible solution would be to rid the VI of the �Array� local variable. This seems to speed up the update rate and solve your problem. Typically variables and especially global variables seem to slow down performance. The following link is one resource when troub
leshooting this behavior.

http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101&RPAGEID=135&HOID=50650000000800000027510000&UCATEGORY_0=_49_%24_6_&UCATEGORY_S=0&USEARCHCONTEXT_QUESTION_0=Vertical+Slider+Control+%28Classic+Control%29+takes+50%25+of+CPU+Time+when+Loaded+in+Memory+Only&USEARCHCONTEXT_QUESTION_S=0

Other responses similar to this can be found on the ni.com website by clicking the support tab at the top of the home page. Then search for �Memory and CPU usage� from Technical Resources at the top of the page. I hope these resources help. Let me know if I can further assist you.

Shea C.
Applications Engineering

[Randall_T]

In your example you have the button on top of the array control. LabVIEW is drawing the button and the array each iteration. Move the button to the side of the control then try running this again.

Are you trying to hide the center of the array for a reason?

Randall

[Randall_T]

forgot to mention in the revised version if the element is true the led will show up. Changing the outside elements to true will give you the effect hiding the center of the array with the button did. If that was what you were trying to do.

[tst]

Thank you all for your answers. They've been very helpful in understanding the problem. I understand that refreshing the screen is hard and I know that LV requires a lot of resources but still - we're talking about 10 FPS - that's not a fast refresh rate. In response to Shea's question, we have a few programs in which such constructions exist. Bad programming practices? Maybe, but I still think a modern computer should be able to handle this task. Anyway, from now on I'll try to avoid doing it, if possible.
P.S. Shea - I understand what you're saying about local variables, but I'd still expect most programs to have quite a few of them.
Thanks again for your answers.

[tst]

BTW, I also have a program that has a tab control and causes this problem. Moving controls from the NON-visible pages to other parts of the screen also causes the CPU usage to go down. Unfortunately, I haven't been able to reproduce this problem in a smaller program. Does anyone have an idea why this is happening?

[Randall_T]

I use the tab control in large applications without this problem. Are other controls overlapping each other? It is interesting that the tab control typically will allow other controls to rest on it without causing the same problem you experienced with your first application example.

Also one other tip. Keep your hands off the shift and ctrl key while your application is running. If you hit the ALT key once be sure to hit it or another key like the tab key. These conditions can cause your version 7 to run the processor high.