Saving issues

[njf1003]

I've got a VI that's set to automatically save a data file (table of points with a header) once the program has finished running. 

Every so oftern, however, it's not correctly determining the file name and is either skipping a number or writing over a previous scan.

ie. the file names should be 1116201601, then 11116201602 (so date followed by number going up). Yesterday I was running scans and it ran 1115201601 and 1115201602 fine, but then instead of writing to 1115201603, it overwrote 1115201602 and then skipped to 1115201604 for the next scan. They are saving as .txt files. It doesn't seem to be a specific number that is always not saving correctly, just randomly, but enough where it is an issue (at least once every 10 times).

I'm not that proficient in Lab View so it's probably something fairly simple, but I can't determine what it is unfortunately.

I've attached the VI

[RavensFan]

I don't see in what part of your code that builds a filename and uses any kind of sequence number.

I do see some filename building, but it relies way to heavily on string functions.  Strip Path and Build Path should be used in place of many of those string concatenations.  But I don't see where a sequence number comes into play in your file path.

You have way to many sequence structures.  Most of those should not be needed.

You use the STOP function in many places in your VI.  That is the equivalent of hitting the abort button and provides no means of cleaning up your open files and references and exiting the program properly.

You have way to many snarky dialog boxes that just seem rude to your user.  Telling them they made a stupid mistake and need to restart the computer and the program is not their fault, but poor programming that allowed them to get to that point and can't clean up after itself.

You seem to split the file reference wire a lot rather than allowing it to pass through the various file VI's. That can lead to race condition errors where you can't control which operation happens first.  (You could be writing to a file before you had a chance to open it.)  It is probably why you used the sequence structure in so many cases where you probably didn't need to use it.

[njf1003]

Preface: I didn't write this code intially, but am trying to troubleshoot through the problems that have been created by having to upgrade.

that's because the create file is in a different VI. (i've attached that VI here)

There isn't any problem creating the files as it's always making the new file name, it's just the data that isn't going into the right file.

I will look into strip path and build path, but I was of the opinion not to fix what kinda works....

Also thankfully (I guess), I'm the user and the poor programmer so those messages only come to me, but yeah I've definetly noticed that there are a bunch of times where it doesn't clean up after itself.

and thanks! that actually is happening a bunch and I already see a couple of places where that can be easily fixed.

I always appreciate the help given by this fourm!

[RavensFan]

A couple of comments with what I see on that subVI.

That subVI runs in parallel with all the other code in that sequence fram.  It is doing a bunch of checks on the file name and directory, creating a directory and opening a file of the name that it determines.  But you never actually use that file after that.

Meanwhile in parallel code in the main VI, ou are doing abunch of file name manipulation there, but isn't quite doing the same thing.  It looks like it is picking out the "largest string" of that array?  Why don't you use the file name you already created in the subVI.

Your message says you are using filenames like 11162016 which would be the day in terms of Month,Day,Year.  But your files seem top be using Year,Month,Day.  YMD would make much more sense for creating filenames that are sortable by date as well as by string.  But all of this is not very robust.  Your subVI is doing a seach for the period.  But suppose someone has a file in there that has an extra period in it that is not part of the file extension.  Doesn't that make things fall apart?

Quote:

"

There isn't any problem creating the files as it's always making the new file name, it's just the data that isn't going into the right file.

I will look into strip path and build path, but I was of the opinion not to fix what kinda works...."

That kind of proves things aren't working.  Time to start blowing up sections of code and replacing it with something that does work.

Seeing the subVI along with the VI you attached earlier, I'm now 99 44/100% sure that you've got a race condition between the creation of a file you don't directly use, and the detection of the "latest" file in the directory.

Whoever, the original programmer was, find them and beat them over the head.  They spent a lot of time putting in sequence structures that weren't necessary, and paid no attention to making sure sections of code that actually depended on each other weren't running in parallel.