Un-compiled runs well, compiled code fails

[mnadams]

I'm running LabView 7.1, controlling a Chatillon test stand with RS232 Ascii transfer from a PC running windows 2000. A version of this code has been running for years. Attempting to upgrade the routine required changes. Now, the new code runs well with no errors uncompiled, but compiled, it fails. And since it's a controlled process, it must run compiled. Sometimes the compiled program just stalls at the switch between sub vis, and sometimes does only a portion of what the subroutine calls for but continues. It will do this reliably wrong. All the code was written with the same version of LabView. 

 Since it works reliably un-compiled, how do you troubleshoot?

[RavensFan]

What kind of errors are your getting?  Information such as error codes or messages can go along way for anyone to be able to help you.

What do you mean by upgrade?  Are you upgrading to a newer version of LabVIEW?  Or are you trying to improve your code, but still using LV 7.1?

[mnadams]

I get no error codes. The program simply stalls or skips portions (or perhaps doesn't output things it does when uncompiled so actions don't happen). By upgade I mean an improvement of the process, not an upgrade of LabView (though that would be nice, it's not in the budget at present). The place in the program it stalls does seem to be affected by how the code is written, but I have seen only one message when running it compiled: in simplified names it says: Main vi stopped at node 08 of sub2 vi. The program then proceeds through and finishes, skipping only a portion of sub2. Odd thing is that sub2 works correctly when called again later.

[Yamaeda]

Sounds like some race condition to me. Is the code using alot of Local Variables?

/Y

[Coq_Rouge]

Can you define what you mean by uncompiled, and compiled code? Do you mean Labview code run inside Labview (uncompiled) and compiled code as running as stand alone code inh exe file.

[Michael.Proctor]

seems to me you might have some remotely calling vi, ie vi that are called using open vi reference...

or using some other method

if you do not link these vis in ie add them to the source window in the Build application

then the compiler does know it should link them into the compiled code.

michael

[mnadams]

Compiled? I'm using the term too loosely. I'm using the "Build Application" function to create a standalone exe file.

To the previous question about lots of variables, perhaps. I define about 17 positions for each of four variations. In order to keep the program in step with the hardware status, I compare actual position with the requested position and only when one is no longer larger or smaller (depending on direction of movement) a True statement is output that lets the loop step forward. The transition from one sub vi going down to another going up is the point at which it fails in the .exe file.

zip file attached of full program. Won't run to completion with the hardware.

[mnadams]

I'll go look at "linking" them. All are in the same folder and I have run the program from a cd with only the known files in one folder and no LabView on the machine. Still runs fine "un-built".

Typo on my last entry regarding attached files. It should read:  The program will not run to completion without the hardware to send position feedback.

[Coq_Rouge]

As I can see you use a lot of visa open/close operations that are not needed. And that may veru well  cause your problems. Open it ONCE like you do in frame 0 then do not do ANY open or close before your program ends in frame 4.  

[Yamaeda]

I notice your LabVIew Serial 3.vi has no wire through if Read is false, which'll clear any error, but more importantly Drops the Visa resource! That might well be a reason.

Your dialogs are perfect for a simple event structure.

The initial nested case is horrible! Simply wire the Response wire and have a case for each number.

Since the Visa isn't used in frame 1 or 2, move it to 3 and you can avoid the border wiring.

You seriously need to look at your Open and Close visa's, they're happening all over the place and you start off in #1 by writing to the com port without opening it.

/Y