Labview project functions differently when compiled

[dhowland]

I have a medium sized labview project that is causing me trouble.  It will work properly when I run in development mode, and it will compile with no problems, but when I run the executable it no longer functions the same.  It seems that large portions of the code just don't run.  I have made sure that all VIs are included in the build.  I have no way to debug it in application mode, so how am I supposed to fix this problem?  Any suggestions would be appreciated.  I'm running Labveiw 8.5.  Thanks,

-d

[shb]

Hi dhowland,

I think some more information could help.

Does the executable run or is there a broken arrow? Is there an error message?

Why is it not possible to debug? When you enable debugging while building the executable and run it on the development computer, you can connect from LabVIEW, even if there is a firewall.

Do you use special things in your Project as LVOOP, .NET or a dll?

The discussion about a non running executable from me is here: http://forums.ni.com/ni/board/message?board.id=170&message.id=297545

This is in LabVIEW 8.2.1, but maybe it helps.

Greetings,

shb

[GerdW]

Hi -d,

you don't give a lot of information...

A common problem is the change of "path to vi" as the executable adds another levekl of folder to the path. Did you check this?

To debug an exe you can:
-use the built in debugging of executables in LV8.5
-use some extensive logging in your exe: write every step/action to a logfile
-enable some more frontpanels and show error clusters! (maybe driven by a "Debug"-Key in the executables ini-file?!)

[dhowland]

The executable runs just fine, no errors or anything like that.  It simply refuses to talk over one of my 1553 buses when I compile it, when the same code works fine otherwise.  I don't believe that the location of the VIs should be a problem, because I don't have any dynamic VIs and I am sure to include all of them in the build.   I also don't have any linked DLLs or exotic dependencies, this is pretty straightforward.

I am trying to express my frustration that the same code can work differently depending on how it is deployed.  I would expect issues of this sort if I had just switched from, say, gcc 2.95 to visual studio 2005, except in this case all the tools are Labview.

[GerdW]

Hi -d,

"1553 buses" - is this something like described here?

How are you talking with those buses? Can you show a vi or atleast a pic of those non-working vis?

I understand your frustration, but your error description is rather vague... "The executable doesn't run..." only leaves us wildly guessing!

[Tohatsu]

I'm having similar problems.

Everything works 100% in the devel. environment, but when I build it, I can no longer browse for any FieldPoint devices using the drop-down list and selecting browse, "component not installed, try reinstalling it" I get. Oh, and yes, I tried reinstalling it and upgrading the FP driver software.

[Joseph_Loo]

When you say the executable does not work are you running on the target machine or on the development machine? This is critical in determineing the problem for the Fieldpoint device. One of the things I do, is to run the executable on the development machine. If it does not work then your Max for the fieldpoint setup is not properly setup. You will need to fix that issue.

As for the 1553, I think you should try executing the executable on the development machine.

[dhowland]

Yes, these are MIL-STD-1553 busses.  The device has two, and one refuses to talk when the project is compiled.  I run the executable on the exact same machine that I develop on.

[Tohatsu]

It's beeing run on my development machine.

I can select the "last used" device (the one I last used before the build) from the dropdown menu, but I cannot select "browse".  http://forums.ni.com/attachments/ni/170/311995/1/prog.png

If I select the "last used" one, everything works...

Here's how it looks in the devel. env.

http://forums.ni.com/attachments/ni/170/311996/2/browse.png

Thanx,

Anders

[shb]

Hi dhowland,

what does refuse to talk mean? Is there no error message when the communication fails?

Do you work with automatic error handling? This does not work in an executable. Program the error handling yourself.

Greetings,

shb

Source, Error handling in Executable:

"- Incorporate error handling into the VIs of the application because LabVIEW does not display automatic error handling dialog boxes in the LabVIEW Run-Time Engine."

http://zone.ni.com/reference/en-XX/help/371361D-01/lvhowto/caveats_apps_dlls/

Message Edited by shb on 04-03-2008 01:34 PM