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 .

Similar Messages

  • 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

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

  • 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

  • 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

  • We are using extends thread and implements runnable which class first calli

    hi

    Yes, the language allows it, but your JSL quote is the 3rd edition, and Java 1.4 is based on the 2nd edition (the 2nd edition of the JSL does not go into such a deep explanation of the example shown, so thanks for that pointer). In any case, since the JSL does not address my specific issue, it is only superficially relevant (IMHO). The language allows it, but the behavior is unpredictable. I think that's what is sticking in my craw. I'm not sure what the behavior should be, but if I had to, I would propose that the behavior should not change when I change the inheritance qualifiers (again, in this particular case), but there may be other considerations.
    HibernateUtil is a snippet that can be found in the Hibernate tutorial/reference at [http://www.hibernate.org/hib_docs/v3/reference/en/html/tutorial.html|http://www.hibernate.org/hib_docs/v3/reference/en/html/tutorial.html]
    The basic idea is a cached session factory, because session factories are expensive to build. We use multiple databases, so our incarnation of HibernateUtil compares the requested database to the one in a static factory variable. If they match, that factory is used. If they don't match, the thread switches to the requested factory and creates sessions from it.
    The odd thing is that with the aforementioned inheritance "typo", it either detects that the requested database is the same as the one in the static factory (which is not true), or it returns the wrong factory (which is wrong). I want to emphasize that no other code changes were made (zero, zip, none, really, I mean it), and lots of other classes extend C1 (from the example) and they have never had this problem.

  • How to use structure pointer with « Call Library Function node » in LabVIEW

    I use GetTimeZoneInformation from kernel32.dll. It definition is :
    DWORD GetTimeZoneInformation( LPTIME_ZONE_INFORMATION lpTimeZoneInformation );
    Where
    lpTimeZoneInformation
    [out] Pointer to a TIME_ZONE_INFORMATION structure to receive the current time-zone parameters.
    http://msdn.microsoft.com/library/default.asp?url=​/library/en-us/sysinfo/base/gettimezoneinformation​...
    I don't know how to set this parameter with my cluster based on the TIME_ZONE_INFORMATION structure.
    Your help will be appreciate
    Thanks
    INKSPEC

    INKSPEC wrote:
    I use GetTimeZoneInformation from kernel32.dll. It definition is :
    DWORD GetTimeZoneInformation( LPTIME_ZONE_INFORMATION lpTimeZoneInformation );
    Where
    lpTimeZoneInformation
    [out] Pointer to a TIME_ZONE_INFORMATION structure to receive the current time-zone parameters.
    http://msdn.microsoft.com/library/default.asp?url=​/library/en-us/sysinfo/base/gettimezoneinformation​...
    I don't know how to set this parameter with my cluster based on the TIME_ZONE_INFORMATION structure.
    Your help will be appreciate
    Thanks
    INKSPEC
    If creating a wrapper DLL which does the conversion for you is not an option (I think it won't since that would require C programming and if you knew C programming you wouldn't ask this here) then you will have to create a byte array of appropriate length and just configure the Call Library Node to pass this array as an Array of unsigned bytes and as C pointer.
    On return you will have to copy out the interesting data at the right position.
    First the length of this structure would be:
    typedef struct _TIME_ZONE_INFORMATION {
    LONG Bias; 4
    WCHAR StandardName[32]; 32 * 2
    SYSTEMTIME StandardDate; 8 * 2
    LONG StandardBias; 4
    WCHAR DaylightName[32]; 32 * 2
    SYSTEMTIME DaylightDate; 8 * 2
    LONG DaylightBias; 4
    } TIME_ZONE_INFORMATION
    Total 172 bytes
    Now the fun part will be to actually get out the information. There are a number of difficulties.
    First the strings are 16 bit Unicode so if you are interested in them you will have to call a different Windows API function WideCharToMultiByte function to convert the 16bit Unicode string into an ASCII string. For this part there has been a post here:
    http://forums.ni.com/ni/board/message?board.id=170​&message.id=123821&requireLogin=False
    For the LONG values you would pick 4 bytes at the appropriate offset from the array through the Array Subset function and then typecast it into an int32 and pass that through the Swap Bytes and Swap Words functions to reverse the LabVIEW Big Endian byte swapping in the Typecast function.
    The SYSTEMTIME is a structure with eight 2 byte integers so it would be best to use Array Subset again to extract 16 bytes at the correct offset, typecast this into a cluster with eight int16 numerics and pass it through Swap Bytes too.
    You see accessing such API functions in LabVIEW directly can get easily quite a mess and that is the reason why creating a wrapper DLL to convert properly between LabVIEW datatypes and C datatypes gets soon the easier solution if you need to interface with more than one or two functions taking such complicated data structures.
    Rolf Kalbermatter
    Rolf Kalbermatter
    CIT Engineering Netherlands
    a division of Test & Measurement Solutions

  • 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

  • Applicatio​n 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

  • 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

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

  • Executable created in LabVIEW 7.1 containing Call Library Function Node runs but creates error when Call Library Function Node is executed

    I have created a simplee application that controls a piece of equipment with all control via a supplied dll.  Hence, there are a number of Call Library Function Nodes within the code and a modicum of other LabVIEW code.  Everything works fine as a LabVIEW application, but when converted to an executable, although the application runs and functions, as soon as any Call Library Function Node is executed, calling from the dll, I get the C++ debug error in the attachment.
    Is this something that I can solve from within LabVIEW, or is the problem likely buried in the dll?
    Damian
    Attachments:
    CLFN error.JPG ‏22 KB

    Hi Wise,
    Try building an executable from a very simple VI that makes one call to the dll. Have you also try using the Call Library Function node on other simple dlls that you know will work?
    Regards,
    Stanley Hu
    National Instruments
    Applications Engineering
    http://www.ni.com/support

  • 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)

  • All EJBs with enable-call-by-reference=true

    How can I set 'enable-call-by-reference' to 'true' to all my my EJBs?
    I don't want to set this option for each one EJB.
    Thanks. Mauro.

    The Java EE specification requires that EJB components invoked through their remote
    interfaces must use pass-by-value semantics, meaning that method parameters are
    copied during the invocation. Changes made to a parameter in the bean method are
    not reflected in the caller's version of the object. Copying method parameters is required
    in the case of a true remote invocation, of course, because the parameters are serialized
    by the underlying RMI infrastructure before being provided to the bean method. Pass-by-value
    semantics are also required between components located in different enterprise applications in the
    same Java virtual machine due to classloader constraints.
    EJB components located in the same enterprise application archive (.ear) file are loaded by
    the same classloader and have the option of using pass-by-reference semantics for all invocations,
    eliminating the unnecessary copying of parameters passed during the invocation and improving
    performance. Set the <enable-call-by-reference>parameter to true in the weblogic-ejb-jar.xml
    descriptor file to enable this feature for each bean in your application. Local references always
    use pass-by-reference semantics and are unaffected by the <enable-call-by-reference> setting.
    The default value of <enable-call-by-reference> was true in WebLogic Server 7.0
    but is false in WebLogic Server 8.1 and later to comply with Sun's Java EE
    licensing policy changes that require all Java EE compatible servers to support the
    specification with their out-of-the-box configuration.

Maybe you are looking for

  • Using the same iTunes account, can two iPads use different phone nubers for Factime?

    Using the same iTunes account and two different iPads, is it possible to associate each iPad to a different phone number?

  • Async-Sync Bridge using RequestResponseBean & ResponseOneWayBean

    Hi All I have to expose a synchronous ABAP proxy server(CRM) to an MQ based Messaging System.  My intention was to avoid BPM and use the Adapter Framework modules of the JMS sender adapter and follow the pattern below: > RequestResponseBean > CallSap

  • Adding Mail receiver to an existing synchronous scenario

    Hi all, I have a synchronous scenario already running fine, it is File to RFC (Sych) scenario. Now the customer wants to receive the response as a mail. I am already receiving the response in a CSV file in a different location, which should also not

  • My home button on 5c keeps rotating

    Recently the home button on my iphone 5c has been rotating so the square is always squint. If I apply pressure I can turn it back round again but it always slides back the way. It works alright but it is really annoying and I'm just expecting it to s

  • Problem with Camera Raw update

    Downloaded Camera Raw 6.2 update.  When attempting to install it I get a message saying I need a new copy of Adobe Application Manager. I can't find such a download anywhere on the site. A search turns up nothing called "Application Manager". Is anyo