tags:

views:

90

answers:

5

i have a numeric control( not Indicator) and a for loop(limit 5)

i need to display the [current loop Index+ value in the numeric control] in the Numeric control. I'm new to lab view. Is there any idea to do this?

A: 

To write a value to a control, you need to create a local variable from it (right-click on the control's terminal on the block diagram and choose Create > Local Variable). To have it update each iteration of your For loop, put the local variable terminal inside the For loop and wire whatever you want displayed to that terminal. I'm not sure if this is going to be a good user interface design, but it's the answer to your question.

You can also use local variables to write to indicators from more than one place in your block diagram, and to read from indicators or controls. You can have more than one local variable terminal for any given control or indicator. Each local variable terminal is either for reading or writing - right-click on the local variable and choose Change to Read or Change to Write.

You should be careful about using local variables to pass data around, because program flow will no longer be controlled by data flow as it is when you pass data along a wire, and this could give you unpredictable behaviour (race conditions). Writing in one place and reading in multiple places is OK if the readers only need to know the current value at the time they execute, and so is writing to an indicator from multiple places where the indicator is only being used to display information to the user.

nekomatic
@ nekomatic : Thank you...
Pramodh
+2  A: 

Is there any specific reason you need to update a control that often?
If it needs to be updated that regular it might be better to alter it into an indicator.
If you update a control that often the user will have the feeling he's not in 'control'.

Ton
@ Ton: Its just for learning... i thought there is no way to display data on control.
Pramodh
+1  A: 

I agree with Ton. If you are changing the value of a control programatically, then you should consider whether it should be an indicator, or maybe have a pseudo-indicator of the control.

It would be a good idea to post an isolated version of your code so we can understand what exactly is going on.

Adnan Z
+1  A: 

If you wanted to maintain dataflow to control the program flow, you could instead use a property node of the control and set the "Value" property.

To create the property node, right click on the control's terminal on the block diagram, and select Create » Property Node » Value. Now you can adhere to dataflow programming by using error wires to control the flow of the program.

Again, to re-emphasize Ton's point - If you are going to change the value of a control frequently, it might be worth changing it into an indicator instead.

J J
You probably want to avoid Value property nodes, since they have some not-so-obvious performance implications. See http://forums.ni.com/t5/LabVIEW/local-vs-property-node/m-p/321755, for example.
Underflow
This only 'maintains dataflow' in that you can force the next operation in the same VI to execute after the property node write. It doesn't affect whether the code that READS that control gets the value you just wrote, or the old value - this is indeterminate. Always check whether you could use a better solution like a notifier or queue instead of value property nodes.
nekomatic
...I guess you could use the Value (Signaling) property and have an event triggered on the value change of the control, but then you're just reinventing notifiers, only with worse performance.
nekomatic
+1  A: 

As mentioned aleady you can use local variables and proerty nodes to set the value of your control or indicator. If you are trying to persist data there is a much better way.

Google "functional global" or "labview 2 style global". The basic pattern is to use a while loop hard coded to stop after one iteration. Add an unitialized shift register. Add a case structure inside the loop. Use a control (boolean, enum, or string) to select on the case structure. Drop a control/indicator pair of the same datatype on your VI. Wire the indicator to the outter-output of the right shifter on the outside of the loop. Place the control INSIDE the loop in the "set" (usually true, non-default) case and wire it out of the case into the input of the right shifter. Go to the other empty case(s) and wire the inner-output of the left shifter through the cases to the terminal that connects to the inner-input.

Becuase you did not wire the outter-input of the left shifter it is an "unitialized shift register". It will persist data from the last call to the VI. This is like declaring a variable on the heap in a c function and having the last assigned value available to you at the next function call.

The three main benefits are preservation of data flow, thread saftey, and performance. You get data flow by adding error IO to your VI. Thread saftey is ensured becasue the VI's execution is guaranteed to be atomic. Perfomance is improved becasue LV data wants to live on a wire. Every time you write data to a control's proerty node the LV runtime writes that data to the UI thread. I think there is a similar threading based performance hit for locals too but I'm not sure.


Per the first comment...

Copied here from the link for your benefit (yes you Mr Reader). Problem: I am considering using local or global variables; in what thread do variables execute?

Solution: A common misunderstanding is that local and global variable operations execute in the UI thread, or require a thread swap to the UI thread - this is not true. The following describes the behavior of local and global variable write and read operations:

Write: When you write to a local or global variable, LabVIEW does not switch to the user interface thread immediately. LabVIEW instead writes the value to the transfer buffer, which is a protected area of memory. The user interface updates at the next scheduled update time. It is possible to update a variable multiple times before a single thread switch or user interface update occurs. This is possible because variables operate solely in the execution thread.

Read: When you read from a local or global variable, the operation will occur in the thread which the VI executes, thus, you can be sure it does not occur in the UI thread by setting the execution system in the VI properties to standard. There is a thread protection mechanism to make sure that no writer of the global is changing the data while you are reading it, but this is done via a mutex, and not by going to the UI thread. However, if the global variable panel is opened, then a message is posted to redraw the global control, and the redraw will happen in the UI thread.


nekomatic is correct. The thread swap does not occur when you write to locals.

dFlat
Locals don't force a switch to the UI thread - see http://digital.ni.com/public.nsf/allkb/A8EE12F2D6A232C586257150007A0E19 . Upvoted for a good explanation of functional globals though!
nekomatic
@nekomatic Thanks for the +1.
dFlat