08-02-2006 11:25 AM
08-02-2006 11:45 AM
Firstly, it is not clear why everything needs to be in a timed loop. Instead, do your acquisition and control hardware timed, then use a plain paralell loop to query the buffered data at leasure.
Things such as writing to files don't really belong in timed loops. 😉
It is difficult to give more detailed advice without seeing the actual code.
08-02-2006 11:52 AM
Ditto Christian's comments.
Although the plots can be goobling up memory the file writing is what will eventually kill you.
A producer consumer architecture can help but an ever growing file will evenually devour all available memory.
So switch to a client server architecture with an option to switch to a new file occationally.
Ben
08-02-2006 12:02 PM
Not sure, how do I find out?
No, I don't even know what this is (I'm a novice)
The table will grow and grow indefinitely as far as I'm aware. But it's not essential, it's just there as a visual guide to the user at this stage. I can easily lose this feature.
About 2 hours I think
Many thanks
08-02-2006
12:08 PM
- last edited on
12-02-2025
12:01 PM
by
Content Cleaner
"I don't even know what the architectures Ben is talking about are -"
This link should explain what I was talking about.
Don't worry, I even confuse myself when I am working fast. ![]()
Ben
08-02-2006 07:47 PM
@Anti-Neutrino wrote:
- What is the VI memory use over time?
Not sure, how do I find out?
"Menu...file...VI properties...Memory Usage"
- Have you done any profiling?
No, I don't even know what this is (I'm a novice)
"Tools...advanced...profile VIs" In LabVIEW 7.x.
"Tools...Profile..Performance and Memory..." In LabVIEW 8.0
- How big do your data structures get? (For example your table?)
The table will grow and grow indefinitely as far as I'm aware. But it's not essential, it's just there as a visual guide to the user at this stage. I can easily lose this feature.
OK, loose the table and see if it make a difference 🙂 Nothing can grow infinitely without hitting a ceiling at one point. Maybe you could just keep the last hundred points or so.
Can you run it a bit faster to quickly demonstrate the problem?
08-03-2006 06:31 AM
Hi guys,
Thanks for all the tips so far. I suspect ditching the table will rectify the problem, along with making the "write to file" VI write to a new file every day rather than one just growing and growing... But I'd like to implement the new architecture anyway, so that the program can be added to and improved at a later date so tips are still wlecome.
I'll do a bit of profiling and analyse the memory usage and see what it says.
I've attached the VI as it stands at the moment. I don't think there's a way to make it run any faster to demonstrate the problem. But feel free to take a peek, I'm probably making all kinds of horrendous errors, and if I am I'd like to know about them 🙂
Many thanks