exit labview (executables) after using large text files

[Martin_]

Hello,

I am using LabView 6.0 and his aplication builder / runtime engine. I wrote some VI`s to convert large Tab delimited textfiles (up to 50 mb). When I am finished with the file it is staying in the memory somehow and is staggered with other (text)files in such a way the computer is slowing down.

When I want to exit the VI (program) it will take a very long time to get  lost of the program (resetting LabView) and get my speed back.

How kan I solve this problem for these large files?

Martin.

[falkpl]

do

[falkpl]

do you explicitly close the files after reading them?

[Martin_]

Hello,

Yes, I use (ofcource) the default close function.

Martin_

[tst]

I suggest you post the relevant code. You might be creating a copy of the data somewhere and not getting rid of it (like an indicator).

[Martin_]

I have included one of the VI`s which is having problems with large textfiles. (the non compiled version) Maybe I overlooked something or having indeed a copy of the data in the memory someware.

Maybe the stucture is looking quite weird to you, but this is depending on the information in the textfiles which I read with the VI, the construcion is made like this so only new selected files are placed into the memory and ony for a new selection of the selector special parameters are read from the file.

(with convert the real reading of the selected dataset is done)

Thanks in advance,

Martin.

[tst]

OK, this may be a bit of a problem to track down, but let's start.

First, while your front panel looks great, your code is very hard to read. Overlapping elements, multiple nested structures and a liberal use of locals make this a problem. My first suggestion would be to with a massive cleanup operation. Make more room, make wires straight, make sure things are going left-to-right, make subVIs, place some documentation and so on. You won't believe the difference this makes.

After you did that, we can turn to find the problems. Some likely suspects are the local variables and the array functions. You use many local variables and perform resizing operations which are certain to generate copies. If you do this on arrays with dozens of MBs of data, this looks like the most likely source of the problem. Some suggestions to deal with this - if you have repeating code, make subVIs or move the code outside of the structures, so that it only has to be run once. Also, you seem to have some redundant code. For instance, you open  the file only to see if you get an error. You should be able to do this with the VIs in the advanced palette without opening it (and you won't need to close it, either). Another example - you check the exit conditions in many places in your code. If your loop runs fast enough, there is no need for it. Some more suggestions - use shift registers instead of locals and avoid setting the same properties over and over again in the loop.

After you do these, it will probably be much easier to find the problem.

To learn more about LabVIEW, I suggest you try searching this site and google for LabVIEW tutorials. Here and here are a couple you can start with. You can also contact your local NI office and join one of their courses.
In addition, I suggest you read the LabVIEW style guide and the LabVIEW user manual (Help>>Search the LabVIEW Bookshelf).

And one last thing - having the VI run automatically and then use the Quit VI at the end is not very nice. Since you are building it, it will run automatically on its own and you can use the Application>>Kind property to quit only if it's an executable.

[johnsold]

Martin,

Your VI has multiple copies of your data as well as race conditions and other structures likely to cause problems. Each local variable results in a copy of the data. So your locals of "array" and "data" mean that your large textfiles get multiplied in memeory.

Many LV programmers try to avoid the use of sequence structures. In most cases dataflow can define the sequence of execution where necessary. I think many of your local variables could be eliminated by the use of shift registers. Also using left to right wiring makes it much easier to understand what is going on in a program.

I don't recall whether LV5 has multithreading or not, but use of local variables and property nodes force all execution into the GUI thread and are generally slower than direct wiring.

Lynn

[Martin_]

Thank you for your fast reply.

I think I poluted the VI  to much with trying to find a solution for the problem, that`s why there are so much exit checks. The check on the file is done to see if it is existing, if it is existing it need to be opened anyway. If the selected filename dit not change during the last action the open action will be skipped, but I agree that there is maybe a bit smarter way to do this.

I also agree with the dirty way of programing. It is a subVI of a much larger program and I programed it (to) fast. The quit funcion was first less dirty, but with some tryals to free the memory before exiting I grayed the exit out and made the sequence. Also it,s like: you start smal and then you make a function extra, and extra, .....

I did not pay attention on the fact that local variables are copies. I thought that it was just a pointer to a memory location vallid for the whole (sub)VI. I also thought that the memory is freed by giving the pointer back to the system, an action which is only costing a milisecond, (and  overwriting the whole used memory block is only done when needed by the o.s.)

So thank you for your answers and I will try to make more data streaming and shift registers where possible and I hope that this works better.

Martin

[Martin_]

You came with the same arguments as tst, so It must be true,

tnx