Invoke node unfonctionnal after compiling

Hello,
I'm currently trying to use an invoke node (I'm not using an english LabVIEW so I don't know if the words are exactly the same translated) : Obtain VI / Editor Version
When I'm using it in my .VI my project work perfectly, but when I'm trying to test the program with the .exe It doesn't work when I want to get old VIs version.
Are there some dependencies issues ?
Thanks for your help !
BR,
Mathieu

Hey Don_Philips !
Thanks for your answer,
I'm not using a Current VI's Path :
Here is my -short- program, I'm using an invoke node to get text from the clipboard and use is as a path
Attachments:
path from clipboard.png ‏4 KB

Similar Messages

Build error after upgrading from 8.2.1 to 8.5 "Error 1055 occurred at Invoke Node..."

After upgrading to 8.5, I'm getting the following error when trying to build an EXE:
Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference:
Error 1055 occurred at Invoke Node in AB_Source_Library.lvclass:Close_Reference.vi->AB_Build.lvclass:Copy_Files.vi->AB_Application.lvclass:Copy_Files.vi->AB_Build.lvclass:Build.vi->AB_EXE.lvclass:Build.vi->AB_Engine_Build.vi->AB_Build_Invoke.vi->AB_Build_Invoke.vi.ProxyCaller
Possible reason(s):
LabVIEW: Object reference is invalid.
I have been building this application for both Windows and Mac OS, and I even get the same error when building the .app on an Intel Mac.
Things that I've already tried:
* Mass-compiling all my code
* Created the project from scratch
* Enabled each panel of the "diagram disable structure" one at a time and compiled again
Any ideas?

Hi Travis,
Ben’s advice if definitely the best place to start. Error 1055 is a very general LabVIEW error for “Object reference is invalid.” The cause is usually a bad install where important LabVIEW function aren’t placed in the right directory or aren’t installed at all.
Charlie M. CLD

[svn:fx-trunk] 10459: Change to ensure ScriptNodes are no longer part of the node tree after interface compilation stage in order to avoid the extra code that was necessary to avoid tripping over them during type checking , etc.

Revision: 10459
Author:   [email protected]
Date:     2009-09-21 08:42:44 -0700 (Mon, 21 Sep 2009)
Log Message:
Change to ensure ScriptNodes are no longer part of the node tree after interface compilation stage in order to avoid the extra code that was necessary to avoid tripping over them during type checking, etc.
Improving revision 10199 a bit, to allow for single line comments.
QE notes: None
Doc notes: None
Bugs: SDK-22027
Reviewer: Paul
Tests run: Checking, Compiler cyclones
Is noteworthy for integration: No
Ticket Links:
    http://bugs.adobe.com/jira/browse/SDK-22027
Modified Paths:
    flex/sdk/trunk/modules/compiler/src/java/flex2/compiler/as3/AbstractSyntaxTreeUtil.java
    flex/sdk/trunk/modules/compiler/src/java/flex2/compiler/mxml/InterfaceCompiler.java
    flex/sdk/trunk/modules/compiler/src/java/flex2/compiler/mxml/builder/AbstractBuilder.java
    flex/sdk/trunk/modules/compiler/src/java/flex2/compiler/mxml/builder/DocumentBuilder.java

In general theory, one now has the Edit button for their posts, until someone/anyone Replies to it. I've had Edit available for weeks, as opposed to the old forum's ~ 30 mins.
That, however, is in theory. I've posted, and immediately seen something that needed editing, only to find NO Replies, yet the Edit button is no longer available, only seconds later. Still, in that same thread, I'd have the Edit button from older posts, to which there had also been no Replies even after several days/weeks. Found one that had to be over a month old, and Edit was still there.
Do not know the why/how of this behavior. At first, I thought that maybe there WAS a Reply, that "ate" my Edit button, but had not Refreshed on my screen. Refresh still showed no Replies, just no Edit either. In those cases, I just Reply and mention the [Edit].
Also, it seems that the buttons get very scrambled at times, and Refresh does not always clear that up. I end up clicking where I "think" the right button should be and hope for the best. Seems that when the buttons do bunch up they can appear at random around the page, often three atop one another, and maybe one way the heck out in left-field.
While I'm on a role, it would be nice to be able to switch between Flattened and Threaded Views on the fly. Each has a use, and having to go to Options and then come back down to the thread is a very slow process. Jive is probably incapable of this, but I can dream.
Hunt

I am using the NI application note "Calling IVI-COM drivers from LabVIEW" I created an Automation Open and an Invoke Node, after wiring

the 2, the AN asked to right click the Invoke Node(this is step9) and choose initialize. However there is no intialize option on the pop up menu. Anything am I doing wrong? I am using Labview6 and I did add the "enableCustomInterface=True" in the INI-fileThank you for your help.
T Tall

the 2, the AN asked to right click the Invoke Node(this is step9) and choose initialize. However there is no intialize option on the pop up menu. Anything am I doing wrong? I am using Labview6 and I did add the "enableCustomInterface=True" in the INI-fileT Tall,
What's the number of the application note "Calling IVI-COM drivers from LabVIEW"? I'm unable to find what you're looking at.
Thanks,
--Bankim

Error 8 occurred at Invoke Node in AB_EXE.lvclass:Build.vi- AB_Build.lvclass:Bui

During software build to make exe file, I got the following error message:
Error 8 occurred at Invoke Node in AB_EXE.lvclass:Build.vi->AB_Build.lvclass:Build_from_Wizard.vi->AB_UI_FRAMEWORK.vi->AB_Item_OnDoProperties.vi->AB_Item_OnDoProperties.vi.ProxyCaller
Possible reason(s):
LabVIEW: File permission error. You do not have the correct permissions for the file.
=========================
NI-488: DMA hardware error detected.
Method Name: Build:Application
The vi was working fine before the build. It just access some text files and creates some excel files. No hardware is involved. See if anybody know how to solve this problem. Thanks.

I am using LabVIEW 2014 and have been getting this error randomly, but fairly consistently on a recent build. I searched all over and could not find a solution that worked. However, just through trial and error I discovered that the problem is related to SSE2 Optimization in the Advanced properties window. I can consistently cause this error by enabling this feature and consistently compile successfully when it is disabled. Try turning this feature off and see if it solves the problem.
...UPDATE: After closing and re-opening LabVIEW this error came back, and did not seem to be affected by the SSE2 option. Not that it isn't related, but perhaps not the silver bullet I thought it was.
I also got the error to go away sometimes when I compiled the EXE while the main program VI was open, whereas it gave the error most of the time when no VIs were open...again, nothing seems to consistently solve the problem...there is definitely some kind of bug in the appllication builder, and it seems like there are a lot of people that have been struggling with this for a long time (as far back as LV 8)...hopefully NI eventually finds this bug and squashes it!..although, I doubt that anybody at NI is even looking for it...

Error 6 occurred at invoke node in dist build app

Error 6 occurred at Invoke Node in Dist Build App from LLB.vi->Dist Build App Image.vi->Build Application.vi
Possible reasons:
LabView: Generic file I/O error
or
NI-488: I/O operation aborted
Version 6.0.2

I noticed that you updated your system to 6.0.2. A couple things to check on that may remedy the problem.
1)Did you install the application builder after upgrading your system to 6.0.2? You will want to install the application builder 6.0 first, and then add the 6.0.2 update to the whole system.
2)Have you mass compiled all of your VIs since the upgrade? You will want to make sure that all of your VIs are in 6.0.2 format before trying to build them into an executable.
Matt Kisler
Applications Engineer
National Instruments

"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

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

Strange behaviour with ActiveX invoke node and Excel

I want to send a table of numbers from LV50.1f to Excel97. After getting a
reg to Excel8.Application I retrieve the Workbooks property, Invoke Item to
select a certain Workbook reference, retrieve the Worksheets collection
reference, Invoke Item and then get a reference to WORKBOOKS again.
Strangely, there is an example code from the NI web site that does exactly
the same, but in the last step a variant is returned in stead of a
reference, which is converted using Variant to G to a Worksheet reference.
when I copied that last invoke node to my VI I also had a variant returned,
so on one diagram I had to invoke nodes connected to the same sources, one
returning a ref, the other returning a variant!
Disco
nnecting the sources to my Invoke node and rewiring gave no change.
Also type casting the ref to workbooks to a worksheets ref, didn't work - I
get errors in the following property node that retrieves a Range - which
exists in Worksheet, but not in Workbooks.
Appearantly, LV gets the returned type mixed up sometimes, and there is no
way to fix it other then copying a invoke node from another diagram?
Finally I got it working though, but this behaviour puzzles me. Contrary to
the example from NI, I now managed to send a table (2d array of strings) in
one call to Excel (don;t need to loop over cells or columns).
PS
I used to do the same using DDE but ranges are different for each language
version of Excel (i.e. R1C1 for English and R1K1 for Dutch), so my VI's need
to know the language of Excel. Also with NT and Win98, getting a DDE
connection often hangs LV. But a big progress has been made - now I need
different VI's for each version of Excel!!!
Ferry Toth
Enraf BV, The Netherlan
ds

Hi Enric,
Can you try your queries again using the new release of DB XML? It contains some improvements in this area.
http://www.oracle.com/technology/software/products/berkeley-db/xml/index.html
John

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

Error 7 occurred at Invoke Node in AB_EXE.lvclass

I get the "Error 7 occurred at Invoke Node in AB_EXE.lvclass" error when trying to build an executable in Labview 8.5.1. I can run the application without any errors but when I try to build the executable, I get the error. I have tried a mass compile of the project, tried ctrl + shift + run on the top level vi, and tried to mass compile the folder where the project is located and nothing seems to help. I have also looked at the project dependencies for conflicts and found none. I have made a new project and tried to build an executable from this same code without any luck. How can I get this to build an executable?
The exact error is:
Error 7 occurred at Invoke Node in AB_EXE.lvclass:Build.vi->AB_Engine_Build.vi->AB_Build_Invoke.vi->AB_Build_Invoke.vi.ProxyCaller
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.
=========================
NI-488: Nonexistent GPIB interface.
Method Name: Build:Application

Are you using the Report Generation Toolkit? A lot of error 7's during builds seem to be related to this toolkit. Any dynamically called VI's?
Take a look here and here.
Also search the forums for "error 7" and you'll find some other threads related to error 7 and the application builder.

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)

LabVIEW Application throws Error in Run VI Invoke node

Hi All,
We are facing an issue with an application developed from LabVIEW 2010SP1.
Application Description:
In our application, there is a top level VI which tries to run VIs dynamically[using Run VI invoke node] from a particular folder. This folder is like a plugin - not part of Exe. This implies when the top level VI is launched, the plugin VIs under particular folder will not be in memory. When we try to run a VI dynamically from the top level VI, the VI execution works perfectly in LabVIEW development mode.
Problem Faced:
When we created an EXE, it worked well in my PC [LabVIEW is installed]. We created an installer and tested in few other PCs.
[Non LabVIEW PCs – Win XP and 7]. In few PCs it throws the following error, when the plugin VI is run dynamically.
Error 1003 occurred at Invoke Node
Possible reason(s):
LabVIEW: The VI is not executable. Most likely the VI is broken or one of its subVIs cannot be located. Select File>>Open to open the VI and then verify that you are able to run it.
Method Name: Run VI
We tried the following possible ways to find the reason for the issue:
1. Installed LabVIEW - Issue got fixed.
2. Installed .net 2.0 without installing LabVIEW - Issue got fixed.
3. But in one of the Windows 7 [Non - LabVIEW PC] in which .net was already installed, we faced the same error.
Only after installing LabVIEW the error got fixed.
4. When .net 2.0 is uninstalled the EXE itself is broken.
We are not sure what is the Exact reason fo the issue. Anyone faced these kind of issues? Please share the solution. Thanks in advance.
Note:
1. The VIs which are dynamically called is a plugin and not a part of EXE.
2. These plugin VIs have no dependencies from vi library and is completely isolated.
3. We are not using any .net related objects in any of the VIs.
4. The plugin VIs use Call library function node in which a C DLL developed from Microsoft Visual Studio 2010 is used.
Thanks,
Meena
Solved!
Go to Solution.

Error 1003: This clearly indicates that the 'Dynamic VI' is broken and now you should check for the various reasons, why the 'Dynamic VI' is broken.
Also path of 'Dynamic VI' is not a problem.
One thing that you may try is:
-> First open just the 'Dynamic VI' in a new LabVIEW project and check for the 'Dependencies'.
-> Now if any of the item in 'Dependencies', other than what is listed in vi.lib (lets call it 'Dependency.VI'), is also a part of your 'Main Exe', then its a problem. Because when you will execute the 'Main Exe', say in a new computer other than your development computer, it will load all its dependencies including 'Dependency.VI' (and the path will be within the 'Main Exe', but when it will try to (dynamically) load the 'Dynamic VI', this VI will also try to load the same 'Dependency.VI' but from different path and that will cause a conflict. I had experienced this.
-> If thats the issue, you may want to rename (add suffix/prefix) to all dependencies of your 'Dynamic VI' which is common to the 'Main Exe'.
Hope this solves your issue.
I am not allergic to Kudos, in fact I love Kudos.
Make your LabVIEW experience more CONVENIENT.

Error when executing VI with "Invoke Node" in loop

Hello,
please check if this is possible what i am doing here or if there is a better way to do it.
The goal is to have a VI that i can start in TestStand which is then running in a loop until i set a global variable.
I do this currently with:
1.) Starting the VI with "Invoke Node" (see screenshot 01)
2.) This Vi is then running all the time in a loop until the global for exiting is True (screenshot 02)
3.) Then i have another VO to set the Quit-variable to true
Normally this works as it should, but sometimes i get the error-message:
Invoke Node in NameOfTheViCalledInTestStand.vi
Method Name: Run VI
VI Path: NameOfTheViThatContainsTheInvokeNode.vi
LabVIEW: Das VI befindet sich in einem für diese Operation unzulässigen Zustand.
The question is: what does this error mean and what better ways are there to do what i want to.
Perhaps for better understanding, the VI which runs in a loop executes dll-functions to enable and disable an ample-tower to make a light blinking.
And because there is no function "blink", i have to make it on off on off on off....
So the vi loops and makes on off until i say "quit" then blinking stops.
Thanks for any ideas
Attachments:
01_InvokeNode.jpg ‏8 KB
02_ViRunsInLoop.jpg ‏23 KB

I cant´t do this "Try changing the "Run" node
to "Wait Until Done" = True." because then the TestStand-Step is
hanging until the loop is finished.
I only want to start the "blinking" and the continue normally in the sequence.
To
avoid that the vi with the "Invoke Node" is started twice a have a vi
above it whick checks with the globalVariable "IsCurrentlyBlinking" if
the start is allowed.
If IsCurrentlyBlinking= True then nothing happens.
So normally it can´t happen that it starts twice. Only if the GlobalVariables are not correct.
The
variable "IsCurrentlyBlinking"is set to TRUE in the subvi before the
loop starts and after the loop is finished its set to FALSE in the
subvi.
Attachments:
03_CheckStart.jpg ‏16 KB

Multiple VI instance will not RUN using invoke node

Hi,
I need to have multiple instances of the same VI running.
I've created a template of the VI i wan't to call multiple times.
The VI is called via Open VI reference with a reference to the VI template.
Parameters to the instance is passed via set control value.
When opened and parameters has been passed, I use a invoke node to run the VI.
An error occur.
"Error 1000 occurred at Invoke Node in Template_Call plot window.vi
Possible reason(s):
LabVIEW: The VI is not in a state compatible with this operation.
Method Name: Run VI
VI Path: NULL"
Note ! The VIs should stay open after the call running independently of each other and the caller should not be waiting until the VI stops.
Any ideas what I am doing wrong
Regards Kahr
Certified LabVIEW Architect
CIM A/S
Solved!
Go to Solution.
Attachments:
Call_Plot Window.png ‏31 KB
Template_Plot window.png ‏23 KB

As simple as that Kumar !
Thank You all
Regards Kahr
Certified LabVIEW Architect
CIM A/S

Invoke node unfonctionnal after compiling

Similar Messages

Maybe you are looking for