Cancel or abort invoke node that hangs up

Hello,
i use an invoke node to grab an image from firewire camera. camera in trigger mode.
application hangs up when trigger signal fails. running VI in highlight execution mode shows that "IICImangingControl, MemorySnapImage" (upside left) hangs up.
VI cannot be cancel with abort execution button.
target: abort invoke node in case of timeout (error handling)
question: how can i abort hanged up invoke node?
timon
Attachments:
GrabPicture 02.tg.vi ‏97 KB

The camera code is an ActiveX/COM DLL that you are calling out to. Unfortunately, when a thread leaves LabVIEW and calls external code, we have no control over it anymore. When you abort the VI, we'll stop the code execution, but we have to wait for the COM DLL to release the thread.
Being able to do this is outside our control, unfortunately. You should look at the camera API, or talk to the vendor, about a method that either has a timeout or is asynchronous in nature.
Brian Tyler
http://detritus.blogs.com/lycangeek

Similar Messages

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

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

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

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

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

Run VI Invoke Node: VI works, EXE doesn't?

This is LV2009 with no patches or updates. I am calling buffer.vi by static reference with an invoke node set to Run VI. I don't have an incredibly good reason for doing this, but just don't want that code on the block diagram. I hate to put alot of effort into this since I can just drop the code on the main diagram and I'm sure it will work, but I don't understand why it gives me the error 1000: VI not in a state compatible with this operation?
In the EXE, when I check the execution state of the buffer.vi before I tell it to run, it comes up bad. Same code in the VI, comes up idle. I also tried replacing the static VI reference with an open VI reference using the name of the buffer and received the same error. I have the buffer VI included in the build under always included.
Solved!
Go to Solution.

"You did not compile the vi to be in the EXE, did you?"
I'm not sure what you mean. I have included buffer.vi and all of its sub VIs in the build as Always Included. I am investigating creating a source distribution. Never done that before. I will let you know if it works.
I attached snippets of the caller and buffer.vi itself. I was playing around with the caller, trying to abort if running and such...
Edit: Sorry if its confusing, what I'm calling buffer.vi is actually Waveform FIFO AE.vi
Message Edited by deskpilot on 04-08-2010 09:04 AM
Attachments:
Remote Call.png ‏34 KB
Buffer.png ‏42 KB

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

"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

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 6 at Invoke Node in Dist Send Result File to RT.vi-- Build Applicaiton.vi

I am using cFP 2000 RT in my application. When I build exe and download the application to the cFP 2000 RT, I get "Error 6 occured in Invoke Node in Dist Send Result File To RT.vi--> Build Application.vi"
The steps followed.
1. In the LabVIEW 7.0 Main Panel, Select the execution target as RT Target.
2. Tools --> Build Application or Shared Library. In the Target Tab the destination directory is selected as \\xxx.xxx.xxx.xxx\c\ni-rt\startup automatically.
3. In the SOurce file tab, select the Top level VI.
4. Press Build to make the executable of the application. The application is built and at the end the error message is poped up. (see the attached file)
Software Configuratio
n:
1. LabVIEW 7.0
2. Field Point 4.0
3. LabVIEW RT 7.0
Help me solve this problem. Thanks in advance.
Attachments:
Error_Message_and_RT_Info.bmp ‏313 KB

This is most likely coming from the specific file it mentions in the error, Dist Send Result File To RT.vi. The error 6 means the file can't be found. One thing to try first is to add this VI as a Dynamic VI in Application Builder. Another option is to change the path that this VI is invoked from, or is not called by an Invoke Node at all.
I hope this helps, feel free to contact support if the problem continues.
Regards,
Robert Jackson
Application Engineer

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

Error 1003 occurred at Invoke Node

Good morning.
I work with LW8.5 and created with the following architecture:
There is main.vi on the links at the user's calls and runs the other VI.
That is, not directly, these are not included in the VI block diagram main.vi.
In the development of a happening in normal mode, all dynamically called VI,
But once I make EXE, when you try to call the dynamic VI error 1003.
Error 1003 occurred at Invoke Node in Main.vi
Possible reason (s):
LabVIEW: The VI is not executable. Most likely the VI is broken or one of its subVIs cannot be located. Open the VI in LabVIEW using File>> Open and verify that it is runnable.
VI Path: C: \ Shaikov \ Labwiev \ builds \ NSIAES \ Initialsettings \ Initialsettings.vi
Show you how to act?
Thank you.

Hello margasan.
In my Projects I use to pass more dynamic and VI classes.
In the attached file - an example of my project:
In the main folder is a folder UpperClass, it is the parent class and child classes and HeirClass.lvclass Heir2Class.lvclass are organized into folders respectively Plugin1 and Plugin2, and these Classes inherit from the parent one and the same WI - UpperClassTest.vi. Plus, this Plugin1 has two, independent from the others, but related classes. A block diagram for an object placed Core.vi UpperClass.
So, here, if you take EXE, making llb files and run them from start VI for each of the Plugin, then everything works OK.
But as soon as I on the block diagram of a Plugin will put any object UpperClass, or one of its nasalednikov, there arises a familiar ERROR 1003. Prompt, plc, margasan I get rid of it in this case?
Attachments:
Example.zip ‏1481 KB

Cancel or abort invoke node that hangs up

Similar Messages

Maybe you are looking for