quadrature encoders

JTC

To anyone. I am new to the propeller and am trying to decide if it is the chip I want to use.

Has anyone used a quadrature encoder to read the feedback from a servo motor ?
The encoder is a 250cpr and will be used as a Z axis CNC plasma table.
What kind of speeds will the propeller chip read ?
Thank You
Jim

Beau Schwabe

Jim,
·
Jeff Martin has worked out a very nice object that will support up to 16 rotary encoders.· I have attached the file, and derived·some·of the·formulas
from the document that allows you to calculate the number of 'clock cycles' and maximum RPM the encoder·can operate.
·
Total Cycles = 144 + 50*(Number of Encoders-1)
·
RPM of Highest Resolution Encoder = XINFreq * PLLMultiplier / Total Cycles / 2 / MaxEncPulsesPerRevolution * 60
·
·
Example 1: Using a 4 MHz crystal, 8x internal multiplier, 16 encoders where the highest resolution encoders is·250 pulses per revolution:
·········· Max RPM = 4,000,000 * 8 / 894 / 2 /·250 * 60 = 4,295 RPM

Example 2: Using same example above, but with only 2 encoders of·250 pulses per revolution:
·········· Max RPM = 4,000,000 * 8 / 194 / 2 /·250 * 60 = 19,793 RPM
·
Example 3: Same as Example 1 above except a 5MHz crystal is used with a PLL value of x16·:
·········· Max RPM = 5,000,000 *·16 / 894 / 2 /·250 * 60 = 10,738 RPM

Example 4: Same as Example·2 above except a 5MHz crystal is used with a PLL value of x16 :
·········· Max RPM = 5,000,000 *·16 / 194 / 2 /·250 * 60 =·49,484 RPM
·




·

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

Post Edited (Beau Schwabe (Parallax)) : 11/22/2006 6:25:22 PM GMT

JTC

Wow ! you guys are great.

I guess I need to invest in the propeller development kit .

Thanks

JTC

Well my propeller came today so I can get to work learning it.
Thanks for your help.
Jim

Richard S.

I worked through the math for max. rpm's and do not come up with the same results.· Am I missing something?· Brackets to delineate sequence of steps would be helpful.·

If a separate cog counts each axis, i.e. X, Y, Z...why the increasing overhead for software as cogs (encoders) are added?· Can't each cog dump the results into shared memory independent of the others?

I am new to Propeller.· Board is on order.· Fascinating chip!·

Richard in Michigan.

Richard S.

I figured out the math...just sequentially do the divides and multiplies.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Richard in Michigan

epineh

Keep us informed how you go Jim, myself I am interested in using a rotary encoder on a stepper motor, using it to check for lost steps, and of course correct on the fly, similiar to servo's, but at much less cost both in motor's and drivers.
I have built my first 3-axis timber router and having a ball with it, a friend used a similiar machine to rout a PCB for a Prop development board, I have just finished getting it setup, ran the obligatory flashing LED program's today.
The intention is to use a Prop for the brains of my next machine, with the features I mentioned, and maybe a nice LCD display to Woo onlookers...

Cheers.

Russell.
·

JTC

· I got mine about a month or so ago and have been trying to get my old brain around the programming. A lot different than what did before. I think it is the fact that I have 8 processors and I am trying to figure out how to make use of them.

The stepper motor idea is a good one. I had thought something similar but didn't feel I am up to the programming that needs to be done. It is coming... just need to spend a bit more time expermiting with it.

I do have my first product about 90% done and·my customer is pleased with the results so far.

I·use a 5 inch color video monitor instead of the LCD. I bought the LCD but it is so easy to use video I used it. You can get a game video flat screen at Marlin P. Jones online for about $50.00 makes programming more enjoyable for sure.

Jim

scotta

JTC,

I have used a variation of the QuadratureEncoder routine up to it's limit.

A 4096 ppr encoder will clobber it, but 250 ppr on a single cog is not an issue.

I have a single Cog reading Position, velocity and acceleration on 4 axises
and with 4096 ppr encoders, the cog is asking for more to do.

This chip is fantastic:
http://forums.parallax.com/forums/default.aspx?f=25&m=181024

Scott

cgracey

I am curious to hear from you guys just what kind of·performance you could actually use in a quadrature encoder object.

Is the sky the limit, or is 30k rpm at 4096 counts per revolution (2.048 MHz) beyond necessary? Just how much is needed to put things well in the black for an advanced project of yours? And for how many concurrent channels, ideally?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

OzStamp

Hi Chip
Hope you and fam are all well.

A typical small/medium size PLC has 2 to 4 high speed encoder inputs.
Normally the first 4 or 8 inputs are dedicated to high speed pulse counting in either single
or quadrature input mode..( A + B phase + optional Zero marker for cntr reset )
Typical input frqs are in the 100KHZ for most small/medium type plcs's .
Special input cards that cost megabucks will count around the 1-2MHZ not aware of all
the ins and out of all the brands .. sure somebody can add to my details.

Once you start looking at Motion Controllers ..ie feedback for positioning loops for feedback..
pule rates are a little higher .. some controllers can capture up to 10MHZ easily ( dedicated hardwarre)
with associated loop update times of 50 to 100 micro_secs typcially etc etc... (PID loops for positioning)

Cheers
Ronald Nollet Australia

scotta

A table top cnc machine with encoders on the motor won't need much more
than the current chip has.

An external decoder IC might be necessary if we start using rail mounted
Heidenhain encoders.

Scott

Skogsgurra

I am possibly missing something - or someone else is - but there are two distinct type of encoders; absolute (mostly Grey) encoders and incremental (the channel A/channel B types). The example given in Rotary Encoder.spin is for an absolute Grey encoder and can not be used for the more common (and usually cheaper) incremental encoders. For the latter, I have used an encoding technique that is less known, but very fast. I have tested it in Spin and it can count close to 10 000 edges/second in high-level language.

I haven't got to the ASM part of the Prop yet, but assuming that assembler is around 100 times faster, it should be able to do 1 MHz edge rate. Perhaps someone could put together an ASM piece of code to test it? Or wait a week until I have done it myself.

See my post "Code Decodes Encoder" for a description and a piece of Spin code.

T Chap

The rotary object does work for A/B encoders, I use it everyday with multiple A/B types. I think there is some misunderstanding with the document, and there was some conversation about this a long time ago, I'm not sure why it is defined as is.

Post Edited (TChapman) : 3/27/2007 9:03:43 PM GMT

Skogsgurra

OK, I have had a more thorough look at the Rotary Encoder.spin.

It is written for the incremental encoder type. And can handle lots of them.

The term Grey Coded is being used in the functional description and that is what misled me. Gray Code is usually reserved for absolute encoders having the typical "straddling" pattern and usually something like eight - twenty tracks that are read in parallel.

The term Grey Coded is correct, though, (what else did you expect frpm Prop guys?) in the sense that only one bit position changes at a time.

The technique used is xoring to detect edges and then checking bits to see if it is a forward or backwards movement. The usual and/or chain is avoided - which is very good.

My version does it a little different. I shift "old pattern" left twice and add "new pattern" to get a number ranging from $0 to $F. I then use the number to look up the increment in a table containing 0 (no movement), +1 (fwd) and -1 (bwd) to add to the ctr. It will be very interesting to compare speeds between the two versions. But, as I said, I have to get warm using assembler before I can do that. Anyone else?

Graham Stabler

I had the same confusion with the term gray code, so much so that I misread the description of "up to 16 2-bit encoders" as "16-bit encoders" and ignored it! Doh!

Actually because I needed speed it made more sense for the encoder code to be inline with my assembly, in those cases you can probably do better than the object anyway because you don't have to deal with hub ram.

Are you wondering about encoder read mode for the counters in Prop MkII Chip?

Graham

cgracey

Skogsgurra said...


My version does it a little different. I shift "old pattern" left twice and add "new pattern" to get a number ranging from $0 to $F. I then use the number to look up the increment in a table containing 0 (no movement), +1 (fwd) and -1 (bwd) to add to the ctr.

That's the most efficient technique I've seen. You could use a single long to hold all 16 of the 2-bit lookup values. Use the old+new 4 bits * 2 as a SHL·argument and then do a SAR #30. Then, you will have a 32-bit (-1, 0, or 1) value that you can add into you accumulator. It would take the least amount of code, anyway.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

Skogsgurra

I think you got it Chip!

I am trying to get a working code in asm, but I need some experience with the Prop asm before i can do it effieciently. I guess that you could do it in a few minutes - please show us.

Regarding what is needed in terms of resolution and speed, there's a lot of exageration. I do a lot of paper machine drive work. The accuracy needed there is nowadays around 0.005 % in the speed loop. That can be achieved with a 500 PPR encoder (although the standard seems to be 1024 PPR nowadays) and some smart coding using reciprocal measurement over a limited time. Usually between 1 and 5 milliseconds. Motors seldom run faster than 2000 RPM in such applications.

On the other hand, a machine-tool servo may need a 4096 PPR encoder, or better. Motors reach up to 10 kRPM, so I think that is where you need to be. If using a linear encoder with 1 microns resolution and a maximum speed around 1 m/s you arrive at 4 000 000 edges/second. That would be a possibility, I think, with the 4xOLD+New technique. Boy, do I want to test it in the Prop!

Jeff Martin

I agree, that's a great way to do it:·short code and very fast!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Jeff Martin

· Sr. Software Engineer
· Parallax, Inc.

Richard S.

I have been working with the rotary_encoder.spin. I have a working 4 encoder model using vga_text.spin and keyboard.spin. It will accept simple keyboard commands and display encoder values. I have just started work on developing a menu for other functions. What I need to develop is a way to display a numeric string from the keyboard, justify it in reference to a decimal point, pad zeros and then strip out the decimal point and convert the numeric integer to binary. My encoder readout displays green positive numbers and red negative numbers. If interested, I can post my work in progress.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Richard in Michigan

Graham Stabler

Well Skogs,

I actually needed some neat and fast encoder reading action so here it is attached using your idea and Chip's single long lookup table. Its just some raw code to be included into a proper object and it just does the one encoder however it works fine.

Graham

here's the main part of the code, short and sweet huh!

entry                   mov   combined, #0         
                                                
:loop                   mov   look, lookyup        ' load look up table
                        mov   state, ina           ' Read inputs
                        and   state, pinmask       ' Mask
                        shl   combined,#2          ' Shift old bits left
                        or    combined,state       ' combine to provide 4 bit word
                        and   combined,#15         ' mask off really old bits
                        mov   shift,combined       ' Make ready to use as index 
                        shl   shift,#1             ' Shift to multiply by two
                        shl   look,shift           ' Use to shift look up table bits to bits 30,31                                       
                        sar   look,#30             ' Shift to bits 0 and 1 keeping the sign                        
                        
                        adds  count,look           ' Add the result to the count                             

                        jmp   #:loop 

pinmask                 long    %0011
count                   long    0
combined                long    0

'                                 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
lookyup                 long    %00_01_11_00_11_00_00_01_01_00_00_11_00_11_01_00  


state                   res     1
look                    res     1
shift                   res     1

JTC

Good job Graham.
Jim

Graham Stabler

Thanks Jim, it was harder than it should have been, I shifted twice to multiply by two at first (sounds feasible, doh) and later just had a one where I needed a #1, very confusing and it kids your mind into thinking its OK.

I've got this code reading an encoder then dividing down the pulse stream to send to a stepper motor, all so I can convert a HP printer into a Zcorp 3D printer without doing an entire printer's firmware. The propeller monitors the encoder and when it sees the high frequency of a paper feed it goes into sync mode, its lind of spooky.

Graham

rjo_

Graham...

You could also use it to make 3D lenticular prints... I have a whole bunch of film!!!

Propeller holograms anyone?

Talk to Graham[noparse]:)[/noparse]

Rich

Graham Stabler

Not unless they can be made from cornstarch.

Skogsgurra

Thanks Graham!

It took me some time to understand what you did to my algorithm. It was the sign part that I had to think about. Neat!

Now, how fast can it go? Anyone tested already? I have been too busy to do any real work with the Prop for a long, long time. But I will surely set up a test as soon as I get the time for it.

I have one little problem, still: The lookyup long seems to be backwards. I always have bit # 0 to the right (LSB). Does it really work when you reverse it?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Skogsgurra

Sorry, I didn't read the comments. Shouldv'e done that. I see now, why it works with reversed data; the lookyup is symmetric, it doesn't matter from which direction you read it!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Graham Stabler

12 commands in the loop (including the jmp) so I assume that is (1/80000000)*4*12 seconds per loop, 1.6Mhz 50krpm for a 500cpr encoder.

BUT at the moment it does not write the data to main memory or anything so that would add a bit more delay.

Graham

JTC

Graham,
·· Have you done a speed test on you code.
Just wondering ?
Jim

Graham Stabler

No but I can soon add a pin toggle and hook up the scope.

Graham

Skogsgurra

That's very good, Graham. I seldom need more than 50 kHz in a typical high-precision drive. (1024 PPR and 3000 RPM). Another idea: Out of the 16 possible combinations, four are FWD and four are BWD. The remaining eight combinations represent illegal states that never shall occur. It would then be an easy matter to check for them (zeroes in the lookyup) and either shut down or issue a warning. Either directly (I guess that that wouldn't be very popular) or after a number of illegal combinations has occured - possibly within a prescribed time.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔