Encoder Issues

Sjeti

I've been trying to get readings from my quadrature encoder. Just incase: It is a US Digital E3-200.

I am constructing a motor controller and I have all the code working except for the encoder object.
Here is the code I'm using to test it:

VAR
long pos


CON
_xinfreq = 5_000_000
_clkmode = xtal1 + pll16x

OBJ
serial : "FullDuplexSerial"
Encoder: "Quadrature Encoder"

PUB Main
serial.start(0,1,0,38400)
Encoder.start(4,2,0,@pos)
repeat
waitcnt(cnt+8_000_000)
serial.hex(pos[noparse][[/noparse]0],4)
serial.tx(" ")

My output can vary between 0x0000 and 0xFFFF or 0x0000 and 0x0001 depending where the wheel is when I start.
I'm using just the basic Encoder object and I have two channel encoders. Is there something I'm doing wrong?

WNed

Welcome to the forum!
Is the encoder object you're using from the Object Exchange?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"They may have computers, and other weapons of mass destruction." - Janet Reno

John Abshier

Since you have 2 encoders, you need to make pos an array of length 2. You don't really describe what your problem is. Since pos is long its value can vary between 0x00000000 and 0xFFFFFFFF. Remember incremental encoders count up or down. I think for your encoder one revolution would be 800, two revolutions 1600, etc.

A nit waitcnt(cnt+8_000_000) is usually coded as waitcnt(8_000_000 + cnt)


John Abshier

MagIO2

@John:
Is there a hidden secret in the waitcnt-implementation? I can't see a difference! Adding is commutative, so the result is the same for A + B and B + A.

Richard S.

I have successfully implemented a four channel DRO using the quadrature encoder from the object exchange.· It can be implemented with a propeller proto board, some minor wiring, a keyboard, and a cheap crt/lcd screen (new 15-17 inch lcd monitors are now about $70!).· Although designed to use with Jenix glass scales, it can also be used and calibrated for rotary quadrature encoders.· I also have a version for use with four·Caliper (Chinese) scales, but it is not finalized.· The following pointer is to the propeller forum where you can read more....··
http://forums.parallax.com/showthread.php?p=720621


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Richard in Michigan

jazzed

@MagIO2,

Normally one writes waitcnt(ticks + cnt) so that cnt is the last value fetched before the waitcnt pasm instruction executes.
It is possible for a program to appear to hang on the order of a few minutes if CNT has passed before waitcnt happens.
For small values of "ticks" there is risk in hanging the program anyway ... best to be aware of this potential problem.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230

StefanL38

@MagIO,

plus is commutative but the systemconter is running free at a very high speed
increments every 12.5 nanosecond
if you code

waitcnt(cnt + 2_000_000)

then the actual cnt-value will be a lot of ticks ahead when the PASM-waitcnt of the interpreter gets executed
(the interpreter needed some 100 ticks to execute the "+"

if you code
waitcnt(2_000_000 + cnt) the ticks lost until executing the PASM-waitcnt is minimized and still it has to be above

waitcnt(381 + cnt) the ticks lost until executing the PASM-waitcnt is minimized and still it has to be above

as it takes 382 ticks to finish the "+" of 381 and cnt

so with
waitcnt(379 + cnt) the actual value of cnt will be already OVER the result of 379 + cnt and then the next time
the cnt-value matches is 2 ticks away (which is around 53 seconds at a 80 MHz clock

StefanL38

@MagIO,

plus is commutative but the systemconter is running free at a very high speed
increments every 12.5 nanosecond
if you code

waitcnt(cnt + 2_000_000)

then the actual cnt-value will be a lot of ticks ahead when the PASM-waitcnt of the interpreter gets executed
(the interpreter needed some 100 ticks to execute the "+"

if you code
waitcnt(2_000_000 + cnt) the ticks lost until executing the PASM-waitcnt is minimized and still it has to be above

waitcnt(381 + cnt) the ticks lost until executing the PASM-waitcnt is minimized and still it has to be above

as it takes 382 ticks to finish the "+" of 381 and cnt

so with
waitcnt(379 + cnt) the actual value of cnt will be already OVER the result of 379 + cnt and then the next time
the cnt-value matches, is 2^32 = 4.294.967.296 ticks away (which is around 53 seconds at a 80 MHz clock

best regards

Stefan