Multi Turn Absolute Gray Code Parallel interface encoder logic

[bkottaras]

I may have something coming up that uses a multi turn absolute gray code to binary, parallel interface encoder.
I do know how to convert the actual 12 bits of resolution, have done it many times and the logic is there for me.
Never dealt with a multi turn so far though.
I do know that I will need additional inputs for the "turns" bits and registers for the count.
We haven't decided on a vendor as of yet so I cannot ask for help.
Does anybody have any logic available real quick??
Contrologic, SLC whatever so I can take a quick look and take it from there??
Even a screen shot, pdf and such will help.
By the way it will probably be a Danaher or BEI which is now rebadged by Turck? Unless someone else walks in and offers something they do make quickly (lead time will play a big role here)
Thanks in advance.

 

[bernie_carlton]

I'm hazarding a guess that the turn bits will just appear as more bits in the Gray code structure. Assuming the bits within one turn are a power of 2 then it should just look like an encoder with more lines of resolution. In that case, assuming the built in Gray to Natural binary commands won't do here is the general format for conversion. I'm assuming a 16 bit input with I:0/15 being the most significant bit.

 

[bkottaras]

I'm hazarding a guess that the turn bits will just appear as more bits in the Gray code structure. Assuming the bits within one turn are a power of 2 then it should just look like an encoder with more lines of resolution. In that case, assuming the built in Gray to Natural binary commands won't do here is the general format for conversion. I'm assuming a 16 bit input with I:0/15 being the most significant bit.

Bernie,

thanks!!
I do have that part done for the actual bits (12) for the resolution.
Are you saying that the count bits will be bit13 to bit xx which will be treated the same way as the rsolution bits? (reading and converting that is).
I have no clue what we will end up with as far as part numbers but this could be all I need.
Can you confirm?
And the count bits will go to their onw INT location so I can read an integer for turns?

 

[bernie_carlton]

I did a lot of guessing in my answer. You really will have to check with the manufacturers.

If the turn count is presented in a totally separate number then it allows for a count within one turn to be a non power of 2 number. The turn count and the count within one turn will each be interpreted in its own sense (its top bit copied across then xor the rest of the way down.)

It's going to totally depend on how these are presented. Check into a few.

 

[bkottaras]

Thanks.
That's what I thought but wasn't sure.
I have to find out the manyfacturer first, they haven't decided on any particular one as of yet.

 

[kamenges]

Having a Gray Code encoder with a count that is not a power of 2 kind of defeats the purpose of a Gray Code encoder, doesn't it? You can't guarantee that you get only one bit changing per transition if you don't have a power of 2.

I have never used a multi-turn encoder where the counts within a revolution and the number of counts are not treated as separate elements. I'm sure they exist but I have never seen one.

Keith

 

[bkottaras]

Having a Gray Code encoder with a count that is not a power of 2 kind of defeats the purpose of a Gray Code encoder, doesn't it? You can't guarantee that you get only one bit changing per transition if you don't have a power of 2.

I have never used a multi-turn encoder where the counts within a revolution and the number of counts are not treated as separate elements. I'm sure they exist but I have never seen one.

Keith

Makes sense, Bernie was just speculating, the colnclusion wasn't that the count won't be a power of 2 number.
How do they treat the "count" part is my question.
First 12 bits will define the resolution (4096).
That part is OK, no issues.
The rest of the bits, I just assume bit 13 to bit xx will define the "turns". Will this be treated as a separate integer?
Or they combine all bits to determine "turns" as well as "position"?
That was my question.
Can you post a screen shot of sorts?
Or a pdf if any? Or anything on the conversion part?
Just trying to get started.
I still don't know the manufacturer, it will be a while before I find out.

 

[kamenges]

The two portions (position in a turn and the number of turn) are treated independently. So the lower 12 bits (0-11), for example, go through a Gray Code progression once per revolution. Bits 12-23 go through their own Gray Code progression for number of counts. You decode that bit group just like you would the lower 12.

Keith

 

[bkottaras]

Thanks.
That was the question. That is what I assumed, just wanted someone to confirm it.
Never done a multiturn but have done plenty of single turn ones. That part I did not have an issue with!

 

[bernie_carlton]

As a side note - there are Gray code encoders which don't have a power of two count. Examples are 360, 720 etc. Now, you wonder as kamenges did, how is the quality of Gray code maintained on such an animal? We'll I'll tell you.

When you see a Gray code 360 count encoder you'll also see a reference to something called 'excess 76'. Now I digress slightly.

In your mind lay out the pattern to a Gray code encoder. Let's do a 512 count or 9 bit pattern. Isn't it pretty and, except for that pesky most significant bit, symmetrical. Now, starting from the middle, the 255/256 transition, go out the same number of patterns each way. What do you see about these end points? They are 1 bit different from each other (the most significant bit to be exact). No matter how many you go each way this holds.

Let's try going, oh let's say, 180 patterns each way. A total of 360 patterns. Yup, the ends are still still one bit different from each other. Hey let's use just those patterns as the output from a 360 degree encoder! But, you say, zero won't be zero. It will be (let's see 256 minus 180 equals ...) 76! Wait! Haven't I heard that number before?

Yes, there are 360 degree Gray code encoders. But after you do the Gray to natural binary transformation you have one more step. You subtract - let's all say it together - 76. Thus the 'excess 76' remark before. Thus ANY even count can be represented in a Gray code fashion using this 'excess' method.

 

[bkottaras]

Bernie,

awesome stuff.
Good reading material.
I appreciate the add on.
Luckily, so far, haven't had to use an absolute encoder that isn't using the power of 2.
I better keep that in mind for the odd balls!

 

[Peter Nachtwey]

Wow, that is new to me.

The two portions (position in a turn and the number of turn) are treated independently. So the lower 12 bits (0-11), for example, go through a Gray Code progression once per revolution. Bits 12-23 go through their own Gray Code progression for number of counts. You decode that bit group just like you would the lower 12.

Keith

Are you sure? Does only one bit change when the turn rolls over? With two different gray scales how can this be guaranteed?

We treat the gray code as just one gray code for turns and counts within a turn combined. One one bit changes from 0 to 2^n-1 and then wraps.
I will check with our FPGA designers tomorrow.

 

[bkottaras]

I'll be checking this thread tomorrow Peter.
Any replies will be appreciated.
Thanks.

 

[Peter Nachtwey]

I just asked one of our FPGA engineers

We use just one combined gray scale. If you used one gray scale for turns and another within a turn then 2 bits will change every time the turn rolls over. This defeats the purpose of gray scale.

We don't know of anyone that uses a separate gray scale for turns and counts within a turn.

BTW, FPGA = field programmable gate array

 

[bernie_carlton]

Another minor trivia thing.

Gray code is named after the person who invented it. His name is Frank Gray.

Therefore the name Gray code should always be spelled that way.