Help needed: Memory leak causing system crashing...

[Mark_Yedinak]

---

@Harry.W wrote:

Mark,

Thanks for taking time replying my questions (so entry level and probably looks hopeless to you).

I have to admit that each of your answers opens a whole new topic to me. Originally I wanted to do something "quick n' dirty" - as long as it runs I am good. I am a researcher type of guy, not even familiar to the word of "programming". The thing is when software team pushed the ball to us, we did not say no - and this is our cost I guess... 

Anyhow, I plan to sit down and do some study if I can survive from the endless meetings...  Thanks again!

Rgds,

Harry

---

Granted, I am a programmer (computer science) guy but regardless of that one thing I have learned is that if you write a program unless it is truly a one time use and throw away code you always need to plan for the future and expect that you will be touching the code in the future. As it gets used new features will be required or other modifications to keep it up to date. Planning for this type of activity from the beginning saves lots of time and energy in the future. To paraphrase a SCUBA phrase "Plan the code and code the plan."

BTW, for someone who is not a programmer your code is pretty decent. Defintiely can be improved but it is neat and organized. That in itself helps a lot.

[Harry.W]

Yamaeda,

Now I heard "State machine" the second time and I guess I can say I "knew" it

As you and everyone said the way I create/close DAQmx task is most likey the reason of my problem, can you pointing me to an example or some ref how I can take those out of the big loop? It's probably way too basic but I do need a little help here. Thanks!

Rgds,

Harry

[Harry.W]

Jeff,

Thanks! As many of you guys pointed out, I'll definitely spend some time focusing on this DAQ issue.

Harry

[Harry.W]

Mark,

Cannot agree more! I'll put it "Plan the job and job the plan." 🙂

I need a little suggestion here. I see so far ppl pointed two issues:

1. Q: Structure/flow/logic of the code need to be improved. A: Implement State Machine.

2. Q: DAQ tasks been constantly create/close is bad and may cause eating up memory. A: Initialize/close DAQ outside the loop.

I am thinking it might be benefit to take these by steps. Seems item 2 is on a higher priority because it can potentially resolve the root issue. Item 1 is necessary as well but it probably won't help much with my main problem. So do you agree I should focus on item 2 at the moment and work on item 1 as the second step?

Any particular examples or reference I should look to gain knowledge on these two topics?  Any suggestions would be highly appreciated!

Rgds,

Harry

[myle00]

You currently have the create channel and start task executing each time the loop runs, what you need to do is move those two VIs outside the loop, execute them before the loop starts and send the task out output lines into the loop. Within the loop connect the task out to the write VI so that only the write VI is run each iteration. Do the same with the clear VI, move it after the end of the loop. Do that and then see what happens. You might have to use a shift register when passing in the tasks, but you can do this after you doing the above

I cannot edit the block diagrom to move the start and stop task outside because the block diagrom is too large for me to handle easily.

Matt

P.S. which version of LabVIEW do you run?

[Harry.W]

Thanks Matt,

I tried what you said and actually moved the start/clear task outside of the loop by putting them on the top of the block (instead of on the left and right ends), and hope this is ok. Right now I plan to let it run overnight to see how memory usage changes.

What do you mean by using shift register to pass task? I put images of the analog inputs and outputs part of the code here. Please let me know if you see anything wrong.

I'm using LabView Base 2010.

Thanks again!

Harry

[myle00]

If you post the VI I'll add the shift register to show what I mean. I'm not 100% sure if the DAQ tasks requires the use of a shift register or not (probably not because the task that you pass in is probably a reference so that you always reffer to the same task, it's a bit diffucult for me to explain what I mean) but it's definitly nicer. See here for what a SR is: http://www.ni.com/gettingstarted/labviewbasics/shiftregisters.htm

Matt

[JÞB]

There is nothing wrong with a VI that works!

---It may not be "software" it may be of "poor design"  That is an important point of LabVIEW, so easy a caveman can do it, but a valid niche market that LabVIEW does fill. 

Often- you will find that LabVIEW users fall into two distinct groups; Software Engineers that know LabVIEW, and Experiment Developers who need results quickly. 

Concentreate on Getting the VI to behave.   Take the other points to heart though and the next project will be easier

[Yamaeda]

---

@Harry.W wrote:

As you and everyone said the way I create/close DAQmx task is most likey the reason of my problem, can you pointing me to an example or some ref how I can take those out of the big loop? It's probably way too basic but I do need a little help here. Thanks!

---

Check out the Action Engine, it's basically a sub-vi which can be used as a set/get memory. What you'll need to do is Set/create your task outside the loop, and then get and use that task in the loop. It's the quick'n'correct 😉 solution to his particular problem.

You can e.g. create a sub-vi with Tasks, which'll hold an array of tasks, or a separate one for each task.

The AE is a uninitialized shift register with a case structure containing your commands (Enum recommended), the simplest one is only a get/set one, but it can easily be expanded with Initialize, Sum or other commands.

Check out Darrens Nugget (if memory serves).

/Y

[Harry.W]

Matt,

Attached is the vi. It's essentially the same as the old one (so it's still extremely lousy :)) but with the DAQ tasks been moved outside the loop.

Thanks very much for your help!

Rgds,

Harry