Labview executable spontaneously quits

I have a LV6.1 executable that acquires AI data via SCXI and transfers info back and forth to MS Excel 2000, and the serial port Com1. It is working on 4 seperate PC systems, all using Win2000 SP3. There are no terminate LV nodes in the code. The newest PC, a new Dell, set up exactly like the other 3 systems, has begun spontaneously stopping the executable LV program with no error messages displayed. LV just quits as if the X "Close" button had been pressed and sits at the Win desktop. If the PC is restarted, the Programs/Startup/.exe will restart, but after a time it just quits again. Anyone ever seen this kind of behavior before?

Hi Jim,
Are you doing any error checking in the executable? Is it possible that the problem lies with the hardware and that is somehow closing out the exe? Also when the exe runs for a while before stopping, can you see any data written in the spreadsheet?
Ankita

Similar Messages

Labview executable immediately quits on WIndows XP

Greetings,
Short description of the problem: I build an executable of my Labview 2010 (32-bit) project on my Windows 7 (64-bit) development machine and it runs fine. When I attempt to run the .exe on a different Windows 7 (32-bit) machine it runs fine. When I try to run it on any Windows XP machine, the executable starts and then quits immediately. No error message is reported and it appears that the VI doesn't ever start executing. My installer includes the LV2010 run-time engine and NI-VISA run-time. The application window opens just for a split second, just long enough to see the front panel briefly, before disappearing.
Background: This problem showed up early in the project but it went away when I installed Service Pack 1 for Labview 2010. I assumed it was some obscure bug. I went through several revisions of the project over the next couple of months. Most of the target machines run Windows 7 so I never spent a lot of time testing the executables on WinXP but all of the early versions worked fine. At some point in the development the executables stopped working on Windows XP. I haven't made any changes to the build specifications or installer that I can find.
I've found the latest revision of my code that produces an executable that works on WinXP. There are a lot of small changes between that version of the code and the earliest non-working version I have but none of them seem like they should cause such a fundamental failure.
I cannot even use the debugger on the XP target machine. The window will appear and wait for me to start the debugger. As soon as I start execution (either locally or via the debugger) the application quits immediately and closes the connection with the debugger. I cannot probe any signals or set any breakpoints. Nothing in the VI code executes prior to quitting.
No errors are generated, no crash message, nothing in the Windows event log. Just...poof.
Any suggestions?
Thanks,
Dave

In addition to race conditions, bad (or non existant) error handling is also known to create such issues. Please note that executables do not have "automatic error handling" so maybe errors are simply not reported, but the code exits execution.
Sources of errors like this are often:
- File IO and plugins (relative paths may change in exe!)
- Trying to load components which require recompile (which is done in the development system without notifying you, but the RTE cannot do this). Refers to plugins mainly.
- Using DLLs which are either not found or have invalid parameter settings in exe (unhandled exception of either the DLL itself or the LV RTE when accessing return values).
Are you sure that you have all components installed on each machine (please remember that there are modules requiring dedicated RTEs)?
Can you try building the exe on a XP machine? Does it behave differently?
thanks,
Norbert
PS: I am not aware that there is a general issue. If this issue is persistent on your machines, i would take a look into user rights on each system. Does the behavior change if you meddle with the user rights?
[EDIT] PPS: Another source for the issue might be virus scanner and/or firewall.....
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.

Labview executable only works for about ten seconds before shutting down

Hi,
I'm not a newbie to LabVIEW but I am a newbie to creating executables and installers using LV. On my first attempts I'm having a strange problem that I cannot resolve. I already began discussing this problem on another thread, but I was advised to start a new one.
I've made a variety of VI's but for debugging purposes I made the simplest VI possible: just some plain text on the front panel, no code on the block diagram.
I created a project with just that VI, compiled an executable, compiled an installer, and sent the installation files to my colleague. I use a Win XP machine and so does he. He does not have LV installed.
The installation goes fine, the VI starts up, appears to run fine and then spontaneously quits (i.e. the window closes and disappears) after twelve seconds with no error message.This happens even if I create a VI with a loop. The VI executable, installed via the installer on my WinXP PC (which has the full LV application) does not replicate this problem. It occurs only on a WinXP machine where LV is not installed.
version info: LabVIEW 2010
My debugging ideas going forward are:
- try to play with the "Source File Settings --> Use default save settings" checkboxes, as suggested by another user in another thread.
- ask another colleague with WinXP and no LV to test the VI's, to see if the problem is somehow linked with my first colleague's machine.
- to check the Windows Event Log (following the advice of user Norbert on this forum), but I'm not sure if I'll be able to decipher what I read in there. A first look has turned up nothing interesting.
- am pretty stuck for ideas after that.
Thanking you in advance for any input you can give,
Garrett

Issue solved: the anti-virus was forcing the application to shutdown.
Bit of a newbie problem
I discovered the problem when I tried the executable on another colleague's PC. When the exe was launched, the anti-virus software (Avast!) showed a pop-up that said it was verifying the unknown program and then after about 12 seconds it shut it down. It then proposed to open the program in either the "sandbox" or "as normal" the next time. By choosing "normal" the VI worked fine the next time.
It turns out that on my first colleague's PC, he also had Avast! software, except that on his PC it was running in some sort of hidden background mode. This meant that it didn't display any pop-up messages to indicate that it was interfering with the VI. Once we manually launched the Avast! interface, it finally proposed the option of opening the VI in the sandbox or normally.
All works fine now. I hope this helps other newbies out there.

Wine & Labview Executables?

Is it possible to run LabView executables under wine? Has anyone ever attempted to do this? Thanks for any information.
Regards,
Ken

Kenneth.Miller wrote:
Is it possible to run LabView executables under wine? Has anyone ever attempted to do this? Thanks for any information.
Regards,
Ken
I've tried it several years ago with
LabVIEW 5.1.1 and 6.1 and didn't really have any significant issues
except that everything was sort of sluggish and certain screen updates
left artefacts on the screen. Now Wine has come a long way since but so
has LabVIEW and I doubt somewhat that LabVIEW 8.0.1 would be as
complient with Wine as older versions have been.
All the .Net, Active X and what else more is quite involved and LabVIEW
8.0.1 does not for nothing require Win2000 or XP to run. Wine has on
that area quite some deficiencies related to specific functionality
such as ActiveX/DCOM and does not attempt to provide .Net functionality
at all. Of course you could get Mono into the picture here but last
thing I heard they were trying to sort of modify Wine to get their
system to load properly.
I believe that .Net is optional in that LabVIEW will only weak link to
.Net functionality and did so before with ActiveX/DCOM but since
Win2000 comes with ActiveX support out of the box, this weak linking
might not have been tested properly anymore and might actually fail.
All in all not exactly a good constellation and since LabVIEW for Linux
is available since a long time I haven't bothered about LabVIEW on Wine
for quite some time.
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

LabVIEW 2013 SP1 Quit LabVIEW

Hello all,
I have a question regarding the Bug 425800 (Quit LabVIEW will not quit if the event 'Application Instance close' is present) in LV2013. According to NI this Bug is fixed in LV2013 SP1.
I have an application, which was converted from LV2011. The application compiled in LV2011 worked well.
After converting to LV2013 I had the issue, that the exe won't quit. I updated to LV2013 SP1 and mass compiled my project. After building the executable again, I have the same issue. My compiled EXE (LV2013 SP1) will not quit.
One VI contain the 'Application Instance close' event, because the PC is connected to an UPS and the application should be terminated in a save way in case of power loss.
Is there any other reason why the 'Quit LabVIEW' will not work?
As a little reminder: The application worked well in LV2011.
Regards
Heinrich Eidloth

Dear Mr Eidloth,
I would like to help you resolve this issue.
Would you mind sending me your program to look into so I can help you better?
Alternatively you could try running the added example to test the functionality of the "Application Instance close" Event and the "Quit LabView" funktion.
Thank you very much in advance.
Best Regards
Veronika Kurz
Veronika Kurz
National Instruments
Applications Engineering
www.ni.com/support
Attachments:
Quit LabVIEW CAR-1.vi ‏10 KB

Labview executable monthly password distribution via internet

We control some equipment with a Labview executable that operates a USB DAQ board (Analogue Inputs and Digital Outputs). Does anyone know of software that would automatically email operating parameters and data files and would manage Password Access. The proper password would be available weekly or monthly on our server when the account is in good standing. If the payment for the equipment has not been made the software should show information pertaining to making a payment and how to obtain the appropriate Password.
It appears that the Internet Toolkit only partially solves the internet access problem the secure password distribution, if it exists, is most likely a third party software. Does anyone know how secure this solution in the face of some person who prefers to crack than pay?
I am open to suggestions. I would like to use the solution nationally and internationally.
Raymond

I'm pretty sure you won't find a ready made solution for this to download. Your requirements are quite specifc and involve quite a bit of different componenets. And any one having written something like this has spent A LOT of hours into it, so he will not post it for free.
So lets look at your description:
1) Having a password to download from your server. Why??
You simply want to connect to your server with a license key that the user got when purchasing the software and see if the application has still support in your database. But you do not immediately want to disallow operation when the internet connection is flaky so you need to add some grace period, with a warning to that fact but still allow to run for some time. A legitimate user that can not run your software because something messed up that he does not understand, will in the best case call you up and tell you what he thinks about your #$%^ company.
2) Password access is not for you to check that the application is used properly (you do that through the license key) but for your users to allow protecting the software to be run by anyone he doesn't want.
But for your online license check you do need also a VERY reliable database backend on your server. And an internet access component that can query your database through some interface like CGI or Web Services. And of course you do not want to have this connection through unencrypted connections, so there needs an underlaying SSL connection.
So let me ask some question? How much would you be willing to pay for such a LabVIEW component and how much time and money would you be willing to spend yourself to build and test the database backend?
Message Edited by rolfk on 11-06-2009 09:25 PM
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Improving load times in Linux LabVIEW executable

I'm looking for (simple) ways to improve the loading times in a Linux LabVIEW executable. We're using a low performance, low cost CPU board, and loading times are terrible. The CPU is capable of doing everything after the application is loaded, but takes forever to get there.
One of the problems is the size of the executable, that grows everytime you just look at it. Are there ways to create smaller executables? It runs from a Compact Flash card, which is ofcourse much slower than hard disk.
Another problem is a dynamic vi, that is started for every TCP connection that connects to the application. It takes a long time to load, and connecting too fast can even effectively hang up the system. Starting a handler task takes about half a second, up to a few seconds for the first task.
We're using the LabVIEW 7.1 runtime, system is a 300 MHz cyrix SBC, running from a Compact Flash.

Dennisvr wrote:
I'm looking for
(simple) ways to improve the loading times in a Linux LabVIEW
executable. We're using a low performance, low cost CPU board, and
loading times are terrible. The CPU is capable of doing everything
after the application is loaded, but takes forever to get there. One
of the problems is the size of the executable, that grows everytime you
just look at it. Are there ways to create smaller executables? It runs
from a Compact Flash card, which is ofcourse much slower than hard disk. Another
problem is a dynamic vi, that is started for every TCP connection that
connects to the application. It takes a long time to load, and
connecting too fast can even effectively hang up the system. Starting a
handler task takes about half a second, up to a few seconds for the
first task. We're using the LabVIEW 7.1 runtime, system is a 300 MHz cyrix SBC, running from a Compact Flash.
I'm
not sure about the first part of your question. LabVIEW is highly
binary and does a lot of memory allocations before even one VI is ready
to be started. So maybe the memory manager is a problem. Another issue
is that the Macintosh like resource file format that is used by LabVIEW to store its VIs etc. results in
lots and lots of individual disk accesses with a rther random like
character inside a single file. So if you can configure the read
caching of your disk to use more memory this may significantly increase
the speed of loading LabVIEW VIs or applications.
And finally spawning VIs through VI server is a rather costly operation
especially on low resoruce systems. A VI is more like an executable in
many ways as far as resource consumption is concerned rather than a
thread. A much better way would be to avoid spawning subVIs altogether
and implement a queued TCP/IP server similar to the Date Time Server
example. It is a little extra work to work with this shift register
architecture but it will not have the issues of long load times for
every new TCP/IP connection coming in.
Rolf Kalbermatter
Message Edited by rolfk on 03-07-2006 06:33 PM
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Open VI Reference to a LabVIEW executable.

Hello,
I haven't done this for a while and it's not working like expected. I'm trying to "Open VI Reference" from executable A.exe to B.exe. I'm trying to get a control value from B.exe in A.exe. Can someone send me an example?
Right now I'm at this stage: I have A.exe running as a LabVIEW executable. I'm trying to "Open VI Reference" to A.exe from LabVIEW development without success. Not sure what I'm doing wrong.
Don't hesitate to ask more info if you need some.
LabVIEW 2012, Windows 8.1.
Thanks,
Michel
Solved!
Go to Solution.

Bob_Schor wrote:
Once you have an Executable, does it matter that the underlying Development system is LabVIEW, rather than (say) Visual Studio, or Matlab? I suppose you could write an application that "knows" to, for example, listen to a TCP/IP port and interpret/execute commands, but that doesn't sound like the question being asked.
BS
LabVIEW-built executables still run as VI's in the RTE, though. Their identities have not been abstracted away into one single object or anything, and they still have name-based VI server access.
You can configure a build specification to include almost nothing, and require the VI files to be present in expected locations (i.e build specification's data or support directories). By default, all items in an executable application build specification are set to be put in the same location as their caller, which results in most things going into the .exe file, internally referenced in a directory-esque form like crossrulz mentioned, "MyExecutable.exe\MySubVI.vi".

Is it possible to call a VI that is inside a LabVIEW executable from a TestStand sequence?

I have created a custom TestStand operator interface and have modified the default sequential process model to display a UUT information dialog that prompts for more information than just the UUT serial number. This UUT information dialog is a LabVIEW VI. To distribute the operator interface, I build it into an executable. As part of the build process, I make a copy of the UUT information dialog VI (which is part of my operator interface project) and place it in the same folder as the executable. I have then configured the sequential process model to call the dialog VI from this location. It would be really nice if I could embed the UUT information dialog VI inside the operator interface executable so that I could distribute just an executable instead of an executable and separate VIs. Is this possible? In other words, is it possible to call a VI that is inside a LabVIEW executable from a TestStand sequence just like a standard LabVIEW VI call?

Ryan,
The dialog that you've created isn't being directly called by the OI at all and shouldn't need to be included in the same directory as the OI for distribution. Since you are modifying the PreUUT of the default process model, you will give the path to the VI in that step, create a deployment and then manually copy the VI to the directory referenced in the step. The VI is considered a support file for the process model and is not related to the OI at all.
Test Engineer - CTA

How to open labview program with Quit Labview function inside?

Hi Any idea how to open labview program with Quit Labview function inside?
I forgot to add and set the condition of the type for this program.
If the program is an application, it would close straight away.
If it is still labview work, it will go straight to editing program without closing.
So I need to recover, open it and make some changes.
Clement
Solved!
Go to Solution.

Put the VI in a project and open it from there, then it shouldn't autorun. You can use App.kind property of application to decide whether to close or not.
/Y
LabVIEW 8.2 - 2014
"Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
G# - Free award winning reference based OOP for LV

How can I run a labview executable file inside a VI

How can i add and run a labview executable file inside the vi and grab the output of the executable file to be used in the vi?
mytestautomation.com
...unleashed the power, explore and share ideas on power supply testing
nissanskyline.org
...your alternative nissan skyline information site

Hi cmdrb,
to run an executable you use SystemExec function.
To get the output of your (LabVIEW-made) executable you need to program some data transfer means: you may use network functions or file functions. In both cases your "LabVIEW executable" needs to provide that options…
Best regards,
GerdW
CLAD, using 2009SP1 + LV2011SP1 + LV2014SP1 on WinXP+Win7+cRIO
Kudos are welcome

How can I call a LabVIEW executable from within another LabVIEW executable?

I have a customer requirement for two LabVIEW executables. Based on their current setup, they need to run executable "A" or "B", both of which are under independent revision control. I have created a third "selection" executable that allows the operator to choose between one of the two, but I am receiving errors when I attempt to call a LabVIEW executable from within a LabVIEW executable using either the "System exec" VI or the "Run Application" VI. If I call a non-LabVIEW executable (such as Windows Explorer) everything works fine.

> I have a customer requirement for two LabVIEW executables. Based on
> their current setup, they need to run executable "A" or "B", both of
> which are under independent revision control. I have created a third
> "selection" executable that allows the operator to choose between one
> of the two, but I am receiving errors when I attempt to call a LabVIEW
> executable from within a LabVIEW executable using either the "System
> exec" VI or the "Run Application" VI. If I call a non-LabVIEW
> executable (such as Windows Explorer) everything works fine.
As with the other poster, I suspect a path problem. You might try the
path out in a shell window, and if it works, copy the complete absolute
path to LV to see if that works. LV is basically passing the comma
nd to
the OS and doesn't even know what is in it, so you should be able to get
it to work.
The other poster commented on subpanels, which is a good suggestion, but
without going to LV7, an EXE can have open more than one VI. You can
use the VI Server and the Run method to fire up another top-level VI.
The decision is whether you want both to be in unique processes.
Greg McKaskle

Control where a LabVIEW executable write it's Settings Configuration file

Is there any way to control which directory a LabVIEW executable writes it's configuration settings file to? I am using version 7.1.

I believe the INI file must be in the same directory as the executable. You can use the keys found in the LabVIEW.ini file and they will apply to your executable without any special programming on your part. That being said, you can always create a custom settings file or files anywhere you like to store configuration information specific to your application.
If we could specify some other path for the executable settings file, it would probably hurt more than help in the long run. The same directory as the executable is the only one whose existance you can be sure of..... or of whose existance you can be sure.
Dan Press
PrimeTest Corp.
www.primetest.com

Problems with a waking up a labview executable after computer hibernation?

I am just wondering if anyone has had any problems with waking up a labview executable after hibernating a computer. The executable was running before the computer was hibernated and it seems to have frozen not crashed after the computer was woken up. I am using Windows 7 and Labview 2009.
Thanks for your time.

What is the application doing? (if that even matters)
If it were performing a data-acquisition hardward process then that might matter..
I haven't experienced this problem.

Labview executable does not open excel...

i just compiled labview code into an executable and when i run the executable, it does not open an excel document like it is supposed to. it opens the excel program, but not the specific file stipulated in the code. the problem only exists on one of my computers. the "problem computer" is being set up for the first time to run labview executables.
thanks in advance for the help.
Erik

That is probably the reason. Microsoft is notorious for the way they change their activeX components between office versions.
At the minimum, you need to install the LabVIEW runtime engine on the other PC. It needs to be the same version as the version of LabVIEW you developed in. You can either search the NI website and download and install the run-time engine, or you can create an installer for your application from the development PC that will include the run-time engine.
You may need some other run-time engines such as VISA or DAQmx if your application is using any of those functions.

Labview executable spontaneously quits

Similar Messages

Maybe you are looking for