Best way to update an indicator

[sebster]

I've attached a very simple vi to demonstrate my question.

I'm making a test using the state-machine architecture. In the test, there is an indicator on the front panel which is to be updated at various places in the test.

My question is ... what is the best way to update the value of the indicator? In the vi, I've wired it directly, used a property node and used a local variable, all of which achieve the same result.

The first way - directly wiring - is obviously the best way if I have access to the input terminal of the indicator (as in state '0').

But what if I need to update the same indicator from the second or third states? What are my options here?

This is only a simple demonstration vi, so please don't say 'move the indicator outside the case structure and wire it through a tunnel', I know I can do that here. My 'real' vi updates the indicator several times within the state and I currently do using property nodes. I read somewhere that this isn't very efficient, which is why I'm asking this.

Regards,

Sebster

LabVIEW 8.6, WinXP.

[nolsqn]

i dont have labview installed in my pc rite now , but the best way to update a indicator , other then directly wiring is by using local veriable, not the property node , i will let you know more once i will see your vi 

regards 

[Ben]

They look the same but they are implemented very differently. See this thread for some performance numbers.

The control terminal is the most efficient technique. If you read the docs on creating XControls there is an explicit warning to only use the terminal and in cases where the indicator gets updated in some conditions and not others, we need to move the terminal into a following case and use a boolean to decide if we are writing to the indicator.

I thought I had this list tagged already but i could not find it so here it goes again.

In order of speed fastest to slowest.

1) Terminal (VL has optimized code that let the update slip in thru a back door.

2) Local but these require additional copies so the data has to be copied to each instance of the local.

3) Property node has to use the User Interface thread to update. This means waiting for the OS to re-schedule the work after the thread swap.

Both Locals and Property nodes can result in a Race condition if you use the indicator for data storage. See my signature for a link to avoid Race Conditions using an Action Engine.

Ben

[jcarmody]

In your example, this isn't so bad.



In a more complex application, I used JKI's String-Based Queued State Machine and send it to a UI Update state to update indicators.  A simple Queued State Machine can do the same thing.