Crash course in Event Structures

[Ray.R]

Hi kmous,

I will do so tonight.  🙂

[DFGray]

Local variables are one of those things which are easy to abuse, but are also very useful in certain circumstances.  Alternate sources for much of the same functionality are wires, outputs of event structures, terminals, and value or value (signalling) property nodes.  My order of preference is:

1. Wires - use block diagram wires if at all possible - shift registers are your friend.  This is fast and efficient.  Never use local variables / front panel controls for data storage.
2.  Event structure outputs - this is less used, but is automatically generated.  The previous value of event structures is often highly useful.
3. Terminals - if you have the terminal, use it.  This is the fastest way to get and / or set data to a front panel control.
4. Local Variable - used to initialize controls or read values from indicators.  Very useful for initializing or reading current settings for complex GUIs.  As mentioned before, do not put state information in front panel controls.  Use a single-element queue or action engine.
5. Value (signalling) property node - used to set a value and trigger the appropriate action for that value change.  Note that this is a synchronous action, so the value will be fully set to the GUI before the property node returns, making this a very slow way to set values.
6. Value property node - used only in complex GUIs to encapsulate behavior.  The Value property is orders of magnitude slower than a local variable, so should only be used when the local variable is not available (e.g. in a subVI).

Message Edited by DFGray on 05-14-2009 08:56 AM

[J.Mamakos]

Thank you for clearing that up for me - I was never really 100% sure what to use (other than wires) to transfer data to different places.  Now I shouldn't have to guess each time and hope for the best! 😉

[J.Mamakos]

How do you create a link (possibly using a property node) to something on the front pannel of another VI?

[Ben]

---

James Mamakos wrote:
How do you create a link (possibly using a property node) to something on the front pannel of another VI?

---

It depends on the realtionship between the control you want to touch and the the toucher. If the "toucher" is a sub-VI of the VI that has the widget you can create a reference to the widget and pass it using the icon connector.

If they are not connected then given a a reference to the VI that has the widget (optional how to get this but "Open VI ref and pass it that name via the path input, assuimg its in memory) you can get a ref to the FP and start waliking down into nested tab pages looking for the widget using its name.

There are variation on all of the above but hopefully that gets you started.

Ben

[DFGray]

When I write a GUI based LabVIEW program, I usually create references to all the possibly visible controls and indicators (right click, create reference) and bundle them all up for later use.  I cache them with an appropriate reference object (shift register wire, single-element queue, or action engine depending on the application).  This allows me to easily do fairly complex things with the front panel without too much effort.

[Ben]

---

DFGray wrote:
When I write a GUI based LabVIEW program, I usually create references to all the possibly visible controls and indicators (right click, create reference) and bundle them all up for later use.  I cache them with an appropriate reference object (shift register wire, single-element queue, or action engine depending on the application).  This allows me to easily do fairly complex things with the front panel without too much effort.

---

I do the same!

Ben

[Ray.R]

I used to do that. 

Would creating references for Front Panel objects impede cause any detriment to the overall software, especially when the references are not being used?

Of course all references (used or not) would be closed prior to terminating the program.

R

[Ben]

---

Ray.R wrote:

I used to do that. 

Would creating references for Front Panel objects impede cause any detriment to the overall software, especially when the references are not being used?

Of course all references (used or not) would be closed prior to terminating the program.

R

---

One of the other developers I work with wrote a little (cough cough) set of VIs that allows selection of any FP object on any FP in the app. Under the hood he used an AE to cache the references and an enum lets him choose it by name. The tricky part was getting the AE to inititalize and find all of the objects. He did that by sneaking his code into an XControl so he could detect when the app changed from edit to run modes.

So in that case, we have seen no issues (after he learned that explicitly opening a reference always allocated some memory).

Ben

PS: No I will not post that code because as soon as I did someone would ask me to explain it.  

[J.Mamakos]

I promise I won't ask you - I'll be sure to ask someone else! 😉