VI stops saving data to file

[vickykld]

Hello Steve and Diane,

I have a new update. 

I began reading about the the DAQmx Read properties, to see if I can monitor something.

I put an indicator for the "Total number of samples acquired" property. The context help  for this does not clearly explain what this is, but I found out that this contains the accumulated value of all samples acquired since the VI started running.

This value keeps increasing, even after the VI stops saving data to file. I checked the increase in number of this property, and it matched perfectly what I expected.

So the DAQ board still is acquiring, and the counter is still generating the pulse train correctly, but for some reason the "available number of samples"property that I use to control the case statement does not function correctly anymore.

Is there a possible bug in LabView 7.1?

Regards,

Victor

[CoastalMaineBird]

So what happens to the "available number of samples" value?  Is it stuck at 0?  Stuck at some other number?  what does it do when you stop writing?

P.S. Since you don't use a shift register, you're appending that "available number of samples" value to an empty array every time. Not a useful plan.  But that's nothing to do with your problem.

[vickykld]

Hi Steve,

Thanks for getting back to me and helping out !!

Yeah, that array you're talking about is something I just added a few moments ago. I did not get a chance to check it's operation yet. I just stuck that in there to see what info I can gather. So you're saying I'm not appending the "available number of samples" value correctly to this array?

"the "available number of samples" value?  Is it stuck at 0?  Stuck at some other number?" 

Apparently it's stuck at zero, at least that is the number I see displayed on the indicator all the time.

"what does it do when you stop writing?"

What do you mean? Sorry, I did not understand your question.

Regards,

Victor

[CoastalMaineBird]

So you're saying I'm not appending the "available number of samples" value correctly to this array?

Well, your code takes an empty array, appends one value, and displays it.

The next time thru, you start with an empty array, append one value, and display it.

You're not appending to the array you're displaying, you're appending to an empty array. Every time.

 "what does it do when you stop writing?"

What do you mean? Sorry, I did not understand your question.

I meant what was the indicator doing, when the program had stopped writing files.  Your answer is that it's stuck at zero,

 I've no answer for you.

Things to try:

When it's stuck, open the diagram and turn on the spotlight (the light bulb icon in the tool bar).

That might tell you where in the diagram it's executing. 

[vickykld]

Thanks Steve,

I fiixed the array building. I now use a shift register. Will this create a new problem for me? cause it's adding a value to the array every 50mS. will the VI run out of space?

I'll turn on the highlighting next time it stops saving, and let you know.

Victor

[CoastalMaineBird]

I fiixed the array building. I now use a shift register. Will this create a new problem for me? cause it's adding a value to the array every 50mS. will the VI run out of space?

That's not a good plan for long term, but if it helps find the problem it's OK.

When you APPEND to an array like that, the memory manager has to get involved a lot.  Since you don't know how many points will go into the array, it starts small.  When that space is used up, it has to allocate more space. When it allocates more space, that space might not be in the same place, so it has to move your old data into the new space.  The longer you go, the worse that becomes.  And, if your real program doesn't end, then you end up consuming all available memory.

Consider writing it to a chart  on the panel, rather than an array.  The chart only keeps the most recent N samples.  Although the time aspect might influence the program adversely, I don't know.

If you want to avoid the above problems, then pre-allocate an array of say 1000 points, put it into a shift reg,  and use REPLACE ARRAY SUBSET to replace one every time thru.  Use the index (i mod 1000) to determine the element you replace.  This keeps the most recent 1000 points around, and has no memory allocation issues (every time thru).

----------

I have no experience with the "Total number of samples acquired" property. If that number keeps increasing (as expected), but the "Available" number is stuck at zero, then something is wrong with the buffering.  Try a bigger constant instead of 10000 (where you set the buffer size).

That is a wild guess, but that's the best I can offer from here.