Probably Bug in Kye's QEDEngine

Duane Degn · 2013-12-09 12:34

In Xanadu's treaded robot thread, Wildatheart reported some strange behavior in Kye's quadrature encoder object.

I was able to replicate the strange behavior.

The transition from 00 to 01 registers as an increase in the encoder count however the reverse transitions, from 01 to 00 doesn't decrement the count. It's possible to continuously increment the encoder count by transitioning between 00 and 01 without a net rotation of the encoder.

I'm attaching the program I used to test Kye's object.

I know I personally use a lot of Kye's objects and I figure a lot you probably do too. This bug isn't likely to cause trouble very often but it could cause strange behavior if you have repeated 00 to 01 and back transitions.

Edit: There was a bug in my demo program. Instead of displaying the new count and the total count, the program displayed the total count twice.

Wildatheart · 2013-12-09 13:31

Duane Degn wrote: »

I was able to replicate the strange behavior.

The transition from 00 to 01 registers as an increase in the encoder count however the reverse transitions, from 01 to 00 doesn't decrement the count. It's possible to continuously increment the encoder count by transitioning between 00 and 01 without a net rotation of the encoder.

You are correct, the transition from 01 to 00 doesn't cause a change. But did you try this on both the rising and the falling pulse edges? One edge of the pulse will increment the count and the other edge will decrement the count - although the second condition is of no consequence at this point. If there's a fault on just one of the pulse edges, Houston has a problem.

Thanks for confirming this. I'm sure it'll be of help to other folks using this object.

Kye · 2013-12-09 19:53

Weird, well, if you have a fix for the bug I'll change the code. I don't really have the time to debug it anymore however.

I've used this object for robot races and I've not had a problem before... the PID control works for both going forward and backwards. Additionally, when I wrote it I tested it being able to count up and down...

Duane Degn · 2013-12-09 21:00

Kye wrote: »

Weird, well, if you have a fix for the bug I'll change the code. I don't really have the time to debug it anymore however.

I've used this object for robot races and I've not had a problem before... the PID control works for both going forward and backwards. Additionally, when I wrote it I tested it being able to count up and down...

It does count up and down.

The only time the problem shows up is when the motor is just about stopped. It's the single bit transitions back and forth that are the problem.

The code as it is should work in most applications but it doesn't follow the rules a "well behaved" quadrature encoder program should (it should catch all reverses).

I don't have a bug fix. The code is too advanced for my basic understanding of PASM. The problem would likely never be noticed if the encoder is being used on a motor. The problem would be more apparent if used on an encoder used as a knob.

It could be a problem if used with a motor if the motor oscillates while nearly stopped.

Duane Degn · 2013-12-09 21:34

While I don't have a bug fix for Kye's object, I did fix the bug in my demo program in the top post.

If you're one of the four who downloaded the "c" version, make sure and download the corrected "d" version. Or you can just fix the code yourself. The error is an obvious one.

Erlend · 2013-12-10 00:31

This may explain the strange behaviour I have observed in a piece of code I've written. It uses Kye's code to read a knob-encoder meant to provide user input. I really only need a 'slow' single-channel QE reader object to do this. Any suggestions for an alternative Object to use?

Erlend

Duane Degn · 2013-12-10 04:54

Erlend wrote: »

Any suggestions for an alternative Object to use?

I've used the object in the Propeller Tool library several times.

I couldn't find any demo code for the object in the library so I'm attaching a couple of my demos here (this are demos to the library object).

Here's the simple demo:

CON

  _clkmode = xtal1 + pll16x                             '' Clock Settings
  _xinfreq = 5_000_000                                  


  ENCODER_FIRST_PIN = 16                                '' User Changeable                          
  ENCODERS_IN_USE = 1                                   '' User Changeable


  MAX_ENCODER_INDEX = ENCODERS_IN_USE - 1
  DEBUG_BAUD = 115_200                                  '' User Changeable
  
OBJ


  Pst : "Parallax Serial Terminal"
  Encoder : "Quadrature Encoder"


VAR


  long knob[ENCODERS_IN_USE]
  
PUB Main | encoderIndex
 
  Pst.Start(DEBUG_BAUD)
  waitcnt(clkfreq * 2 + cnt)
  Encoder.Start(ENCODER_FIRST_PIN, ENCODERS_IN_USE, 0, @knob)
  waitcnt(clkfreq/10 + cnt)
  Pst.Clear
  repeat
    Pst.Home
    Pst.NewLine
    Pst.ClearEnd
    Pst.Str(string(13, "         Encoder Demo"))
    Pst.ClearEnd
    Pst.NewLine
    Pst.ClearEnd
    repeat encoderIndex from 0 to MAX_ENCODER_INDEX
      Pst.Str(string(13, "knob["))
      Pst.Dec(encoderIndex)
      Pst.Str(string("] = "))
      Pst.Dec(knob[encoderIndex])
      Pst.ClearEnd

I'm getting very close to having a useable demo for my quadrature encoder object.

Erlend · 2013-12-11 01:20

Thanks Duane, I'll try this out and see if the strange behaviour dissapears.

Erlend

Probably Bug in Kye's QEDEngine

Comments