Invoke Node Method: Close FP (LV7)

LabVIEW Masters:
If an Invoke Node is used with the Close FP method, does any code remaining after the Invoke Node execute? Specifically, if you've invoked the Close FP Method (on the same top level VI that is calling the function) and then follow this function with the Close VI Reference function (for the same top level VI), does the Close VI Reference function ever execute? I'm aware that by closing the Front Panel the top level VI and all sub-routines are released from memory so is it necessary to call the Close VI Reference function as well?

Hi Steve,
Sorry no master, just Ben.
Interesting question. I put together the attached VI to see if I could answer this Q for myself.
The bottom line depends...
If you want your VI to play nice and be usable as a dynamic VI called from a bigger badder VI TestStand, etc. you should close the reference.
When you invoke the close FP method that closes the FP, Yes.
If that VI is the only VI in memory and you exit LV, then get cleaned-up in your behalf when LV exits. In this case it is not required to lose the reference, but,
"Flame suit on"
It is concidered bad style.
"flame suit off"
If you trying running the LV7 demo I posted and open another new VI, then look at the VI hiarchy screen you will see what I mean.
The demo I posted uses an event structure with a case structure in the timeout event case. This case lets you determine from a front panel boolean if the code executes an invoke node close FP. After the invoke node there is a seq structure that drives a boolean indicator to let you know the code following the invoke node does execute.
The example also lets you experiment with close the VI ref. If you run the example and allow all of the references to be closed, then a front panel close event will close the VI and un-load it from memory. Closing a VI ref can be thought of as being an official way of telling LV "I do not care about this VI any more, unload it no no else cares either". If you le tthe demo loop a couple of times opening ref to itself and then start shutting down the refs, you will see that VI will say in memory.
The example also shows that you can set up an event case that will fire on the close FP event giving you the ability to abort the operation programaticly. This demonstrates that the can run well beyond the close FP.
The demo also illustrates DR VI's rule "if the refnum changes, close it" by type casting the ref's as an array of I32's.
Summarizing:
IF this is a top level "quicky" VI you do not HAVE to close the reference. You can get away with just the invoke node close FP.
If you want to write re-usable code that will load and unload in a predictable manner, close the ref.
Sorry about the rambling, I hope this makes sense,
Ben
Ben Rayner
Certified LabVIEW Developer
www.DSAutomation.com
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction
Attachments:
Demo_close.vi ‏48 KB

Similar Messages

How to get a LabVIEW class object to expose an invoke-node method?

Hi,
      I like the property/invoke-node "paradigm" used for interacting with "objects". Can LabVIEW-class objects expose their properties and methods this way? Can one or more LabVIEW-class objects be compiled into a library or "assembly" (or other distrubution format) that allows the property/invoke-node usage?
I've looked at (but not completely understood) "Creating LabVIEW Classes". Have also searched for related posts.
The pic below shows an invoke node wired to a class with a Public VI "VAT.Status.Hello.vi". I'd like to see VAT.Status.Hello show-up as a Method. (I just tried "Select Method", and selected "VAT.Status.Hello.vi" but dialog's "OK" button stays greyed-out.)
Cheers.
Message Edited by tbd on 03-29-2007 03:15 PM
"Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)
Attachments:
VATStat.JPG ‏54 KB

Hi Aristos,
      Thanks for the reply!  It was a bit dissappointing, though.
It appears the LabVIEW-class object will be moving away from (what seems to me) a convenient object-interface presented by the invoke-node/method paradigm - which allows us to interface with a large set of "objects" (.NET, ActiveX, LabVIEW GUI, VISA Resource, ?) in a similar manner and independent of the object's origin. Being able to read the methods and parameters that appear in these nodes is also helpful for understanding diagram logic!
I do like the option of dropping a friendly "VI looking" icon on the diagram, but perhaps an optional - even default - VI-icon representation for a class-object invoke-node is feasible - so the LabVIEW class-object could be the more generic object first, but with a traditional-G representation(?)
Given the answer "We would like, someday, to support the property node"
and "in the next version of LV, wiring the LV class to the property/invoke nodes will break the wire so we'll avoid confusion in the future",
... I guess you'll break the wire in the next version, but (perhaps) allow it again - if support of the property node is ever implemented?
Regards.
P.S. For the record, huge THANKS to whoever it was that straightened-out enumerated-types (somewhere) between LV4.1 and LV6.1.  Every time I add or remove an enumeration in a typedef, I silently give thanks to the bright and thoughtful soul(s) who made this valuable tool work so well!
Hello. This is your friendly neighborhood R&D guy for LabVIEW classes.
Regarding your request about property and invoke nodes as relates to LV classes....
Short story: We would like, someday, to support the property node. We have no intention of ever supporting the invoke node.
Long story: As we were creating LV classes, we had to evaluate the right programming interface for these things. We wanted LV classes to behave as new data types in LV. A developer should be able to create a LV class, then give it to someone who doesn't even know OO programming, and that second programmer could use the new data type without learning a lot of new concepts. From this principle, we held fast to the idea that the programming interface should be subVI calls whereever possible. The invoke node is really nothing more than a VI minus the icon. If you want, you can popup on any subvi node and uncheck the option "View as Icon". This will make the node display in a way that has the terminals listed as text, like the invoke node. So, at the end of the day, the invoke node is simply a subroutine call in LV that is language dependent, as opposed to the language independent iconography of LV generally.
The property node is a slightly different story -- the functionality of a property node is actually different than an invoke node as its terminals are various subsets of the properties available, not a fixed list of parameters like the invoke node. The property node provides a nice interface for setting multiple properties in a block and only having to check a single error return. Very friendly. Our intent is to allow you to create a VI that has 5 terminals: object in, object out, error in, error out, and either a single input or a single output of your chosen type. VIs with this conpane could be marked as "properties" of the class and would show up when you wire the class wire to the property node. We would call the subVIs behind the scenes as needed to get/set the properties.
This is on the longer term roadmap because it is "syntactic sugar" -- it sweetens the programming style, but it is not necessary to program effectively. You can get the same effect by writing those same VIs and stringing them along on a block diagram "railroad track" style. We'll probably get around to it in three or four versions of LV -- there are some major user requests that impact functionality that have to get done first.
PS -- in the next version of LV, wiring the LV class to the property/invoke nodes will break the wire so we'll avoid confusion in the future of people thinking there's a way to use these nodes.
Message Edited by Aristos Queue on 04-02-2007 09:56 AM
Message Edited by tbd on 04-03-2007 12:39 PM
"Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)

Does "Run VI" invoke node work on strict references to REENTRANT VIs?

I am using LV 6.02 on Windows 2000.
I am trying to use the "Run VI" invoke node method with a reference to a Reentrant VI, with no success. (It works when VI is not reentrant. Perhaps there is a reason this cannot work. But if not, I wonder if there is a workaround, or if LabVIEW 6.1 has a fix?
Hopefully the picture of the block diagram I included is sufficient...but I also included the actual code just in case.
Thanks!
Steve
Attachments:
block_diagram.jpg ‏66 KB
Parent_VI_Example.vi ‏43 KB
Prototype_subVI_shell_for_Simplex_Fit.vi ‏40 KB

Hi, Labviewguru,
Thanks for taking the time to look at my admittedly messy (flawed) block diagram. I will try to state my ultimate goal:
You may be familiar with Levinberg-Marquardt nonlinear curve fit in Labview, which is about 5 VIs in a LLB file. In order to change the type of curve fitting, one has to either modify a formula node in the lowest subVI (Target Func and Deriv), or place a different subVI in there. That's fine until I want to have many different sorts of algorithms.
What I was thinking of doing is instead passing Target Func and Deriv a reference to the VI which would perform the calculations. This would allow me to use the same fitting code to fit different types of data with substantially different methods--without modifyin
g the low-level fitting code at all.
I'm not sure this is going to make any sense to you, but thanks again for your help.
In regards to your answer above, let me clarify somewhat. I had the call by reference node in there to prove that the reference to the VI was "good" and worked fine...this same reference was passed to the invoke node, which didn't have any apparent effect.
Also, I don't think the path to the VI I am opening the reference to is redundant. It is required to tell the "Open VI reference" which VI to load.
I agree that using references to pass values around is not generally a good idea: I was using that method for my supposed versatility in the future.
Thanks,
Steve

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

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

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

ActiveX Object Creation method to pass to an Invoke Node

Hi!
I'm trying to optimize the way in which I use MathCAD from LabVIEW. One of my VIs is having really poor performance in terms of execution speed and memory usage.
My VI converts a 2D LabVIEW array of doubles into a 2d Mathcad matrix and puts that matrix into a Mathcad worksheet. The issue is that you do not just pass the 2d array of doubles into the SetValue invoke node as a variant. You have to create a Mathcad.MatrixValue object, and then pass the object to the SetValue invoke node.
Here is the example code provided in the Mathcad developers manual:
SetElement Method
var m = CreateObject("Mathcad.MatrixValue");
for(row = 49; row >=
0; --row)
for(col = 9; col >= 0;
--col)
var val = row + col;
m.SetElement(row, col, val);
Here is my implimentation in LabVIEW:
Here is my SubVI
Here is my main VI:
My SubVI is running out of memory and throwing the following error:
Exception occured in mplrun: Exception of type 'System.OutOfMemoryException' was thrown. in NL SubVIs Library.lvlib:Convert LabVIEW 2d Array to MathCAD Variant Matrix (SubVI).vi->test.vi
It doesn't always throw the error. When I watch the memory consumption of LabVIEW it goes up to about 250k and then drops to 90k and slowly builds back up to 250k. Initialy starting the code takes awhile too on my computer. From start of VI until first loop iteration it is about 20 seconds, and then about 150-250ms after that. Not very good performance.
Any advice on how to optimize this code would be appreciated. I'm not really sure when I should close some of these references. I tried closing the reference in my converting SubVI, but I guess that destroys it so MathCAD can't use it.
I'm in LabVIEW 2009. Any help is appreciated.
Thanks for your time and input!
-Nic

I'm not sure this will solve your problems but it should help. You need to close ALL of your references to Mathcad objects when you're done using them. That means you need to close the reference to the Mathcad MatrixValue after you pass it to Mathcad (to do this you'll need to convert it back from a variant, or pass the reference directly out of your subVI), and you should also close the reference to the matrix that you get back after you've converted it to a LabVIEW array. Otherwise you'll continuously allocate more and more memory rather than allowing it to be reused.
Less importantly, you should also close your references to IMathcadWorksheets and IMathcadWorksheet (but since you only open them once it's not causing your memory problems).

Method Not Found Invoke Node error 1316 using Solid Works IEdm

Hi Forum members,
I have been having a problem with calling a function in a dll file. I have attached the VI as example. When I use the GetFile method I get a reference to that. I then use the Invoke node and recieve a list of methods, the first of which is ChangeState. I select this method and wire all required inputs and when I run the program I receive the error at that invoke node that the method does not exist. How is this possible? I have tried various methods to ensure the inputs are all correct and none have worked. I do not believe the fault lies in the inputs, but I cannot for the life of me find the problem... Perhaps someone has experience using Solid Works in Labview? Any help would be appreciated.!!
Cheers
Ben
Attachments:
SetFileSatus.vi ‏18 KB

I have determined that there is a problem with the Invoke node not recognising the function. This is a Labview problem as the function is listed and selectable, so when the error comes saying the function is not found, this is a problem with Labview and not the dll. The Function when selected also has the right input parameters that automatically appear. How is it then that the method is not found when the program is run?

Invoke a method when Close Window is clicked

Hi,
How do i invoke a method when "close window" on the global button bar is clicked.
Can someone please help.
Thanks in advance.
Pavan
Edited by: user12215240 on Feb 23, 2010 9:32 AM

Is it possible to change the settings so that when the red 'close' button is clicked, the application will hide instead of closing?
Applications don't "close," windows do. If you are just closing windows but not quitting applications that opened them, it is no wonder that there are hundreds of apps in the Dock.
A few apps like System Preferences have only one window, so they automatically quit when you close that one window. Most apps do not do this: even after all their windows are closed, they remain running & thus show up in the Dock, in Activity Monitor, & so on. They each require a little (or sometimes more than a little) real memory reserved for their use to remain running -- this subtracts from what is available to do useful tasks, & will slow down your Mac when it results in too much virtual memory use.
Thus, it is a good idea to quit applications you don't have an immediate need for, especially if they don't require long startup times. If you want easy access to select applications, create a folder & fill it with aliases to those apps, then drag that folder to the right side of the Dock, where it will create a stack. When opened, the stack will allow one click launching of those apps.

Invoke Node and clipboard methods

I have encountered a very useful vi that allows me to obtain an image from the clipboard by using an invoke node with the clipboard.get image method. As I was experimenting with this, I attempted to place an invoke node and selecting the clipboard.get image method. Clicking the invoke node gives me three methods: empty (after enabling scripting), read from clipboard and write to clipboard. I could not find get image anywhere. How do I select this method on a newly placed invoke node?
Part 2: Given that this method seems to be hidden from me, how can I learn about other "hidden" methods?
- les

The block diagram is simply an Invoke node with the Clipboard.Get Image method. All inputs and outputs are routed to the front panel and connector pane, so you are not missing any functionality.
Since it is a private function, I can not release it without locking the block diagram. Private functions are just that, functions that are not exposed to our customers, usually due to insufficient development time or testing. I have crashed LabVIEW, corrupted my LabVIEW installation, and corrupted a huge hierarchy of VIs using private functions, so they must be approached with extreme caution, even internally. This particular function has been certified safe, so I was able to release an encapsulated version of it. However, you will not be able to find it in the development environment until it is officially released.
This account is no longer active. Contact ShadesOfGray for current posts and information.

Invoke node: invalid method error

hi, can someone help me explain what i did wrong or help me try to solve these errors..
i am trying to work on an example problem and i dont see where i did wrong..
thanks in advance
labview 7.0
Message Edited by krispiekream on 03-14-2008 12:11 PM
Message Edited by krispiekream on 03-14-2008 12:15 PM
Best regards,
Krispiekream
Attachments:
doing wrong.PNG ‏51 KB
cont_mult_vis_rem_pan.zip ‏155 KB

I'm a little confused, because I'm pretty sure you can't insert a VI into a tab control.
I think that's the source of your error, but I have no idea how you got those invoke nodes to appear on the block diagram.
edit - I see what you did. When you changed the example, you deleted the subpanels that were originally on each Tab page. You have to insert the VI into a subpanel which is displayed on a tab page. (Subpanels are on the Control Palette under Containers)
Message Edited by JeffOverton on 03-14-2008 01:23 PM
=============
XP SP2, LV 8.2
CLAD
Attachments:
subpanel.PNG ‏18 KB

"Error 7 occurred at Invoke Node..." when attempting to open .vi for editing

I am attempting to open a vi for editing, and instead the vi is attempting to execute. I get the error:
"Error 7 occurred at Invoke Node in BuildTargetBuildSpecification.vi->BuildXFS.vi"
Possible reason(s): LabVIEW: File not found. The file might have been moved or deleted, or the file path might be incorrectly formatted for the operating system. For example, use \ as path separators on Windows, : on Mac OS, and / on Linux. Verify that the path is correct using the command prompt or file explorer.
Method Name: Project: Open
When I close the Error Message dialog, Labview terminates.

Hi R.Jay,
Error 7 generally occurs when trying to create an executable when there is an extra instance of a top-level vi. You may need to remove the file as a support file (but leave it as the top level vi).
Are you trying to run an executable that has already been created? Unless you have already built an executable, it should not automatically run when opened. Also, was it built in a previous version of LabVIEW? Sometimes this error can be seen when you upgrade to a newer version without compiling.
Regards,
Lauren
Applications Engineering
National Instruments

Linux AppBldr Error 7 Invoke Node

* LabVIEW 6.02 FDS Linux S/N G12X17332
* AppBldr 6 Linux S/N J12X64523
My SSP subscription on this software has expired.
The products were installed on Linux Mandrake 8.2 using the provided National Instruments RPM method. A query of the rpm database shows that the following
versions are installed:
labview-help-6i-1
labview-examples-6i-1
labview-ref-6i-1
labview-desktop-6i-1
labview-rte-6.0.2-1
labview-pro-update-6.0.2-1
labview-app-6i-1
labview-vxi-6i-1
labview-update-6.0.2-1
nivisa-2.5-1
If I attempt to build an application from a workable VI (that resided on the local disk and not in memory), the build process proceeds until a dialog box is
displayed, stating "Error 7 occurred at Invoke Node in Dist Build
App from LLB.vi->Dist Build App Image.vi->Application.vi"
I have looked into the NI Knowlege Base and I see the notes about not using forward slash in VI names, and I have complied with this naming restriction.
Do you have any suggestions??
Thank You,
Jerome Whelan

Jerome,
I strongly suggest that you submit a support request to NI at ni.com/ask. But first, try the following.
The error you are receiving is a missing file. The source could be your build. I have received error 7 on many occasions building an app (on Windows) because I had the source code open. Be sure that you first open all of your code, and do a "Save All". Then, close all code, and close LabVIEW. This will ensure that all VIs are out of memory. Then, open the app builder anew, and try building your application.
If you still have the problem, try doing a test build of a simple "Hello world" type of VI that has no subVI calls. Follow the procedure above to dump the memory, and build it. If you still have the error, then the problem is with
the Application Builder, at which point, you will want to contact NI.

Invoke Node causes error in VI

The attached VI is one of numerous VIs in an application that I "inherited". I am attempting to rebuild the application to incorporate some changes I have made. This VI has an error, which indicates that there is a bad or unwired terminal at the Invoke Node for the PrintOut method. According to the Help system, all of the unwired parameters for this node are optional, so the node appears to be wired correctly. What am I missing? Thanks.

Hello,
Thanks for attaching the VI. I believe the preview -> lost attachment issue has already been reported to the admins for this discussion forum.
As for your VI, I'm guessing this problem is happening because you are running a different version of Office than the computer on which this application was originally developed. On the PrintOut invoke node, try selecting another method in the method list. Then try selecting "PrintOut" again. This should re-link the method to the "PrintOut" method specific to the Word version on your computer, and you should be fine. By the way, the VI opens just fine (no broken run arrow) on my machine, and I'm running Office XP.
Let me know if this solves the problem. Oh yeah, here's a tip. I noticed that in this code, there is a Boolean constant wired to the "Close" method, but it's wired into a "To Variant" function to convert it to a variant. This explicit conversion is not necessary...for any ActiveX property or invoke node that takes variant inputs, you can just wire the native LabVIEW type directly into the input (without an explicit conversion) and it will work fine...this should save you some time as you write new VIs, or edit this set of VIs you inherited.
Good luck,
-D
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

VI Server - Property Node (Execution: Close After Call)

I would like to dynamically call and run a VI and
have its front panel close after it is called.
The method I tried was:
1) Open VI Reference to the VI.
2) Set Front Panel.Open and Exec.CloseFPAfterCall
Properties to True.
3) Use Invoke Node (Run VI with Wait Until Done =
True)
4) Close VI Reference.
No matter what I do I can't get the Called VI's
front panel to close after the user quits or
exits the VI. What am I doing wrong?
My only thought is that the Exec.CloseFPAfterCall
Property only works on Called VI's that return a
value.
Also I'd like to avoid using VI server from
within the Called VI's diagram because I have a
lot of individual VI's that I would like to call.
Thanks,
Brian
Sent vi
a Deja.com http://www.deja.com/
Before you buy.

I would like to dynamically call and run a VI and
have its front panel close after it is called.
The method I tried was:
1) Open VI Reference to the VI.
2) Set Front Panel.Open and Exec.CloseFPAfterCall
Properties to True.
3) Use Invoke Node (Run VI with Wait Until Done =
True)
4) Close VI Reference.
No matter what I do I can't get the Called VI's
front panel to close after the user quits or
exits the VI. What am I doing wrong?
My only thought is that the Exec.CloseFPAfterCall
Property only works on Called VI's that return a
value.
Also I'd like to avoid using VI server from
within the Called VI's diagram because I have a
lot of individual VI's that I would like to call.
Thanks,
Brian
Sent vi
a Deja.com http://www.deja.com/
Before you buy.

Is it better to use Invoke nodes or property nodes to set/get control values?

I have a series of VI's that run in parallel, each to manage different functions- pumping, sensing, a fluid flow model, an experiment generator/runner.
These need to exchange data, which I am currently doing using invoke nodes (that are all in subVIs), using methods "Set control value" and "Get control value". I find that every now and then (perhaps 1% of the time) the data isn't exchanged correctly and therefore the system doesn't work. I can imagine how "set" could go wrong if they happen simultaneously, and can devise ways of preventing this. However, the "Get" method suffers from the same problem. This is a major problem, because I want to leave it running for several hours.
I could in
principle achieve the same thing using property nodes and find myself wondering if this might be more reliable. But I don't want to change over only to find it makes no difference!
Can anyone advise?

You can use some kind of syncronization such as queues, occurances, or notifiers but I think the easiest way would be to create and action engine. This was only one action can execute at a time avoiding a "race condition". Possibly a write action and a read action might help. You also can add queues or notifiers into this concept. hope this helps.
BJD1613
Lead Test Tools Development Engineer
Philips Respironics
Certified LV Architect / Instructor

Excel ActiveX invoke nodes are broken

I am using LabVIEW 2007. We are using a VI that runs on most of the PC's in our facility however on some the "invoke node" related to Excel functions don't operate. They are broken and the VIs won't run. We get errors that the "Invoke Node: contains unwired ro bad terminals". When going to select methods or properties not all of the properties are shown as seen on the functional PCs. Some of the properties are missing from the selection menus, thus making it incompatible.
Has anyone seen this problem and a solution?
Thanks
Manliff,

What about separating the compiled code from the source? I recognize that this will only work in LV2010, but I expect that that will prevent the compiler from breaking activeX code that depends on a different version than the local one...
Testing this idea is on my to-do-list, but I was wondering if anyone has tried it already.
-Barrett
CLD

Invoke Node Method: Close FP (LV7)

Similar Messages

Maybe you are looking for