VI stops saving data to file

[CoastalMaineBird]

I'll have like 20 to 30 folders per day, each containing about 1000 files.

Those should be more manageable, both for the OS itself, and any humans who might use it. 

Although personally, I would break it down even more so that you have a folder per hour or per event or something, but your change should avoid your main problem. 

[CoastalMaineBird]

Here's a pic of how I would insert a column into an array:

Message Edited by CoastalMaineBird on 03-24-2009 07:04 PM

[vickykld]

Excellent Steve !!

I implemented that right away. Saving the files into different folders works fine so far. I'll let you know.

Thanks,

Victor

[vickykld]

Steve and Diane,

I've got news. Not good ones sadly.

I think I'm chasing (and making you chase) the wrong problem.

Separating the files into separate folders works perfectly, and also the last thing Steve suggested.

But today I noticed that even though the timestamps were being updated correctly (done in the FALSE case lower (acquisition) loop),  after a while no new folders were created (done in the TRUE case lower (acquisition) loop, together with reading the data).

This means that apparently no more samples are acquired.

I added an indicator to display how many samples are available, and this afternoon I was able to catch the moment when events were generated, but no data was acquired (the indicator always displayed zero samples available).

I restarted the VI and waited for another sequence of events to occur, and this time the available samples indicator always displayed a value, the display updated the data, and files were written.

As I write, I'm observing yet another sequence of event, with correct acquisition and file saving.

I'm monitoring the system through a VPN access to the remote site.

Why would the DAQ card and/or VI stop acquiring? Sorry I did not discover this earlier...........

Regards,

Victor

[CoastalMaineBird]

Perhaps you should post your updated code, all I have is your original.

If I understand you correctly, the SAMPLES AVAILABLE was stuck at zero, when you noticed the failure? 

[vickykld]

Hi Steve,

Thanks for your help !!

You understand correctly.

Here is the VI.

Victor

[CoastalMaineBird]

Let me just say what I see, maybe something will come up.

#1 - I finally loaded your code on a machine with DAQ.  I get a missing VI called "Get Terminal Name with Device Prefix.vi".  It's looking in the Examples folder.  It's not a good plan to use code from there directly, as those folders change from time to time.  I suggest copying any such code you need into your own folder/LLB.

#2 - You are setting the digital channel to read at 250000 Hz fixed, but  have the analog channel reading at a variable rate (default 62500).  That has potential problems written all over it.

#3 - Related to #2 - if the analog side has N samples available (default 3750), then you read N samples from the analog side, and you read 4*N channels from the digital side.  Depending on those clocks being 100.0000000% synchronized is a bad plan.  If you want to make them synchronous, then make them synchronous by using RTSI and/or defining one clock to drive both systems.  That's easy enough to do.

#4 - Your diagram is huge, and unreadable.  Use SubVIs.  Use sequence frames.  Use something, but shrink that diagram! 

#5 - the bottom loop is a CPU hog.. There is no WAITING - you are just checking, checking, checking.  I suggest you put in a WAIT of 100 mSec in the FALSE case, so that you share the CPU with the other loop, and with other programs.

#6 - why are you querying to see if the task is done, then disregarding the result?

#7, I'm not sure what you're doing with the CO PULSE FREQ chain.  It is set to FINITE SAMPLES, so that task will be done after N samples have been generated. 

If AVAILABLE SAMPLES is stuck at zero, then your DAQ process has stopped. It looks like your error chain will stop on any DAQ error, and report it.

If something's wrong with all that MERGE ERROR stuff, I don't see it.

Try putting an indicator on the "i" of the WHILE loop.  That will tell you if the loop is still running.

[DianeS]

Lots of action since I've had time to look at this...

I was starting to suspect that the problem might be occurring in your DAQ loop, after my analysis (found in an earlier post).  I haven't had time to come back to it since.  Fortunately you've had Steve to help you.

As far as what could be going on here... 

You may recall that in a previous post I noted that you aren't using any kind of timing in either of your loops.  That causes the loops to execute as quickly as they possibly can, which hogs up processor time.  Eventually that will have a detrimental effect on the functioning of your VI.  You need to have some kind of time delay somewhere in your lower loop.

It's not as critical for your upper loop since your queue will wait until there is data available...the queue function is therefore providing your timing.  I generally set a timeout on the queue, so that I know how often my loop executes.

I would insert a delay into your lower loop...100msec or something.  That should prevent your loop from hogging the entire processor, and will hopefully solve the problem you're seeing.

[DianeS]

Ah, I see that Steve already posted and gave you the same advice. 

[vickykld]

Hi Diane and Steve,

Your minds think alike !!

OK Let me respond. I'll use Steve's item numbers:

#1 Good suggestion, I did not know that. 

#2 I know  the analog channel has a control, and the digital has a constant, I never got to replacing it with a constant as well. This never changes, but I'll put the constant.

#3  As far as I understand, I'm using the same clock for both systems, it's the counter clock.

#4 Sorry about that, I just began adding and adding more stuff, I know it needs "cleansing". It also needs proper documentation. One thing though, some time ago (years), I made a complex VI that had many sub VIs that I created. At that time, support from NI told me the reason my VI was not performing well was because of the subVIs. He advised me to remove them and explicitly put all the code in one large VI. So from that date on, I'm a little confused about the use of subVIs.

#5  This matches what Diane says. I put a 50mS delay tin the FALSE case. Let's see what happens. I chose 50mS because my acquisition takes 60mS, the delay should be less than that to read as soon as possible, correct?

#6  I don't know, I began developing this VI based on an example.

#7  This is my Clock. I set the counter to be the clock source. It generates a finite amount of pulses for the acquisition. It's supposed to be retriggerable, so every time an event happens, it generates clocks for 60mS.

I know the loop is still running, because the  LED and the timestamp (FALSE case) continue to function.

I was reading a little about the  "merge errors.vi" it only reports the first error it encounters. I'm going to look at the error flow, and see how it goes. Maybe I'll stick in more error dialogs along the path. But again, if there were an acquisition error, it should have been sufficient to stop the VI.

Thanks for all your help !!!

VIctor