VI of the Day (9/17/2009) - Call By Reference Node

[Darin.K]

A very useful object today, the "Call By Reference Node".  The idea is very familiar to text programmers, you write a great numerical routine and you'd like to call it with several user-defined functions.  No problem, just use a few pointers and you are all set.  This node gives you very similar capabilities in LV.  It is not as simple as simply calling a sub-VI, but it is not that hard once you get the hang of it.

This simple example shows the basic steps. First you open a reference to the VI and strictly type it, then you call the VI and finally close the reference.  In this instance, it is just a slightly slower way of calling a sub-VI, in an actual application you would most often pass the reference to sub-VI which would contain the Call By Reference Node.  In this manner you have a sub-VI which can operate on user defined functions.  How do you get that type reference into the constant, you could either dig through the right-click menu, or simply drag a VI on top of it.

Let's say you (or NI) have written some very nice routines for root finding or curve fitting.  You don't want to dig inside every time you want to change the function, and how could you if it is selected at run time?  Easy, use the formula parsing version.  WRONG ANSWER (IMO).  Why flush all of that performance that you (or NI) worked so hard for by slowing it down with formula parsing?  Instead, use the 'f(x,a) is a VI' version and create your own VI.  More on fitting in an upcoming VIOTD.

Groundrules for VIOTD here. 

Message Edited by Darin.K on 09-17-2009 09:55 AM

[elset191]

There needs to be a VI like this for calling reentrant VI's, because what you posted balloons into something like this when you want to have multiple instances running.

At least this is how I understand it.  If I'm wrong, please somebody tell me.  I have like 5 VI's like this floating around that I want to get rid of.

[Ben]

---

elset191 wrote:

There needs to be a VI like this for calling reentrant VI's, because what you posted balloons into something like this when you want to have multiple instances running.

At least this is how I understand it.  If I'm wrong, please somebody tell me.  I have like 5 VI's like this floating around that I want to get rid of.

---

I agree but to give this topic another twist...

If you use LVOOP then you pass all of those values (and others you may not have concidered previoulsy) via a single set operation. See image where Olivia was showing us this idea in an earlier thread.

One of the strong points of LVOOP is the generic LV defined class that everything else inherits from. In theory any LVOOP VI could be called using this same code construct.

Just trying to spin this a diferent way,

Ben

[tst]

Ben's example is certainly a better way of passing multiple parameters to a VI (and is what I do today as well), but I agree that there needs to be a better way of making an asynchronous call to a dynamic VI. Luckily, there's already an idea for this here, so if you feel so as well, I suggest you head over there and vote for it.

[elset191]

---

tst wrote:
Ben's example is certainly a better way of passing multiple parameters to a VI (and is what I do today as well), but I agree that there needs to be a better way of making an asynchronous call to a dynamic VI. Luckily, there's already an idea for this here, so if you feel so as well, I suggest you head over there and vote for it.

---

Been there, done that.

[J-M]

Ben,

 

Could you provide the link of the thread you mention (Olivia).

 

Thanks

 

Jean-Marc

[Darin.K]

---

tst wrote:
Ben's example is certainly a better way of passing multiple parameters to a VI (and is what I do today as well), but I agree that there needs to be a better way of making an asynchronous call to a dynamic VI. Luckily, there's already an idea for this here, so if you feel so as well, I suggest you head over there and vote for it.

---

That idea is worth 2 Kudos, you'll have to settle for one here and one there.

I have a semantic question now.  Is this a function or a structure (as well as a node)?  The LV2009 help started calling it the "Call by Reference Node Function".  That would give us the "Call Library Function Node Function", which is better than the "Call Library Function Function".  (Conjunction Junction Function).  I would have thought of it as a structure myself, and "Node Function" seems redudant since all functions are nodes.  Just when I think I am starting to understand the vernacular...

[tst]

A structure is something that contains other code inside it (case structure, event structure, loops, etc.), although you would know it by looking at the structures palette (globals, feedback nodes, formula node (which has code, but not G code).

A node is basically everything on the diagram that has functionality and isn't a wire (control terminals, subVIs, primitives, structures, XNodes, etc.). That said, there are a few objects which are also explicitly refered to as nodes by name. Offhand I can think of the formula node, the property node, the invoke node, the call library function node XNodes and the code interface node (ooh, I forgot the feedback node I mentioned in the last paragraph). The call by reference node also falls into this group. You can refer to it as a function (just like you can refer to the primitives as functions), but as you say, it creates redundancy in the name.

That said, it's purely a matter of semantics. NI could have given it a different name as well.

Message Edited by tst on 18.09.2009 12:34 AM

[Darin.K]

---

Ben wrote:  

 See image where Olivia was showing us this idea in an earlier thread.

 

---

 My daughter chooses a more conventional path to learning OOP.

[tst]

Ben's post is in this thread.