Run VI versus Call by Reference

I noticed that when you do Run VI you have the option of specifying whether or not you want to wait until the VI is done. I need to pass in a parameter so I'm using the Call by Reference node instead but I can't find the property that will allow me to specify if LabVIEW should wait until the sub-VI is completed or not. In this case I don't want it to. Is there a way around this?
Message Edited by Gary D on 07-11-2005 09:27 AM

Dennis Knutson wrote:
You have to use the Run invoke node and pass parameters to the VI using either the Set Control Value or Set Control Value [Variant] method.
I just tried that and I'm not sure if I set it up correctly. I'm now getting Error 42 at the invoke node. Its reason is listed as a General Error.
Using the Variant thing works more. I get no errors but I also don't see my VI (have show FP on load and call wired as true). I think I can figure the rest out on my own. Thank you.
Message Edited by Gary D on 07-11-2005 10:02 AM
Message Edited by Gary D on 07-11-2005 10:02 AM

Similar Messages

Is there any way to show vi's called by reference in the hierarchy window

I've inherited some code and in order to save memory and system resources at run time it calls several vi's by reference rather than including them as sub vi's.
Howver I would like to use the hierarchy window to get a more general overview of how the system works but the vi's called by reference don't show up here. Is there any easy way of finding out how all the parts interconnect?

VIs called by reference should appear in the hierarchy window but not under the caller icon. They appear at the top line of VIs.
If you are sure that a VI is in memory and it does not appear in the Hierarchy window, this VI has been marked as "System VI". Such a VI won't appear on the Hierarchy window or on the application property "VIs in memory".
LabVIEW, C'est LabVIEW

LabVIEW RT, Timed loop, finished late, Call by reference

I have a timed loop triggered by the sample clock of a DAQ-Card. The sample Clock is 8 kHz and the loop will run with dt = 4. Normally the loop is running without finished late[i-1]. But from time to time it happens that the loop is running extremly longer which means instead of 0.5 millisec it needs 4 - 5 millisec. It seems this doesn't never occur while accessing DAQmx.
The application uses plugin technologies and some of the VIs in the timed loop are preloaded and called by Call by Reference.
Does those VIs inherit the priority, execution system and CPU of the timed loop?
The application is running on LV RT 2009 on a Dual core PXI-Controller. The timed loop is bound to CPU 1. There is no difference runinng the application from the development environment or as a startup application.
For the measuring test I modified the application in a way that I don't have:
disk access for storing the result file
TCP/IP communication
Controls on the front panel of the top level VI
Waldemar
Using 7.1.1, 8.5.1, 8.6.1, 2009 on XP and RT
Don't forget to give Kudos to good answers and/or questions

To keep you informed:
I stripped the application and have left only the measurement storing module and the timed loop. The loop was using the microsecond timer running each 500 µsec. Additional all Non-Real-Time modules were loaded and only one module creates a XML string and sends it to the communication layer which will drop it because no TCP/IP port is open. The creation of the XML string is done each 300 ms.
In this case I don't have any finished late iterations
Next I added the DAQ Module. Now I get finished late again but with a lesser frequency as original.
I removed all unnesseccary tasks from the DAQ moulde leaving one task for a PXI-4204 for using as the clock source for the timed loop. No I get finished late seldom.
I removed the module which will send the XML string and I don't get finished late.
Next I was adding code to see memory allocation. I can when memory allocation is changing but it is not related to the finished late iterations.
Next time I have the chance to do more tests I will see which DAQ task triggers the finished late iterations. I have one AI task on a PXI-4204, 4 Counter tasks on a PXI-6602, 1 DI task on a PXI-6514, 1 DO task on a PXI-6514, 1 DI task on a PXI-6259, 1 DO task on a PXI-6259, 1 AO task on a PXI-6259 and 1 AO task on a PXI-6711.
The AI task on the PXI-4204 is running in Continous Sampling (Single Point HW Timed is not supported), all other tasks exept the DI and DO are Single Point HW Timed.
Waldemar
Using 7.1.1, 8.5.1, 8.6.1, 2009 on XP and RT
Don't forget to give Kudos to good answers and/or questions

Threading and Re-Use of buffers Using Call By Reference node (Duct Tape required)

I have been trying to get the following information into the public domain for years and now that I have the answers, I will share with those that may be interested.
Warning!
Wrap your head in duct tape before reading just for safety sakes.
My two questions have been;
1) can LV Re-use the buffers of the calling VI when using VI Serve Call by reference?
2) Is the UI thread used when using Call by reference?
1. When calling a VI using the call by reference node, does the data going into the connector pane of the node get copied, or is it in-line as it would be with a properly set up subVI?
Short answer: It is somewhere in-between.
Long answer:
The compiler doesn't know what VI will be called, but it does have a hint:
the reference wired into the Call By Reference node. It uses that to get the "Prototype" for the call. So for the best performance, use a prototype that has the same "in-placeness characteristics" as the called VI. That being said, users don't know what the "in-placeness characteristics" are.
Before I go into the details, I should say that the overhead of these copies shouldn't matter much unless it is a large data structure (an array with a lot of elements, or a cluster/class with many fields or containing large arrays etc.).
Example 1:
If the prototype does not modify the data then the compiler assumes that the Call By Reference node will not modify the data. However at run-time a check is made to see if the actual called VI will modify the data. If so, then a copy is made and passed in so that the original data can remain unmodified.
Example 2:
If the prototype contains an input that is wired through to an output in such a way that both the input and output terminals can use the same memory buffer, but at run-time a check determines that the actual called VI's input and output do not share a buffer, then a copy will be made from the actual call's output to the original VIs (combined input and output) buffer.
I should also mention that even with this "attempt to agree with the prototype" behavior, it's not always possible to get as good performance as a regular SubVI call. For instance if you have a situation where the prototype does not modify the data and passes it through to an output then the compiler must assume that the data is modified (because as in example 2, there exist VIs that may modify it even if the actual VI called does not).
And there are some caveats:
1) This "using a prototype" behavior was new to 2009. Before that we used a more naive way of passing data that assumed all inputs will be modified and no outputs share a buffer with an input.
2) This behavior is subject to change in future versions, if we find further optimizations.
3) This behavior is the same as we use for dynamic dispatch VIs (when using LV classes)
4) If you want to create a VI only to be used as a prototype, then you can use features of the In-Place Element Structure to control the "in-placeness characteristics" Namely the In/Out Element border nodes, the "Mark as modifier" feature of the border nodes (note the pencil icon on the In Element), and the Always Copy node.
5) The prototype is only the first reference ever wired into the Call By Reference node. So if you do make a new prototype VI, you can't just make a reference out of it to wire to the Call By Reference node. I suggest deleting the Call By Reference node and dropping a new one.
6) For remote calls, we always have to "make copies" by passing data over a network.
I hope this helps, if you want any further information/clarification, then feel free to ask.
2. Does the call by reference node execute in the UI thread? If the call is being made by a remote machine over ethernet, which thread does the host (the machine that makes the call by reference) execute on and which thread does the target (the machine that contains the VI file) execute on?
In the local case, the Call by Reference node does not require the UI thread and can run in whatever thread the VI wants to execute in.
When calling a remote VI, the Call by Reference node uses the UI thread (detailed below) on both the client and on the server.
The client uses the UI thread to send the call request to the server and then again when the response comes back. The UI thread is not blocked during the time in between.
The server receives the TCP message in the UI thread and then starts the call in the UI thread. The server also uses the UI thread to send the response back to the client. The UI thread is not blocked on the server during the execution of the VI.
I hope people find this when they need it!
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction
Solved!
Go to Solution.

I never use duct tape. I wrap my head in aluminum foil and thus get much better shielding from the aliens trying to tap my mind.
Also easier to remove later, but why risk taking it off??
LabVIEW Champion . Do more with less code and in less time .

Asynchronous Call By Reference Examples

The asynchronous Call By Reference feature was added to LabVIEW 2011 which introduced the Start Asynchronous Call node and the Wait On Asynchronous Call node. However, an oversight lead to the examples for this feature only being installed with the win32 version of LabVIEW 2011.
I attached the examples for those running a non-win32 LabVIEW 2011. These examples should reside in <examples>\viserver\AsynchronousCallByReference.
Attachments:
AsyncCallByRefExamples.zip ‏99 KB

Hi jcase,
Thank you for bringing this issue to our attention. I have created a Corrective Action Request to notify R&D of the issue. Sincerely,
Julianne K
Systems Engineer, Embedded Systems
Certified LabVIEW Architect, Certified LabVIEW Embedded Systems Developer
National Instruments

Labview 7.1 call by reference node that won't compile on OSX

Hi,
Here is the issue. I have an app that has been running in dev mode for a few years. Someone just noticed and wants it compiled. Everything seems to compile properly and loads fine. It is only when I get to a part in the code that has a call by reference node does it crash. It is a bad crash. The app quits all the way to the finder. I have no idea even where to begin to debug these. I am pretty sure that call by reference is the think that is causing. I remove it, doesn't crash. Only problem is that if I need to remove it, the whole app needs to be redesigned..... Soooo anyone has an ideas?
Spec:
OS X 10.4.8
Labview 7.1.1
PPC
I have tried to goto Labview 8 but that was another headache. Alot of the code changes and acts differently then it did in 7. So for now I am going to stay with 7. Anyone had this problem or can think of a way to figure out fix it or even find out for sure what the problem is?
Any help is much appreciated........
Message Edited by Tarek316 on 06-04-2007 09:11 PM

Hello,
You may be calling dynamically loaded VIs and not including them in your build. If so, please include the VIs that you are calling. You can add them by going to the Source Files Tab and clicking on Add Dynamic VI. Then please rebuild your executable.
ERROR 7 When Running LabVIEW Executable That Uses Dynamically Loaded VIs (VI Server)
http://digital.ni.com/public.nsf/websearch/FEE9D75A70FB8EBA86256A9D00498B8A?OpenDocument
Please let me know if this does not fix the problem.
Regards,
Elizabeth S.
Applications Engineer
National Instruments

Need help with Call By Reference on cRIO-9012

I have a RT application running on a cRIO-9012 in which I am attempting to establish references to a variable number of clones of the PID Autotuning (Temperature).vi, and then passing these references to a FOR loop in which I am opening each clone with a Call By Reference node to perform the PID. Essentially, I am trying to make the PID Autotuning (Temperature).vi accept an array of process variables, similar to the behaviour that some of the simpler PID VIs provide out-of-the-box.
The code I am using to obtain the references is here:
...and the code within the control loop where I am trying to do the processing is here:
The problem I am encountering, according to the Highlight Execution tool, is that all inputs to the Call By Reference node are present and reach the node, but all processing stops at this point on the first iteration and the cRIO hangs. I cannot stop the SubVI or the RT parent VI without performing a software restart on the target.
I don't know if I am using the Call By Reference node or Open VI Reference functions incorrectly, or if there is a problem with the VI being part of a library, or if something else is wrong. Any help would be appreciated.
Sean

I'm not sure this is your issue, but I think there's a conflict between opening a bunch of rereferences, and then setting the asynchronous call pool size for one of them.You don't need asynchronous execution here, you just need reentrant parallel execution (you may not even need the parallel part; your current code, if it worked, would execute sequentially, and the PID calculation is just math so should be quick and may not benefit from parallel execution). You do need reentrant execution to maintain separate data spaces.
Try opening the references with the 0x08 (Prepare for Reentrant Run) flag instead. Remove the Populate Asynchronous Call Pool. If this works, you can run in parallel by enabling For loop parallelism - but you might find that's actually slower, especially on a cRIO.

Cluster & Call by reference ( Sorry for the re-posting)

If this is set to 'true', then what happens when the bean is in a diffent
          machine(Cluster)( Does it automatically passes object by 'value' or still
          tries to pass the object by reference, in which it is going to be a empty
          object )
          Looking at the document provided by weblogic , it looks like it
          automatically passes the object by 'value' even if it is set 'true'(Only
          incase of bean is running in a different container/server)
          Thanks
          
          <!ELEMENT enable-call-by-reference (#PCDATA)>


You cannot pass-by-reference a non-RMI Object across 2 VMs, no matter what the flag is, no matter
          what application server you are running under. An object reference in one VM is meaningless in
          another VM, for they do not share the same memory-address-space.
          Even though EJBs are RMI Objects, their method arguments are not unless you explicitly pass the RMI
          interface.
          Gene Chuang
          Join Kiko.com!
          "lal" <[email protected]> wrote in message news:[email protected]...
          > Is this true for WEBLOGIC server (5.1) ?
          > Does the container automatically switches to 'call by value' mode even
          > though the flag is set 'true' for call_by_reference in XML deployment
          > descriptor.(I know this only arise in the fail over process in a cluster
          > environment)
          >
          >
          > "Rob Woollen" <[email protected]> wrote in message
          > news:[email protected]...
          > > Anytime a call goes over the network, it will be call by value.
          > >
          > > Call by reference is only possible within the same server vm.
          > >
          > > -- Rob
          > >
          > > lal wrote:
          > > >
          > > > If this is set to 'true', then what happens when the bean is in a
          > diffent
          > > > machine(Cluster)( Does it automatically passes object by 'value' or
          > still
          > > > tries to pass the object by reference, in which it is going to be a
          > empty
          > > > object )
          > > >
          > > > Looking at the document provided by weblogic , it looks like it
          > > > automatically passes the object by 'value' even if it is set 'true'(Only
          > > > incase of bean is running in a different container/server)
          > > >
          > > > Thanks
          > > >
          > > > 
          > > > <!ELEMENT enable-call-by-reference (#PCDATA)>
          >
          >

Why the subvi can not show,when i use call by reference node.

I used a call by reference node in function pallete,i follow the labview manuals and examples(dynamic load example), but i can not see the subvi show when the program running.
Attachments:
comshow.vi ‏75 KB
交流稳态频谱.vi ‏19 KB

Hi Sunny,
Open your subVI,
1. go to File->Vi Properties (or Ctrl+I)
2. choose Window Appearance category
3. choose Customize
4. check "Show Front Panel When Called" (and "Close Afterwards ..")
5. save the VI, close it and try again.
Let us know if it's OK ...

Subroutine execution priority with Call By Reference nodes

Hi -
I have a VI which contains a Call By Reference node. I would like this VI to run with subroutine execution priority (the VI is small, is called frequently, and must run quickly). The VI being called by reference is itself set to run with subroutine execution priority. However, I get an error which reads: subroutine priority VI cannot contain an asynchronous node. What is asynchronous about a call-by-reference to another subroutine VI? Is there any way to get around this? Thanks.
Jason
Jason Rolfe

This is what the help files mention:
Subroutine priority VI cannot contain an asynchronous node
This VI has subroutine priority selected in the Execution page of the VI Properties dialog box. It cannot use an asynchronous node on its block diagram. Asynchronous nodes, such as dialog boxes, are supposed to allow other VIs on the same thread to continue to execute while they wait to complete their own execution. However, subroutine priority VIs block the execution of other VIs on the same thread until the subroutine priority VIs finish execution.
You can correct this error in the following ways:
Change the execution priority of this VI. To change the priority, right-click the VI icon in the upper-right corner of the front panel or block diagram window, and select VI Properties from the shortcut menu to display the VI Properties dialog box. Select Execution from the top pull-down menu of the VI Properties dialog box, and change the priority in the Priority pull-down menu.
Remove the asynchronous node.
I am affraid that the call by reference node is asynchronous.
aartjan

VI loaded with either Invoke Node or Call by Reference only functions properly when it is already open

I have modified the Dynamic Loading example so that my case for the first button loads three VIs in succession, rather than one. The first VI generates a waveform, the second uses this waveform to calibrate the measurement, and the last VI stops the waveform generation. I discovered that the middle Calibrate.vi would only function properly if the Calibrate.vi was already open. I attempted the VI loading of the Calibrate.vi with both the Call by Reference (identical to the example) and the Invoke Node method. In both cases, the first and last VIs (Multitone Gen.vi and Stop Gen.vi) functioned properly, but the Calibrate.vi only worked correctly when it was already open.
I have tried resetting the NI USB DAQ device and that hasn't helped.
My search for answers has come up empty and I am hoping that someone in the forum might be of assistance. I have attached a snapshot of each version of my code, both built off of the Dynamic Loading example.
Thanks!!
Attachments:
Call by Reference.png ‏19 KB
Invoked Node.png ‏21 KB

Hello Anjelica,
I do not receive any error messages when the middle VI is loaded and run.
The Calibrate.vi acquires three separate corrections (Open, Short, Load), averaging results from a number (N) of measurements, determined by the user. When the VI is loaded and run correctly, information describing the multitone waveform generated by the first VI is first acquired. Then the user selects each correction individually. The corrections are made and averaged after N corrections, taking approximately 10 seconds per N.
When the Calibrate.vi is malfunctioning, the multitone waveform information is not loaded and when a correction is selected, the indicator displaying the number of measurements performed (n of N where n = 0 to N) instantaneously displays N of N. The correction measurements are not performed. I have even tried using the Front Panelpen method and then running the middle VI and this results in the same malfunction unless the Calibrate.vi is already open.
Though it is an obvious workaround, I can live with opening the Calibrate.vi via the Open VI Reference method outside of the while loop. This will be my solution for now.
Thank you for your response.
Attachments:
Open Outside Loop.png ‏23 KB

Application locking up at Call by Reference

We are seeing our application lock up occasionally at a VI Server Call By Reference node. The VI acts like it is waiting for subVI called to execute, but the subVI acts like it never got the message to execute. We've seen this at a number of VIs that call subVIs by reference. In some cases we are using strickly typed VI references, and in other cases we are not. We've seen the code lock up in both. Has anyone else seen this type of behavior?
We are running LabVIEW 7.0, Windows XP, and TestStand 3.0.
Also, I noticed that in a couple of places, the reference isn't explicitly closed. Since these VIs are only a small part of the application, not called very often, would that cause much of a problem (memory or otherwise)?

SAS,
The problems described by TPoint in the thread "TestStand hang, Execution with Event-Callback-VI " sound familiar. Our code locks up at the "Run VI" Method (I've enclosed a screen capture of the VI where it locks up), and once it does, you can't open any VIs from Explorer. You can still open VIs from within LabVIEW. My main problem, though, is trying to get it to happen in a small application, and getting it to repeat more frequently. Right now, we can go through 200 test runs before it happens. Not enough to stop production, but enough to cut into our yields. Unfortunately, it also makes it very hard to diagnose. On our development system, it takes about 4 days to get through 200 runs. So what I'm getting at is, if you can post an example of where you saw the problem, may that would help me put together an example of my problem.
We don't use Events, we use polling. We are also using LabVIEW 7.0, and I see that TPoint was using LV 7.1, so I couldn't open that example. If there are other screen shots that you think would be helpful, let me know. The Operator Interface is huge (its inherited code, I wish I had the time to rewrite it), so I can't post the whole thing, but if there are specific routines (such as the polling routine) that you'd like to see, I could post that.
Thanks,
Tom
Attachments:
Call_Driver_Mode_Block_Diagram.jpg ‏72 KB

Application locking up at Call by Reference

We are seeing our application lock up occasionally at a VI Server Call By Reference node. The VI acts like it is waiting for subVI called to execute, but the subVI acts like it never got the message to execute. We've seen this at a number of VIs that call subVIs by reference. In some cases we are using strickly typed VI references, and in other cases we are not. We've seen the code lock up in both. Has anyone else seen this type of behavior?
We are running LabVIEW 7.0, Windows XP, and TestStand 3.0.
Also, I noticed that in a couple of places, the reference isn't explicitly closed. Since these VIs are only a small part of the application, not called very often, would that cause much of a problem (memory or otherwise)?

It sounds like your reference is pointing to something else than you
think it is pointing to. Generally speaking, not closing
references is not good. Whether it will lead to problems is most
likely a matter of probability. Could it be that the reference is
actually being closed before you issue the correct command?
Fix the code first (make sure that references are closed when they're
no longer used and make sure references aren't closed when they are
still in use).
References are great for uncovering tiny errors in code. Hunt
them down and show no mercy! Or just debug, that'll work too.
Seriously, I recommend you trace where the references are coming from and make sure they're being closed at the right time.
Important is also the difference between (what I understand as)
"static" references (right-clicking a control and selecting -create
reference) and those created dynamically (such as in lauching a VI via
VI server). All Dynamic references should be closed when finished.
If you could post a picture of the block diagram (Jpg is good, BMP is bad) maybe someone can offer some more precise help.
Hope this helps
Shane.
Using LV 6.1 and 8.2.1 on W2k (SP4) and WXP (SP2)

Check VI type for call by reference node

Hi Ppl,
I'm calling a set of VI's dynamically using call by reference node. And I have a type specifier linked to a particular type connector pane. But at times when the VI prototypes do not math I get error from the open VI reference node. Is there any way to check if the VI connector panes matches before opening the refrence with the VI type specifier ?, or using the error code is the only way to check if there were miss match in VI connector pane.
Thanks
Solved!
Go to Solution.

But what is wrong with Error checking?
For example, I using code like this in my application for detect which type of dynamic VI should be used (decision based on Error output):
Andrey.

Java programming language uses call by reference for objects?

Is Java programming language uses call by reference for objects?

Yes. You make calls to an object via itsreference.
No.Yes, you're referring to passing a reference into a
method in which case the value of the
reference is passed.I believe the OP is using the term "call by reference" to mean "pass by reference." The two are interchangable, AFAIK. So, while "making calls to an object via its reference" is correct, I don't believe it's germane to the question.

Run VI versus Call by Reference

Similar Messages

Maybe you are looking for