04-30-2013 05:55 PM - edited 04-30-2013 05:56 PM
So I have this piece of code to save rows of data into a text file. The problem I'm having is that some times I am missing one of the data sets from the text file. It's always the same (first column) I say about .1% of the time.
Maybe it's just me but I really can't see why the first string would be missing. As far as I know the double going into Number to String can never be empty, right ? so the string shouldn't be empty either. I really don't see why or where the string goes missing. Maybe I'm not seeing something...
To clirify all the other data out of the concatenate string is there except the first string, where this string goes missing I really don't know. Any input is appreciated.
This is in LabVIEW 2010 by the way.
Here's how the data comes out on the file:
04-30-2013 09:49 PM
Hello JMotaB!
I'm trying to figure it out but I don't really know what to say.
Did you try to probe those wires and see the input? As you said, if you input isn't empty, so isn't your output (at least it shouldn't). So, try using probes to detect the location of your problem: Input or Output.
Regards!
05-01-2013 01:06 AM
Could you post the VI? One realllly outlandish guess, but you aren't setting the file position anywhere in parallel are you? The only place that file is accessed is shown here correct? The reference isn't split and being written to elsewhere?
05-01-2013 09:31 AM
Well it can be seen from this code snip that the problem is more than likely occuring outside of this loop. I can see two indications of this.
1: the last number written never changes within the loop and, when the error happens, the last number changes so the loop had to have quit and wrapped back around again.
2: Not only is the first number missing but the first comma also (second terminal).
Since we cannot see the rest of the code it is impossible to determine the cause. Please post more...
05-01-2013 09:56 AM
The code you are showing cannot cause your observed problem. We need to see the entire VI (not just a picture section).
(Also note that you could dramatically simplify all these duplicate primitives by building a 1D array and using "array to spreadsheet file using a comma as delimiter. Suddenly, there is 80% less code for the same task!)
05-01-2013 12:55 PM - edited 05-01-2013 12:57 PM
Thanks for all the responses guys. I really appreciate the help. Unfortunately I can't post all the code due to company security policies but what I can do (I believe) is post parts of it ;). This part of the software is basically a queue state machine that receives commands from another queue, this queue is self contained and nowhere else in the code is the file reference touched other than here. Also inside this state machine only the part you see on my pic is the one that touches the file once the reference is opened. I will post this queue, just give me a few minutes so I can "prepare it".
Meantime I found another instance where only the last part of the second data set (second column if you wish) are present on the file . What you guys think about that ?
05-01-2013 02:13 PM - edited 05-01-2013 02:25 PM
JMotaB
This is just a guess
IF it is not time critical in your code..
Try puttting a 1ms delay in the loop to give the write function more time to complete.
See if this apparently intermittent kind of problem dissapears.
edit: Guessing more about this.
Is at any time your array inputs to the for loop possible having a size of zero?
Sometimes when faced with nonsense like this I try to stand back and reconsider ALL the external effects that may be occuring during the time that
the code seems to be failing (here it appears to be failing in the write function but it is hard to tell what is really happening).
(Given no other info than your picture It looks like some kind of possible race condition related to the writing of data to disk.)
05-01-2013 02:43 PM - edited 05-01-2013 02:44 PM
Yeah I know is hard without the rest of the code, I'm working on it so I can post this queue.
I'm not sure why adding a delay should make a difference, this is pretty data flow dependent, the write to file function should not return until it's done.
Also, if the incoming arrays are empty (by the way these are arrays that are deconstructed from a 2D array so they should all be the same size) the while loop will not execute yes, but that's why I have shift registers to keep all the data intact.
Thanks
05-01-2013 03:47 PM - edited 05-01-2013 03:49 PM
So here's the queue, I had to make some changes to it so I could post it but nothing related to the file management.
Basically these are the commands I send to it during a test:
1) DCE.Initialize (only at application initialization)
2) DCE.Initialize.RawFile (this comes from a GUI queue)
3) DCE.Start.SaveData (from GUI queue)
4) DCE.Process.DataToFile (from a DAQ loop that is always running and passes the Raw Data cluster)
5) DCE.Stop.SaveData (from GUI queue)
6) DCE.Close.File (from GUI queue)
Notes:
- No other queues send messages to this queue other than the GUI and DAQ loop.
- I did monitor the queue and there is never a backup of unprocessed elements.
- Not sure if it matters but so far this has only happened when running as an executable.
- Like I mentioned before this only happens in about .1% of the data sets.
Thanks
05-01-2013 03:51 PM
If the data were just missing, you would still get a zero in the formatted output so that cannot be the problem.
I wonder if there is some race condition with the disk cache in a way that the file position is not updated correctly. Try to check your HD for errors. Also try to upgrade any drivers for your computer.
For debugging, try to add a flush file operation after the write. See if it makes a difference.