Shop OBEX P1 Docs P2 Docs Learn Events
Probably Bug in Kye's QEDEngine — Parallax Forums

Probably Bug in Kye's QEDEngine

Duane DegnDuane Degn Posts: 10,588
edited 2020-10-29 13:28 in Propeller 1
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.

Comments

  • WildatheartWildatheart Posts: 195
    edited 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.
  • KyeKye Posts: 2,200
    edited 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 DegnDuane Degn Posts: 10,588
    edited 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 DegnDuane Degn Posts: 10,588
    edited 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.
  • ErlendErlend Posts: 612
    edited 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 DegnDuane Degn Posts: 10,588
    edited 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.
  • ErlendErlend Posts: 612
    edited 2013-12-11 01:20
    Thanks Duane, I'll try this out and see if the strange behaviour dissapears.

    Erlend
Sign In or Register to comment.