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

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 .

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.

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

LabVIEW 7 and NI Switch and DMM function, Won't compile

After installing labview 7, I get broken arrow for PXI Ni Swich. Error occurs in NiSwitch Initialize.vi when initialzing Switch. The error message indicates: "Call Library Function Node: Function not found in library"

Thanks for you input. I did installation in the sequence you mentioned but it didn't help. With a help of apps at NI and being on the phone for soooo long, he found out that two dll files called ivi_Switch.dll and ivi_switch_32.dll were listed in VXIPNP\WINNT\bin folder as well as C:\programfiles\ivi\bin. By removing those dll from VXIPNP folder fixed the problem.
Bottom line is - leave the dll fils in C:\programfiles\ivi\bin as it is!

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

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.

How to implement a callback function using LabView's Call Library Function Node?

I am trying to call a fuction from a SDK.dll library using the Call Library Function Node. The SDK was provided to
me and I do not have the source code, just the .dll and .h files.
The SdkSetPropertyEventHandler function has a callback fuction as one of its parameters. How do I implement the
callback using the CLF node? I am a good LabView programmer but this is my first time using the Call Library
Function Node. I have read all the info I can find on NI's web site and the discussion board but cannot figure
this one out. I am using LabView 8.6.
The SDK.h deacribes the function as:
// Function:   SdkSetPropertyEventHandler
SdkError SDKAPI SdkSetPropertyEventHandler(
            SdkCameraRef                    inCameraRef,
            SdkPropertyEvent                inEvnet,
            SdkPropertyEventHandler         inPropertyEventHandler,
            SdkVoid*                        inContext );
// Description:
//       Registers a callback function for receiving status
//          change notification events for property states on a camera.
// Parameters:
//       In:    inCameraRef - Designate the camera object.
//              inEvent - Designate one or all events to be supplemented.
//              inPropertyEventHandler - Designate the pointer to the callback
//                      function for receiving property-related camera events.
//              inContext - Designate application information to be passed by
//                      means of the callback function. Any data needed for
//                      your application can be passed.
//      Out:    None
// Returns:    Any of the sdk errors.
A separate header file called SDKTypes.h contains the following data:
typedef SdkUInt32 SdkPropertyEvent;
typedef SdkUInt32 SdkPropertyID;
typedef void       SdkVoid;
typedef struct __SdkObject*    SdkBaseRef;
typedef SdkBaseRef    SdkCameraRef;
SdkPropertyEventHandler
typedef SdkError ( SDKCALLBACK *SdkPropertyEventHandler )(
                    SdkPropertyEvent        inEvent,
                    SdkPropertyID           inPropertyID,
                    SdkUInt32               inParam,
                    SdkVoid *               inContext );
Thanks for your help.
Alejandro
Solved!
Go to Solution.

alejandroandreatta wrote:
I am trying to call a fuction from a SDK.dll library using the Call Library Function Node. The SDK was provided to
me and I do not have the source code, just the .dll and .h files.
The SdkSetPropertyEventHandler function has a callback fuction as one of its parameters. How do I implement the
callback using the CLF node? I am a good LabView programmer but this is my first time using the Call Library
Function Node. I have read all the info I can find on NI's web site and the discussion board but cannot figure
this one out. I am using LabView 8.6.
Basically you do not do that. LabVIEW does not know pointers and certainly not function pointers. What you should do instead is writing a C DLL that implements the callback and also exports a function to be called by LabVIEW that translates between the callback and a LabVIEW user event. Look for PostLVUserEvent() here on the NI site to find examples how to do that.
Rolf Kalbermatter
Message Edited by rolfk on 02-11-2009 08:00 PM
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

LabVIEW PDA reports COREDLL.DLL error when using Call Library Function Node

I'm trying to build a LV PDA app that calls an external DLL file built using embedded visual C. When configuring the Call Library Function node I select the stub DLL, configure the I/O parameters and select OK. When the configuration dialog closes I get the following error:
LabVIEW: LabVIEW.exe - Unable to Locate Component
This application has failed to start because COREDLL.DLL was not found. Re-installing the application may fix this problem.
I do not get this error when using the configuration dialog in the example VIs.
Any suggestions as to the cause and/or the solution?
Thanks,
Ryan

Hello -
When you create a PDA VI that calls a DLL, you must include the .c or .lib file that corresponds to the DLL. Take a look at these documents:
LabVIEW PDA Module Build Errors with VIs that Call DLLs
Why Do I Receive Errors When Calling a C++ DLL from a Call Library Node Using the LabVIEW PDA Module...
How To Call External Code in LabVIEW PDA for Palm OS
H
ow To Call External Code in LabVIEW PDA for Pocket PC
Hope this helps!
S Vences
Applications Engineer
National Instruments

Is a call library function node in LabView 8.6 synchronous or asynchronous?

I tried setting a sub-VI with a call library function node in it to "subroutine" execution status. The error list indicated that the Call Library Function node in the block diagram was an asynchronous node. The LabView on-line help content indicates
"...CINs and shared libraries execute synchronously, so LabVIEW cannot use the execution thread used by these objects for any other tasks. "
Does anyone know for sure what the status of a Call Library Function is? Does it depend upon the specific code in the DLL being called?
Thanks,
Mike H.

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

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

Similar Messages

Maybe you are looking for