Timing Issue when compiled as stand-alone program

[eustis74]

Greetings,

   I have built a program which generates an input for a fortran program.  I have a number of input panels, some of which have conditional case structure, formula nodes, etc.  Essentially, I am generating a string of text and integers, with each row representing a specific card that is handed to the program.

   When I run it in LabView, it works fine and I am able to generate the file, execute the fortran program, read and convert the output, and display it graphically.  However, when it is built into a stand-alone version, the timing gets thrown off.  I have isolated the problem, and what is occuring is that the string is being passed to the next frame in my sequencial frame series before all values have reached the "build text" vi.  So, I end up with a generated input file that has gaps in it.

   I have tried to configure a while loop with no success, implemented wait commands at various points, and attempted to use rendevous but I really don't understand the setup for that.  I will post my vi here as well as the correct and faulty files generated by the LabView version and the stand-alone version.

   I am running LabView 2010 (Mac).

   I would greatly appreciate any help.

Regards,

Soren

[altenbach]

Nobody here is probably willing to debug a program that covers 50 screens.

I am on a laptop so there is no way to efficiently navigate your monster diagram. In any case, you have some very strange code constructs (concatenating a scalar string is a NOOP, so why do you do it? a FOR loop with the iteration fixed at 1 does not do anything useful).

There are definitely race conditions. For example in the second big frame you are writing to string indicators and at the same time reading from local variables of the same indicators. Since there is no way to tell in what order these things happen you get inconsistent results.

Since a built applications disables debugging, things probably execute in a different order. None are probably as expected.

Another big mistake is to carry file paths in strings instead of path datatypes. This makes everything very OS specific and I would never be able to run any of this under windows anyway.

I give up!!!

[eustis74]

I appreciate it is a large screen.  I do apologize.  It was meant to be a small vi, but it got huge fast.  The for loop at 1 was for debugging.  It was requiring 2 iterations for it to run properly at one time. 

I just needed some help, so thanks for what help you did give. 

[jtagg]

Hi eustis,

I agree that there are many potential problems in the code.

It seems that most of it is run in parallel and then is all put together into one large string.

I would consider doing things sequentially to get rid of the race conditions (unless you have a very specific reason why it should all run parallel as fast as it can).

Some kind of simplified state machine should do the trick. I attached a small example of what I mean.

Best regards,