LabVIEW temporary directory

[mrbean]

I am using LabVIEW's Temporary Directory (Tools::Options::Paths) to test an external SCSI drive.  When the SCSI is powered on, it is mapped to the 'G' drive.  My SCSI test uses the temporary directory control (which points to the G drive) to verify the presence of a file that only exists there, then it opens/creates a new file, writes/closes opens/reads, etc.  Anyway, if the SCSI is on and then I bring up LabVIEW and run my test, everything works great.  If I then turn off the SCSI the test fails as expected.  However, if I then turn on the SCSI with LabVIEW still running, then the problems begin.  Here's what happens....

At LabVIEW, if you look at the Tools::Options::Paths, the temporary directory is reset to C:\Documents and Settings ...., which is fine when the SCSI is down, but it doesn't go back to G:\Data... UNTIL I exit LabVIEW and restart it.  This is not good for my test.

Is there a way to 'touch' or somehow tell LabVIEW to try again to re-establish its directories?  If there is an alternative to the way I'm testing the SCSI, I'd be open to suggestions.

[altenbach]

In my opinion, the "temporary folder" path constant is only appropriate if you don't care where it is located. In your case, you should probably use direct paths that can be tested and calculated at runtime.

[Ray.R]

I agree with Altenbach.  You should check the status of G-drive as you run the test.  If it's a series of tests, then check at the beginning of each series.

Also, by building dynamic paths, you may not have to worry about overwriting older test files, but especially not reading previous results. Example, the test sw is ungracefully shut down and does not go into a "clean up" routine.

RayR

[mrbean]

This test merely verifies that this external drive is alive/on, and that we can write/read to/from it.  I wanted to avoid 'hard coding' a path in my VI so as to make the code more robust.  The use of the Temporary control helped me do that.  However, if there is no easy way (without exiting/restarting LabVIEW), then I'll probably have to hard code the path.

[Jarrod_S.]

You could avoid hard-coding paths such as a G: drive into your application by saving them manually in an ini file that your app reads on startup. That would mean your code is not tied down to one specific location, users can change the drive mapping easily, and you don't have to rely on LabVIEW to detect or re-detect your drive settings.

[mrbean]

Good idea.  Is there a preferred method of doing this.  Is there a user.ini or a specific location where this type of information is stored?

[Jarrod_S.]

You could use the Configuration File IO VIs in the File IO functions palette to read and write your custom settings for this. These functions are really pretty easy to get started with. Popular convention seems to be to expect a configuration file to be in the same directory as the application and generally have the same name, but with an *.ini extension. This would be up to you, of course.

One thing to note is that if you build this application into an executable, LabVIEW will automatically build an .ini file for you with your VI Server settings and other such things, so if you wanted you could just expand that ini file to include your settings as well.

Message Edited by Jarrod S. on 02-12-2007 04:38 PM