Open/Create/Replace file Problem

[Ray.R]

Hi Ton,

That's a good fix to get around the problem...  🙂

As a matter of fact, if both instances of opening or writing to file can occur while one is busy with the file, then having that Local with the filename is definitely not a good idea.

Unique file generator would be a good workaround.  However, if the idea was to append to the same file, then a re-write would be in order..  🙂

[omomom]

I don't think there should be any duplicate filenames. Like I said, this problem occurs sporadically and can't be reproduced every single time. Sometimes it occurs at the beginning of a scan, sometimes it occurs at the end. I save one last file (a compilation of the data stored in all previous files) after the scan is complete, and I have gotten a pop up asking for a location to save this file on some occasions as well. In that case, there would be no problem with the DAQmx, because the pop up would happen after the scan was complete.

I will eventually rewrite the whole thing using a state machine as suggested, but I'd like to point out that this program has been working for many months. I started getting this error because there was a worm on the computer. Once the worm was gone, the program began to work again, so I assumed that the worm was taking up the system's memory and wasn't letting LabVIEW write any files.

But now I've transferred to another computer and I'm getting the same error (I have yet to do a virus scan).

I'm almost sure that all the local variables are used independent of one another (because of case structures).

Why is it wrong to use the run continuous button ?

[Ray.R]

The "run continuously" is a debugging tool and is not meant to run a VI normally. A better name for that button might be "restart VI from the beginning whenever the program finishes".

What happens is that it resets everything to their initial default values and proceeds with the execution.  You are probably using the "Abort Execution" button to stop the program, which may lead to memory leaks.  Furthermore, depending on how the wires are initialized, or how they obtain data in order to execute the next object, simply running "wild" or continuously, or using the Abort Execution, followed by a restart may put the program in unexpected states and resulting in undesired behavior.

The appropriate method is to have a while loop that allows the operator to stop / end the program.

Now you mention the following:

---

@omomom wrote:

I have gotten a pop up asking for a location to save this file on some occasions as well.

---

I would have to re-visit your code.  Does that mean you are defining a new path during run-time?  There's nothing wrong with selecting a different path or filename.  It is just that I don't recall seeing this and must therefore assume that I overlooked another Local Variable, one which is being written to.  Or is it a different terminal or wire?  (If I have time I will download the code and have another look)

[TCPlomp]

---

@omomom wrote:

I don't think there should be any duplicate filenames.Like I said, this problem occurs sporadically and can't be reproduced every single time. Sometimes it occurs at the beginning of a scan, sometimes it occurs at the end. I save one last file (a compilation of the data stored in all previous files) after the scan is complete, and I have gotten a pop up asking for a location to save this file on some occasions as well. In that case, there would be no problem with the DAQmx, because the pop up would happen after the scan was complete.

---

If I look at this code:

You can get a duplicate filename, if a duplicate filename exists, the program will show a pop-up, I would check to before creating the file, whether the filename exists and then do an additional 'Increment'.

You description of your problem sound like a race condition that happens sometimes on the original (slower?) computer, but more often on the current (faster?) computer. Check every part of your code for race conditions. And try to debug/trace the returned error as good as possible.

Ton