PDA

View Full Version : Speed Encoder



hank van buren
01-07-2006, 10:44 PM
This program shows the use of any stepper motor can be converted for the use of a wheelencoder or a speed controller simply by driving the stepper motor, it will make a perfect magnetic encoder, with one exception instead of getting 8 pulses per revolutions you will get 48 and it is more economical. This system is currently used on www.gpscontrolledvehicle.net (http://www.gpscontrolledvehicle.net) to maintaine a constant speed.

Post Edited (hank van buren) : 11/11/2007 5:21:16 PM GMT

Tronic (Greece)
01-10-2006, 03:48 PM
I tested it yesterday and its working great!

Is there a way to make it understand and the direction of turning also?

Thanos

Bruce Bates
01-10-2006, 06:25 PM
Thanos -

Presuming you have two wheel encoders, you are always turning in the direction of the lagging or slower wheel, presuming there is no spinning or slippage of either wheel.

Regards,

Bruce Bates

Tronic (Greece)
01-10-2006, 06:58 PM
What I mean is if you can use a single·stepper in reverse connection to read the same signals you feed·it to turn either clockwise or counterclockwise in normal operation.

The above code uses only 1 pin of the four that a stepper, what if I use the rest in conbination to intepret if its turning one way or another like the some encoders with two outputs do? I think that it can be done.

I tried to implement it but stuck on the programming side. For this I connected the common of the stepper to the ground and the rest four pins of the stepper on four ports of the stamp thru 470 resistors.

Thanos
·

Clock Loop
01-10-2006, 07:07 PM
Tronic (Greece) said...
What I mean is if you can use a single stepper in reverse connection to read the same signals you feed it to turn either clockwise or counterclockwise in normal operation.


The above code uses only 1 pin of the four that a stepper, what if I use the rest in conbination to intepret if its turning one way or another like the some encoders with two outputs do? I think that it can be done.



I tried to implement it but stuck on the programming side. For this I connected the common of the stepper to the ground and the rest four pins of the stepper on four ports of the stamp thru 470 resistors.



Thanos



I would imagine it would work just like the single wire stepper mode, but you will need to constantly scan all wires quite fast. In sequence.

I do this to determine if certain switches are pressed on a matrix keypad. I would imagine the same technique could be used to scan the stepper wires to see which of the 4 are giving pulses. You would have to scan the inputs pretty fast.

I would personally just start with scanning all stepper wires as fast as the stamp could in a repeating loop, and pump the output to the debuger, let each stepper line change a variable to 1 or 0, then display that variable in the debuger, this will let you see how fast your variables change, and also the pattern that results from the stepper motor rotating backwards or forwards.

But the debug might slow your loop down, so it may mess with the results. But its a start? I would think that rotating the stepper motor a bit slower would help you determine a directional pattern using debug.

Tronic (Greece)
01-10-2006, 08:16 PM
I tried to adapt the code of an old Nuts & Volts article for rotary encoders but the code wasn't in Pbasic and I gave up during the conversion...

http://www.parallax.com/dl/docs/cols/nv/vol1/col/nv8.pdf

Clock Loop
01-10-2006, 08:36 PM
Tronic (Greece) said...
I tried to adapt the code of an old Nuts & Volts article for rotary encoders but the code wasn't in Pbasic and I gave up during the conversion...

http://www.parallax.com/dl/docs/cols/nv/vol1/col/nv8.pdf


If you don't get this to work, or no one else can help you, I might have some free time in a few days, and can help you out. I own two stepper motors, mine also have 4 "signal" wires, and a 5th common.

Bruce Bates
01-10-2006, 09:34 PM
Thanos -

My apologies for misunderstanding your question the first time around. It DID seem too simple at the face of it. I didn't realize you were trying to determine the MOTOR (encoder) direction, since neither the of those words appeared in your original question.

Generally speaking those encoders whose dual output can be used to determine both speed and direction are emitting quadrature signals. In truth, the signals need not be true quadrature to be usable, but simply consistantly out of phase with one another by a sufficiently large angle that it can be detected. I suspect with a bit of empirical testing, you can find 2 pairs of windings on your stepper motor/encoder, that will provide such a detectable phase angle difference.

Here are some applications notes, thanks to Dr. Tracy Allen, that are intended to be used for quadrature output, but which I suspect can be adapted for use on your setup:
http://www.emesystems.com/BS2fsm.htm#directional

The whole "trick" here is to determine whether the Phase A signal (one of the stepper windings) leads or lags the Phase B signal (a different winding). If it LEADS, it's going in one direction, and if it LAGS, it's going in the opposite direction. The designation of Phase A and Phase B is purely arbitrary, but must be consistant throughout.

As you read through the code, just remember that both signals, from one single source (one encoder, two signals), are merely out of phase with one another, and that's all you're detecting to ascertain direction. Please let us know how you make out with it.

Regards,

Bruce Bates

Tronic (Greece)
01-10-2006, 10:04 PM
Bruce, from what I read on the emesystems page, I figured·I could downsample the 2 bits of each winding to 1 bit upon reading the state of the outputs, so I could then compare the state of·only two logical outputs:

----> ----> ----> ----> CW
0 1 1 0 0 B
0 0 1 1 0 A
<---- <---- <---- <---- CCW
0 1 3 2 0 state


And·it gives enouph code examples. Cool!!!! http://forums.parallax.com/images/smilies/hop.gif
I'll give it a try tonight...

Thanks

Thanos
·

Bruce Bates
01-10-2006, 11:01 PM
Thanos -

Again, I'm not sure I understand what you're trying to do here, but I hope the following will clarify it. I tried to make it clear in my last message, but I guess I didn't do a very good job of it.

There is NO 2-bit "signal" per say. You have two signal sources (two different windings) which we're calling Phase A and Phase B, just by convention. Just for the sake of reference, we'll call the first winding you choose (whichever it may be) as the Phase A signal. The second winding that you choose to use will be the Phase B signal. For each of these signals you need to know the last or past state (0 or 1) and the present state (0 or 1). Now, if you want to call that two bits that's fine, but for me that just adds to confusion. To my way of thinking those are two different states of the SAME signal. Since we need to know the past and current state of two DIFFERENT signals (Phase A and Phase B), we need to use 4 variables to save them: PhaseA_Prior, PhaseA_Now, PhaseB_Prior, PhaseB_Now. These variables can be defined as a BIT, if it's storage you're concerned about.

Why do we need 2 states and 2 signals. Here is the rationale:

First we need to know if the state (0 to 1 or 1 to 0) has changed for a given signal. We have no interrupt-on-change facility on the PBASIC Stamp, so this is a way to imitate that feature. Thus, we need to know its past and current state. Once we know that, we can detect (by comparison) if/when a single signal change occurs. We might be standing still, and in that case there will be no change at all.

Second, if/when a change HAS occurred in the state of the signals, we need to know WHICH signal changed first (Phase A or Phase B). The signal which changes first is the LEADING signal. Once we know which is leading, the other is obviously the lagging signal. Once we've made the LEAD/LAG determination, we now know the direction of rotation, and from that we know the direction of travel. We also know if the direction of travel has changed as well.

I'm not saying you can't "condense" those states, I've just never seen it done, and would have to set up a test jig to test out whether it would work as planned. My suspicion is that you may be in for trouble, and that the trouble may be in the non-moving case. That's just an off-the-top-of-my-head guess, quickly thinking about it.

Regards,

Bruce Bates

Post Edited (Bruce Bates) : 1/10/2006 3:20:07 PM GMT

hank van buren
01-11-2006, 01:08 AM
Thanos,
This is good place if you are looking for some cheap stepper motors. http://www.allelectronics.com/cgi-bin/category/400600/Stepper_Motors.html (http://www.allelectronics.com/cgi-bin/category/400600/Stepper_Motors.html)·
I would be very interested in a copy of your program reading the direction of the stepper motor.
regards Hank van Buuren

Tronic (Greece)
01-11-2006, 05:19 PM
Presumming the stepper thas 4 windings whose motion sequence·is 1,2,3,4 I tested it by connecting winding 1 and 2· on two bs2 ports and it actually increased or decreased the counter variable by the way I turned the stepper.

BUT it was kind of jumpy or sometimes going the opposite direction from what it supposed to be.

The reason for this must be that the stepper outputs half step information:

1 2 3 4
--------
1 0 0 0···<---
1 1 0 0
0 1 0 0·· <---
0 1 1 0··
0 0 1 0·· <---
0 0 1 1··
0 0 0 1·· <---
1 0 0 1··

That has·four states·more·on each winding·indecated above with arrows.
If I had a way to filter these extra states...·to a usefull one that could be:

1 1 0 0
0 1 1 0··
0 0 1 1··
1 0 0 1··

The code really needs modification for 4 ports reading so when a beta vesion is available I'll post it...

Thanos
·

Bruce Bates
01-11-2006, 07:15 PM
Thanos -

If the encoder (motor) was positively driven (no slippage in either direction) the "cogging" you're seeing would probably disappear. True encoders use Grey code, which is inherently error proof, and you can toss out any errors which may be seen.

If you want to have fun continue on. If you want a true encoder that is durable, accurate and repeatable, without errors, may I suggest that you purchase one, and these problems will ALL disappear. One old adage is "You can't make a silk purse out of a sow's ear"!

Regards,

Bruce Bates

Tronic (Greece)
01-11-2006, 07:54 PM
Bruce·you're right!·I'm doing it for fun right now!

But if works out, it would a durable self powered encoder with nice turning feel for the end user (I like all these halfstep stops it makes·when I·turn it by hand)

One good application could be used is in a·force feedback joystick where the stepper can provide both the reading of the movement caused by the users hand and both the feedback·movement fron the computer program he plays on.

I know already there are better solutions to this (I own a Microsoft Sidewinder FF2)
but it would be fun to·use some devices in way never intended to be.

Thanos
·

stamptrol
01-12-2006, 01:29 AM
· Hi Folks,

···· I had an application awhile ago to use an encoder to measure lumber width on a moving conveyor.

···· In working that out, I was able to combine a signal processing textbook from France with an old N&V article (or maybe it was an early Parallax app note) and ended up with a very elegant way to read an encoder which also generated a signal to show direction.

···· The program is attached, use at your own risk!

·· Cheers

· Tom