LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Need for speed - property nodes are killing me!

Hi everyone,

I am trying to manage a control system with a large number of controls that I want to act as indicators simultaneously.  The system is a state machine in a consumer loop feeding from a data queue from a producer loop.  I want this Producer to run at 10-20 Hz, meaning that the consumer has to be faster than this.

I am wiring cases to the properties of the controls so that they change colors and blink etc when certain states occur in our system.  This front panel design is desired so that several users can control the system in a straightforward manner.  I have a created a state that I call "Draw Front Panel" where some queued data are accessed and compared to data from the "Process UI" state via shift register.  As soon as I started implementing this state, the machine slowed down to a crawl.  I have an indicator to tell me what state is active, and the "draw front panel" state is taking the most time.  As a result, I build up a data queue and my indicators travel in time and become useless, even fraudulent, to the user.

A few specific questions:
Is there any faster way to do this than property nodes?  I am aware of some other posts (http://forums.ni.com/ni/board/message?board.id=170&message.id=153572&query.id=48999#M153572) that deal with property node molasses.  but the options seem limited.

Is there a way to flush a  data queue when the state machine gets held up in a certain state?

Is there a difference in processing time for different properties?  Why?  Blinking seems the worse, and I have recently written my own blinker that is just as slow even though it only accesses the color property. 

Any help will be greatly appreciated.
0 Kudos
Message 1 of 11
(4,772 Views)
The first thing to try (before ditching property nodes altogether!) is to defer front panel updates before accessing the property nodes and re-activating them afterwards.

Get a reference to current VI, then a reference to the panel, there there's an option to "defer front panel updates".

Basically each property node write causes a screen update, and if you have lots of them, lots of (forced) screen updatesd will kill your speed.  Deferring the updates until all property nodes have been written can seriously improve your speed.

Shane.
Using LV 6.1 and 8.2.1 on W2k (SP4) and WXP (SP2)
Message 2 of 11
(4,762 Views)
Thanks Shane, this sounds like a good lead.  How does one get a reference to the VI and the panel?  I am not sure how to implement what you suggest.

Thanks,
Brad
0 Kudos
Message 3 of 11
(4,746 Views)

"CFAMS Brad" <x@no.email> wrote in message news:1168261808603-460942@exchange.ni.com...
Hi everyone,


I am trying to manage a control system with a large number of controls
that I want to act as indicators simultaneously.&nbsp; The system is a
state machine in a consumer loop feeding from a data queue from a
producer loop.&nbsp; I want this Producer to run at 10-20 Hz, meaning
that the consumer has to be faster than this.


I am wiring cases to the properties of the controls so that they change
colors and blink etc when certain states occur in our system.&nbsp;
This front panel design is desired so that several users can control
the system in a straightforward manner.&nbsp; I have a created a state
that I call "Draw Front Panel" where some queued data are accessed and
compared to data from the "Process UI" state via shift register.&nbsp;
As soon as I started implementing this state, the machine slowed down
to a crawl.&nbsp; I have an indicator to tell me what state is active,
and the "draw front panel" state is taking the most time.&nbsp; As a
result, I build up a data queue and my indicators travel in time and
become useless, even fraudulent, to the user.


A few specific questions:
Is there any faster way to do this than property nodes?&nbsp; I am
aware of some other posts
(http://forums.ni.com/ni/board/message?board.id=170&amp;message.id=153572&amp;query.id=48999#M153572)
that deal with property node molasses.&nbsp; but the options seem
limited.


Is there a way to flush a&nbsp; data queue when the state machine gets held up in a certain state?


Is there a difference in processing time for different
properties?&nbsp; Why?&nbsp; Blinking seems the worse, and I have
recently written my own blinker that is just as slow even though it
only accesses the color property.&nbsp;


Any help will be greatly appreciated.



Hi,


I don't know if this is possible in your application... I'd try to make a buffer (smart global, lv2 global) that handles the color change. In this buffer, you can store the state of the colors (and other properties). The benefit of this, is that you can check the state before you update the property. So the property doesn't get updated if it doesn't change.


Another solution might be to update the colors only when useful. It's usually not useful to update the colors 100 times a second. So you could try to put it in a buffer 100 times a second, and update the controls every second, in a parallel loop. There are more clever scenarios possible. You can update the buffer in the event structure, and in a parallel loop, check when the earliest update was. When the update is more then 1 sec. earlier update the colors, else wait. So when the buffer is filled 1000 times in 800 ms, the colors get updated only once. If the buffer doesn't get filled, the colors don't get updated at all.


If there are a lot of properties that you have to update at once, you might gain some performance by disabling the panel updates (get a reference to the front panel, and use the method Differ Panel Updates). You can also try combinations of the differ panel updates, and the advanced property of the controls "synchronous display".


Hope it helps.


Wiebe.




0 Kudos
Message 4 of 11
(4,745 Views)

I usually put my indicators into a large cluster outside the while loop. Inside the loop using a shift register, I use the Bundle by name function to put values into the indicator. There has been talk in the past, about using a picture indicator as a control by using mouse events to check click position. Perhaps you could overlay a control on top of the indicator with some transparent coloring.

Show us some code for more help.

0 Kudos
Message 5 of 11
(4,714 Views)
0 Kudos
Message 6 of 11
(4,710 Views)
In some cases, with judicious use of transparency, you can overlay a color box control with your actual control, then use the color box to change the colors.  If you can't use transparency, use the overlay to give you a colored border.  This gets away from the property node issue altogether.  However, defer panel updates should still be used.  I have attached a LV7.0 example that should work with any later version.  The color boxes were customized by changing the border to a flat box, then coloring it transparent.  The first string is a simple, traditional string control with the background colored transparent so the color box shows through.
0 Kudos
Message 7 of 11
(4,661 Views)

One other bottleneck that you are fighting is that each property node causes a thread-swap to the UI thread.  Depending on your machine, this can take up to 10ms for each property.

I suggest that you create an array of the references of the controls and use a sub-vi to change all properties at once.  Then set the execution of the sub-vi to run in the UI thread.  This will combine all property nodes into one thread swap.

Michael Munroe, CLD, CTD, MCP
Automate 1M+ VI Search, Sort and Edit operations with Property Inspector 5.0, now with a new Interactive Window Manager!
Now supports full project automation using one-click custom macros or CLI.
0 Kudos
Message 8 of 11
(4,622 Views)
Thank you Michael.  This I don't understand.  What if the properties are different, i.e. some buttons are red and some are green depending on the inputs coming from the consumer loop?  Maybe I'm just not understanding what you are meaning by the thread swap.

I have found that some of the overhead on the front panel was due to a large sized-picture that I had imported onto the panel.  This of course was resized according to LabVIEW's resolution algorithm, and I guess that every time one button had to blink, the whole picture had to be redrawn.  That meant that the UI state was redrawing this large picture 3 times in one frame if there were 3 blinking buttons.  This problem was easily resolved once I changed the picture out (the picture is not interactive, it is just a sort of template).  Now the VI is running between 5-10 Hz, which is close to where I want it to run.

I still haven't tried the update front panel option because I am not sure what loop this belongs in.
0 Kudos
Message 9 of 11
(4,565 Views)

It may be old thread but helped me to speed up the update rate of my VI with 8 1D arrays. Original refresh rate was sluggish at about 0,1s and with defer panel updates feature that dropped to acceptable 0,002s.

 

Press CTRL + SPACE and type static VI reference

right click on output crate >property for VI class > Front panel

right click on output of Front panel > crate > property for Panel class > defer panel updates

Delete the static VI reference

 

I used a sequence and in the beginning of it I set the disable updates to true. Then in the second frame placed the code that updates all 8 arrays and in the third frame I set the updates back to false. 

0 Kudos
Message 10 of 11
(2,421 Views)