Hi all. This is my first post.
I have a number of DC motors and their speed controllers - which all require pulses to change their motor speeds.
I wish to use them for another purpose, where I want to start them and control their speeds with a rotary encoder switch.
These motor controllers require pulses to make them run the motors faster on one terminal and to slow them down on another terminal.
I determined that I can do this with a rotary encoder, but need to separate the pulses resulting from CW and CCW turning of the encoder.
This is my plan, but a first breadboard attempt didn't work.
I just connected a couple of LEDs to the output of my 'decoder' to try it out, so I could see the pulses on either output.
Am I missing something or have I just made a logic mistake somewhere?

 

Generally you only require A & B pulses for direction indication, if just rpm then one pulse should be sufficient.
Do you have a make/model of the DC drives?
Max.

 

You are quite right Max. That's all I need. BUT I need them on TWO terminals. One turning the dial clockwise (for faster) and one turning the dial anti-clockwise (for slower).
The A and B pulses get both generated turning the dial EITHER way. So that doesn't help at all.
What my circuit attempts to do is send the A pulses out ONLY when turning clockwise and the B pulses ONLY when turning anti-clockwise.
The decoder chip is meant to 'know' which direction I'm turning by the order in which the pulses arrive from A and B.

 

Nobody have any input for me?

 

Hi all. This is my first post.
I have a number of DC motors and their speed controllers - which all require pulses to change their motor speeds.
I wish to use them for another purpose, where I want to start them and control their speeds with a rotary encoder switch.
These motor controllers require pulses to make them run the motors faster on one terminal and to slow them down on another terminal.
I determined that I can do this with a rotary encoder, but need to separate the pulses resulting from CW and CCW turning of the encoder.
This is my plan, but a first breadboard attempt didn't work.
I just connected a couple of LEDs to the output of my 'decoder' to try it out, so I could see the pulses on either output.
Am I missing something or have I just made a logic mistake somewhere?

View attachment 153687

I suggest you download digital works, and model your circuit. It's the perfect tool for learning digital electronics and gate logic. You can test your circuit to your heart's desire before attempting to build it.

 

Thank you very much cmartinez! I just downloaded it and will explore tomorrow.
Cheers,
Joe

 

There is this -

https://www.brainy-bits.com/l9110s/

And then PSOC can implement a rotary encoder component -

https://community.cypress.com/thread/10200?start=0&tstart=0

http://www.cypress.com/comment/418006

Speed control by PWMs (also inside PSOC).


Regards, Dana.

 

Hi all. This is my first post.
I have a number of DC motors and their speed controllers - which all require pulses to change their motor speeds.
I wish to use them for another purpose, where I want to start them and control their speeds with a rotary encoder switch.
These motor controllers require pulses to make them run the motors faster on one terminal and to slow them down on another terminal.
I determined that I can do this with a rotary encoder, but need to separate the pulses resulting from CW and CCW turning of the encoder.
This is my plan, but a first breadboard attempt didn't work.
I just connected a couple of LEDs to the output of my 'decoder' to try it out, so I could see the pulses on either output.
Am I missing something or have I just made a logic mistake somewhere?

View attachment 153687

I may be misreading the logic here, but I think switching from NAND to NOR gates will provide the desired behavior.
*** EDIT: Nope! I had it wrong... I've replied down below with a better solution.

 

All very interesting replies, thank you! Got a bit more reading done - and more to think about.
Dasly, I suddently don't have much spare time to devote to testing and trying things. But very soon. I'll update what I've learned then.
Cheers,
Joe

 

Ahhh... just played around in simulation a little. I had it all wrong! I was misunderstanding how the active-low rotary encoder signals were behaving with the flip-flop.

I found a way to make it work with almost the same components, using AND instead of NAND in this case. I've switched to using pull-down resistors instead of pull ups, and momentarily connecting to supply voltage when the switches close (active-high behavior now.) This change got the flip-flop clock responding as I'd expected, and then switching from AND to NAND got the outputs working as expected.

I'm sure there are many ways to make this work, and I don't know if you're stuck with active-low and/or NAND gate construction, but this is at least one possible solution to consider.

 

Hi ebeowolf, many thamks for going to all that trouble! I will certainly give that design a try out.
What a great community this is!
Cheers,
Joe

 

Just be careful with small angle path encoders during low speeds or direction reversing. They use to bounce a lot.

I'd advise to debounce it via software counting two consecutive steps on the same direction before taking it for real movement.

Regards, Ciro.

 

Hmm, I hadn't even thought of that... something else to consider.... Thanks!

 

I agree with Ciro, what he's talking about is called hysteresis, and it's a must for obtaining reliable and stable results in a circuit such as this one.

 

Just be careful with small angle path encoders during low speeds or direction reversing. They use to bounce a lot.

I'd advise to debounce it via software counting two consecutive steps on the same direction before taking it for real movement.

Regards, Ciro.

At first I was worried about the subtleties of flip flop and logic gate timing, but then I realized the outputs are meant to be driving mechanical relays (at least according to the attachment in the original post.) I think the slow response time of a mechanical relay will eliminate those problems, and I think it will effectively ignore bounce from the rotary encoder as well.

Of course, even if I'm right about all that, then you've got the contact bounce on the relay outputs to worry about. Depending on what the original intended source of pulses for motor control was, the motor controller may or may not have debouncing already.

 

Hi ebeowolf, many thamks for going to all that trouble! I will certainly give that design a try out.
What a great community this is!
Cheers,
Joe

No trouble at all. I enjoy working through puzzles like this! Fair warning though - I'm no expert, and they are still puzzles to me too! There are no guarantees that I've got it right, although I'm fairly optimistic about this one.

 

At first I was worried about the subtleties of flip flop and logic gate timing, but then I realized the outputs are meant to be driving mechanical relays (at least according to the attachment in the original post.) I think the slow response time of a mechanical relay will eliminate those problems, and I think it will effectively ignore bounce from the rotary encoder as well.

Of course, even if I'm right about all that, then you've got the contact bounce on the relay outputs to worry about. Depending on what the original intended source of pulses for motor control was, the motor controller may or may not have debouncing already.

At first I was worried about the subtleties of flip flop and logic gate timing, but then I realized the outputs are meant to be driving mechanical relays (at least according to the attachment in the original post.) I think the slow response time of a mechanical relay will eliminate those problems, and I think it will effectively ignore bounce from the rotary encoder as well.

Of course, even if I'm right about all that, then you've got the contact bounce on the relay outputs to worry about. Depending on what the original intended source of pulses for motor control was, the motor controller may or may not have debouncing already.

I wouldn't tale relays for reference. They're too slow and there might be no relay mechanical bouncing while the microcontroller will count thousands of them.
If you write a small routine to print to the terminal every change of encoder's switches maybe your gonna see that when you slowly move the axis.

Regards, Ciro.

 

What kind of resolution are you needing?
I have made a quadrature encoder from a dual slot opto, can also be done with two separate ones if needed, no problem with need for debounce etc.
Max.

 

I overlooked that the attached image still shows the original idea with relays. They will not be used at all.
So forget about the output to those. The output will go straight to the input of the controller.
I don't need much resolution, nor precision. I doubt that even some bounce is going to be an issue. This is just a way to quickly set a speed of the motors to a range -starting from 0 each time....
Sorry, I'm still not at home to actually try out some of the suggestions.

 

I overlooked that the attached image still shows the original idea with relays. They will not be used at all.
So forget about the output to those. The output will go straight to the input of the controller.
I don't need much resolution, nor precision. I doubt that even some bounce is going to be an issue. This is just a way to quickly set a speed of the motors to a range -starting from 0 each time....
Sorry, I'm still not at home to actually try out some of the suggestions.

Just curious if you've made any progress on this project. I'm intrigued by it and I'd love to know how it turns out (and of course I'm happy to do more brainstorming and try to help if I can.)