Ben,
First the executive summary: Sorry, No Can Do.
You won't be able to generate a sampling clock pulse on the transition to each of the 4 quadrature states. Here's a thread I was involved in where a similar question was asked. If you need to correlate in exactly that manner, you may want to pick up a quadrature decoder chip such as the 7084. It'll generate a "pulse" whose width is controlled by selection of an RC time constant during circuit build. I put "pulse" in quotes because it isn't truly a TTL signal due to the long transition time. I would recommend that you plan on adding a Schmitt trigger to square it up, perhaps another to re-invert it back to original polarity.
However, all that being said, you may be better off using an internal sampling clock to drive analog and encoder position acquisition anyway. On many encoders I've used, the transitions are NOT perfect 1/4 divisions of the cycle. You can sometimes see this on the spec sheets where the A to B relative phase is given as, say, 90 +/- 15 degrees. There will also be a tolerance on the phasing of A's rising and falling edges, maybe 180 +/- 10 degrees (it's often a little tighter than the A to B phasing).
In practice, I've typically found that these deviations tend to be systematic rather than random. Of the company's 1000 similar encoders, the phase stays within the range 90 +/- 15. With my 1 instance, the phase may be 84 +/-3 around a full rev of the encoder. The point is that if you generate pulses with the quadrature transitions, the samples still won't *really* be equally-spaced in position. They'll just think they are.
I'd suggest at least considering high-speed sampling with an internal clock that's shared by both tasks. Then do a little bit of curve-fitting / interpolation to the data when you need to derive more precision.
Re: frequency division. You have to select a specific edge (either rising-only or falling-only) as the active edge. Your counter will then ignore the other type of edge. Also, you'll need to specify the # of edges each for the idle and pulse states. These must each be >= 2. So you can't divide by 1 - the best* you can do is to divide by 4. (*Technically, you could sort-of divide by 2 if you configure the counter to pulse rather than toggle its output. However you can't control the pulse width, and as I recall it's fixed at 50 nanoseconds.) Write back if you'd like to see an example.
-Kevin P.
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
