11mm and 12mm rotary encoders?

It appears that their width is 11.7mm and 12.4mm, respecively. That would be my guess how they got their name.

I noticed that too. Kind of superficial difference. "Hey, we have two types of rotary encoders, they kind of differ only by 10 percent in a minor dimension". Should be other reason?!

For potentiometers the normal dimension to use is the shaft diameter. Knowing what sized hole to drill in the front panel
is also useful.

Borh series have 6mm diameter shafts.

Riva:
Maybe it does not refer to a measurement dimension but to case style. EN11 is cast metal body & shaft, EN12 is pressed metal body & plastic shaft.

Thanks Riva. I start to grow a feeling that there is no huge difference between 11mm and 12mm encoders.

Other than one has parts that are a bit more durable, and encoder is and encoder. They Give pulses as you rotate them. The various sizes have more to do with mounting than with function.

kf2qd:
Other than one has parts that are a bit more durable, and encoder is and encoder. They Give pulses as you rotate them. The various sizes have more to do with mounting than with function.

Boy I disagree. The first encoders I bought were mechanical ones with detents. Then I bought several optical ones that give a whole lot more resolution and no freaking detents. I love these encoders, they are the nicest thing I have as far as user interface parts. They also breadboard really well.

http://www.ebay.com/itm/370592502534

It is so choice. If you have the means, I highly recommend picking one up.

That's the whole reason I was buying these encoders, for user interface. A rotary encoder is analog/digital in one. You can control speed with how fast you turn it, with a large range of speed. With buttons, you cannot press them too fast.

http://arduino.cc/forum/index.php/topic,130945

JoeN:

kf2qd:
Other than one has parts that are a bit more durable, and encoder is and encoder. They Give pulses as you rotate them. The various sizes have more to do with mounting than with function.

Boy I disagree. The first encoders I bought were mechanical ones with detents. Then I bought several optical ones that give a whole lot more resolution and no freaking detents. I love these encoders, they are the nicest thing I have as far as user interface parts. They also breadboard really well.

http://www.ebay.com/itm/370592502534

It is so choice. If you have the means, I highly recommend picking one up.

I can't agree more with that statement. My first playing with quad-encoders was with one of those cheap $5 mechanical ones. Between contact bounce and the mechanical de-tents not always matching up well with the contact transition positions, I was pretty frustrated with the whole concept of using on in any of my projects.

Then I found a web site (gold electronics) that was selling some nice surplus (new old stock) high grade optical encoders for $5 and boy what a different (I bought 4 and they sold out quickly so don't look for them there now). It's a great device to use if you can be patient and look for a good one via surplus or used on E-bay. The cheap mechanical ones are really garbage, I'm not saying that with enough tweaking of code and you can't make a mechanical one somewhat work, but I personally will never waste my time using one. I still have 3 optical encoders left.

Lefty

The mechanical ones I bought for less than a dollar a piece are fine enough for user interface. I'll make some videos hopefully today.

liudr:
The mechanical ones I bought for less than a dollar a piece are fine enough for user interface. I'll make some videos hopefully today.

Sure if you hate the user. Steve Jobs would never have approved the use of a mechanical encoder. :smiley:

Lefty

Works fine for me! I don't care much about Steve Jobs or his fruit company

Mechanical encoders have their place, and opticals have their place. I have designed a welding machine that used 10 of the $2.58 mechanical encoders and the users loved them. Previously they had used optical encoders and they were almost useless. For an operator input the small mechanicals fit the bill well. for motion monitoring the optical encoders are much better.

kf2qd:
Mechanical encoders have their place, and opticals have their place. I have designed a welding machine that used 10 of the $2.58 mechanical encoders and the users loved them. Previously they had used optical encoders and they were almost useless. For an operator input the small mechanicals fit the bill well. for motion monitoring the optical encoders are much better.

One thing I don't like about the mechanicals is their stated lifetime. It's usually pathetic. Is it OK to use that on a machine that is used two shifts a day?

retrolefty:
Sure if you hate the user. Steve Jobs would never have approved the use of a mechanical encoder. :smiley:

I like the clicky ones. I've never had any problems with them, and I buy cheap.

JoeN:

kf2qd:
Mechanical encoders have their place, and opticals have their place. I have designed a welding machine that used 10 of the $2.58 mechanical encoders and the users loved them. Previously they had used optical encoders and they were almost useless. For an operator input the small mechanicals fit the bill well. for motion monitoring the optical encoders are much better.

One thing I don't like about the mechanicals is their stated lifetime. It's usually pathetic. Is it OK to use that on a machine that is used two shifts a day?

For cheap encoders with 20,000 cycles minimal you are talking about say 20 year for a machine and 1,000 cycles per year or 3 turns a day, no it's not proper. But for an arduino project that gets used for up to 3 years on an occasional basis and it becomes a lot more proper. FYI, I'm not making 20-year machines. The user can also switch out bad encoders and replace them if they need to. An LED in the optical encoder has maximal life time of up to 100,000 hours so 7 years non-stop. So it would also not last 20 years. You need something quite expensive to keep your machine working and you need people to maintain your machine too. I am talking about hobby projects. Don't take me seriously. :wink:

fungus:

retrolefty:
Sure if you hate the user. Steve Jobs would never have approved the use of a mechanical encoder. :smiley:

I like the clicky ones. I've never had any problems with them, and I buy cheap.

The clicks are detents.

You can get mechanical and optical encoders with or without detent.

One problem I had when playing with mechanical encoders was pretty bad contact bounce. I like to use encoders in interrupt service and have not yet seem a nice example of contact de-bouncing code that works well inside a ISR function? So that leaves external R/C de-bouncing components? Optical encoders don't bounce, ever. :smiley:

Lefty

I wait 15ms to debounce in software. In ISR, you can do that too. After debouncing I also assign states to the different values of grey code so if I see 00 01 10, I wait until the grey code is back to 00 before doing anything. My library is not isr. But there is no reason not to put it in isr. If you are interested, it is here together with phi_prompt library in a zip folder:

http://code.google.com/p/phi-prompt-user-interface-library/downloads/detail?name=phi_interfaces_V100.zip&can=2&q=

The library includes rotary encoders, buttons, matrix keypad, analog buttons, serial keypad etc. Everything runs on keypad.getKey().

liudr:
I wait 15ms to debounce in software. In ISR, you can do that too. After debouncing I also assign states to the different values of grey code so if I see 00 01 10, I wait until the grey code is back to 00 before doing anything. My library is not isr. But there is no reason not to put it in isr. If you are interested, it is here together with phi_prompt library in a zip folder:

http://code.google.com/p/phi-prompt-user-interface-library/downloads/detail?name=phi_interfaces_V100.zip&can=2&q=

The library includes rotary encoders, buttons, matrix keypad, analog buttons, serial keypad etc. Everything runs on keypad.getKey().

Inside ISR delay() doesn't work and millis() doesn't increment, so how do you delay 15msec inside a ISR? Not saying there in not a way I just haven't come across a clean useful code example. Also be aware that the bouncing contacts will often mean that there will be another interrupt pending waiting to re-enter the same ISR as soon as the first one completes no matter how long you wait inside the ISR, it gets hairy I think.

Lefty