Newbie Q: Writing to controls

[Michael Malak]

30 years software development experience, but new to LabVIEW.

The control/indicator dichotomy has me flummoxed. I would like to programmatically set the default values of user input controls. Is this possible? I'd like to have a "setup" dialog or window populated with controls, where the user can select a file containing a "setup" that populates the controls with the settings from that setup file, and then the user can fine-tune the values in the controls. How can this be done?

[Mark Smith]

QUOTE (Michael Malak @ Apr 7 2009, 10:22 AM)

30 years software development experience, but new to LabVIEW.

The control/indicator dichotomy has me flummoxed. I would like to programmatically set the default values of user input controls. Is this possible? I'd like to have a "setup" dialog or window populated with controls, where the user can select a file containing a "setup" that populates the controls with the settings from that setup file, and then the user can fine-tune the values in the controls. How can this be done?

This is the one place where using local variables (or property nodes) is considered good LabVIEW style - to write values to a control, right click the control on the BD and select Create->Local Variable - now, whatever you wire to the local will get written to the control

Mark

[Edit]

Just one more thing - you can save a lot of time doing this sort of thing if you group controls into a cluster and then use some tool that automates persisting that cluster to file. Then you can do one simple write to save the initial values and one read to repopulate the cluster - or, if you need to separate the controls on the UI, you can then unbundle the cluster on read. There are several approaches that essentially automate the write and read from file. I've attached an example that uses the LabVIEW Schema XML Tools, but if you would prefer to save the config data in ini style files, a couple of good options are the OpenG Config File Tools

http://wiki.openg.org/Main_Page

and David Moore's Read/Write anything VI's

http://www.mooregoodideas.com/File/index.html

Mark

Download File:post-1322-1239123211.zip

[Mark Yedinak]

You can programatically write to a control using a property node. If you right-click on the terminal of a control in your block diagram you can create a property node. With this property node you can write a value to the control. You can also change many other attributes of the control as well. Do be careful to avoid using property nodes all over the place in place of data flow. If you use them very liberally you can end up with race conditions in your code.

[Francois Normandin]

QUOTE (Michael Malak @ Apr 7 2009, 12:22 PM)

30 years software development experience, but new to LabVIEW.

The control/indicator dichotomy has me flummoxed. I would like to programmatically set the default values of user input controls. Is this possible? I'd like to have a "setup" dialog or window populated with controls, where the user can select a file containing a "setup" that populates the controls with the settings from that setup file, and then the user can fine-tune the values in the controls. How can this be done?

Hi Michael,

there are a few ways to do that. For starters, I would lead you in the direction of local variables. You can read from/write to local variables. You can also use the Value Property accessible from the Property Node. Be careful not to use too much local variables as they are not inherently "dataflow-friendly".

EDIT: Looks like you've got plenty of help...

[shoneill]

QUOTE (normandinf @ Apr 7 2009, 05:37 PM)

Hi Michael,

there are a few ways to do that. For starters, I would lead you in the direction of local variables. You can read from/write to local variables. You can also use the Value Property accessible from the Property Node. Be careful not to use too much local variables as they are not inherently "dataflow-friendly".

EDIT: Looks like you've got plenty of help...

If you need local variables or property nodes, try to use local variables.

Property nodes are much less efficient than a simple local variable. Property nodes have other capabilities which locals don't, but if these extra capababilities are not needed, locals are the way to go.

Shane.

[Mark Yedinak]

QUOTE (shoneill @ Apr 7 2009, 11:59 AM)

If you need local variables or property nodes, try to use local variables.

Property nodes are much less efficient than a simple local variable. Property nodes have other capabilities which locals don't, but if these extra capababilities are not needed, locals are the way to go.

Shane.

When did this change? I seem to remember from way back when that property nodes were more efficient and recommended as the preferred method over local variables. I seem to recall NI recommending this at one point. Granted, I it was many years ago but I have generally followed this advice. Should I switch to local variables now instead (that is when I do use them)?

[Mark Smith]

QUOTE (Mark Yedinak @ Apr 7 2009, 12:46 PM)

When did this change? I seem to remember from way back when that property nodes were more efficient and recommended as the preferred method over local variables. I seem to recall NI recommending this at one point. Granted, I it was many years ago but I have generally followed this advice. Should I switch to local variables now instead (that is when I do use them)?

Here's my two cents - at NI developer days last month, our local rep (who's a sharp guy) was giving the "Prepare for the CLD" talk. He said never use property nodes to update controls on the CLD - use locals - while the viewgraph behind him said "Use Property Nodes to initialize Controls" - so it would appear that NI can't agree among themselves

He then showed his example where locals update a front panel control much faster than using property nodes. At this point, I commented that the performance difference is beside the point, because if you're using either to update a control in a fast loop, you're doing it wrong. You should only need to update a control to initialize it or show some other change of state that a user would need or want to know before using that control for input. If you need to update the display in a fast loop (faster than the user can possibly grab and use a control) it should be an indicator anyway.

Mark

[crelf]

QUOTE (Mark Yedinak @ Apr 7 2009, 02:46 PM)

I seem to remember from way back when that property nodes were more efficient and recommended as the preferred method over local variables.

I don't know when (or if) it changed, but my understanding has always been that efficiency is best starting with the node, then local variable, then the property node. I agree with shoneill - use locals if all you're doing is reading/writing from/to the FP item, but if you're doing anything else through a property node then you should use that instead (also nice to use with the error clusters as well, but make sure you set the "ignore errors" setting appropriately.

[crossrulz]

QUOTE

When did this change? I seem to remember from way back when that property nodes were more efficient and recommended as the preferred method over local variables. I seem to recall NI recommending this at one point. Granted, I it was many years ago but I have generally followed this advice. Should I switch to local variables now instead (that is when I do use them)?

For as long as I have been using LV, NI keeps telling everybody NOT to use locals...beaten into our heads sometimes. So I then see all of my coworkers using the property nodes instead. Then I tell them why that is even worse.

NI tells people not to use the locals because it breaks off from the data flow paradigm and is likely to create race conditions. Guess what...setting the value with property nodes does the exact same thing except that it is WAY slower. I have some test data floating around somewhere that proves this. So now I'm getting everybody to use shift registers inside of their loops instead of the locals and/or property nodes to save data inside the loop. It was almost funny when I compared my CRC program (using shift registers) to coworker's (using property nodes to set front panel objects being used as temperary variables) and mine ran circles around his and he was so perplexed.

[Mark Yedinak]

QUOTE (crossrulz @ Apr 7 2009, 02:23 PM)

For as long as I have been using LV, NI keeps telling everybody NOT to use locals...beaten into our heads sometimes. So I then see all of my coworkers using the property nodes instead. Then I tell them why that is even worse.

NI tells people not to use the locals because it breaks off from the data flow paradigm and is likely to create race conditions. Guess what...setting the value with property nodes does the exact same thing except that it is WAY slower. I have some test data floating around somewhere that proves this. So now I'm getting everybody to use shift registers inside of their loops instead of the locals and/or property nodes to save data inside the loop. It was almost funny when I compared my CRC program (using shift registers) to coworker's (using property nodes to set front panel objects being used as temperary variables) and mine ran circles around his and he was so perplexed.

I agree completely with not using front panel items for temporary data that the user doesn't need to see. I try to keep all such data in shift registers, functional globals or LVOOP objects. However, when dealing with a front panel control exposed to the user it seems that you have to use a local variable or property node. There simply is no way to read from an indicator or write to a control without them.

Lately I have even been isolating the UI much further and using queues to pass data between the processing tasks and the UI task. I just seem to remember attending a seminar put on by NI back in the mid to late 90's where they were receommending property nodes over local variables. So the comment earlier in the thread surprised me.

[Yair]

I have no idea about the history, but the issue is fairly simple - Updating a control has two parts - updating the control value and updating the actual control on screen.

When you use a local, LabVIEW only does the first part and does the second part when it's ready for it.

When you use the Value property, you force it to do both parts (and force a switch to the UI thread).

That's why using the Value property is slower - it just does more work.

That said, I wouldn't say to "never" use either of them. Each of them has its uses and its pros and cons. Deciding which to use (or if to use either of them at all) should depend on the specific case. The speed issue isn't really relevant for many cases. Nothing terrible will happen in the update takes an extra X ms.