Calling exe pauses Labview execution

I've written a program that needs to call another program. When that program opens, it pauses the now "background" vi, but I need it to continue running in the background. If I chose 'F' for 'Wait until completetion' the main program doesn't pause, but the window (from the exe I called) never opens.
Can this be done?

TNeilson wrote:
Well, I'm not quite sure what your vi does here. The actual call doesn't really look like you did anything that I didn't do, and your program ends after the calculator is loaded. Basically, I just want my program to load another program but continue running. One would think this wouldn't be that challenging, but so far, I've had no luck.
I didn't realize I'd need to provide an example of how to use the Run Program.vi that I referenced.
An example is now attached.
LV v7.1.1 and you will need to provide it with the aforementioned Run Program.vi
Attachments:
Example Using Run Program.vi ‏27 KB

Similar Messages

How to call Exe from labview?

Hello NI,
I want to call the exe from the labview. presently i am using command.vi to open the exe. but it works only with source code. after creating the exe it doesnt work.
I checked the path of exe.
do you have any solution for this?
Regards,
Balaji DP

Working directory should be c:\windows\system32
copy your winword.exe into that system32 folder and just try this
Message Edited by mathan on 01-06-2009 03:24 AM
Attachments:
untitled.PNG ‏3 KB

How to call a Linux exe from LabVIEW for Windows

Hello,
I need to call a non-LabVIEW Linux executable using LabVIEW for Windows. Any suggestions, aside from buying LabVIEW for Linux?
Thank you,
Chris White

Okay, I'll throw out a few ideas and I'll let you pick which one you may think is easiest.
1. Use the internet toolkit ($$$) or build a simple telnet client yourself in LabVIEW (use the TCP VIs in labview). This would allow you to connect to the telnet port of your linux box, login, password, and execute a command. (You'll probably want to use nohup, do a man on nohup to find out more).
2. Install SSH daemon on your linux box, and an ssh client on your windows machine. You can't get SSH for windows from cygwin. This would be more secure, and you wouldn't need to use the TCP VIs, you could simply use the "system exec" vi to call SSH.
3. On your linux box, install your app in inetd. Then, whenever someone connected to a certai
n port # on the linux box, it would execute your command. A little dangerous because someone might try to connect 50 million times (or a port scan) and kill your box. You also wouldn't be able to send a dynamic command line argument.
4. Write a small TCP application on your linux box to wait for connections (listen for command line options) and execute your command.
You'll probably find one of these options ideal depending on your administration and programming background.

Is this roughly how the labVIEW Execution Systems work?

I've not taken a class in OS design, so I don't know the strategies used to implement multitasking, preemptive or cooperative. The description below is a rough guess.
LabVIEW compiles Vis to execute within its own multitasking execution environment. This execution environment is composed of 6 execution systems. Each execution system has 5 priority queues (say priorities 0->4). Vis are compiled to one or more tasks which are posted for execution in these queues.
An execution system may either have multiple threads assigned to execute tasks from each priority queue, or may have a single thread executing all tasks from all priority queues. The thread priorities associated with a multithreaded execution system are assigned according to the queue that they service. There are therefore 5 available thread priority levels, one for each of the 5 priority level queues.
In addition to the execution queues, there are additional queues that are associated with tasks suspended in various wait states. (I don't know whether there are also threads associated with these queues. It seems there is.)
According to app. note 114, the default execution environment provides 1 execution system with 1 thread having a priority level of 1, and 5 execution systems with 10 prioritized threads, 2 threads per priority queue. NI has titled the single threaded execution system "user interface" and also given names to the other 5. Here they will be called either "user interface" or "other".
The "user interface" system is responsible for all GUI actions. It monitors the keyboard and mouse, as well as drawing the controls. It is also used to execute non-thread-safe tasks; tasks whose shared objects are not thread mutex protected.
Vis are composed of a front panel and diagram. The front panel provides an interface between the vi diagram, the user, and the calling vi. The diagram provides programmatic data flow between various nodes and is compiled into one or more machine coded tasks. In addition to it own tasks, a diagram may also call other vis. A vi that calls another vi does not actually programmatically branch to that vi. Rather, in most cases the call to another vi posts the tasks associated with the subvi to the back of one of the labVIEW execution system�s queues.
If a vi is non-reentrant, its tasks cannot run simultaneously on multiple threads. This implies a mutex like construction around the vi call to insure only one execution system is executing the vi. It doesn�t really matter where or how this happens, but somehow labVIEW has to protect an asynchronous vi from simultaneous execution, somehow that has to be performed without blocking an execution queue, and somehow a mutex suspended vi has to be returned to the execution queue when the mutex is freed. I assume this to be a strictly labVIEW mutex and does not involve the OS. If a vi is reentrant, it can be posted/ran multiple times simultaneously. If a vi is a subroutine, its task (I think there is always only one) will be posted to the front of the caller's queue rather than at the back of the queue (It actually probably never gets posted but is simply mutex tested at the call.) A reentrant-subroutine vi may be directly linked to its caller since it has no restrictions. (Whether in fact labVIEW does this, I don�t know. In any event, it would seem in general vis that can be identified as reentrant should be specified as such to avoid the overhead of mutexing. This would include vis that wrap reentrant dll calls.)
The execution queue to which a vi's tasks are posted depends upon the vi execution settings and the caller's execution priority. If the caller's execution priority is less than or equal the callee's execution settings, then the callee's tasks are posted to the back of the callee's specified execution queue. If the caller's execution priority is greater than the callee's specifications, then the callee's tasks are posted to the back of the caller's queue. Under most conditions, the vi execution setting is set to "same as caller" in which case the callee�s tasks are always posted to the back of the caller's execution queue. This applies to cases where two vis are set to run either in the other execution systems or two vis are set to run in the user interface execution system. (It�s not clear what happens when one vi is in the �user interface� system and the other is not. If the rule is followed by thread priority, any background tasks in the �other� systems will be moved to the user interface system. Normal task in the �other� systems called by a vi in the �user interface� system will execute in their own systems and vice versa. And �user interface� vis will execute in the caller�s �other� system if the caller has a priority greater than normal.)
Additionally, certain nodes must execute in the "user interface" execution system because their operations are not thread-safe. While the above generally specifies where a task will begin and end execution, a non-thread safe node can move a task to the �user interface� system. The task will continue to execute there until some unspecified event moves it back to its original execution system. Note, other task associated to the vi will be unaffected and will continue to execute in the original system.
Normally, tasks associated with a diagram run in one of the �other� execution systems. The tasks associated with drawing the front panel and monitoring user input always execute in the user interface execution system. Changes made by a diagram to it own front panel are buffered (the diagram has its own copy of the data, the front panel has its own copy of the data, and there seems to be some kind of exchange buffer that is mutexed), and the front panel update is posted as a task to the user interface execution system. Front panel objects also have the advanced option of being updated sequentially; presumably this means the diagram task that modifies the front panel will be moved to the user interface execution system as well. What this does to the data exchanged configuration between the front panel and diagram is unclear as presumably both the front panel and diagram are executing in the same thread and the mutex and buffer would seem to be redundant. While the above is true for a control value it is not clear whether this is also true for the control properties. Since a referenced property node can only occur on the local diagram, it is not clear it forces the local diagram to execute in the user interface system or whether they too are buffered and mutexed with the front panel.
If I were to hazard a guess, I would say that only the control values are buffered and mutexed. The control properties belong exclusively to the front panel and any changes made to them require execution in the �user interface� system. If diagram merely reads them, it probably doesn�t suffer a context switch.
Other vis can also modify the data structure defining the control appearance and values remotely using un-reference property nodes. These nodes are required to run in the user interface system because the operation is not thread-safe and apparently the diagram-front-panel mutex is specifically between the user interface execution system and the local diagram thread. Relative to the local diagram, remote changes by other vis would appear to be user entries.
It is not clear how front panels work with reentrant vis. Apparently every instance gets its own copy of the front panel values. If all front panel data structures were unique to an instance, and if I could get a vi reference to an instance of a reentrant vi, I could open multiple front panels, each displaying its own unique data. It might be handy, sort of like opening multiple Word documents, but I don�t think that it�s available.
A note: It is said that the front panel data is not loaded unless the front panel is opened. Obviously the attributes required to draw an object are not required, nor the buffer that interfaces with the user. This rule doesn�t apply though that if property references are made to front panel objects, and/or local variables are used. In those cases at least part of the front panel data has to be present. Furthermore, since all data is available via a control reference, if used, the control�s entire data structure must be present.
I use the vi server but haven�t really explored it yet, nor vi reference nodes, but obviously they too make modifications to unique data structures and hence are not thread-safe. And in general, any node that accesses a shared object is required to run in the user interface thread to protect the data associated with the object. LabVIEW, does not generally create OS level thread mutexes to protect objects probably because it becomes to cumbersome... Only a guess...
Considering the extra overhead of dealing with preemptive threading, I�m wondering if my well-tuned single threaded application in LV4.1 won�t out perform my well-tuned multithreaded application in LV6.0, given a single processor environment�
Please modify those parts that require it.
Thanks�
Kind Regards,
Eric

Ben,
There are two types of memory which would be of concern. There is temporary and persistent. Generally, if a reentrant vi has persistent memory requirements, then it is being used specifically to retain those values at every instance. More generally, reentrant code requires no persistent memory. It is passed all the information it needs to perform its function, and nothing is retained. For this type of reentrant vi, memory concern to which you refer could become important if the vis are using several MBytes of temporary storage for intermediate results. In that case, as you could have several copies executing at once, your temporary storage requirements have multiplied by the number of simultaneous copies executing. Your max memory use is going to rise, and as labview allocates memory rather independently and freely, the memory use of making them reentrant might be a bit of a surprise.
On the other hand, the whole idea of preemtive threading is to give those tasks which require execution in a timely fashion the ability to do so regardless of what other tasks might be doing. We are, after all, suffering the computational overhead of multithreading to accomplish this. If memory requirements are going to defeat the original objective, then we really are traversing a circle.
Anyway, as Greg has advised, threads are supposed to be used judiciously. It isn't as though your going to have all 51 threads up at the same time. In general I think, overall coding stategy should be to minimize the number of threads while protecting those tasks that absolutely require timely execution.
In that sense, it would have been nice if NI had retained two single threaded systems, one for the GUI and one for the GUI interface diagrams. I've noticed that control drawing is somewhat slower under LV6.0 than LV4.1. I cannot, for example, make a spreadsheet scroll smoothly anymore, even using buffered graphics. This makes me wonder how many of my open front panel diagrams are actually running on the GUI thread.
And, I wonder if threads go to sleep when not in use, for example, on a wait, or wait multiple node. My high priority thread doesn't do a lot of work, but the work that it does is critical. I don't know what it's doing the rest of the time. From some of Greg's comments, my impression is it in some kind of idle mode: waking up and sleeping, waking up and sleeping,..., waking up, doing something and sleeping... etc. I suppose I should try to test this.
Anyway that's all an aside...
With regard to memory, your right, there are no free lunches... Thanks for reminding me. If I try this, I might be dismayed by the additional memory use, but I won't be shocked.
Kind Regards,
Eric

Creating dll and calling it in labview crashing the program

Hi All,
I am using labview from quite a long time.But this time i am stuck with dll.Not able to solve this issue.
I have to communicate with FTDI chip.
I have a VC++ Project to communicate with SPI of FTDI.That Code is working perfectly fine.
Now I Have to automate that through LabVIEW. VISA Drivers i cant use in this. So Last option left is either to create dll or to make EXE out of it.
I have tried by creating DLL and then calling it in LabVIEW by using Call Library Function Node.But its not helping me out every time LabVIEW is getting Crashed.
Is there error in creation of dll or something i am not doing properly while calling?
Thanks In Advance
Shweta
Attachments:
old_dolphin_sub_spi_func_ftdi.c ‏21 KB
ftdi_write_read.vi ‏15 KB

Which function call crashes LabVIEW?
Have you tried switching the calling convention from stdcall to C for all of the DLL calls?
Why are you converting a string to a number, instead of using a numeric constant directly? If you want a number in hex, you can right-click a numeric constant, make the radix visible, and switch it to hex display.

LABVIEW.LIB was not called from a LabVIEW process when creating unit tests

We are developing a DLL to be integrated in LabVIEW using CLFs. So far we have the system working, but we wanted to create some unit tests in C as part of our release process. The problem is that when I link labview.lib in VS C++ and then call the EXE generated I get an error saying: "LABVIEW.LIB was not called from a LabVIEW process". As mentioned in http://zone.ni.com/reference/en-XX/help/371361J-01/lvexcodeconcepts/debug_dlls_and_dll_calls/:
"Calling the shared library from another C program is also another way to debug the shared library. By calling the shared library from another C program, you have a means of testing the shared library independent of LabVIEW, thus helping you to identify any problems, sooner."
Some of our functions, however, use LabVIEW specific instructions and we would like to test them in a realistic environment (i.e., calling to the actual functions instead of creating stubs).
Is there any workaround to this problem?
Thanks!!

Hello SaraGr,
Welcome to the NI Discussion Forums! I have a couple of questions to better determine the issue here:
1. What is the LabVIEW version that you are using?
2. Does your DLL uses Serial Compatibility VIs? If so, try using your development on NI-VISA instead of Serial.
3. Are you using a Code Interface Node (CIN)? If you do, I see that from the help file you would need to compile the code for the new platform. Also, please remember that functions specifc to CINs (such as SetCINArraySize) will not work in a DLL.
4. Be sure to include the header files in your program, like extcode.h. Please follow this white paper to link labview.lib to your program, or follow the Alternate Method.
Regards,
Daniel REDS
RF Systems Engineer
Help us grow.
If a post solves your question, mark it as The Solution.
If a post helps, give Kudos to it.

Pda execute other exe from Labview

I'm looking for ways to execute an exe from Labview PDA that is stored on the PDA (another PDA application)... I'm running WM5.0 ... .any ideas ...
Greycat

Hey Greycat.
That is a great question! So as you noticed there is no equivalent to System Exec in LabVIEW PDA, so you cannot launch an application that way. I would think that there would be a DLL that could be called on the PDA that will allow you to launch applications. However, after several Google searches I was not able to come up with any specific code or DLLs. Once you found that DLL hoewever, you shouldn't have problems launch an EXE. I am assuming that these are not other LabVIEW PDA built EXEs, which is a shame since you might be able to open a VI reference to that VI.
Andy F.
Message Edited by Andy F. on 04-25-2006 06:52 PM
National Instruments

Heisenbug: Subsequence call, different file, LabVIEW

Hi, all,
I'm wondering if anyone has seen this Heisenbug. Sometimes, not always, when I call a subsequence in a different file, LabVIEW refuses to start -- even if the subsequence contains no LabVIEW. Usually I have to kill all threads to clear the problem.
If I'm lucky, I get a message in the report that the LabVIEW ActiveX server couldn't be contacted or some such. Or sometimes I get a popup with a 406 error (Memory Manager) in LabVIEW.
Once this starts happening, the TestStand script is permanently scrozzled and I have to revert to a known good copy.
Also possibly relevant:
- TestStand 4.1, LabVIEW 8.5.
- I'm starting a subsequence that includes LabVIEW calls in a separate thread. This has been working when the subsequence is in the same file. (The bug still shows up sometimes when the subsequence is in the same file.)
- The only common factor I've seen so far is that both the calling and called files contain LabVIEW.
Has anyone seen something like this? It's killing my ability to modularize the tests I'm working on.
Thanks,
- Steve.
Message Edited by SPM on 08-29-2008 12:16 PM

Steve,
reading your post leaves the impression that this malfunction occurs only after a reboot.
So i take it that you switch on the PC, start TestStand after booting and start the execution. There it can (!) happen, that the file somehow gets messed up and does not work anymore with the given issue.
Other sequencefiles can be loaded and executed properly after this.
If that is correct:
Can you check out if this behaviour is connected to e.g. special VIs?
Did you ever encounter this issue with examples from NI?
Is it connected to certain sequencefiles? If so, how do they concur (e.g. step definitions)?
What happens if you make sure that LV is running before execution of the sequence?
If you reboot the system, is the "corrupted" sequencefile still malefunctioning or does it (possibly) work again?
hope this helps,
Norbert
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.

Calling NIST from Labview

Does anyone have any experience using NIST software with Labview. I am wanting to call NIST to get properties of two different gases, and not exactly sure how to accomplish this.
Can anyone point me in the right direction?

aputman wrote:
I use a TCP connection to get NIST time. Not sure if something like this is available for what you are looking for. Hope it helps.
NISTime-32.exe is shareware and available here
Their is a command line hook so you can just call it with the system exe from LabVIEW
Jeff

How to send a command from a vc++.exe to LABVIEW.exe in order to control the button on the LABVIEW.exe

Hello, everyone. Using VC++, I have gotten the handle of a *.exe(built by Labview), but I cannot get the button handle. I want to get the button handle and post the message to control the button. How can I do that? When I use the SPY++, the *.exe(built by Labview) have not any child windows which is very different from the *.exe(built by VC++). In SPY++, what is the LVDChild class? How can I send the message to control the button on *.exe(built by Labview)???
That is to send a command from a vc++.exe to LABVIEW.exe in order to control the button on the LABVIEW.exe. How can I get it ?
Thank you!

hummingbird wrote:
Thank you! But I dont kown how to use vi server to raise a value signalling event. Can we put vi server into the vc program? Can you give me some more information or some examples, hehe!
hummingbird
Checkout the LabVIEW ActiveX server interface in the User Manual in Chapter 20, Windows Connectivity and the VI Server Reference in Chapter 17, Programmatically Controlling VIs.
There is a sample for Visual Basic under examples/comm/VBtoLV.frm, which should be quite simple to translate to Visual C as long as you can figure out the basics of ActiveX programming in VC (I have never done anything with ActiveX in VC). For those basics I would recommend some text book or MSDN.
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

LABVIEW.LIB was not called from a LabVIEW process

Hi All,
I've inherited LV code that calls a CIN node to access a motor controller. I'd like to compile this code to a .NET DLL, but receive the following error when calling it from an external source:
I've read the knowledgebase article explaining the problem from here, as well as the following support questions:
http://forums.ni.com/t5/LabVIEW/Labview-lib-was-not-called-from-a-labview-process/m-p/232548
http://forums.ni.com/t5/LabVIEW/Problem-with-lsb-LABVIEW-LIB-was-not-called-from-a-LabVIEW/m-p/48809...
http://forums.ni.com/t5/LabVIEW/Labview-lib-was-not-calld-from-a-labview-process/m-p/718427
http://forums.ni.com/t5/LabVIEW/Building-a-LabVIEW-DLL-with-VIs-that-use-CINs/m-p/632817
The conclusion seems to be recompiling is the answer. I've tried recompiling the original CIN vi within LV with no success. Do they mean to recompile the original C code against the newer labview.lib (sorry, I'm not all that familiar with how the CIN nodes work)? Any suggestions would be awesome. Thanks.
-Joe

You can't make use of LabVIEW manager functions in non-LabVIEW based processes. Basically unless the C code is for a CIN or DLL that is to be called by LabVIEW (inside the development system or a LabVIEW built application), any function pulled in from labview.lib is not available. LabVIEW.lib is an import library that does not implement any functions but simply imports them from the LabVIEW kernel, either the LabVIEW development system or the LabVIEW runtime DLL. And no you can't just link in the LabVIEW runtime DLL into your .Net application. This DLL needs to be started up and initialized in very specific ways, that only LabVIEW itself knows about when building an application.
Basically if you want to recompile the code (yes in C/C++) for use in a non-LabVIEW application, you also have to remove all the link libraries from the LAbVIEW cintools directory, and replace any use of functions now unavailable (link error: unavailable external reference) with other similar functionality from your C runtime library. Or implement those functions yourself using C runtime library calls.
Another possibility could be to actually create a LabVIEW executable that exports the functionality as ActiveX Server. Or in LabVIEW 2010 you could also select to create a .Net Interop Assembly from inside the LabVIEW project.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

What kind of function(s) (in dlls) have to be call by a Labview application to be able to manage the PC's power supply

Assume that a Labview application is running on a PC. The PC has a DC battery. When a "power off" is detected on the AC line, data should be saved, Labview application and Windows should be closed.
What kind of function(s) (of which dll) should be called by a Labview application to realize this data and system management in a safe manner ?

UPS (Uninterrupted Power Supply) systems can send messages to the PC through the serial port when the AC is lost and when battery is low. I'm not sure how this message is sent but I suspect they use Windows Messaging. If you could find this out, you could write your vi to constantly look for this message and shutdown when it sees the message.
- tbob
Inventor of the WORM Global

How to call exe programs

hi all,
just wanted to know how to call exe (like system calculater etc)from my form.i am using forms6i.
thanks
shakeel

You can look up HOST in the online help in the builder. For CLIENT_HOST, look at WebUtil, which you can find by going to the Forms page on OTN: http://www.oracle.com/technology/products/forms/index.html
Regards,
Robin Zimmermann.

Fatal error Labview.lib not called from a Labview process

in teststand my vi works fine with adapter set for LV development
when I configure the LV adapter for runtime, I get fatal error Labview.lib not called from a Labview process
what is going on?
how do I fix it?
thanks.

Howdy Stephen -
Are you by chance calling a LabVIEW DLL within your LabVIEW VI which is being called from TestStand? I know this error occurs when a LabVIEW DLL built in a different version of LabVIEW than the selected Run-time Engine.
Here is a KnowledgeBase which references the issue:
KnowledgeBase 203EA3XC: LabVIEW.LIB Error When Calling a LabVIEW DLL Built with VIs That Use Externa...
If this is the case, you will need to open the LabVIEW DLL source VI in the LabVIEW version you are using and rebuild the DLL.
Thanks and have a great day!
Regards,
Andrew W || Applications Engineer
National Instruments

WMIC with Arguments/ Parameter while use PROCESS CREATE CALL exe

Hi Team,
I want to call exe from remote system using WMIC direct command. for that I prepare one command here
WMIC /NODE:"RemoteSys" /USER:"domain\username" /PASSWORD:"XXXXXXXXX" PROCESS CREATE CALL "C:\Program Files (x86)\Company\Product\productapp.exe"
But issue here is this productapp.exe is expecting an arguments/ parameters like " -p PlantA "
Question here is How to pass it ?
I tried many alternate ways but all fails like:
WMIC /NODE:"RemoteSys" /USER:"domain\username" /PASSWORD:"XXXXXXXXX" PROCESS CREATE "C:\Program Files (x86)\Company\Product\productapp.exe" -p PlantB
Output: Invalid Verb Switch
WMIC /NODE:"RemoteSys" /USER:"domain\username" /PASSWORD:"XXXXXXXXX" PROCESS CREATE "C:\Program Files (x86)\Company\Product\productapp.exe" "-p PlantB"
Output: Invalid format. Hint: <paramlist> = <param> [, <paramlist>].
Don't know what is paramlist & How to use that.
Can anyone help me here ?
Regards, Brijesh Shah

Go to
https://social.technet.microsoft.com/Forums/windows/en-US/home and find the forum for the version of Windows you're using. That's the appropriate place to ask the question. Best of luck!
Kind regards,
Margriet Bruggeman
Lois & Clark IT Services
web site: http://www.loisandclark.eu
blog: http://www.sharepointdragons.com

Calling exe pauses Labview execution

Similar Messages

Maybe you are looking for