NI USB-6343: Erratic Low frequency 1 Counter measurements

[Brown@KTR]

Dear forum members,

I am looking for help with a low frequency counter measurement.  I have been trying to get this to work for a week or so but I continue to get erratic measurements.  It will read the rpm correctly for a second or two and then it will give a ridiculous value on the order of 10000 times the correct value. I cannot get a steady value. 

I am using a NI USB-6343 Multifunction X-Series DAQ with a Honeywell GTN1A111 Geartooth Sensor. I have attached a rough sketch of the wiring configuration.  I believe it is correct.  Sensor output to Gate of counter. 

In trying to troubleshoot this issue I hooked up the sensor to an analog input channel to make sure that I was getting a TTL signal from sensor.  I noticed that every once in a while I would see a small noise glitch in the signal and I'm assuming this is what's causing my issue with the counter.  I've inserted two waveforms of the signal from the sensor (one with the clean signal and one with the noise glitch).  From my understanding of a TTL signal, the counter channel will consider the voltage LO when it is below 0.8V and HI when it is above 3.8V.  So I don't really understand why these little glitches might be causing the problem because they are well below and above 0.8V and 3.8V, respectively.  I believe the noise is coming from a frequency inverter used to drive the motor.  I've tried grounding the system as much as possible. 

 

I guess i'm just looking for another approach.  Could I potentially use a digital filter to help with the noise? Is the glitch actually the problem or am I overlooking something.  The VI in question is attached.

Thanks in advance,

Mike

[John_P1 · Accepted solution]

Have you tried configuring a digital filter yet?  Evidently the glitches are being picked up as an extra transition (the low frequency 1 counter method measures the period and then inverts, so a short glitch would register as a very high frequency).

You can enable the digital filter with the following property node:

Min Pulse Width is the pulse guaranteed to pass the filter, so this should be low enough that the real signal is guaranteed to pass through (but high enough so that the glitch is always rejected).

Best Regards,

[Brown@KTR]

Hi John,

No I have not tried configuring a digital filter yet. I will try that next. Thank you for the suggestion.

I've attached a version of the original VI without the sub VI.

-Mike

[daadmaster@gmail.com]

Dear Mr. John

I used Digital input modules "Digital Input"(NI 9421) and I am trying to figure out if there is way to calculate the speed of tachometer and proximity sensors.
Is it possible to use "Digital Input"(NI 9421) to calculate and change the pulses to frequency to get the revolution of speeds?

[C-Dav]

Hello!

I'd suggest making a new thread for this question as this one is a bit old, somewhat unrelated, and has already been marked as answered.  Creating a new thread will likely increase the traffic to the thread so you'll have more eyes looking through the problem you're experiencing.

Best,

[pcsphk]

I am having this same problem with a PCI-6259.

1) Will this filter work on this board too?

2) What is the value of the filter?  The maximum frequency that I will be reading is 1500 Hz.  Is the value 1500 Hz or .00066667 seconds?

Thanks!

Paul

[robo_Jeff]

Hi Paul. The PCI-6259 has more than 70 signal conditioning options, so perhaps by looking through the manual, you'll find what you are looking for. To answer your question, the DAQmx channel property node DI filter is compatible with the PCI-6259. Minimum Pulse Width specifies in seconds the minimum pulse width the filter recognizes.

[John_P1]

The value should be small enough to guarantee detection of your signal but large enough to prevent registering the intermittent glitches caused by noise/ringing.

667 us is far too long for a 1500 Hz signal.  333 us is closer assuming 50% duty cycle (i.e. the trigger should be shorter than the minimum of the high and low time, not the entire period of the input).  In reality you'd want something shorter than this since there is rise/fall time to consider as well as the glitches themselves.

The M Series only has 3 discrete filter settings available (see here).  Of those, the 6.425 us setting (.000006425) is the one you should use.  125 ns might not prevent the noise you are seeing (and you don't need to measure signals nearly this fast anyway) and 2.56 ms is too long to pass the signal itself.

Best Regards,