write to file taking too long.

[prithvi]

Hi,

I have a peculiar problem :). I have used state machine architecture to build my code. In one particular state i write the data accquired and strore the wave form graphs as jpegs on the disk.

File open and close happen only once outside the while loop. I am using "Write FIle" vi to write the data. Data is first bundled into a cluster and then writte. I use "Write JPEG FIle" to store graphs as JPEGS.

When i create the executable and run, the program stops here in this state for an indefinite amount of time. (sometimes 60 secs, 80 secs)

and then continues. Multiple tests have confirem that the problem is either due to file write or JPEG write.

Can anyone please tell me the cause of error

what happens to all the pop ups (errors thrown by labview when running the program) when the program is converted ino an executable?

Rgds

Prithvi.

[GerdW]

Hi Prithvi,

can you attach your vi?

Did I understand your last sentence correctly: Your vi gives you errors/warnings in the development environment and you expect the executable to run without?

[prithvi]

Hi,

Attching the VI would be difficult since it is big. I am attaching the dataLogging part of the state machine. The size of the folder where the JPEG files is now 3.41 GB. Each JPEG is baout 39 KB.

The last statement of my previous question is a doubt. When we develop programs using labview and we run the program, if an error is encountered Pop Ups display the error. What happens if we convert the program into an executable and these errors occur?

[AnalogKid2DigitalMan]

Your data logging portion of code did not attach.

Have you tried writing to a new, empty directory? 3.4G/39K = over 87,000 files in that folder. Could it be the OS is having a hard time with that many files? Just a guess.

[prithvi]

oops soory for not attaching the code part. i hv attached the code.

[Joe_H]

I would have to say thar it is probably the write to jpeg portion of the code but i would also suspect it to be the size of the folder that is causing there problem. You can debug this by putting a case structure around the jpeg code with a constant true or false so that the code will not execute or if you have the disable structure just put that around it. Then run your code and see if still hangs at the same point.

How big is the other file that you are writing to for the write to binary file.

[prithvi]

The total size of the other file after all the runs (say 60) is about 3 KB. But for each run 2 JPEGS are created (each of size 39 KB). So about 39 * 2 * 60 (for 60 Runs) of space is used.

[DuffmanSays]

I think Joe’s observation is a good one: the large delays may be caused by the number of files (and total size) in the folder to which you are writing. Have you tried creating a small VI whose only function is to create these jpeg files? Try a small test like this when writing to an empty file. If this gives the same behavior, then the delay must be inherent in the code and not in either the surrounding code or the folder to which the write takes place. I hope this helps! Thanks,

Mike

[prithvi]

Hi,

The size of the folder and number of files in the folder was the problem. Clearing the folder helped remove the delay.:manhappy:

I thank all of for your help and time.

But even when the folder contained a large number of files, writing into it sometimes took no time, sometimes 60 secs. the delay was not predictable. Is this delay inevitable as the size of the folder increases?

Thanks and rgds

Prithvi.

[GerdW]

Hi prithvi,

I suppose you work on a windows system. Windows may buffer the contents of a folder to allow faster directory queries. So sometimes your access is granted very fast,
sometimes not (= getting new directory listing)...
It's always a good idea to have a well structured folder tree for your files. Why don't you use subfolders for each measurement? Why don't you use a subfolder for each new day/hour, depending of the number of measurements done it that time?