11mm and 12mm rotary encoders?

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

I never programmed interrupt before but if you can program a timer in isr and have it trigger isr in 15 ms, will it work?

liudr:
I never programmed interrupt before but if you can program a timer in isr and have it trigger isr in 15 ms, will it work?

I have no idea really. As I said I have personally not seen an example of a user interrupt ISR function that handles contact bounce from the user interrupt pin(s)

Lefty

retrolefty:
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:

That's what gray code is for. You have to look at the other pin in your interrupt and see if it changed since the previous interrupt. If the other pin didn't change, the current interrupt is a bounce.

liudr:
I never programmed interrupt before but if you can program a timer in isr and have it trigger isr in 15 ms, will it work?

It might ... but the best way is not to use 'delay()' in your main loop so you don't need interrupts for periodic functions. Save the timers/interrupts for something useful.

delay() is the devil's function.

fungus:

liudr:
I never programmed interrupt before but if you can program a timer in isr and have it trigger isr in 15 ms, will it work?

It might ... but the best way is not to use 'delay()' in your main loop so you don't need interrupts for periodic functions. Save the timers/interrupts for something useful.

delay() is the devil's function.

But the issues is with using encoders where interrupts can be very useful depending on the speed of the encoder is turning. How would one implement software contact debouncing using the user interrupt pins?

Lefty

retrolefty:
How would one implement software contact debouncing using the user interrupt pins?

You wouldn't, you'd use the gray code output by the encoder.

The whole point of using grey code is to detect contact bounce.

If you're talking about a mechanical encoder used as a human input device (not monitoring a motor), then I recommend polling them at regular intervals of 2ms maximum using either a tick interrupt or a cooperative scheduler. This also makes it easy to use several of them in a multiplex arrangement.

dc42:
If you're talking about a mechanical encoder used as a human input device (not monitoring a motor), then I recommend polling them at regular intervals of 2ms maximum using either a tick interrupt or a cooperative scheduler. This also makes it easy to use several of them in a multiplex arrangement.

Yep. Interrupts often sound like a good way to do things but usually they aren't.

A noisy switch is a perfect example of where interrupts cause more problems than they solve.

Keep The Devil's Function* out of your main loop and save interrupts for things which must be done with interrupts.

(*) "delay()"

I replaced delay with wait_on_escape(x), which senses all UI inputs repeatedly for x milliseconds.