NI USB 6212 BNC requires 'warm up time' to sample fast enough

[xander18]

I'm running a 2 channel, analog input, external clock, finite samples DAQ task on the abovementioned board (USB 6212 BNC). My external clock is sampling an engine spinning at 3600 RPM. The rotary encoder pulses 1250 times per revolution. By my math this works out to be 75 kS/s, and since I'm sampling two channels my effective sampling rate is 150 kS/s. (see math below) The 6212 is rated for 400 kS/s (NI page). My program is a consumer/producer loop with some data processing as well.

But my DAQ card intermittently acts like it can't sample fast enough. It will sample just a few of the data points then everything else is zeroes. It works fine 100% of the time when sampling just one channel. I've tried doubling and halving my listed sampling rate, playing with the # Samples/ch on my DAQmx task (currently set at 2), and disabling all of the analysis in the program to make for more available processing power. Last time I was running the engine after about an hour of playing with Labview it just started working perfectly 100% of the time, with the exact same settings I was initially starting with.

Anyone know what I'm missing?

Sampling rate math:

3600 revs/minute divided by 60 = 60 revs/sec. 60^-1 = .016666 secs/rev.

.01666 secs/rev divided by 1250 pulses/rev = .000013 sec/pulse

.000013^-1 = 75030 pulses/sec = 75030 samples/second

[James-K]

Hi,

A few questions:

1.) Are you using the signal from your encoder as the sample clock for two other analog inputs, or are you sampling the encoder signal as analog inputs?

2.) If you are just sampling the encoder signal, is there a reason you are using analog inputs rather than counter inputs?

3.) Would you mind posting your code?

[xander18]

Hi James, thanks for the reply.

I'm sampling two analog inputs using the encoder as a sample clock. The analog inputs are connected to pressure sensors in the head and fuel injector of the engine and I need a consistent number of samples each revolution at a consistent crank angle rate (1 sample/1deg of crank angle or something like that). I'm reading the encoder into counter 0 inputs (PFI8-10).

I attached a zip of my project. My apologies, I don't have it put together as project file, my apologies, so I have a folder of my main program and my sub VIs. (I'm not a coder so I probably haven't organized it in the correct manner.)

[johnsold]

Are the encoder outputs clean logic level signals?  Some encoders have relatively slow transistions. That can cause some logic circuits to generate extra pulses or to miss some.  Use an oscilloscope to check both the voltage levels and the edge speed on the encoder lines at the input to the 6212. The reactance of long cables can also exacerbate this type of problem.

Since you suppress error messages and do not have an error indicator, do you know if you are getting any errors and what they are?

Where do you see the zeros? Live Measurement? Or only after processing?  Do the Index indicators continue incrementing at about the same rate as when it is working?

Lynn

[Joseph_Loo]

Which windows operating system are you using? XP has some issues. Is the USB connected to a port on the computer or are you using a hub outside to connect it? Remember, that USB 2.0 requires computer intervention for each data transfer. How is your load on your computer.

[xander18]

Hi Lynn, thanks for the response. I'll try to answer all of your questions.

I'll scope the outputs with an oscilloscope but the rated rise time on the encoder is quick enough that it shouldn't be an issue. I also run the program on just one analog input with no problems. I figure if there was noise in the encoder signal it would show up no matter how many analog inputs I'm sampling.

When I run two inputs I have error -200019 coming out of the DAQmx Read VI. This error doesn't show up on just one analog input, only when I run two and only when the behavior that I describe in the next paragraph shows up.

The zeros are in my written data but you can clearly see them in the measurement window. The attached picture is what my front panel looks like after a successful run. When it doesn't sample correctly the primary graph (cylinder pressure) drops to zero after between 50-150 samples. I open the spreadsheet and I see that it's recorded primarily zeroes.

I've tried this on both Windows 7 and XP to the same results. I am aware of the XP USB connectivity issues and I installed the necessary Microsoft patch. The card is connected directly to a USB port, I believe it's 2.0. If by load you mean how much avalaible memory and CPU power is available, it doesn't look I'm even close to maxing out the PC. I tried closing excess programs as well as disabling all the other functions of the Labview program (analyzing and writing to file) to see if I was asking it to do too much at a time.

[xander18]

Here's my scope output of the encoder. Seems like a nice clean signal with pretty quick rise time. Any more thoughts?

[johnsold]

That is NOT a "nice clean signal." If you look closely both the rising and falling edges have "glitches" where the signal reverses direction. That kind of glitch may be detected and counted by the logic circuits.  Also, I cannot tell where the ground reference is on that signal.  The little "peak" in the bottom part of the signal appears to be about a volt above the base line. It could come close to the threshold of the logic input. Some logic devices are not happy with that much overshoot, either.

I would put a good comparator with hysteresis larger than the glitches on the rising and falling edges between this encoder and the DAQ input.

Lynn

[xander18]

Ah, I'm used to working with much noisier signals coming from engine sensors. I'll look into what you suggested and other ways to clean up the signal.

What I don't understand is if that's the issue why does it not affect the program when I'm running one channel? I would think that this signal is dependent on engine speed, which doesn't change, not amount of data.

I've been befuddled by this DAQ stuff before though...

[johnsold]

I really cannot answer your question about why it works with one chnnel but not multiple channels.

One speculative answer is that when scanning multiple channels, additional switching actions take place inside the DAQ device. That extra activity may increase the noise level in the timing circuits just enough or at a critical time such that the errors occur.

Lynn