|
Re: Writing a 2D array to a .csv file inaccuracy
I like the attitude. Perhaps my description will help.
When operations take place in parallel and share data, one of the things you have to watch for is out-of-order access to the shared data. This can happen with a file, with memory, with a device like an oscilloscope, etc. When the order is not defined and is somewhat random we will often call it a race-condition. It is just a funny name for it.
The key to avoiding race conditions is to define the order of access of shared data. LabVIEW uses graphical wires as a special form of variable -- a form that is very useful with parallelism. A wire is like a temporary variable, but it has no name and is guaranteed to have only one writer, which goes first, and one or more readers guaranteed to go after the writer and guaranteed to get the same value as was written, no matter when it runs. It may not seem like much help, but these rules really help simplify.
It looks like you want the For loop to finish and then the file write to run. If you use local variables, the write code has no reason to wait and will run in parallel with the loop. If you use a wire for Write Text, the problem will probably go away. But Iteration # should probably be a wire too. The Iteration number that is being formatted inside the for loop can just be wired from the for -- i. I'm not sure if you really meant for it to the last loop iteration of the for loop or the while loop's iteration number. Either way, a wire is more clear what you meant and will be sequenced as intended.
Inside the for loop, the Data Flow subVI is called and the values are stored into the Data Controls in parallel with the values being read, charted, etc. Again, wires are almost certainly what you intended.
In summary, local variables are actually pretty rarely used. You typically want to use a wire instead.
Greg McKaskle
|