I am having trouble deleting files and folders after creating in the same .VI

[DanielAllis]

I have a larger .VI that runs an automated balancing routine for a large rotating mass.  The test needs to create some folders and files so that as the rest is run multiple times, there is a way to track how units did under test and when they were tested.

The attached .VI is only the portion of the code that creates the files and folders, waits for user input, and then deletes them if the test is cancelled before data is collected.  There are other elements, but they are irrelevant given that I can't even get the stripped down code to work.  I have checked the permissions on the deepest file (within both folders) and I am unable to get 777(oct) permissions on this file which could be the only problem I have.  Does anyone have any suggestions?

[altenbach]

Your code suffers from localitis and sequenceitis, so it's a bit hard to see what's happening. 😉

You are trying to delete the folder instead of the file and later it's parent folder if not empty. Since the first folder is not empty (you just created a file in it!), you probably would need to wire a true to the "entire hierarchy?" input to clean it out.

[tst]

OpenG also has a recursive delete VI in its file package which changes the files and directories permissions to make sure that you can delete them.

[DanielAllis]

DOH!  It's always something stupid when my stuff doesn't work.  I actually had three separate T/F constants set incorrectly that all piled up to make the thing fail.  Now it works.  Every time I try to be absolutely sure I have things straight before asking for help, it's something silly like that.

Since I've never attended a formal software course, nor specific LabVIEW training of note, I'll gladly take the constructive criticism about local variable and sequence use, but only if you can make some general corrective comments .  I've always just used the sequences to save space (by the time I am done with a complicated control or test algorithm, I can usually fill 3-4 monitors worth of desktop).  Are there any good tutorials that focus on optimal labview coding practices?

Thanks for the help.

[altenbach]

Here are a couple of things:

Frame 0: the pane properties are saved with the file, so once they are set you never need to set them again. Delete the property node and associated constants.

Frame 1:

• Shouldn't "Serial#" be a control (and an integer)? You do a complex song and dance to add leading zeroes. Simply format your serial number with format "%04d"
• Shouldn't "Operator" be a control?

Frame 2: That loop needs a small wait statement. Since STOP is always true when the loop ends, the later case structure seems unneeded.

Frame 3:

• the STOP function seems unneeded. the VI will stop anyway since there is no code left. 😉
• never use default tunnels for references.
• All your error outputs are "disconnected" and write to the same indicator. Mist likely you'll loose intermediary errors.

Overall, you should use a state machine architecture instead of sequences. It will be much more flexible and will take even less diagram space. The indicators can be outside the state case, so all states can write to them. No locals needed.

[DanielAllis]

Some of the items you mention related to code which was removed because it didn't directly relate to the problem I was having, but the others were very useful.  Now I just need to do my homework on the various tutorials and messages relating to the state machine architecture.

Thanks for your help.

[Marc_A]

Also, use subVIs... lots of them. I don't mean in this particular example, but you mentioned that you have some programs that get complicated and can fill multiple screens. This is something that we see get posted all the time - VIs that take up insane amounts of space and are impossible to follow. If I make a VI that starts to fill more than 1 screen, I'm doing something wrong. If you have a block of code that can be made into a subVI and could possibly be used elsewhere, do it. Your code will be more portable, easier to upgrade, and much easier to read.