Stupid 4024 freq divider question (shaft encoder resolution)

"Fred Bloggs" wrote in message news: snipped-for-privacy@nospam.com...

actually, 1/4 quadrature encode output happen, without

If my challenged parsing skills are working today, I take that to mean that you can make a perfect quadrature encoder, using nothing but the method the OP asked about plus some secret logic that depends on his application in an as yet unspecified manner. And that is something of value to contribute. I guess that would have to be a future contribution.

advance in accordance with direction?

I see only a single post by you on this thread. And it said no such thing. Nor did it give any hint that direction was or might be involved.

In fact, given only your post, and given the OP's actual application, your "solution" would have led him to a system with mysterious misbehavior.

"hunting" will not be a problem.

So, you believe that hunting cannot be affected by the resolution of the position sensor in a position control system? Having designed a few such systems myself, that astounds me.

challenge someone else...

But I can hope to be educated, right?

am assuming here that A is LOW when it's not HIGH

You should not assume that what is obvious to you is true.

A_OUT and B_OUT, as Mac described them, are not anti-phase. Read more carefully. They are true for a pair of input state sets that are not disjoint. This means they can both be true at the same time. And a little more attention to Mac's post (the part you cut) would show that those outputs are, in fact, in quadrature for any monotonic counting sequence.

actually, 1/4 quadrature encode output happen, without

OP needs everything spelled out and I do not feel

advance in accordance with direction?

logic..."- the simple logic would be the A>B or B>A decision.

interesting after the " cannot be done " crowd chimes in.

Clearly your obligations are very limited here.

have.

Here is a summary of your contribution: OP asks: "Can I use two binary up counters to get from one encoding to a courser encoding?" Fred says: "A dual counter with simple logic should do it." This with no indication as to what that logic might be, what it should accomplish, or that the counters might have to be bidirectional.

What, precisely, is the value added by that? If there is any, I cannot fathom it.

"hunting" will not be a problem.

When the OP mentioned "CPR" it was shorthand for "Counts Per Revolution". I cannot tell what your "CPR" input would be in this context.

data at 1/250th revolution- so what is the problem?-

converted to 1/4 resolution.

I take it that by "problem" you mean my claim that "hunting is likely to be worsened". While I hesitate to attempt to educate you about what happens in positioning systems connected to real hardware, with all its non-linearities and dynamics, I will allude to the fact that getting some error feedback for a smaller error can allow finer correction. With your intellect, I am sure you can work out the details.

challenge someone else...

I feel no need or compulsion to prove myself to you. If the OP finds Mac's solution less than satisfactory, I will be happy to lend a hand.

Thanks for the education.

I had a similar project on a telecine (film to video) to do 3 or 4 pulses per frame. It boiled down to using only 1 of the 2 phases BUT you must count both edges meaning divide by 4 needs to count to 8. Detecting both edges used an RC delay and then XOR the delayed and non delayed for a pulse per transition. The secondary phase (which is not counted down) was used to gate the proper state of the counter. This unit had to run forward and backward and generate a new quadrature output at the divide by 3 or 4 for another film (magnetic sound) machine. It required a buffer for the clock pulse delay and a 22V10 for all the counting and gating including the XOR function routed back to the clock input of the 22V10. Changing from RC to delay line should be able run up to the max frequency of the 22V10. GG

am assuming here that A is LOW when it's not HIGH

Yes, that's why I posted.

Irrelevant. What clock can you construct, in this universe, that will cause A_OUT and B_OUT to be anti-phase when, for some inputs, they have the same value?

outputs synchronous to the appropriate edges. You would

Have you ever heard of asynchronous state machines?

rational as anything else you have suggested thus far.

My preference would be that the divide-by-4 counter effect a grey-code sequence.

I take it, by your change of subject and refusal to address my point about disjoint sets, that you are unable to defend your denigration of Mac's post.

You should know, Fred, that it is OK to be wrong once in a while. You would garner more respect if you could admit your mistakes.

"Fred Bloggs" wrote in message news: snipped-for-privacy@nospam.com...

system is going to set itself up for "hunting" by

that may or may not be detented at that. What are you

Now it will jog into mid- 1/250th instead of

Are you claiming that general purpose positioning systems have eliminated hunting? I would love to learn more about this.

If there is hunting, and it is not around an encoder boundary, then decreasing encoder resolution is bound to increase the magnitude of hunting motion.

As you may infer from my statements so far, I am not proposing any particular way of dealing with hunting, or even claiming it mattered to the OP.

field.

Calm down. You are imagining things now.

That sounds like a dual counter with simple logic should do it:

View in a fixed-width font such as Courier.

---- ---- ---- ---- -- A or B | | | | | | | | | input o o o | | | | | | | | | o o o | | | | | | | | | --- ---- ---- ---- ----

------------------- -- | | | Divide | | | output | | | --- -------------------

QUADRATURE SEQUENCE A/4 & B/4 TO CONTROLLER:

---- ---- ---- ---- ---- -- | | | | | | | | | | A | | | | | | | | | | | | | | | | | | | | ---- ---- ---- ---- ----

---- ---- ---- ---- ---- -- | | | | | | | | | | | B | | | | | | | | | | | | | | | | | | | | | | --- ---- ---- ---- ---- ----

------------------- ---- A | | | - | | | 4 | | | ----------- -------------------

--- ------------------- | | | B | | | - | | | 4 ------------------- -----------

Yes, yes, no, and yes, respectively, since I can make a viable, perfect actually, 1/4 quadrature encode output happen, without direction input, and optional direction output if necessary.

Didn't I say that he must add logic to enable/disable the respective counter advance in accordance with direction? If CPR is a programmable input to his controller then your concern about "hunting" will not be a problem. Don't assume that something that is non-evident to you may even begin to challenge someone else...

I think all you have to do is make it so that A_OUT is high when count =

I think this will do it (this is an untested verilog module):

module quad_div(a, b, clk, rst, a_out, b_out) input a, b, clk, rst; output a_out, b_out;

reg a_out, b_out; reg [1:0] count; reg a_in, b_in, b_in_d; // d for delayed

/************************************************* This block syncs a and b to clk, and increments or decrements count on the rising edge of the sync'd 'b'.

always @(posedge clk or posedge rst) if (rst) count

On 25 Feb 2005 11:23:14 -0800, "Randy MacKenna" wroth:

The most simple solution is to add a couple of gears to the motor shaft. Make the ratio of teeth be equal to 1:4 so that 1 revolution of the motor/encoder equals 4 revolutions of the output shaft.

Jim

actually, 1/4 quadrature encode output happen, without

Yes- you understand that correctly, the drawing will be cumbersome because the OP needs everything spelled out and I do not feel like doing that right now.

advance in accordance with direction?

The words in my post were "...sounds like a dual counter with simple logic..."- the simple logic would be the A>B or B>A decision. I am under no obligation to give away the farm- things get much more interesting after the " cannot be done " crowd chimes in.

True- if he's a sloppy reader and does not follow up with any confusion he may have.

"hunting" will not be a problem.

The controller is configurable to any motor- and it is receiving true encoder data at 1/250th revolution- so what is the problem?- there is nothing be "fooled" here- the encoder is being electronically converted to 1/4 resolution.

challenge someone else...

Well- let's see your version of it then.

That's obviously flawed- A and B are then in anti-phase and not quadrature. I am assuming here that A is LOW when it's not HIGH and vice-versa, but maybe...

am assuming here that A is LOW when it's not HIGH

Really? And what is your "clk"?- an unspecified input.

actually, 1/4 quadrature encode output happen, without

OP needs everything spelled out and I do not feel

advance in accordance with direction?

logic..."- the simple logic would be the A>B or B>A decision.

interesting after the " cannot be done " crowd chimes in.

have.

I already drew a waveform that graphically describes what it should accomplish- which is way more than anything you contributed.

Well- that's your problem then. I am not going to waste even as little as 5 minutes drawing an MSI level diagram for some ingrate who may or may not deign to give it the time of day.

"hunting" will not be a problem.

It was the OP himself who said that CPR was an input parameter for his controller's configuration file. What the hell else could it mean?

data at 1/250th revolution- so what is the problem?-

converted to 1/4 resolution.

Apparently you missed the part about it being a router tool- these people set-up their work before each run and the OP apparently thinks

challenge someone else...

You haven't leant much of a hand so far- making a mountain out of a mole hill.

I am assuming here that A is LOW when it's not HIGH

What is "clk"?

There is no conceivable way a single counter can produce true quadrature outputs synchronous to the appropriate edges. You would need to use some dumb doubler thing. Why don't you have the counter count its output as "clk"- that would be as rational as anything else you have suggested thus far.

Controller- shmoller/ there is no way in hell any general purpose positioning system is going to set itself up for "hunting" by adjusting around what by definition is an encoder boundary - and an encoder that may or may not be detented at that. What are you going to do? Jog the thing into what you imagine to be mid- resolution cell? Now it will jog into mid- 1/250th instead of 1/1000th. All of this is dog standard practice- to listen to you, you invented the whole field.

Trust me- there will be little to nothing you will be able to tell me.

The "grey-code" sequence was invented out of necessity of minimizing adjacent resolution cell measurement error in multi-bit encoders. It has little to nothing to do with two separate quadrature one-bit channels.

I will retract the denigration when this magical "clk" input is specified. AFIK, that encoder is outputting A/B, maybe a direction signal, and maybe an index. Which one of those is "clk"?

I am not going to give serious consideration to an underspecified Verilog file- that's nothing more than an ASCII wish. If Mac could write it, why couldn't he simulate it? Or was it he would have to figure what "clk" is?