long timeout checking for file/folder existence

[RobBoyer]

Hello all. Currently, looking to see if there is a native LabVIEW solution to resolve an issue regarding excessively long timeouts when checking if a file or folder is accessible.

I have tried a few different ways in LabVIEW (7.0) to check if a file/folder exists on my company's network - currently, using the File Info VI - but every way I've tried is susceptable to an extremely long timeout when the file or folder happens to be on a server that is down.  (And yes, servers being down are regular occurrences for us. 😕 )

In any case, I was hoping to find a solution to provide some timeout input so that I could specify to check for a maximum of say, 20 seconds for example.  But the closer I look, the more likely it seems this delay has its roots in the underlying Windows API calls being made.  I have considered the possibility of writing a code module in another language that supports multithreading, but would prefer to avoid adding any more requirements to the target machines.  (Even VC++ requires some run-time libraries.)  And to my knowledge, LabVIEW doesn't support explicit multithreading... please correct me if I'm wrong.

Anyway, any ideas will be greatly appreciated.

[MikeS81]

Hi,

I think one solution can be to try to connect to the server where you want to search for the file or folder. With TCP/IP vi´s you can set the timeout to a value you want.

Mike

[Ben]

Rob wrote "And to my knowledge, LabVIEW doesn't support explicit multithreading... please correct me if I'm wrong."

LabVIEW has supported multithreading since LabVIEW 5.1 and maybe earlier. It has also supported hyperthreading ever since that hardware was available.

One of the simplest solutions I have read for check if a remote machine is up is to just do a ping with timeout and check if it answers up before attempting a transaction.

Ben

[smercurio_fc]

Equivalent to a ping is to attempt a connection using the TCP/IP functions (Open Connection), with an appropriate timeout. If you get an error, the server is down.

[RobBoyer]

Thanks for the extremely quick response guys.

That is a good point, but I'm not sure it will completely resolve my problem.  The issue that brought this to my attention actually occurred when the server was "down" only in the sense that the files became inaccessible due to issues on the server's hard drive.  The server was actually running and probably would have responded to a "ping" extremely quickly.  (Sorry for the lack of clarity on that point.)  In any case, maybe adding a ping check before attempting to access the files would reduce delay most of the time - nevertheless, unless I can't find a solution that woudl definitely fix all scenarios, I'd prefer to avoid that approach.  (I think I will be able to resolve this in C++ fairly easily.)

Regarding the "multi-threading" capabilities of LabVIEW, I guess I should have been more explicit.  Clearly LabVIEW is capable of running code on multiple threads.  But my guess is that there is no way (at least not with reasonable elegance) to explicitly run a chunk of code on another thread, and then kill that thread from the main thread when and if necessary.  My point is that in C++, I can run the file/folder access check on a child thread, and then kill it if it takes too long (eg: after the specified timeout).  If this sort of functionality can actually be acheived in LabVIEW please let me know.  I'd be highly interested.  I should point out though that even if LabVIEW is somehow capable of it, I wouldn't really trust LabVIEW 7.0.  I had problems with LabVIEW crashing when I moved to a dual-processor machine and the ultimate solution provided by NI was (and I hope you are sitting down) - change the affinity on the LabVIEW process to only run on one processor!  Now THAT is kludginess writ large.

Cheers, Rob

[pincpanter]

IF you can afford to install on the server (which not very likely) a small TCP application - not necessarily a LV app -, it could check the existence of the file in a short time. And you would also be mastering the applications timeouts.

[tst]

---

RobBoyer wrote:

But my guess is that there is no way (at least not with reasonable elegance) to explicitly run a chunk of code on another thread, and then kill that thread from the main thread when and if necessary.  My point is that in C++, I can run the file/folder access check on a child thread, and then kill it if it takes too long (eg: after the specified timeout). 

---

All you need to do is launch a dynamic reentrant VI and communicate with it using a notifier. If the notifier times out, the dynamic VI did not respond. You don't even need to kill it, because it will be disposed of automatically once it stops running and all references to it are closed.

[RobBoyer]

Hi again,

Thanks for the response guys.  Paolo - that is a good idea, but like you mentioned, I would need to be allowed to install a service on the server machine, which I don't have the permission to do.  I'm lucky if they let me add requirements to the test machines. 🙂

tst - If what you are suggesting will work with LabVIEW 7.0, that would be ideal for me.  I don't suppose you have any code (for 7.0) that you could post to demonstrate?  I'm not that well versed with "dynamic" VIs...  Do you mean running the VI by reference?  If so, I'm not sure how that would alleviate the central problem.  I would think that however the VI is run, it would be executed in process and the calling VI would block until it returns...  I'm hoping that you're right, but I guess I'm not that fluent with LabVIEW.  Thanks for any further expanation you can provide.

[RobBoyer]

A quick update:

I have tried running the file/folder accessibility function in a reentrant VI and calling it using the Run VI function of the VI Server with "Wait until done" set to false.  I figured that maybe that would put that process in a separate thread and allow the rest of the code to continue.  No luck - as soon as the File/Directory Info VI begins executing, the entire LabVIEW process hangs until it comes back.  So I'm guessing that if the VI being called from the Run VI node happens to hang (due to a network delay in my case), all of LabVIEW hangs until it comes back.  Maybe this was fixed in a later version than 7.0?  I know there were definitely other "improvements" (read: bug fixes) that were made between 7.0 and 7.1.

[tst]

I know that the UI thread and the root loop block some things, but I don't see why that should apply to the File Info primitive. In the worst case scenario, you can launch another application to do this, but I don't think that would be necessary. At least in 8.5, the attached piece of code works fine even when the network path is not accessible. The i indicator is updated regularly and the primitive throws an error after about 15-20 seconds. As you can see, this doesn't even require a separate VI. I should be able to test this on 7.0 tomorrow.

Message Edited by tst on 01-17-2008 09:49 PM