A question about position encoder measurement

[Axiom]

Hi All,

Hardware: PCI-6602

Software: DAQmx 7.4 Ansi C API

I have a question about position measurement / pulse generation with the 6602.  In this application the idea is to use position measurments to generate a trigger signal (pulse) every so often, i.e. a known linear distance which translates to some integer number N of encoder pulses.  The most obvious way appears to be to connect either the A or B encoder output as the external clock for a pulse generation (ticks) task with HighTicks = N/2 and LowTicks = N/2.  However, the downfall of this method is that direction information is lost; the pulses will be generated whether moving forward or backward when we really only want them when going forward (sensitive to jitter).  On the other hand, the position measurement tasks consider direction (backward motion decrements count), but I don't know how to use them to generate a pulse - I can export the counter output, but how to control the count so that the output pulse has the desired frequency?  From reading the documentation, it doesn't seem as if Z-indexing will help here... .  Any suggestions would be appreciated.

Jeff

[Erik F]

Jeff,

It sounds like the position measurement is on the right track -- you want it to take backward rotation into account.  Basically, you could perform some math on the counter output to derive the inputs for the other counter to generate an output pulse (either high-time/low-time, frequency/duty-cycle, or high-ticks/low-ticks).  Play around with that and let me know.

Erik F

Applications Engineer

National Instruments

[Axiom]

Hi Eric,

Thanks for your reply.  The difficulties here are that the trigger pulses must be generated at fairly precise distance intervals, the intervals are quite small, and the rotational speed of the encoder will also be relatively fast.  So, if I'm correct in what I think you're suggesting, I don't think reading the position in software and doing some math (monitoring the relative position change until it is larger than the desired trigger interval ?) to generate the pulse will work (subject to software delays which will lead to poor accuracy).  I'm fairly confident that it must be done in hardware so I thought of rigging up a small up/down counter circuit - then I realized I'd just be trying to mimmick a piece of the internal TIO circuitry - probably doable but redundant.

After a bit more searching, I came across a couple articles in the knowledge base discussing a hardware reset of the TIO counter for position measurements :

http://digital.ni.com/public.nsf/allkb/044D5F148390F32486256B8A00724B7A

http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/2c18a47f3d6e7a778625688900080fff?O....

They discuss using Z-indexing to reset the counter to a known value (Z-index value) by applying a reset pulse to the Z-input rather than using the actual Z signal of the encoder.  So, I think the job might be accomplished by setting the appropriate Z-index value in ticks (e.g. terminal count - 10 for 1 output pulse every 10 encoder pulses when counting up), and using the (exported) counter output in pulse mode as the Z-input (gate) to cause the reset.  The counter output also serves as the trigger signal I'm trying to generate.  Seems like it should work and I'll post back on the results.

Jeff

[Lorne H.]

Axiom,

Initially I was going to write back to you saying that what you wanted to do was impossible.

But, after a little bit of LabVIEWing I was able to come up with a solution.

An example VI is attached.

Enjoy,

Lorne Hengst
Application Engineer
National Instruments

[Axiom]

Hi Lorne,

Thanks for the response, however I don't have Labview so I can't use your VI.  Maybe we can work things out by just going through the logic.

My setup is as described in the previous post - angular position measurement (ticks), A and B inputs coming from the encoder, counter output (exported - pulse mode, active high polarity) directly connected to the Z-input (GATE) so as to cause the reset when terminal count (TC) is reached.

So far I've been able to almost get things to work properly.  I'm puzzled however as to why I can only get the counter to reset to the Z-index value during 1 of the possible 4 Z-index phases.  Assuming that the TC pulse is asserted (high) so long as the counter is on its last count (count = 2^32-1 = 4294967295), it seems like any of the 4 possible Z-index phases should work.  However, the reset only works if I select the phase which is present as soon as the count is changing to TC, i.e. A High B Low when A leads B and A Low B Low when B leads A.  I would prefer to use one of the other phases which occur later on in the cycle to avoid having an extremely narrow TC pulse (since the TC pulse is cut short by the reset).  Any ideas?

Jeff 

[Axiom]

Oh yea, I forgot to metion that I'm using X1 type decoding.....

Cheers,

Jeff

[Kevin_Price]

Jeff,

I don't know why my earlier post disappeared into vapor, but here's another go at things.

...assuming that the TC pulse is asserted (high) so long as the counter is on its last count (count = 2^32-1 = 4294967295)

I don't think this is actually how the TC pulse duration is determined.  I'm quite sure that in many other counter operating modes where the counter is configured to "pulse on TC", the duration of the pulse is exactly 1 cycle of the counter's source signal.  I think I recall that for encoder measurement, the pulse duration is determined by the (default) 20 MHz internal timebase -- i.e., a 50 nsec pulse.

it seems like any of the 4 possible Z-index phases should work.  However, the reset only works if I select the phase which is present as soon as the count is changing to TC, i.e. A High B Low when A leads B and A Low B Low when B leads A.

Yeah, this is a problem.  I really love the 6602, but this is a real deficiency of the board and/or driver.  As it stands now, you can only perform a hw-reset of the count value when the counter is configured for encoder measurement.  Further, you MUST also specify a specific state for inputs A & B when the hw-reset pulse will occur.  Finally, though the docs aren't particularly clear on this, the z-index pulse is actually more state-driven than edge-driven.  (This may not affect your app, but in general if the z-index input is tied directly to +5V, your quad encoder would count 0,1,2,3,0,1,2,3,0,1...)

Recalling a previous thread I was in, it is probably fortunate that you're in X1 mode.  The count value only changes once per 4 states, so you could probably assign one of the intermediate states (A-HIGH, B-HIGH) as the z-index reload phase.  Maybe there's a solution if you bring another counter into play, especially if the TC pulse is of a fixed short duration such as 50 nsec.

Hmmmm, let's see.  Ideally, you'd like the TC pulse to stay high just long enough to activate the z-index reload and then revert low so it won't cause multiple reloads.  (A few minutes pass...).  I'm stumped.  I suspect there may be a way, but can't come up with it.  The only basic idea I've got would be to use some external logic to fire the right kind of pulse.

You'd need one that would accept the TC pulse as a trigger that would cause the circuit to instantly generate a HIGH output that you'd wire back as the z-index signal.  The circuit would also have to be reset to LOW output on a High-to-Low transition of phase B.  For either direction, you'll encounter the High-High state after reaching TC but before the next High-Low transition of B.  I'm not a circuitry expert, but this functionality feels like a fairly simple flip-flop, such as a Set-Reset variety.

Hope this helps some.

-Kevin P.

[Axiom]

Hi Kevin,

Thanks for your help. 

I don't think this is actually how the TC pulse duration is determined.  I'm quite sure that in many other counter operating modes where the counter is configured to "pulse on TC", the duration of the pulse is exactly 1 cycle of the counter's source signal.  I think I recall that for encoder measurement, the pulse duration is determined by the (default) 20 MHz internal timebase -- i.e., a 50 nsec pulse.

This comment might explain my observations concering the Z-index phase.  What must be happening is the TC pulse is no longer high for the later phases (the 3 coming after that which is present as soon as the count is changing to TC) - therefore no reset.  Hmm, isn't the usual behavior for hardware counters that the TC pulse is asserted for the duration of the terminal count?  I realize the TIO is not your average counter chip, but what reason is there for changing this behavior?

Recalling a previous thread I was in, it is probably fortunate that you're in X1 mode.  The count value only changes once per 4 states, so you could probably assign one of the intermediate states (A-HIGH, B-HIGH) as the z-index reload phase.

That is exactly what I wanted to do but it just didn't work, at least now we (probably) know why.

Maybe there's a solution if you bring another counter into play, especially if the TC pulse is of a fixed short duration such as 50 nsec.

Agreed.  The simplest attempt would probably be to use the TC pulse as external timebase for a pulse generation (ticks) task on another counter.  There might be an issue of whether the pulse is wide enough to serve as an external timebase though.

Hmmmm, let's see.  Ideally, you'd like the TC pulse to stay high just long enough to activate the z-index reload and then revert low so it won't cause multiple reloads.

I thought about this before.  Under my previous assumption that the TC pulse was asserted for the duration of terminal count, I figured the reset would change the count thereby deactivating TC, then, as long as TC could be deactivated before the next timebase pulse then no reloads would occur.  Now the picure is not quite so clear....

You'd need one that would accept the TC pulse as a trigger that would cause the circuit to instantly generate a HIGH output that you'd wire back as the z-index signal.  The circuit would also have to be reset to LOW output on a High-to-Low transition of phase B.  For either direction, you'll encounter the High-High state after reaching TC but before the next High-Low transition of B.  I'm not a circuitry expert, but this functionality feels like a fairly simple flip-flop, such as a Set-Reset variety.

Agreed.  I was hoping to get by without any external circuitry but it seems like this might be the way to go.

Thanks again for your help,

Jeff