Writing data to file location after a LAN goes down

[MrB.]

I am having an issue where my LAN goes down during my testing sequence. I usually run tests for long periods of time and when the LAN drops out, the vi stops writing data to the file, even when the LAN returns. It doesn;t show an error from the "Write File" function.

I tried monitoring the "Write File" function for an error when the LAN is down. It doesn't show me any error, it just doesn't write the data.

It was recommened that I try to see if using the "Open File" function to open an already open file (w/ valid refnum) will generate an error. But, if the LAN has disconnected, the "Open File" function will not generate an error, showing that the "refnum" is still valid.

That didn't work either.

Does anyone know how I can tell if the LAN as disconnected then reconnected itself?

[Sima]

Are you just storing your file in a remote location, or is there some processing being done there? What's on the other side of the LAN and how does it fit into your application?

Perhaps you could use the TCP functions to let you know if you still have a connection.

I guess it depends on your setup, but one thing we do to check if our network communication is still up, is toggle a bit back and forth between the computers. Send a bit to the remote system. The remote system will invert it and send it back. The PC will read that bit and send it back as is, and so on. If the value you are reading on your PC doesn't change in a certain timeout value, it means something's up - or down 🙂

[MrB.]

Actually, the remote location is a share drive on my companies network. We only use it store the data files, classified by product names.

I have been playing around with the File functions. I noticed that the "Write File" function held some of my data and still wrote it even though the LAN was disconnected periodically throughout execution. I did not use the "Flush" function.

Any idea how much data the "Write File" function buffer can hold?

[Sima]

Ah. Wouldn't it be better to store the file locally, and copy/FTP it over after the test is done? At least you'll be sure that the data isn't lost.

[MrB.]

Yeah, me and the other grunt, here, have been doing that, lately. It's the Sr. Principal Engineer that is complaining about not having the data at his PC upstairs, whenever he wants it.

Like I said, the tests can last months at a time.

I seem to be able to lose the LAN connection for periods of time and still get the data written, using only the "Write File" function. But, if I incorporate any "File Info" or "Flush" Functions, I get an error and lose the data. So, it looks like the only thing that can restrict me, is the size of the buffer.

[smercurio_fc]

Windows caches data writes if you're trying to write to a shared drive that suddenly disappears. We had the same thing happen with a test system where the engineers wanted to save the data directly on the server. Periodically you would get lost data. Regardless of what's happening with the File I/O functions, it is not good practice to have the data being saved to a shared drive to be the sole means of saving the data. A far better approach is to save the data locally to the hard drive and then periodically copy the data over to the shared drive. The latter can be done by a simple batch file that is run via the Windows Task Scheduler. You can set the Scheduler up to simply copy the data every hour, or whatever frequency is appropriate. You can also simply share the local folder and then the engineer can connect to it anytime he wants (as long as the network is up, that is).

[smercurio_fc]

I should add that this test system wasn't even running LabVIEW - it was running Agilent's TestExecSL, so this is definitely a Windows thing, and not a LabVIEW issue.

[MrB.]

My only concern with copying the data periodically, is that the copy might take a significant amount of time. If it is still copying when the file is trying to be written to, then there could be a conflict issue. Also, our tests rely on specific dwell times and ramp rates involving temperature. Adding a dely to copy the file, will mess up the dwells and ramps.

I think the best solution at this point in time is to save to the hard drive and copy the files over at the end of testing.

[Sima]

Would it add too much overhead to write snapshots of the data to a second file that can be quickly copied and viewed across the LAN?

[Khalid]

I have done something similar to what Sima suggested -- write to a temp file, and every so often, say 10 seconds, dump this into another "permanent" file (actually, I just change the extension and close this file, and open a new temp file).  And while the system is writing to the temp file, I FTP the other files. 

On the receiving end, I open the files and group the data back. 

Hope this gives you some ideas. 

-Khalid