Dataflow question about DAQmx operation

[walter-donovan]

Attached is a sub vi that I have a problem with. When this sub is running. it slowly eats up all the page file memory, discovered by Vista performance monitor. Pgm will eventually crash. This sub is called the main pgm ad closes when "RETURN" is pressed. Memory 'gobbling' is quicker when compiled naturally but it's there in the LV editor also.

I supect that my dataflow keeps creating new tasks because it is in a loop even though I have put a clear task function. In any event I'm pretty sure I have to rewrite with the create task outside of any repeating loop. I'm not sure how to do this.

When this sub is open and running, the user must be able to change the channel and timing parameters, so these cannot be controls read only at entry into the sub. If I put them in an event structure, won't they have to initialize a new task like they seem to be doing now, only at a slower rate because this would happen only when the user changed a control?

A little guidance would be appreciated. 

Message Edited by walter-donovan on 02-13-2009 10:10 AM

[Dennis_Knutson · Accepted solution]

You can create a front panel Boolean called 'Config' and have a value change event for that and place the setup VIs in there. Using a shift register for the task, the first thing that this event would do is a clear task. Something like the code below. You might want to disable the 'Capture' button until the config event is fired.

[Wayne.C]

walter,

Here's my guess.  Every time your event structure times out ( 10ms )  you are not clearing the task.  That means that you continue to virtual channels and maybe tasks. 

Why not add more events to your event structure to track changes in the input settings and act accordingly?  That way you only stop and start the task as needed. 

Missed it by that much!

Message Edited by centerbolt on 02-13-2009 11:37 AM

[walter-donovan]

Thanks both. I tried Dennis' approach and it worked but then I wanted to know why. I modified my original vi to put the clear task outside the event structure but inside the do/while loop. At the same time I wired the task through the event loop. The memory issue cleared up, apparently something to do with the broken loop in the timeout. The verification of config being met is a good idea. I will incorporate it.

[Dennis_Knutson]

The memory issue may be cleared up but there is no point at all in repeating all of that configuration every 50 msec. That's just silly. You want to do the configuration only when something changes.

[walter-donovan]

Asolutely right. I even spotted that myself (eventually). Since the data capture is only used in one event of the whole sub, I moved all the DAQ code into the CAPTURE event.

Now none of it executes unless the event triggers. My original thinking was to initialize DAQ routines at the beginning of a vi and just call the read function repeatedly in a loop. I think that reasoning is sound but I had to add the outer loop to keep the vi running and allow changes to channel parameters, etc. When I added that loop I didn't consider the consquenses to the DAQ routines. I am thankful for the little speedo and tach that came with Vista. They made it so simple to determine there was a constant generation of variables that was consuming memory.