Can't close textfile after whrite data

[johntrich1971]

---

@ThomasThePommes wrote:

Hey

I have 3 interactions with the textfile within my program. The first time is a Create Textfile step. This isn't really necessary but since I create the filename from a timestamp + sensor number combination it felt right to do this. 

This is the second step of my statemachine. The first step is just a while loop that stops if someone push the start button. After that the statemachine starts.

Create Textfile

This is my standard subVI to add a new line of measurement data to the textfile. I call it every time if I want to write new data to the textfile.

WriteData

This is the last time I do something with the textfile. After I got all I needed, I calculate the data and write the results at the top of my file.

Create Header

After this step, the statemachine jumps back into the first step (while loop). If someone press the start button the while loop stops and the statemachine starts again. It creates a new textfile from a timestamp + sensor number, whrite measurement data and the results and than jumps back to the start.

I hope that helps to understand my problem better.

---

Why are you opening/closing the file so much? I've not seen your state machine as you've still not included your code (which would make troubleshooting a lot simpler) but I would open the file, do all of the writing that I'm going to do, and then close the file. You could use an Action Engine as JÞB suggested or pass the reference through the states via a shift register. JÞB is likely correct that buffering is the issue, but that would not be a problem if you are only opening/closing the file once.

[James_W]

Well I know close file will close the reference, but if the reference is corrupt from the open, we'll get some interesting behaviour.

- We also don't know if the "subVI" is re-entrant and running in parallel (which could make for interesting behaviour)

I think I've might have seen this sort of behaviour before thinking about it ... Windows reserves the file for an app that keeps opening and closing it (even after it's closed).

Instead of passing the filename, open the file once and pass the refence around.. close when complete and then it should be free. (assuming not.

The "standard subVI" could be massively improved (you don't need to read the file). You want to user "Set file position" to End instead of reading the file. It's much faster for large data sets.

James

[johntrich1971]

---

@James_W wrote:

---

@RTSLVU wrote:

Post ALL of your code NOT pictures of code fragments.

Simply attach the entire VI to your post. If it needs a lot of Sub-vi's then Zip them together and attach the zip file.

---

Did you not read the first post???

---

I don't understand your response, @James_W. @RTSLVU asked to see the code which would be beneficial to see the full picture and offer recommendations on the best way to fix the code. The first post did not include the code. In this case I think that we can make a pretty good guess at the problem and solution, but even at that having the code makes showing what to do easier and assures that there aren't things that are missed because the OP didn't realize it was related.

[James_W]

@johntrich
having remote access to a machine does not always guarantee being able to move files on/off the machine. In this case the OP said they were unable to post code as it was on a remote machine - so I'm assuming they can't grab the files back to post otherwise they would as they've already indicated a knowledge of forum etiquette and expectations here.

James

[JÞB]

Ummm, hey guys.  TtheP hasn't even logged in since five minutes after I posted the tidbit about wiring true to the disable Buffering input.  I doubt we will see him again.

I did come back and explain why you would want to use that feature hopefully closing the loop for future readers.

And yes, I believe the AE would have allowed the ref to release without waiting on Windows (Or, at least required only 1 place to edit to disable buffering)  Kudos if you try it and post results. 

If we don't see the OP in a week or so after the "Did your thread get solved?" Email goes out I'll stick a messy mark on it.  (Yeah, some of us have elevated mark solution power)

[johntrich1971]

---

@James_W wrote:

@johntrich
having remote access to a machine does not always guarantee being able to move files on/off the machine. In this case the OP said they were unable to post code as it was on a remote machine - so I'm assuming they can't grab the files back to post otherwise they would as they've already indicated a knowledge of forum etiquette and expectations here.

James

---

Where did the OP say that they were unable to post code as it was on a remote machine? I do understand that this is sometimes (often?) the case, but this poster did not say this (I went back to double check that I hadn't missed that). In any event the OP appears to have gotten the solution.