LabVIEW
memory leak in while loop
There is no way for us to troubleshoot an image. We need actual code and all subVIs if possible.
Many features of your code are very inefficient, but they should not lead to a memory leak, still:
- You seem to be exclusively use value properties to access controls and indicators. Therese are orders of magnitude less efficient than wires (or even local variables) Why not read from the terminal directly?
- Use a simple tick count to check for deltaT, there is no need to get data/time and convert to U32.
- You could do a +5 inside the case when you log, instead of with every iteration of the loop.
- You have many coercions going into the subVIs. Find out why.
- You should only write properties (e.g. disabled) when they change, not with every iteration of the loop.
- What is in the other event cases?
- What does the "logging" do? Append to file?
I, too, suspect that the problem is in one of your subVIs, but there is no way to tell for sure without doing some profiling.
Yes, not closing the file references was probably your main problem. All other issues are more cosmetic than anything else and only
really need to be addressed if you have performance or memory problems. Still, I always recommend clean and stremlined code. 🙂
There was no way for us to point ot the file problem, because it was not visible in your code. Do you always write to the same file?
In this case you would open the file once before the loop, keep it open during the loop, append data as needed, and close the file once the loop finishes.
severin wrote:* on a related note: What number type does "Open/Create/Replace file" expect? I changed my constant to everything from I8 to U64,
but got coercion dots no matter what. The help shows some funny representation like "<>"
The easiest way to get the correct type is always to right-click the terminal and select "create constant|indicator|control" as needed.
You did not say which input you mean, but both the "operation" and "access" inputs are enums. Use enums instead of numerics to
make the code much easier to read. Who wants to constantly query the help pages or memorize the mappings to numbers? 🙂
severin wrote:* If I'm going to only write properties when they change, don't I have to read them every time to be able to figure out *whether* they've
changed? Wouldn't this make the whole process just as expensive?
No, checking for a change is trivially cheap compared to a property node. In newer LabVIEW versions you would use a globally initialized feedback
node and a simple "not equal" comparison of the current and previous value to see if the value has changed. If I remember right, there is also an openg tool for this.
