I have a program that loses functionality when converted to .exe.

[usedtobe]

Sorry in advance for such a long post

I inherited a LV program from a guy that left our company.  I know a little bit about LV, but I definitely would not consider myself an expert.  When the program originator left, he told me that he was unable to get the program to function as an .exe and had moved on to different projects. 

I am trying to convert the program to an .exe for obvious reasons.  Unfortunately, I am having some issues.  The program runs without any errors as a .vi and as an .exe.  The .exe version skips some steps when running.  There are two main points in the program where I see this occurring.  There might be more things being left out, but I haven't noticed them yet. 

The first is that the program is reading information from a piece of test equipment and is supposed to wait until the information meets a set point before proceeding.  The .exe proceeds to the next step whether or not the set point is met. 

The second is at the end of execution, the program is supposed to write data to an MS Excel file.  This also never occurs.

I am running LV 8.0, and don't want to update because I can't risk losing any functionality of the original .vi since it is used frequently and a lot of people are depending on the information it provides.  Like I said, I am a bit of a LV newbie, and don't want to screw anything up.

If someone could tell me what is occurring and how to fix it that would be great.  But I would also appreciate tips on how to troubleshoot it.

[PJS]

The most obvious thing to me, is that an error is being generated that is causing things not to run.
Does this inherited VI display errors to the user?
If not, you may reconsider coding the VI to trap the error and display the message.  this may involve a lot of rework.  Short of that, in the vi that is suppose to wait for the set point.  Put an error trap there to display any error messages.  This will help point to the source of the issue. 
Short of that, maybe posting some or all of the code would be useful for us to help take a look at it.

[GerdW]

Hi tobe,

atleast for filewriting one problem is common and often asked for in the forum:
when creating an exe the 'current vi path' is changing because the exe itself is added to the path (changing from c:\example.vi to c:\example.exe\example.vi). So be careful when building paths in your vi!

[TCPlomp]

LV 8 has the option to debug a compiled exe, have a look at that. Make sure you have a way to open the BD of the VIs you want to debug (eg. have the standard menu)

Ton

[Wiebe@CARYA]

About excel not working...


If you use the report generation toolkit, you need to include some excel sub vis in your exe. The details are here:


http://digital.ni.com/public.nsf/allkb/C38CE3F30542D65B86256F0E00740DD8


You can also copy the refered subvi's to a directory under the exe's root.


Regards,


Wiebe.

[DFGray]

There are usually three main reasons VIs stop working when converted to an EXE, two of which have been already mentioned.

1. The EXE distribution is missing some subVIs.  This is usually caused by vi.lib subVIs.  If you plan to only run the EXE on a system with only a LV run-time engine, it is essential that you include all subVIs in your distribution, including those from vi.lib.  When you do this, make sure the VI namespace changes.  Either change the actual VI names or put them in a library.  That way you will avoid future namespace and crosslinking issues.
   
2. The EXE contains paths which are now incorrect.  When opening VIs by reference, you should always have some dynamic mechanism of determining where they are.  My favorite is to include a simple VI in the same directory which returns its path.  Use this path and the name of the VI you wish to call dynamically to construct a new path.  In your build, make sure the two VIs stay together.  Changes in the base path will then not result in errors at run time.  Avoid the use of hard-coded absolute paths if possible.
   
3. The EXE contains methods which are not valid in a run-time engine.  This usually only happens to advanced users doing esoteric things.  But something simple, like trying to set the caption on a control which does not have one, can also cause problems.  In the development environment, a caption would be created and the set.  The run-time engine cannot change VIs, so an error results.

One more debugging trick is to create a tiny logging VI which you sprinkle liberally all over your code.  In LV8.0, you can conditionally compile it in and out of existence, giving you a normal and debug version of your code.  Possibilities for the logger include writing data to disk, writing to a named queue (which is read and displayed elsewhere), using library calls to Windows DLLs to generate Windows messages (which are read and displayed using standard debugging tools such as DebugView), or posting into an action-engine style logging VI.

Good luck!