You need to learn more about how LabVIEW works in terms of dataflow.
Your two TCP/IP reads occur together in a flat sequence structure. Your code can't continue to the next frame until both of those functions have completed execution. You have other pieces of code such as writing an empty string to numerous terminals and local variables just sitting out in space. This would lead to a race condition because there is no dependency on when those bits of code execute. The local variable could be cleared first and the terminal written to later in a loop iteration, or vice versa.
<p> </p>You have a couple other oddities with so many strings that seem to have similar names and some doing the same things and some not. Such as 3rd Party Device and 3rd party box. What are the purposes of each of those. Third party device only ever has an empty string written to it, while 3rd party box is the one you seem to use for putting into an array. Also, there is no need to write an empty string to the terminal 3rd Party Device and to its local variable at the same time.
<p> </p>If you want the two TCP reads to be truly independent, then you need to put them in separate while loops. Then look at the structures in the synchronization palette such as rendezvous', semaphores, queues and/or notifiers to control data flow and pass information between the separate loops. Eliminate as many local variables as you can and use wires to flow the data from one part of your code in a while loop to another. Your logic for comparing the two strings to each other to determine which came first makes no sense to me.
And having an infinite timeout on you TCP read functions is a bad idea. If network communication breaks down, your program will freeze forever on those TCP reads.
Also look at the producer/consumer design pattern as a way to use queues to have separate loops communicate with each other such as loop for each TCP read communicating with a loop to write the data to the file.
Message Edited by Ravens Fan on 11-22-2008 12:50 AM
