Encoders! too overwhellming for a basic stamp?

wkeull

Ok, i have a quadrature encoder, (http://spaceagecontrol.com/s021u.htm) that I am trying to interface with a basic stamp. Using supplied code(from forums.parallax) and derived code I have gotten the encoder to work at slow rates of extension, i.e. .25" a second, maybe up to a half an inch a second. however at faster rates, the stamp doesnt seem to be able to keep count. The encoders output is at 134 lines an inch, this doesn't seem to be coming close to what the stamp should be capable of. Am I missing something? Or could the code be overwhelming it? Below is the code that I am using, I have two inputs, channel A, and B. any suggestions would be greatly appreciated. My target extension speed is roughly 1"/sec. Thanks in advance!


'

---

[noparse][[/noparse] I/O Definitions ]

---

' A Output Connects To P0
' B Output Connects To P1


'

---

[noparse][[/noparse] Variables ]

---

oldBits VAR Nib ' Previous State Of I/O Pins 0 - 3
newBits VAR Nib ' Current State Of I/O Pins 0 - 3
direction VAR Bit ' Direction Encoder Is Turned
counter VAR Word ' Counter (0-255)
temp VAR Word
t VAR Word

'

---

[noparse][[/noparse] Initialization ]

---

OUTS = %0000000000000000 ' Set All Output Pins Low
DIRS = %1111111111111100 ' I/O Pins 0 - 1 Inputs
t=1344
newBits = INA

'

---

[noparse][[/noparse] Program Code ]

---

Main:
DO
newBits = INA ' Get State Of I/O Pins 0 - 3
IF newBits <> oldBits THEN ' Have Bits Changed?
direction = newBits.BIT0 ^ oldBits.BIT1
counter = counter - 1 + (2 * direction)
temp=counter*10 / t ' inch conversion
DEBUG HOME, DEC3 temp ," ", DEC2 ((((counter * 10) // t)*10)/844),"/16" , " ", DEC4 counter ' Show New Counter On DEBUG Screen and 16th of an inch fractions etc
oldBits = newBits ' Update oldBits
ENDIF
LOOP
STOP

Franklin

Here is a whole thread on encoders and the BS http://forums.parallax.com/showthread.php?p=629313

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Stephen

wkeull

Thanks, I have read that thread very closely. Most of my application is based from that thread. I have tried variation and different approaches. But I still arrise at the same apparent problem of loosing track of the count. The thread draws to the conclusion of the processing power of the basic stamp. However, unless I am missing something then I should be nowhere near that threshold in resolution/time interval.

Unsoundcode

Hi wkeull, the program has to be faster than the encoder or it stands to reason your going to miss pulses. At 134 pps your program cycle time must be under 7.5mSec for it to reliably catch·every encoder pulse. The debug statement·has a comparatively slow execution time and your example will probably take several mSec's to complete, this in conjunction with the other statements is taking your program over that 7.5 mSec mark. In the thread mentioned above Tom Sisk says that the BS2 is ok up to about 50 pulses per second, for an encoder with greater resolution you might be better off looking at the SX, its fast cheap·and has a good basic style.

Jeff T.

Clint

I was going to post a link to the thread I started, but it looks like you've already been looking at it. Some other alternatives I dug up if you are really stuck with the Basic Stamp are to use counters or quadrature decoders. US Digital makes a decoder for interfacing with a microprocessor, but it requires more I/Os than I was willing to use.

Have you tried running your program with the DEBUG statement removed? That may speed things up.

Martin Hebel

Using the COUNT command you can easily measure the speed of the encoder by counting pulses.

With some a couple bucks of simple logic circuits you can use the phase shift to determine direction.

If you are interested in this approach, let me know and I'll dig up a circuit for you.

-Martin


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
StampPlot - GUI and Plotting, and XBee Wireless Adapters
Southern Illinois University Carbondale, Electronic Systems Technologies