‎09-14-2007 07:59 AM
‎09-14-2007 08:45 AM
Sounds like a tricky app. There tend to be a lot of frequency components in rotational measurements on geared shafts. These will influence your measurements. Also, inferring wear mass via flank tolerance sounds like a very subtle measurement requiring very high signal to noise. So I think you've got your work cut out for you from a physics standpoint.
In the data acq world, however, maybe I can help. First, the terminology. It sounds like you've got some reference position that produces 1 pulse per rev. You'd like to grab 1 sample of position on each of these pulses. You're calling this pulse the "trigger." However, in the data acq world, that sort of operation would usually call the pulse an "external sampling clock."
Step 1: Make sure you're treating that 1-per-rev pulse as an external sampling clock, not as a trigger.
Next, how's your resolution? An 18k incremental encoder is pretty high-resolution, but is it really enough to detect the small angular difference caused by mass loss through wear? Have you worked out the geometry to know the linear distance (at the pitch diameter) represented by 1 encoder count? For good trending and measuring, it's typical for the measurement device to have 10x the resolution that you need to discriminate.
A different approach to try to gain resolution might be to measure time between pulses. Depending on your board, you can get either 20 MHz or 80 MHz time resolution. Then, depending on your linear speed at the pitch diameter, you can figure out how much linear distance is represented by 1 time count.
-Kevin P.
‎09-14-2007 09:03 AM
Thanks for that very fast answer. And you're right: I'm coming from the physical side of the application...
Concerning wear and resolution: I'm working with worm gears which produce enough wear. My theoretical resolution is 15mg (or 1/200deg worm-wheel) and estimated wear is 120+mg per 30.000 load cycles. That should be sufficient.
I also tried time-measurement between pulses but that only showed that the engine speed is fluctuating by +-1 rpm (which is to much for that sort of measurement).
To keep it short: The external sample clock gives a clear impulse, but the DAQmx task doesn't respond to that...
‎09-19-2007 09:35 AM
What have you done to configure your DAQmx task to use that particular external pulse as a sampling clock? Can you post your code? If you can also post a screenshot of it, that'd be even better (for me) b/c I don't have LV near my network PC.
-Kevin P.