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.

Similar Messages

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 .

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

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 ...

How to show the front panel when launching VI with Call by reference node??

Hello!
I just wonder how I make the front panel visible during execution when I launch the VI with CALL BY REFERENCE NODE.
Se example.
Could u also show me how to change different properties (window size ..) of the front panel??? (launched with CALL BY REFERENCE NODE)
Thank you!
Attachments:
test.vi ‏18 KB

In VI Properties>>Window Apperance>>Customize you can check "Show front panel when called". This will open the front panel on each call. It doesn't matter how the call was initiated.
You can set a lot of Front panel properties during runtime. Place a Property Node in the block diagram. Change the class from App to VI. Under properties select Front Panel window>>Panel bounds to set the position and size of the front panel.
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

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

DLL C/C++ syntax for Call Library Function Node

Hello,
I am interested in calling DLL from Labview and found several intersting tutorials on the Call Library Function Node. One interesting tutorial is Building a DLL with Visual C++ http://zone.ni.com/devzone/cda/tut/p/id/3056
One can notice in the example presented in this tutorial that the parameters that are outputs of the exported function are of type pointers. And I am curious about the theory behind this.
I looked also at the example in LabVIEW Call DLL.vi and it seems that all outputs are pointers to the desired data type.
I tried to write a short code where I assign a new value for one parameter in the export function. But this value is not updated in Labview. To make it clear: assume 50 is passed to an input parameter (on the left side of the Call Lib func Node). In the function, i assign 100 to this variable and expect this value on the output in Labview (right side indicator of Call Node) but the output remains 50.
I am trying to change my code but i get errors in linking (compiling is ok) that I cannot understand. LINK : fatal error LNK1168: cannot open Debug/DoseDLL.dll for writing
Error executing link.exe.
I don't get any error with the code provided in the above tutorial so i am trying to reproduce a similar code...
Thank you

Hello,
Please find attached the source code in C, the DLL and the vi.
you notice in the C code that I set variable dose=100 and this is the value I would like to export as an output for labview (right side of Node) for whatever value in the input (i put 50 for input dose). In the current code, the same value of input dose (50) is passed to the output (i assume it has to do with the reference ?). The idea is that variables dose and rate should be set/calculated in the DLL function.
Thank you!
Attachments:
DoseDLL3.cpp ‏1 KB
DoseDLL.vi ‏8 KB

Execution time for Call Library Function Node

I am experimenting with the Call Library Function Node block in LabVIEW and am curious if it should be running faster than what I'm seeing. For testing purposes, I have compiled and transfered to my RT target the .out file from the KB article http://digital.ni.com/public.nsf/allkb/81D1172E3C28A5E4862575CC0076A230 (I'm using the vxworks 6.1 version). The function in the .out file just multiplies two inputs together, adds a constant, and returns the result. I have put this inside a 1 kHz timed loop with a commanded period of 1 ms and via the Ticks(ms) block and shift registers I calculate the amount of time per loop execution. This process is apparently taking 5 ms per cycle and to me that seems slow. Is that roughly the correct execution time for this kind of setup? I will attach my test .vi file.
What I'm using:
Windows 7
LabVIEW 2009 SP1
NI-cRIO 9024 with NI-RIO 3.4.0
Solved!
Go to Solution.
Attachments:
test DLL.vi ‏31 KB

First off, the way you are doing timing isn't necessarily accurate because you don't know when the tick count VI is being called. For example, if it gets called on one iteration after your call library node executes, and the next iteration it gets called before the CLFN it executes, the subtraction doesn't include the call of the CLFN so you aren't seeing the true time it is taking for the dll to be called.
Where it says "error" on the top left hand corner of your loop. left click and choose previous iteration timing. Also, do you have the ability to choose a 1 Mhz clock? Are you sure it's actually being run on the RT and not on your PC? Running it on the PC would definitely make it difficult to execute at a 1 kHz rate.
CLA, LabVIEW Versions 2010-2013

Default billing type for delivery without reference (Delivery Type LO)

Hi,
We have copied delivery type LO to ZLO, so by default Copy control got maintained in VTFL.
But when we do billing for this delivery in VF01 the system is picking F2 as billing type automatically.
The system is not picking the defined billing type (ZF2- copy of F2) for which we have maintained copy control in VTFL
The system is accepting ZLO->F2 but not accepting ZLO->ZF2
Rgs,
Vipin

Hi,
When you have a delivery document created without reference to a sales order, the system uses a defualt order type. Check that in the delivery document type definition ( LO ), the default order type is DL. If you look at the definition of DL in VOV8, the billing document type defined in F2. This is what the system uses as the proposed billing document type. If you want the system to propose ZF2, create a copy of DL and assign that to ZLO as the default order type. Change the billing document type to ZF2 in the sales order definition and you will be able to propose ZF2.
Hope this helps.

Passing Variant to dll using call library function node

Hi,
Using LV2012
I have a dll that the following prototype:
SetTestResult(LPCTSTR Serial, int Test, int Result, VARIANT measuredValue);
How can I pass the Variant to this node when my variant can be either int or float.
I have tried "ToVariant" function but it is not sending data and gets error 1517 on LabView. For configuration parameters for variant I have used ActiveX type and datatype as activeX Variant Pointer.
So for call library function node my prototype looks like this:
int32_t SetTestResult(CStr Serial, int32_t Test, int32_t Result, VARIANT *measuredValue);
Can someone help me understanding What am I doing wrong here please?
Thank you,
Hiren
Hiren Patel

Hello Hiren,
Posting your code (even without the DLL) would definitely make it easier for people to point out potential issues. Here is an example that demonstrates passing an ActiveX variant to a DLL built in CVI, I would suggest cross-checking the way the Call Library Function Node has been configured.
Example:Transferring an ActiveX Reference Pointer to a CVI DLL
http://zone.ni.com/devzone/cda/epd/p/id/3343
Regards,
Tom L.

Strange problem of calling library function node in labview 2010 and 2011

one year ago,I develop a program to usb device data and it works well,in labview 8.6 or 2009(win xp).Recently, When I test
the program in labview 2010 and labview 2011(win xp).,the program always crash immediately.I check the program and find main
problem is in call library function node. In my program,I use labview 2009 library for the USBExpress driver for
Silicon Labs USB MCU's from:https://decibel.ni.com/content/docs/DOC-9522,for example, 2 functions SI_OPEN and SI_READ
can not work well.
the header definition of SI_OPEN and SI_READ is:
SI_STATUS WINAPI SI_Open(
DWORD dwDevice,
HANDLE* cyHandle
SI_STATUS WINAPI SI_Read(
HANDLE cyHandle,
LPVOID lpBuffer,
DWORD dwBytesToRead,
LPDWORD lpdwBytesReturned,
OVERLAPPED* o = NULL
the SI_STATUS is equivalent to int type.
orignally, for HANDLE * in SI_Open, the parameter type in call library function node is numeric, data format is unsigned 32 bit integer ,and pass pointer to value.
for HANDLE in SI_Read, the parameter type in call library function node is numeric, data format is unsigned 32 bit integer ,and pass value.The program works well in labview 8.6&2009,however,crash in labview 2010 &2011.
later,I debug the program, for HANDLE *, I choose parameter type in call library function node as adapt to type, data format is point to Handles.for HANDLE, I choose parameter type in call library function node as adapt to type, data format is Handles by Value.Crash not happend in labview 2010&2011,however,it cannot read any data from from USB device correctly as before.I can not find the reason.
Dear friends,I need your help to answer the problem. Thank you.

Based on the help page it looks like it should execute asynchronously.
The thing in the description that leads me to believe they execute asynchronously is that you can configure the library to run as a multi-threaded operation.
Please take a look here to see the difference between synchronous and asynchronous execution.
Since the code even has the ability to be multi-threaded, you can consider it as running in parallel to your other code.
Any data returned is passed to the thread that called that function.
Cory K

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)

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.

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.

Check VI type for call by reference node

Similar Messages

Maybe you are looking for