Missing Tooth Detection MyDAQ Counter

[nslogan]

I'm trying to use the MyDAQ to detect a trigger wheel missing tooth using the Counter period function but have thus far had spotty results. My input signal looks like this:

Which is the output from a 36-1 trigger wheel (which means teeth are spaced evenly for 36 teeth but 1 is missing). My goal is to detect the missing tooth (so I can synchronize other measurements to it) and use the period from all of the other non-missing teeth to get RPM.

I have attached the code I'm working on - it's not very pretty at the moment and has a few inputs that have not been hooked up yet because the core logic is not working properly. I know that my signal is extremely consistent but the periods in the output array indicate otherwise (I have thuroughly tested the signal generator I'm using to create this signal - I know that it is not the problem). Here's a sample:

There seem to be a lot of missing or incorrect periods - it should have the (relatively) same period for 35 samples and then 1 period should be roughly 2 times that of the previous period.

Any idea what I'm doing wrong or how I can do it better?

Thanks!

[BobRodge]

Hi nslogan,

Looking at the results you have posted here it seems you are missing quite a few period measurements. There could be a few things causing this:

For starters, only have the DAQmx Read.vi in the while loop. All of the other data manipulation could be slowing down the loop enough for you to be missing several measurements. You can use the Producer/Consumer model for the data manipulation of your measurements. I will attach a link to a White-Paper on this.

Also, how fast is the trigger wheel signal? If this pulse train is faster than 1 kHz, then you might want to set up hardware timing using the DAQmx Timing.vi. This way you can use the 100 MHz on-board clock from your MyDAQ.

Application Design Patterns: Producer/Consumer:

http://www.ni.com/white-paper/3023/en/

[nslogan]

Thanks for getting back to me!

First an update on my signal. After reviewing my sensor configuration there is a slight change in the way the signal works - the period is still ~x2 that of the previous but the pulsewidth is no longer the same size, it should also be ~x2. The signal looks like:

This didn't effect the consistency of readings though, as I have already retested multiple configurations.

As for frequency, I don't know the exact RPM of the engine yet but I would guess the max RPM we'll see is around 3kRPM. So, with a 36 tooth trigger wheel I'm at 1.8 kHz.

Regarding the producer/consumer model - will I be able to use this to (roughly) synchronize my other acquisitions to the trigger wheel? My hardware is more broken up than I like it to be but that's a constraint of the class I'm taking. I'm using a MyDAQ and a USB-9201. The data I'm really concerned about synchronizing is all collected on the MyDAQ - I'm using both analog input channels and would like to align the analog data to the trigger pulses (I'm collecting temperature and, more importantly, manifold pressure so knowing manifold pressure relative to crank position is important).

Thanks!

[nslogan]

I'm also a little hazy on how to configure the DAQmx Timing.vi - do you have some sort of resource I could use to set it up at a specified rate? Every time I've tried to use the VI I get an error like this:

And I'm not sure how to rectify it other than to not include it (which works) or choose implicit, which produces a new error:

So I'm not sure what's wrong.

[johnsold]

The lowest frequency of interest will be important also.

Consider using an analog acquisition (or hardware timed Digital Input if your hardware supports it) at a rate of 20 kHz or higher. Use the midpoint between the maximum and minimum values of voltage as a threshold. Compare the voltage values to the threshold. Place the output of the current comparison in a shift register. Use and XOR gate or the Implies function to find the threshold crossings. Subtract indexes to get periods (or half periods, depending on the logic used). Search the array of differences for values > ~1.5*mean. The large periosd should be at your missing tooth.

If your signal is unusually noisy for an encoder, you may need to do some denoising.

Lynn