Counter stops sampling during several-minute acquisitions

Question

Hello All,
    I am working on rewriting a data-acquisition program for DAQmx.  The code was originally written for traditional DAQ, but ceased working when we upgraded to LabView 8.5 and the corresponding version of DAQmx.  The program is designed to sample  many accelerometers using one AI Voltage task, and also sample a motor tach sensor and record all this data.  The program works fine right now except sometimes after 2 or 3 minutes of recording, the counter suddenly stops gathering data for no apparent reason.  It's not a timebase overflow error, because I've already dealt with that problem seperately.  I'm hoping someone has encountered similar behavior before and can help me out, because i'm not sure how to proceed with troubleshooting.
    The counter task is a period measurement which runs continuously and takes all the samples from the buffer each time.  This number varies with motor speed (more samples are taken per loop) and also seems to vary 10 or 20% independent of motor speed (luckily this doesnt affect or post processing programs).  Interestingly, i recorded the number of samples taken at one of these "counter stopping events" and found the last few sample numbers were:  947, 981, 964, 2(?!), 0, 0, 0...   I'm hoping the presence of that bizzare 2 helps someone out.
Here is a picture of the relevant section of this code:
The sub-vi "Idler MX Config" contains the configuration for the voltage task, and the sub-vi "Idler MX Read" contains the voltage read block, these work fine having been tested over many programs.  It's a work in progress so I apologise for the mess.
Any advice is greatly appreciated.  The program does work, but this intermittant problem is hampering its usefulness at the moment.
Tristan Ericson
Ohio State University Mechanical Engineering
Dynamics and Vibrations
201 West 19th Ave Suite N350
Columbus, OH 43210-1142
Office: 614-292-9029
Lab: 614-247-8077
Fax: [phone]
"No one is useless in this world who lightens the burden of another." - Charles Dickens

Answer 1

Thanks for the reply Kevin, you've given me several new things to think about.
I've done a lot of counter apps and I don't believe you've stumbled on a known issue with the board or driver. 
- Perhaps you have a noisy tach signal causing an
error in your counter task?  This could explain *part* of your
observations.  The other part, well, I would start by suspecting your
app code.
> I've checked the tach signal with an oscilloscope, and found it to perform well, additionally the old version of the code never had any problems with it
- The 10-20% timing variability didn't immediately
raise any alarms, but the fact that it's independent of motor speed
*does* trigger some suspicions.  It suggests that spinning your motor
at different speeds causes your software timing variability to change
inversely.  Double the speed and a 10% variation in # of period samples
represents only *half* as much time as the 10% variation meant at the
original speed.  Something about that relationship doesn't sit right
with me.  Dunno what exactly to point to, but it's, well, weird.
> Our motor has a little bit of speed variation (I think <1%) which explans some of it.  I don't believe the software timing is changing much (is there a way to measure this?).  The variability in number of samples with respect to motor speed makes sense to me given the number of pulses passing duing a sampling interval.  at 50 RPM it's 16 or 17 at 3000 RPM it's around 1000. 
- My guess for why you get an instance of 2 samples
before getting stuck at 0 is that for some reason, the *prior*
iteration finished much faster than normal.  Perhaps this is because an
error was asserted causing a block of time-consuming code to be
skipped?  Whatever the cause, it's telling you that you looped back
around so fast that the task didn't have time to buffer the normal ~900
samples, but only had time for 2.  So I agree, the "2" should be a
bigger clue than the sequence of 0's.
>  This is interesting too, is there an easy way to measure the time each loop iteration takes and store it in an array?
- comment: is that a 10000 second timeout to your counter task?  Is that on purpose?  Really?
>  Originally I thought the timeout might be to blame for the counter stopping after awhile, so I put some arbitrarily huge number in there to rule it out.  Can this have downsides?
- just curious -- I notice you don't specify a buffer
size for the counter task.  Try explicitly setting that to a fairly
large size (or at least query the size with a property node).  I don't
know how well DAQmx guesses at a default buffer size for an "Implicit
Timing" period measurement task.  (It generally does well for
explicitly timed tasks.)>  This is a good suggestion, I'll try some things along this avenue and get back to you.
- what does the rest of the loop code do?
> To the right hand side of what I posted, there's only some file writing code and the end of the loop.  I neglected to mention it, and probably should have, but there's a second while loop in this program running concurrently.  It sends an analog out voltage via out 6704 card every 50ms to control motor speed.  It's completely independent of the rest of the code but might be interfering?
-Kevin P.
Tristan Ericson
Ohio State University Mechanical Engineering
Dynamics and Vibrations
201 West 19th Ave Suite N350
Columbus, OH 43210-1142
Office: 614-292-9029
Lab: 614-247-8077
Fax: [phone]
"No one is useless in this world who lightens the burden of another." - Charles Dickens