Go Down

Topic: 11mm and 12mm rotary encoders? (Read 2447 times) previous topic - next topic

fungus


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


I like the clicky ones. I've never had any problems with them, and I buy cheap.
No, I don't answer questions sent in private messages (but I do accept thank-you notes...)

liudr



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.  ;)

liudr



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


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



The clicks are detents.

http://en.wikipedia.org/wiki/Detent

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

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.  :D

Lefty

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().

retrolefty


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

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?

retrolefty


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

fungus


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.  :D


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.

No, I don't answer questions sent in private messages (but I do accept thank-you notes...)

fungus


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.
No, I don't answer questions sent in private messages (but I do accept thank-you notes...)

retrolefty



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

fungus


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.

No, I don't answer questions sent in private messages (but I do accept thank-you notes...)

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.
Formal verification of safety-critical software, software development, and electronic design and prototyping. See http://www.eschertech.com. Please do not ask for unpaid help via PM, use the forum.

fungus


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()"
No, I don't answer questions sent in private messages (but I do accept thank-you notes...)

liudr

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

Go Up