How to not overwrite an existing file using the "Save Report to File" vi?

[parkerfly]

When using the "Save Report to File" vi, it will overwrite an existing file with no way to report an error and stop the save if the file already exists.  Is there some way to see if a file exists before calling the save vi?  I'd like to set it up so that it checks to see if the filename exists.  If it does, it returns an error.  If it does not it proceeds with the save.

Thanks!

-Bill

[Matthew_Kelton]

Bill,

You didn't say which version of LV you're using, but in later versions of LabVIEW, there is an input Prompt to Replace?.  The default is False.  Wire a True to it and it will ask the user if you want to replace the file.  If the user cancels, you'll get an error.

It looks like older version automatically prompt the user and do not have the input.


Message Edited by Matthew Kelton on 02-19-2008 03:50 PM

[Dragon64]

In order to either read or write to a file, you must have a File Open vi first. I have LabView 5 (I expect all later versions have even more options and control), and the "Open/Create/Replace" vi has an option to "Create" only, if you use this option and file already exists, it will report you an error instead.

[parkerfly]

We are using labview 8.0, and it looks like it doesn't have that input yet - a snap of the context help for that vi is attached.  I've not seen this vi automatically prompt the user - are you talking about a different vi?

Using the Create option won't work for many of our situations.  We are writing tests in TestStand 3.5, and are going to be using the Microsoft Office toolkit as the means to generate reports for our tests using Excel.  Often we'll have a spreadsheet template that the script will open, so we'd want to save the template, once filled with the new data, to a different filename.  That's where I'd like it to be able to have some kind of error handling that can take care of a file that already exists...

Thanks,
-Bill

[Matthew_Kelton]

Sorry Bill, I assumed you were using LV's standard reports.

Which version of the toolkit do you have?  In v 1.1.2, If you open the VI, there actually is a control on the front panel with a boolean that controls overwriting that is not wired to the connector pane.  You can wire it up.  I would save a new copy in with your code, so if it moves between PCs, that you don't have to redo your work.

The other alternative is to use the File/Directory Info in the File I/O Palette under Advanced File Functions.  This VI will geenerate an error if the file does NOT exist.  So, if you get an error 7, then you know the file doesn't exist, and you can proceed.  If you don't get an error, then the file does exist and you don't write the file.

If you modify the report code, you will get an error 43 if the user hits cancel on the dialog of whether to replace the file.

What may be a better alternative to to modify your naming convention to ensure this can't happen.  TestStand timestamps the data file with the sequence name.  I typically use the Serial Number (or whatever unique identifiers there are for your UUT), followed by the date/time stamp.  This pretty much guarantees that you won't end up with duplicate filenames.

[tbob]

Modify the original Save Report to File.vi.  At the beginning of the vi, add Open/Create/Replace to see if the file exists (look at error out), then close the file if it exists.  If it exists, prompt the user to overwrite or replace or abort or whatever and use the result to select the proper constant (open, open or create, create or replace) and use this constant for the input to the Open/Create/Replace vi that is near the end of the Save Report to File vi.  The original code has Create or Replace as the input.  Your new selection should replace this constatn.  You can name this new vi something like Save Report to File with Options.vi

[parkerfly]

We've got version 1.1.1 of the toolkit.

Unfortunately modifying the vi would be a hard sell as this will be used by many different projects within our company.  I like your idea of the File/Directory Info vi.  I'll give that a try - thanks!!

Once I get this done, with as many different people using it there's a good chance people wouldn't follow any convention I suggest, and if I make it so it hard codes a unique filename, they'd make me change it so they can create their own filename.... 🙂

[parkerfly]

To use the File/Directory Info vi in TestStand I need to know where the vi is located on my hard drive.  I'm not having any luck finding it.  Is there a method of getting the path to where a particular vi is stored?
Thanks!

-Bill

[tbob]

Why are you trying to call this vi directly from TestStand?  You should write a vi that calls File/Directory Info, tests if the file exists, opens files, closes files, and calls SaveReport to File.  Then call your new vi from TestStand in one step.  Sounds like you are trying to use TestStand to do what Labview should do.  In Labview, all file utilities are directly accessible through the file functions palette.  You don't need to know where they reside.

[parkerfly]

I need to call it directly because with the policy our company has in place for our test systems it is difficult to get a new vi approved for release in the company.  It is much easier to get approved a custom step type with a "library" sequence file that has all the calls in it.  Our toolkit implementation consists of no new vi's, and 1 "library" sequence file containing all the code that the custom step types need to get to Word/Excel.  Unfortunately I don't make the policy for how we implement our test code - I just have to follow it.

So is there some way to find a vi?  I'm not having any luck finding this one.