LabVIEW hangs while writing to unavailable network Drive

[Jaggs]

Hello,

I am trying to write data at the end of my test sequence run to a file and storing it on a network drive.

If there is a problem with the network drive (busy or disconnected), then my application hangs for around 10-15 secs before giving out error that the drive is unavailable.  This is causing the hardware to stop functioning which is dependent on my application.  Is there a easy way to check if my network is present and my drives are present?  I have tried using the file/directory info VI's present on the file I/O palette and they also cause the application to hang for 10-15 sec before giving out the error.

Thanks,

Jagan.

[Graziano]

Hi Jaggs,
   nice question!

   I think the problem is that is not only your LabView application which stops, but the Operating System which hangs, if Storage device access fails.  I experienced this problem under many OSs, Win, Linux, Dos-like...even RTOSes (try to access a corrupted Flash card in PharLap ETS for FieldPoint!).

   To check if drive is present, you can ping it... it's quite naive, but at least you avoid the "drive disconnected" problem... I think a ping shouldn't hang PC...

   What Hardware are you controlling? You know, some NI boards (many...) have onboard memory, and can sample independently of PC control....for a while, of course!

   I hope some guru will answer to your question (which I didn't answered, I know! ), because I'm interested too!

   Have a nice day!

graziano

[cmpowell]

Write the file locally and move it afterwards.  I know that seems elementary, but I agree the lag time is most likely due to the OS trying to find the network resource, are you using Windows?  How are you addressing the network drive \\10.10.x.x or \\serverx  or have you mapped the drive to a drive letter?  I'm not certain a ping will tell if the drive is available, the machine on the network could well be up and responding to pings but the share could still be in accessible, i.e. not logged in, file sharing is broke, etc...

[GuenterMueller]

I also use the strategy to first write a file to the local disk and move it later (when connected) to the target. This works reliable and I typically place the code that does the move in a low-priority VI.
Especially on RT targets, do not place too many files in one folder else you might face poor disk performance.
Furthermore you should consider having an algorithm that deletes old files to prevent "disk overflow" in case of long periods of "disconnection".
Regards, Guenter

[Jaggs]

I agree that the lag is mostly a windows issue. I am having my drives mapped. Right now we are writing the files locally and using a VB application to write them to network, whenever it is available.

I will try to use the ping command and see if it improves.  Thanks for your input.

[cmpowell]

For what it is worth, how you map your drive's matters.  If you use a machine name like \\serverx, you are dependant on a name server, master browser or you local cache to resolve that name into an IP (which your machine understands)  If you map a share something like \\10.10.x.x\sharepoint\ then you don't need the external machine to do the resolution, i.e. faster performance.

Good Luck

later
cp

[Jaggs]

I think ping will work! However, the problem I am facing right now is obtaining the names of the computer to which the network drives are mapped. For example if a network drive is mapped as I:/ then to ping the computer which has the drive, I need to know its name.

Is there a dos command which can give the name from the network drive letter?

[GuenterMueller]

As cp said, it depends on the way you map a share.
You can use a script to map a network drive by specifying an IP address and the name of the share, like
net use I: \\192.168.0.1\NameOfTheSharedFolder

This way you don't need any computer name. In your application you can use a ping to verify that the computer is available on the network.

In LabVIEW you should be able to establish a TCP connection to that computer by specifying the port 445 (I think this one is used for Windows shares ?). That way, you check if the computer is currently accessable.
If you can open the connection, you should able to transmit files. (Do not forget to close the "test connection".)
Regards, Guenter