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

Similar Messages

Call by reference

Hi,
Please explain to me the very basic java rule: how can I update variabels inside a method:
f(Integer a)
a = new Integer(6);
public static void main(String[] args)
Integer a = new Integer(8);
f(a);
//here a is still at it's old value, right??
how can I change values inside a method (like calling by refrence in c)?

Primitive types (byte, short, int, long, float, double, char, boolean) are copied into the other variable. This is "call-by-value". Two examples:
Example 1 for call-by-value (without methods):
int a = 5;
// make a copy of a
int b = a;
// let's change b
b = 7;
// here a is of course still 5: the value 5 was copied from a into b aboveExample 2 for call-by-value (with methods):
public static void main(String[] args)
int a = 5;
// call a method with a as parameter
fn(a);
// here a is of course still 5: the value 5 was copied from a into the parameter
public static void fn(int x)
x = 7; // changes x, doesn't change a
}With objects, it's the other way around: Only their reference is copied into the other variable, so they are still both dealing with the same object. (Note that Strings are objects, but constants, so in this case you can treat them as if they were passed on as call-by-value.) Arrays are objects and I will use them in my examples for call-by-reference:
Example 1 for call-by-reference (without methods):
int[] a = new int[3];
a[0] = 2; a[1] = 3; a[2] = 4;
int[] b = a; // <-- here the reference to the array a is copied!
// let's manipulate b
b[1] = 5;
// here a[1] is 5, not 3!Example 2 for call-by-reference (with methods):
public static void main(String[] args)
int[] a = new int[3];
a[0] = 2; a[1] = 3; a[2] = 4;
fn(a);
// here a[1] is also 5, not 3!
public static void fn(int[] x)
b[1] = 5;
}How can one pass on an object as call-by-value if needed, you might ask. See method clone() in java.lang.Object. All objects inherit this method. It creates a copy of the object. Note that the result is simply type "Object" and you need to cast it into the correct type.
E.g. Calendar c1 = new Calendar();
Calendar c2 = (Calendar) c1.clone(); // <-- copy of c1
How can one pass on a primitive type as call-by-reference, seems to be your question.
The best way to get variables updated in methods is to use return values.
Example:
public static void main(String[] args)
int i = 4;
i = square(i);
public static int square(int x)
return x*x;
}Another possibility is to define "global" variables, i.e. outside of all methods. This might be necessary if more than one variable is to be changed in a method. Example:
protected static int i, j;
public static void main(String[] args)
i = 4;
j = 5;
public static void square()
i = i*i;
j = j*j;
}You could stuff the variables into arrays, use their wrapper classes, or create your own objects, too. Examples:
public static void main(String[] args)
int i = 4;
int[] i_array = new int[1];
i_array[0] = i;
square(i_array);
public static void square(int[] x)
x[0] = x[0] * x[0];
}An example with your own object:
class MyInt
int value;
MyInt(int v)
    value = v;
public class MainClass
public static void main(String[] args)
    int i = 4;
    MyInt i_object = nwe MyInt(i);
    square(i_object);
public static void square(MyInt x)
x.value = x.value * x.value;
}I hope one of these things will answer your question.
Monika.

Teststand New Thread VS LabVIEW "Call & Forget" Asynchronous call

Hi everyone,
Here is an example taken from the ni.com website showing how to use LabVIEW to post a TestStand Notifier. I have modified the example to fit the situation I needed to use it for. I have an example which works fine (When I use a TestStand new thread to launch the Notifier VI) and an example which does not work (When I use a LabVIEW "Call & Forget" Asynchronous call to launch the Notifier VI).
I would like to understand why it doesn't work in the second situation. The reason why I would prefer the 2nd situation which currently doesn't work is that I try to eliminate all multi-threads from an obsolete sequence written by someone else a few years ago so that I can troublesoot it and update the code to make it work with today's new reality.
Also, for my personal knowledge. I don't understand why the second strategy doesn't work. The Testsand notifier reference is the same and hadled the same way. I have included my example files with the 2 situations in seperate sequences files.
Thanks in advance to the person who will be able to enlight me.
Nien
Solved!
Go to Solution.
Attachments:
New Thread Or Dynamic Call.zip ‏41 KB

Hello Nien,
This isn't a TestStand issue. I suggest you take this to the LabVIEW forum. Looking over your code your Notifer and Forget.vi is dependent on the notifier.vi. So it's not necessarily anything wrong with the sequence steps but actually within your LabVIEW code itself. One suggestion is to insert a simple error handler.vi in your Call Notifier and Forget.vi. You have error wires connected to the functions itself, which is good practice but you don't have anything to inform you if an error occurs or not. I would suggest you to run try to debug your LabVIEW code, such as using highlight execution, while you're running your code so you know where exactly the error is happening.
Thanks,
Jonathan R.
Applications Engineer
National Instruments

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.

How can we tell if a VI is already running before calling Start Asynchronous Call?

The new Start Asynchronous Call node is awesome for spawning multiple instances of reentrant VIs. However, I've stumbled a bit in using it for non-reentrant VIs. The old practice of using the "Run VI" method would allow us to check the Execution.State of the VI before invoking the method to run it. That way if the State was Running or Run Top Level, we could skip the invoke node and just use a property node to open its front panel. WIth the Start Asynchronous Call node, it looks like we have to use a strictly typed static VI reference, and when we open the VI reference, the VI gets reserved and its Execution.State = Running. So, how can I tell if it is not just reserved by the thread but actually executing before making a redundant Start call?
By the way, the redundant Start has interesting behavior. It will actually cause the targeted VI to be executed again after it stops. Even if you hit the Abort button on the target VI, it will immediately execute again and again equal to the number of times the Start Asynchronous Call node was run. There's nothing wrong with that, and I suppose the simple answer is to just go back to using the old "Run VI" method. It's just that the ability to wire up those inputs directly to the connector pane is so nice. Perhaps I am missing something obvious. Oh, I am referring to the Call and Forget mode (0x80).
Thanks,
Dan
Solved!
Go to Solution.

Just throwing it out there, I know I'm a year.5 late on this but if it's a psuedo-modal dialog or some other window that you only want a single instance visible at one time, you can check the FP.State property on the strictly typed vi reference. If it's loaded and visible to the user it will be "Standard", if it was closed or not opened prior then the state will be "Closed".
I think the standard behavior of serializing execution on another thread would be great for doing a pre-set number of iterations with a sub vi in a non-blocking sort of way but for sub vi's meant for UI interaction checking FP.State works.
Philip
CLD

How to move files in background (asynchronous call)?

Hello
I would like to make an an Asynchronous call to the Move.vi for moving files as a background process.
I am having the following problems:
- The static VI Reference as input to the Open VI Reference function asks for a path to the VI to be called, but I can't find it. Where exactly is Move.vi located?
- The Type Specifier VI Refnum node accepts VIs via drag and drop, but only from an explorer window, not from the LabView VI palette. Again, I need to know where to find Move.vi. Or is there another way to specify the connector pattern?
It all works, if I call Move.vi from within a wrapper VI (because I know where to find that), but for the sake of simplicity I would like to avoid that step.
I'd appreciate any suggestions, also alternative approaches for moving files in the background.
Sebastian

Move is not a VI, but a primitive, so you can't call it like that. As you've seen, the wrapper method works.
Try to take over the world!

Unexpected loop behaviour with asynchronous call

I am having trouble with loop behaviour when using an asynchronous call.
I am building an application to record simultaneously temperature (NI USB-TC01 thermocouple), displacement (DC voltage, read from an Agilent 34401a) and resistivity (using a Keithley 2400 sourcemeter).
I am using a voltage sweep function on the Keithley 2400 to alternate current direction in a sample and measure the voltage drop - this is a common technique for eliminating thermal emf from resistance measurements. But what you need to know is that I set the number of current cycles I want and then wait for the instrument to measure and return the meausurements - up to 50 samples, which takes nearly 30 seconds. With the other two measurements, I have to programmatically call a measurement vi for each sample I want.
I have set up my application to asynchronously program the resistivity measurement and then wait for the response, and I want to in parallel measure temperature and position until the resistivity is done. I then want to record the mean and standard deviation for each signal. I used an event structure to interrupt the temperature and position measurements when done.
The problem I am running into is that after the first resistivity measurement is completed and I go to do the second one, the loop that measures temperature and displacement only runs twice, so I only get two samples, regardless of how many resistivity samples I want to collect. For example, if I want 50 resistivity samples at a time, the first iteration will measure rougly 40 samples of temperature and displacement, but any subsequent iterations will only measure twice.
I know this is probably overwhelming to understand the operation, but can anyone help? I have attached my code ('Delatometer') as well as a test vi I built that uses the same structure but has no interactions with instruments ('asynchronousCall').
The
Attachments:
Delatometer.zip ‏221 KB
asynchronousCall.zip ‏29 KB

I forgot to mention...the test vi that I uploaded executes as expected, so I am thinking that maybe its an issue with the instrument calls? I also found that if I run the Delatometer program in 'highligh execution mode' it runs properly, and it is my understanding that in 'highlight execution mode' there is no multi-threading.

Problem about asynchronous call: subVI front panel doesn't pop up when called.

Dear All,
I'm new to LabVIEW, and this is the first time I try to use the asynchronous call.
I'm using LabVIEW 2011.
I want to build a directory for several VIs, and it should allow users to open more than one of the VIs at the same time by pushing the buttons. Before building this directory, I simply tried to use asynchronous call to call a VI form another VI, but found a big problem.
I followed the steps in the help file, created a strictly typed reference, set the option to x80 because I don't need the return. When I run it for the first time, it worked fine: the subVI popped up and run. Then I closed the subVI. But for the sencond time and on, when I run the caller VI, the subVI didn't pop up, instead it seemed to run silently on background because when I manually opened it from the file I found it running. Besides, I didn't find any option like "show front panel when called" of the asynchronous call.
The caller VI and subVI are attached. The address of subVI in caller VI should be changed accordingly.
What should I do to make it work properly? Thanks very much for any idea!
Solved!
Go to Solution.
Attachments:
asynchronous_call.vi ‏8 KB
boolean.vi ‏7 KB

Jeff·Þ·Bohrer wrote:
A better approach is to set the vi properties programaticly like this:
Jeff, you will be happy to know that I used this tactic in full force on a project recently (lots of dialogs in this program). Not sure how many LabVIEW reboots it has saved me from. Reuse VIs made it even easier to do.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

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 .

Java is call by value or call by reference

Hi! friends,
I want to know,java is call by value and call by reference.
Please give the the exact explanation with some example code.

All parameters to methods are passed "by value." In other words, values of parameter variables in a method are copies of the values the invoker specified as arguments. If you pass a double to a method, its parameter is a copy of whatever value was being passed as an argument, and the method can change its parameter's value without affecting values in the code that invoked the method. For example:
class PassByValue {
    public static void main(String[] args) {
        double one = 1.0;
        System.out.println("before: one = " + one);
        halveIt(one);
        System.out.println("after: one = " + one);
    public static void halveIt(double arg) {
        arg /= 2.0;     // divide arg by two
        System.out.println("halved: arg = " + arg);
}The following output illustrates that the value of arg inside halveIt is divided by two without affecting the value of the variable one in main:before: one = 1.0
halved: arg = 0.5
after: one = 1.0You should note that when the parameter is an object reference, the object reference -- not the object itself -- is what is passed "by value." Thus, you can change which object a parameter refers to inside the method without affecting the reference that was passed. But if you change any fields of the object or invoke methods that change the object's state, the object is changed for every part of the program that holds a reference to it. Here is an example to show the distinction:
class PassRef {
    public static void main(String[] args) {
        Body sirius = new Body("Sirius", null);
        System.out.println("before: " + sirius);
        commonName(sirius);
        System.out.println("after: " + sirius);
    public static void commonName(Body bodyRef) {
        bodyRef.name = "Dog Star";
        bodyRef = null;
}This program produces the following output: before: 0 (Sirius)
after: 0 (Dog Star)Notice that the contents of the object have been modified with a name change, while the variable sirius still refers to the Body object even though the method commonName changed the value of its bodyRef parameter variable to null. This requires some explanation.
The following diagram shows the state of the variables just after main invokes commonName:
main()            |              |
    sirius------->| idNum: 0     |
                  | name --------+------>"Sirius"
commonName()----->| orbits: null |
    bodyRef       |______________|At this point, the two variables sirius (in main) and bodyRef (in commonName) both refer to the same underlying object. When commonName changes the field bodyRef.name, the name is changed in the underlying object that the two variables share. When commonName changes the value of bodyRef to null, only the value of the bodyRef variable is changed; the value of sirius remains unchanged because the parameter bodyRef is a pass-by-value copy of sirius. Inside the method commonName, all you are changing is the value in the parameter variable bodyRef, just as all you changed in halveIt was the value in the parameter variable arg. If changing bodyRef affected the value of sirius in main, the "after" line would say "null". However, the variable bodyRef in commonName and the variable sirius in main both refer to the same underlying object, so the change made inside commonName is visible through the reference sirius.
Some people will say incorrectly that objects are passed "by reference." In programming language design, the term pass by reference properly means that when an argument is passed to a function, the invoked function gets a reference to the original value, not a copy of its value. If the function modifies its parameter, the value in the calling code will be changed because the argument and parameter use the same slot in memory. If the Java programming language actually had pass-by-reference parameters, there would be a way to declare halveIt so that the preceding code would modify the value of one, or so that commonName could change the variable sirius to null. This is not possible. The Java programming language does not pass objects by reference; it passes object references by value. Because two copies of the same reference refer to the same actual object, changes made through one reference variable are visible through the other. There is exactly one parameter passing mode -- pass by value -- and that helps keep things simple.
-- Arnold, K., Gosling J., Holmes D. (2006). The Java� Programming Language Fourth Edition. Boston: Addison-Wesley.

Asynchronous call to web servie using pl/sql

1) How do I make an aynschronous call uisng pl/sql. I am currently using utl_http.
But it is expecting me to get repsonse using utl_http.get_response.
Is there anyway I can make asynchronous call to web service? Please give me examples if any.

Web services are NOT asynchronous as the HTTP application protocol is not asynchronous. A web service cannot (as an sync callback event) initiate a call to the web browser (client app) - as the web browser does not have a tcp listening endpoint. The web service must respond using the EXISTING tcp session established via a connect() call from the browser.
PL/SQL code executes in a dedicated or shared server process. Execution is serialised. So asynchronous calls are not supported and non-existent. Again, async processing requires some from of notification (callback event, message handler or signal interrupt handler) to inform the main process (while it is executing code), that the async call has completed.
And this does not exist in PL/SQL processing for very good reasons. (Oracle would have been one of the most unstable products on the market if it did support async PL/SQL processing, as 99% of developers would not understand how to use it correctly, and would have severely violated the fundamental concurrency and MVCC principles)
What can be done via PL/SQL (and SQL) is parallel processing - not to be confused with async processing. The API in PL/SQL to use for that is DBMS_PARALLEL_EXECUTE. You can also self roll this using DBMS_JOB or DBMS_SCHEDULER.
No default IPC exists for inter process communication between parallel processes. If IPC is needed, it needs to be manually coded using a standard SQL table (where row locking provides for mutexes and semaphores), or something like DBMS_PIPE.

Error handling / logging with asynchronous calls

Hi,
I want to log every error my app might throw. I thought it would be sufficient to surround either the launch method or the start method with a try...catch. But it doesn't work as excepted.
If an error occurs in an asynchronous call, e.g. in a button click, the exception is never caught.
Do you have an idea, how to solve this?
Example:
import javafx.application.Application;
import javafx.event.ActionEvent;
import javafx.event.EventHandler;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.layout.VBox;
import javafx.stage.Stage;
public class TestApp4 extends Application {
    public static void main(String[] args) {
        launch(args);
    public void start(final Stage stage) throws Exception {
        try {
            final VBox root = new VBox();
            Button button = new Button("Click");
            button.setOnAction(new EventHandler<ActionEvent>() {
                @Override
                public void handle(ActionEvent actionEvent) {
                    int i = 0;
                    int a = 5 / i;
            root.getChildren().add(button);
            Scene scene = new Scene(root);
            stage.setScene(scene);
            stage.show();
        } catch (Exception e) {
            // do logging here
            e.printStackTrace();
}

I'm not 100% sure how it works, but what I am pretty sure is that these Exceptions in EventHandlers are caught by JavaFX itself inside the JavaFX thread. They have to, because if they let the exception bubble up to the top, the FX thread would end (and with it, all response in the UI). It is probably caught at the level where Events are triggered somewhere (my guess is inside the QuantumToolKit).
Anyway, these exceptions are printed to System.err -- if you can redirect that stream to a log file or whatever you can have them all in one place. The error stream can be set in your application simply by calling System.setErr().
Note also that exceptions occuring in a Task are stored in the exception property -- sometimes these can be hard to find as they are put there silently -- you'll need to check your Tasks for exceptions and print them.

Asynchronous call deployment

I need to deploy an executable to a customer's computer and for the first time I have the need to use an asynchronous call in my program I am not sure how i am going to keep the file path to the "Open VI Reference" valid after I build and deploy the application. The Obvious manner would be to use a configuration file to allow me to set the path independently of the LabVIEW Application. However, when you include A VI in the "Always include" it is not An EXE thus not include as a file in the build folder, making it had to reference on the host computer.
Some educational tips on how to do this would be very help full for learning how to deploy this application
Attached is a code snippet of how i am currently stating an asynchronous call
Thanks
Mark R.

Actually, what you're referring to is a "type specifier VI Refnum", which is only used for type, but doesn't have any other information about the VI really. I've run in to bugs before where I changed the connector pane on a VI, but the type-only references I had in my code didn't update because there's no link to the VI, just the pane...
So really there are three different forms of a VI reference. Normal, Strict, and Type-only. Strict encapsulates both the normal reference and the type-only reference.

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.

Start asynchronous call very slow to return

Hello,
I have a user interface that contains 12 subpanels. These 12 subpanels are populated at startup with 12 reentrant VIs that are a method of a class (called PulseOx). At startup, I initialize the subpanels by opening a reference to the VI (PulseOx:isplay). An image of the initialization routine is show below.
Matt Richardson
Certified LabVIEW Developer
MSR Consulting, LLC

OK - so the formatting blew up on me and I can't seem to edit the original post. But, what I have found related to the above is similar to the Start Asynchronous Call performance. Essentially, the VI that I call via this routine is reentrant and it starts by attempting to initialize a serial port. If the device is not present, the port throws an error when I attempt to configure it, but only after waiting 5 seconds. So, the reason everything seems so slow is due to the long configuration time. This seems to be a hardware defined timeout - the configure serial port VI will not relinquish control until it has finished attempting to configure the port - 5 s. This in and of itself is not a big deal. We can live with this timeout, but what I don't understand is why this might be interfering with other VIs that are attempting to read from other serial ports that are properly connected. In my current setup, the display VI launched via the call to the Start Asynchronous Call attempts to connect repeatedly (this helps if a user accidentally disconnects the device and then reconnects later). The call to initialize the ports resides in a reentrant VI that runs on the instrument i/o execution system. All others use the stanard execution system.
Does anyone have any thoughts as to why the execution of reentrant VIs might interfere with each other if all VIs called are reentrant themselves?
Matt
Matt Richardson
Certified LabVIEW Developer
MSR Consulting, LLC

Asynchronous Call By Reference Examples

Similar Messages

Maybe you are looking for