long timeout checking for file/folder existence

[RobBoyer]

Tst- I just tried the code in the png file in LabVIEW 7.0, and (at least with the version of the File/Directory Info VI that comes with LabVIEW 7.0) it doesn't behave in the same way.  Instead, the VI hangs until the File Info VI completes, and then the numeric indicator begins incrementing.  It sounds like if my company were ready to upgrade to LabVIEW 8.5 (which they're unfortunately not), this could probably be done like you suggested.  In the meantime, I'll throw together a DLL to do the dirty work and created a wrapper VI for it.

If anyone's interested, I can attach the files, just let me know.  It should be a decent work-around for those of us stuck in 7.0 land.

[TCPlomp]

Hi,

this should work:


You should load the VI dynamically and run it while setting the 'Wait untill done' to false.
In that case you could run the VI after you sent the path notification from the main VI.

Ton


Message Edited by TonP on 01-17-2008 09:47 PM

[RobBoyer]

Hi TonP,

Thanks for the response, but this doesn't appear to resolve the issue in LabVIEW 7.0.  The trouble is that the File Info VI block the entire LabVIEW process while it waits for a response from the network.  So while File Info runs, neither the subVI nor the calling VI can execute.  (I just tested it out, and this behavior seems to occurs even if the subVI is executed by a call to "Run VI" configured to not wait for the VI to complete.)  According to tst, it sounds like sometimes between LabVIEW 7.0 and 8.5 some undesirable blocking was fixed, but upgrading LabVIEW isn't an option for me right now.  (Not enough time for regression testing, etc.)

If you can get this to work appropriately, let me know.  I am by no means a LabVIEW guru.

Thanks, -Rob

[RobBoyer]

OK, I discovered the source of LabVIEW non-responsiveness on my machine - I have LabVIEW configured to run without multiple threads.  I imagine that the solution proposed by tst/TonP would work if LabVIEW was configured to run using multiple threads.  (I tried out a little test with "Run VI" and it now behaves as expected.)

Alas, I don't think I can change that setting...  Our system was plagued by intermittent LabVIEW runtime crashes (only on machines with more than one processor) and this behavior stopped when we discovered we could force LabVIEW to run on one thread.  Since then, NI proposed that we force LabVIEW's affinity to run on only one processor - maybe we could let LabVIEW run on multiple threads as long as it is forced on one processor.  But we haven't tested, and right now would be a very bad time for us to try it out unfortunately.

Anyway, thanks everyone for the ideas!  I'm sure I'll put them to use at some point.

Cheers, -Rob