Need cRIO or cDAQ?

[Kevin_Price]

Multiple thoughts, worth at least what you paid for them:

1. I personally don't have the experience with cRIO or FPGA to recommend or comment.  I would only say that LabVIEW Real-Time has some additional learning curve beyond "vanilla" LabVIEW, and FPGA has considerably more.  I'd make sure you need it before signing up for that learning curve.  It can be really good stuff, but using it well isn't going to be trivial for a first-timer.

2. I agree with mcduff that this seems doable with 1 cDAQ chassis and several I/O modules.  If you can confirm that it definitely *is* doable, I'd recommend you stick with regular LabVIEW and cDAQ..

3. To start with, follow mcduff's link and make sure you get a cDAQ chassis that has 3 analog input timing engines.  This is what you'll need to have 3 independent programs that each have access to AI.

4. You'll also need to have 3 separate AI modules.  Any given module can only be driven by 1 timing engine at a time.

5. The cDAQ chassis will have 4 counters, you'll use 3 of them for your quad encoders.  You don't *inherently* need 3 separate DI modules for them, you just need enough total DI terminals to get the signals connected from the encoders and routed to the chassis counters.

6. You'll likely want to sync each system's two tasks by using the AI task's sample clock as the sample clock for the encoder.  The syntax will vary from one system to the next as the 3 different timing engines get used.  One will be ".../ai/SampleClock", one will be ".../te0/SampleClock", one will be "../te1/SampleClock".   Plan to come back for more advice when you get to this point, it'll probably make more sense once you've gotten that far.

    Note that with an approach like this, you should call DAQmx Start for the encoder task *before* calling it for the AI task.  That makes sure the encoder task is ready when the AI task's sample clock starts, so their first samples are taken at the same time.  All the rest will remain sync'ed as well.

7.  Having said all of that, your general system description makes me wonder what purpose is served by the encoder data.  Most of the job seems to be about a sufficiently high speed AI capture that you can make fine distinctions about "pulse widths" of the analog data to measure gear tooth wear or damage.  Encoder data may help "key" the anomaly to a specific rotational position, but do you know how to maintain the mapping of encoder index to specific gear tooth position and then maintain it after you remove the gear for further inspection?  It isn't obvious to me how you'll set and maintain such mapping, thus it's unclear how useful the encoder data really is.

8.  So what do I mean by "high speed capture"?   Well, it's considerably faster than the 4 msec per tooth that seemed really fast to you.  I'll just think out loud a little bit here.

    For starters, I'm going to suppose you want to nominally measure at least 100 samples of high enough voltage to indicate "tooth presence".  That gives you the theoretical possibility of detecting 1% wear, i.e., 1 sample less than nominal.  I'll further suppose that tooth presence is 1/2 the waveform, tooth absence is the other 1/2.

    You mentioned 58 teeth at nominal 150 RPM.  That's nominally 145 teeth per sec or ~0.0069 sec per full tooth cycle.  If half of that is tooth presence, that leaves you ~0.00345 sec for at least 100 samples.  Put it all together and you'd look for sample rate of *at least* 30 kHz to get the desired spatial resolution (1/100th of a tooth width) at your particular gear speed.

    Now bear in mind that your 150 RPM is very likely only *nominal*.  There will be speed variations.  These speed variations will cause *some* amount of variation in your measured gear tooth width that has nothing to do with tooth wear or damage.  You'll need to be aware of that and accomodate it in your pass/fail criteria.

And now, after that last bit of thinking out loud, I've got a much clearer idea of how your encoders can be really important after all.  It's a big enough change that I'll make it a separate post a little later tonight.

-Kevin P

[Kevin_Price · Accepted solution]

And here's an alternate approach.  If your system allows for it (and I suspect it probably can), it removes the concern about variations in speed.

This method depends on having high resolution encoders because they will drive your measurement precision.

1.  The basic idea is to use one of your encoder signals as the sample clock for your AI task.  The one catch is that this method only works if you have unidirectional motion during the time of testing.   It sounded like you probably do.

2. You could use the same signal for an encoder measurement task as well, but it'll be kinda redundant.  Every sample is the same distance from the previous one -- either 1 count or 4 depending on whether you do 1x or 4x encoding.  You could just as well calculate the known position from the AI sample #.

3. You'll still need 3 separate AI modules which will each use a different timing engine to take in the encoder signal and feed it through its timing engine to become a sample clock.

4.  If you choose to calculate position instead of measuring it, you probably only need 1 DI module for the 3 encoder inputs you'll use for your sample clocks.

5. With 58 gear teeth occupying 50% of the circumferential space, that's 116 distinct regions around the gear.  To get that same 1% precision, you'll want encoder resolution that's at least 100x that, or 11600 full cycles of both the A channel and B channel of your encoder.  (Encoders are often marketed according to their quadrature 4x resolving power, so you may need to key in on ones that can resolve > 46400 positions per rev).

    Adjust numbers appropriately for other gear tooth quantities and the % of filled space vs empty space.

6. Nominally, you still need AI modules capable of the same sample rate as in my prior post.  It's just that now your samples will always be equally spaced in *position* rather than equally spaced in *time*, which is actually much more appropriate for the job you're doing.  Speed variations stop mattering, even nominal speed matters only if it would cause sampling rates to be higher than a module can support.

Overall, I would much prefer this approach provided you can count on unidirectional motion.

However, in retrospect, the first approach I discussed where you capture sync'ed data for gear "presence / absence" and encoder position could still work out pretty well.  You'd be able to do a pretty fair facsimile of equal-position sampling with some simple interpolation of your encoder data.  I prefer doing it in hardware like this 2nd approach, but it may not turn out to be crucial for your particular app.

-Kevin P

[crossrulz]

---

@jawilli91 wrote:

We are waiting for one more piece of the puzzle, and then we will probably invest in a system and begin seeing how bad it will be, or more likely, begin looking for NI contractors/integrators in the northern Detroit, MI area.

---

If looking for a partner, start here: Work with an NI Partner.  I know Konrad has a location in the Detroit area.  I'm not sure who else is in that area.

[jawilli91]

Kevin_Price, thank you for your timely, and thorough, response.  I've addressed points in a 1A:, 2A:... format below your original points.

1. I personally don't have the experience with cRIO or FPGA to recommend or comment.  I would only say that LabVIEW Real-Time has some additional learning curve beyond "vanilla" LabVIEW, and FPGA has considerably more.  I'd make sure you need it before signing up for that learning curve.  It can be really good stuff, but using it well isn't going to be trivial for a first-timer.

1A:  Duly noted, indeed.  I've also been looking at the training tools from crossrulz' signature links.  It looks like NI is making that even harder to access than I remember it being, ad Digilent doesn't seem to be leaning into taking over the NI training system. not considering paid lessons from NI.

2. I agree with mcduff that this seems doable with 1 cDAQ chassis and several I/O modules.  If you can confirm that it definitely *is* doable, I'd recommend you stick with regular LabVIEW and cDAQ..

2A:  That is indeed most of the problem.  I clearly don't have the depth of knowledge or experience to make such a judgement.

3. To start with, follow mcduff's link and make sure you get a cDAQ chassis that has 3 analog input timing engines.  This is what you'll need to have 3 independent programs that each have access to AI.

3A:  I'm glad you both mentioned this as I would've missed it and used 1 AI module with the assumption I could look at 1 cards individual channels simultaneously.  Aside from I believe the maximum capture speed gets derated per channel.

4. You'll also need to have 3 separate AI modules.  Any given module can only be driven by 1 timing engine at a time.

5. The cDAQ chassis will have 4 counters, you'll use 3 of them for your quad encoders.  You don't *inherently* need 3 separate DI modules for them, you just need enough total DI terminals to get the signals connected from the encoders and routed to the chassis counters.

6. You'll likely want to sync each system's two tasks by using the AI task's sample clock as the sample clock for the encoder.  The syntax will vary from one system to the next as the 3 different timing engines get used.  One will be ".../ai/SampleClock", one will be ".../te0/SampleClock", one will be "../te1/SampleClock".   Plan to come back for more advice when you get to this point, it'll probably make more sense once you've gotten that far.

    Note that with an approach like this, you should call DAQmx Start for the encoder task *before* calling it for the AI task.  That makes sure the encoder task is ready when the AI task's sample clock starts, so their first samples are taken at the same time.  All the rest will remain sync'ed as well.

7.  Having said all of that, your general system description makes me wonder what purpose is served by the encoder data.  Most of the job seems to be about a sufficiently high speed AI capture that you can make fine distinctions about "pulse widths" of the analog data to measure gear tooth wear or damage.  Encoder data may help "key" the anomaly to a specific rotational position, but do you know how to maintain the mapping of encoder index to specific gear tooth position and then maintain it after you remove the gear for further inspection?  It isn't obvious to me how you'll set and maintain such mapping, thus it's unclear how useful the encoder data really is.

7A:  The part is a crankshaft timing ring, the voltage sensor is an in production crankshaft position sensor.  We are measuring new unworn parts.  Occassionally there is tooth damage from the fine-blanking press or defects introduced before it gets to us.  Bent teeth, or teeth with strong burrs hanging off of them is the primary concern.  The test spec as defined by the customer measures pulse width (voltage in) against degrees of rotation (encoder position).  I don't know how to "maintain the mapping of encoder index to specific gear tooth position and then maintain it after you remove the gear for further inspection."  Other than to say I don't need to maintain tooth/encoder position after the data is collected, because I'm not assembling it to the crankshaft.  But using the encoder to measure the voltage signal that results from a 6 degree tooth width is the entire point of the test.  In truth, if speed was held relatively consistent, we probably could so what they want without and encoder.  However, we have to test to the spec.

8.  So what do I mean by "high speed capture"?   Well, it's considerably faster than the 4 msec per tooth that seemed really fast to you.  I'll just think out loud a little bit here.

    For starters, I'm going to suppose you want to nominally measure at least 100 samples of high enough voltage to indicate "tooth presence".  That gives you the theoretical possibility of detecting 1% wear, i.e., 1 sample less than nominal.  I'll further suppose that tooth presence is 1/2 the waveform, tooth absence is the other 1/2.

    You mentioned 58 teeth at nominal 150 RPM.  That's nominally 145 teeth per sec or ~0.0069 sec per full tooth cycle.  If half of that is tooth presence, that leaves you ~0.00345 sec for at least 100 samples.  Put it all together and you'd look for sample rate of *at least* 30 kHz to get the desired spatial resolution (1/100th of a tooth width) at your particular gear speed.

    Now bear in mind that your 150 RPM is very likely only *nominal*.  There will be speed variations.  These speed variations will cause *some* amount of variation in your measured gear tooth width that has nothing to do with tooth wear or damage.  You'll need to be aware of that and accomodate it in your pass/fail criteria.

8A:  1/2 tooth presence, 1/2 absence.  This is sort of up to us.  They let us choose between two different crankshaft position sensors.  One operates on a 1/2 on 1/2 off signal, with about a 4millisecond pulse width at 150rpm.  The other sensor holds high longer, or low longer, depending on rotation direction.  Oscilloscopes are showing us we want to use the first sensor I've described.  Speed variations, indeed.  We will be using a servo motor to control speed, and the test spec allows a small deviation around 150rpm.

And now, after that last bit of thinking out loud, I've got a much clearer idea of how your encoders can be really important after all.  It's a big enough change that I'll make it a separate post a little later tonight.

[jawilli91]

crossrulz, I was looking for exactly such a link, thank you very much.

[jawilli91]

Kevin_Price:

This is an interesting idea, and makes sense to me, not to imply I know how to use the encoder signal as the sample clock.

Unidirectional rotation is correct.  I'll note, it's actually more like 60 teeth with two side by side missing.  This "gap tooth" or "dwell spot" is a timing spot for the engine, I assume.  So the 58 teeth are consistently spaced around 360 degrees.  We want the tester to ramp up to 150rpm.  Once at 150rpm, we look for the gap tooth.  When the gap tooth comes around (edit: ...comes around AGAIN...), we begin our measurement on the immediate following tooth (after the gap), and capture all data for one rotation back to the gap tooth.  In practice, I'm sure we are collecting data before and after the "single rotation of test" but we can throw this extra data away for the purpose of good/reject judgement.

The math isn't immediately clear to me on your comment about needing a super high resolution encoder.  I'll have to work on that offline.  

Comments on using modules that actually can sample fast enough, is a major thing I'm looking for help here on.  Plan was to use NI-9215 for the analog in, with 100,000 samples/second.  And NI-9401 for encoder, with 100 nanosecond sampling.

The non NI company that has done some testing for us with their proprietary system samples at 1000Hz.  That breaks down to 6.67 datapoints per tooth at 150rpm.  We would've thought that was plenty.  But it isn't, something in their ADC chip for voltage is choking above 100rpm, and we loose the falling edge of the square wave.  But, it doesn't look far off.  If they almost have it a 1000Hz of sampling, I'd think 100,000 samples per second of voltage sampling and 100nanosecond sampling of encoder would be more than fast enough.  But again, I thought this at 1kHz and was proven wrong.

[Kevin_Price]

Here is a very simple working (hopefully!) example for using an encoder signal as a sample clock for an analog acquisition task.  I left several inputs unwired where the channel is being added to the new task.  You can wire up real values to them if the defaults aren't appropriate.

But the very basic idea here is to capture at least 2 revs -- 1 to make sure your gap can be found, 1 more to make sure you get a full rev after the gap.  Each encoder pulse will cause an AI sample to be taken so you'll automatically have correlation between analog sensor and position.

All this does is get you some raw data.  The important work is the algorithm for pass / fail criteria which will probably end up being significantly more sophisticated than checking a "tooth width" at a certain voltage threshold.  There are probably a lot of different kinds of anomalies to consider that may leave different kinds of signature patterns to look for and identify.

But in the meantime, I figured an example was worth sharing to show that the acquisition part of the problem doesn't have to be a major roadblock.

-Kevin P

[mcduff]

---

@Kevin_Price wrote:

But in the meantime, I figured an example was worth sharing to show that the acquisition part of the problem doesn't have to be a major roadblock.

---

There should be a way to nominate someone for early Knighthood before they reach 10k posts.

[jawilli91]

Wow!  Thank you very much for that.  That is very kind of you.

Our decision is to use 3 cDAQ chassis.  It's a bit more expensive than one rack, but it shortens cable runs and makes us worry less about processing time, because we just don't know.

Depending on how things shake out, we will probably quote out to an NI contractor and they may have different advice.  But for now I think we are ok.  I'm grateful to everyone here.

I'll probably come back to ask questions when we start to talk to an NI contractor.  I might also see if I can't make the .vi you've kindly shared in an emulator.

Thanks again.