error with rapid data acquisition

[elset191]

We have our encoder running through a filter, so it should not be very noisy.  I haven't tried the DAQmx Is Task Done method, but we've tried some things.  I'm going to just list everything I know here and hopefully something comes of it.

In all of the following scenarios I commented the AvailableSamples code out.

On 32bit Vista we can run at 950 RPM no problem.

On 64bit Vista with LV2010 Eval (64 bit) we were only able to run at about 500 RPM.  Higher than this and we were getting ADC errors saying they were happening before the previous one was complete.  I started with a rate of 60000 and worked my way down to 40000 and was still getting this error.  According to my calculations, at 950RPM we only need a rate of at least 37000.  This was all after following these steps to resolve MIG errors.

On 64bit Vista with LV8.6 (32 bit), I believe the scenario was the same as above.  However, on Tuesday we were able to run at 750 RPM with no problem.

The only differences that I see are that on the 64bit Vista we have a different version of DAQmx installed than on the 32 bit Vista.  This version is installed in the Program Files(x86) folder, rather than the Program Files for 64bit programs.

[Mcdan]

Tim,

Nothing comes to mind directly.  Can you post the actual error messages you get?  Can you do this with the Is Task Done.vi in your timeout loop?  I'll throw out some thoughts and see if we can figure out what's going on.

The only ADC error that comes to mind is -200019.  This error is detected in hardware, and should be completely unrelated to software configuration.  Essentially, each time a convert clock occurs the hardware starts a counter which counts down from some fixed value to zero.  If a second convert pulse arrives before the counter reaches zero, HW indicates an error to us.  According to your initial screenshot, you're using an internal convert clock.  For each sample clock DAQmx will generate a convert clock for each channel.  You can query the rate of this clock if you're interested in how fast it is running.  You can also query how far delayed it's start is from the sample clock (DAQmxTiming->More->AI Convert->Delay From Sample Clock->Delay Units and DAQmxTiming->More->AI Convert->Delay From Sample Clock->Delay along with DAQmxTiming->More->AI Convert->Rate). Is it possible that the time from the last convert clock of one sample to the first convert clock of the next sample is too short?  I could see intermittent issues with this if the rotating device had spikes in speed.  However, this does not tie into different behavior on different operating systems.

Do you commit your task, then start and stop it multiple times?

If you can answer these questions, I'll see if I can shed any light on the behavior you're seeing.

Dan

[elset191]

I took a screenshot of my code with the error.  I didn't try the Is Task Done? because I commented out the timeout code entirely to remove that from the equation.  You were correct in assuming error -200019. 

This was LV8.6 on Vista-64 with daqmx 9.0.2 I think.

[elset191]

I took a screenshot of my code with the error.  I didn't try the Is Task Done? because I commented out the timeout code entirely to remove that from the equation.  You were correct in assuming error -200019. 

This was LV8.6 on Vista-64 with daqmx 9.0.2 I think.

[Mcdan]

Tim,

That is an error generated by hardware.  At this point, I think it will be worth our while to figure out what our convert clock is actually doing.  If your device has a counter free, we might want to start by doing a buffered frequency measurement on the AI Convert Clock.  Here I would expect to see a pattern of three frequencies of the frequency 'DAQmxTiming->More->AI Convert->Rate' followed by a variable length frequency.  This variable length frequency would basically be the time from the last convert of sample n, to the first convert of sample n+1.  I would look to see if any of these frequencies were suspiciously high.

What I suspect may be happening is that since your sample clock (signal from encoder) is not going to have a constant frequency, you may be pushing the last convert from one sample too close to the first convert from the next sample.  Take the following example (hopefully my ASCII clock diagram will stay formatted decently):

Sample Clock:

      _                                                               _                                                 _

___|  |___________________________________|  |___________________________|  |_________

Convert Clock:

           _             _            _            _                     _            _             _            _       _          _           _          _

______|  |______|  |______|  |______|  |___________|  |______|  |______|  |______|  |___|  |_____|  |_____|  |_____|  |____

Here the first sample clock arrives, and causes the convert clock to pulse for each channel you are scanning.  The second sample clock arrives, and kicks off your second batch of convert clocks.. However, right after these clock pulses complete the 3rd sample clock arrives.  This immediately begins the 3rd set of convert pulses.  But because the arrival of the 3rd sample clock was so close to the end of the 2nd sample, the 8th and 9th cycle of the convert clock are too close together, and violate the ADC's timing.  If this is the situation you are running into, then one way to fix it may be to speed up the convert clock.  By default, DAQmx does not run this clock at full rate.  Instead it adds some padding between ticks of the clock.  You can over-ride this by setting the DAQmxTiming->More->AI Convert->Rate property to a higher rate.

I'll let you know if anything else comes to mind, but this is one behavior that could explain an intermittent failure.

Hope that helps,

Dan

[elset191]

We had to switch tools at the end of last week, so I don't know when I'll be able to have access to the machine to see what kind of results I get.  I will be sure to resurrect this thread again when the time comes.  Thanks for sticking with it, much appreciated.

[elset191]

A passing question a coworker asked me today, that may or may not affect the progression of this thread.

I've been doing my math assuming 4 input channels.  If, however, these channels are differential, would I need to do the math assuming 8 channels?  If so, could that maybe explain why I'm overrunning my ADC timer.

My intuition tells me no, I don't have to do this, since at the beginning of the thread I was running at 36KS/s/channel just fine, and it recently stopped working.

[Mcdan]

Tim,

No, the terminal configuration simply affects what signals are measured by the ADC.  It should not have any impact on valid clock rates.

Hope that helps,
Dan

[elset191]

---

@Mcdan wrote:

The only ADC error that comes to mind is -200019.  This error is detected in hardware, and should be completely unrelated to software configuration.  Essentially, each time a convert clock occurs the hardware starts a counter which counts down from some fixed value to zero.  If a second convert pulse arrives before the counter reaches zero, HW indicates an error to us.  According to your initial screenshot, you're using an internal convert clock.  For each sample clock DAQmx will generate a convert clock for each channel.  You can query the rate of this clock if you're interested in how fast it is running.  You can also query how far delayed it's start is from the sample clock (DAQmxTiming->More->AI Convert->Delay From Sample Clock->Delay Units and DAQmxTiming->More->AI Convert->Delay From Sample Clock->Delay along with DAQmxTiming->More->AI Convert->Rate). Is it possible that the time from the last convert clock of one sample to the first convert clock of the next sample is too short?  I could see intermittent issues with this if the rotating device had spikes in speed.  However, this does not tie into different behavior on different operating systems.

Do you commit your task, then start and stop it multiple times?

If you can answer these questions, I'll see if I can shed any light on the behavior you're seeing.

Dan

---

Hi Dan, I'm back.  We got around to testing a few things yesterday.  Our new setup is 1 channel analog acquisition running at 15000 pulses/revolution and a varying RPM.

When I query to the AI Convert>Rate property it is what I expect, and I can set it as high as 250000.  When doing nothing but maxing out the convert clock we could only run at about 708 RPM which is about 177kS/s.  This is only about 70% of our ability, as I understand it.

When we switched to our other DAQ card (NI PCI-6254) which has a maximum rate of 1.25MHz, we had no problem going at 800 RPM, or 200KS/s.  We are not really physically capable of running much faster than this to test the limits of this card.  I guess the takeaway here is that the encoder is working well enough to allow us to take good data at this rate using this card, but not at this rate using the 6229, which should be more than capable.

Going back to the 6229...  We started fiddling with the Delay.  If we set the delay to 4E-6 (1/250000) seconds, we were able to run at about 730 RPM without getting the ADC error, however the data we were acquiring was not accurate.  With any other value for the delay we were getting the ADC error.  I'm not sure what this tells us about the problem, if anything.

[Mcdan]

Hi Tim,

At this point, I think it would be nice to see exactly when you're getting pulses from your encoder.  Can you spare a counter on your 6229?  If so, I think it would be informative to perform a buffered implicit period measurement on the signal coming from the encoder.  You can use the shipping example, Meas Dig Periods-Buffered-Finite-High-Freq-2 Ctr as a starting point (change measurement method constant to be Low Frequency with 1 Counter).  This would give us the period of each pulse from the encoder, and allow us to analyze if any of these are shorted than your convert clock delay + convert clock period.  Without having a better view of the actual timing of your signals, I'm not sure I'm going to be able to guess at the reason you're seeing the ADC errors.

Hope that helps,

Dan