decoding quadrature encoders

[HenrikOlsson]

Hi Chris,
In your test routine loop you're re-Writing alot of static text on the LCD and you're doing some "strange" things to get the correct formating. Here's an idea which probably is a bit more efficient:

 ' Print static information on LCD once, then leave it alone.
 lcdout $FE,$80, "Measurement   "
 lcdout $FE,$C0,"TST ANGLE: "


 '************************** TESTING ROUTINES HERE **************************
 test:
   If portC.5 = 0 then clearall
   
if enc_counter <> enc_counter_old then 'see if value has changed
  enc_counter_old = enc_counter  ' move new value to old
  Counter = enc_counter
  Sign = Counter.15              ' Save sign
  Counter = ((ABS Counter) * 25) ' Degrees is now 0 to 900
        
  ' Not doing this here, later (or not at all).
  'If Sign THEN Counter = -Counter ' Restore sign, value is now -900 to 900

  LCDOUT $FE, $CB   'Position cursor at 11th character on 2nd row.
  IF SIGN THEN
    LCDOUT "-"
  ELSE
    LCDOUT " "
  ENDIF

  LCDOUT DEC Counter / 100, ".", DEC Counter // 100, " " 

  ' To save execution cycles you're better off not using HIGH/LOW
  low ledUp 'turn off CCW led
  low ledDown 'turn off CW led

  ' If the only purpose of the Counter variable is to display the value 
  ' the there's no need to restore the sign of it so the following line
  ' could be deleted.
  If Sign THEN Counter = -Counter ' Restore sign, value is now -900 to 900

endif
 
goto test

/Henrik.

[cbrun17]

Hi Henrik,

I changed the display routine as you described and it does work much better. I sure do over think some of this stuff... I did have to increase the pause to 250ms to allow for the display to update since it seemed to trip over itself a little more frequently this way.

I believe moving to either serial LCD or 7 seg LED might be the better solution.

Thanks again for your expert advise.

Chris

[Dave]

Excuse me Henrik, If you read the spec. sheet you can set the interrupt edge for the INT0 and INT1. It is not required to set it each time. Also the interrupt routine look like:
'************************************************* ********************
INC_C: 'INTERRUPT SERVICE ROUTINE FOR EXTERNAL INTERRUPT-0
'************************************************* ********************
POSITION = POSITION + 1
@ INT_RETURN

'************************************************* ********************
DEC_C: 'INTERRUPT SERVICE ROUTINE FOR EXTERNAL INTERRUPT-1
'************************************************* ********************
POSITION = POSITION - 1
@ INT_RETURN

That's all there is to it.

[richard]

When I added the mcu context save routine the display crashed. It will ~ work if I move the shaft slowly, however, moving quickly caused the code to trip over itself and lockup the screen.
My first guess was that when jumping out of the ISR, the next return in the main program uses the most recent return address on the stack and returns to the point the interrupt occurred, crashing the program.

I have not tried your code but can assure you that it is essential to save the mcu context upon isr entry and to restore it on exit . restoring the context without saving it can only lead to tears, not saving it can only lead to tears.

so good luck with that


dave
the chip used here in this somewhat hijacked thread is a 16F876 it has only one "INT" pin your suggestion just cannot work in that case.
afaik no pic16 chips can respond to rising and falling levels on an INT int pin simultaneously
its one or the other. as henrik says to do a full quadrature decode every edge needs to cause an interrupt.
RBC int can do it a single INT int cannot , the intx edge would need to be toggled on every interrupt .

secondly that circuit with all its extra bits cannot use the full resolution of a encoder its a 1x decode.

thirdly since the portb rbc pins on a 16F876 are schmidt trigger type inputs and if the chip is close enough to
the re (opto type not mechanical)no other components are required at all to do a full 4x decode , why complicate it ?

[HenrikOlsson]

Excuse me Henrik, If you read the spec. sheet you can set the interrupt edge for the INT0 and INT1. It is not required to set it each time. Also the interrupt routine look like:

Dave, I think you're misunderstanding what I'm saying.
The circuit you linked to is x1 decoder, effectively provoding 1/4 of the encoders available resolution. Your simply counting the individual lines of the A and B channels respectively. If that's enough, perfect go right ahead but if you need the full resolution of the encoder (as is the case here) then it's not going to cut it.

To use the full resolution of the encoder each and every edge of the two signals needs cause the counter the change up or down. If the encoder is connected directly to INT0 and INT1 it means that the edge causing the interrupt needs to changed on every interrupt so that it "catches" the falling edge after a rising edge etc. It's certainly doable if the PIC allows you to do it (not all do) but it does complicate things.

By using interrupt on change this is handled automatically because ANY change on ANY pin causes an interrupt so you will "catch" every edge (rising AND falling) automatically and you just need to decode the gray code in the ISR. From any given state (there's only four) you can only get to two other (valid) states, one is forward the other is backwards.

Look at this NI page on qudrature encoders, about half way down is a comparison of x1, x2 & x4 decoding.

/Henrik.

[Dave]

Henrik and Richard, I understand what it is you are trying to accomplish. The problem becomes noise and the ability of the micro to intercept the interrupts. When you are trying to capture each and every edge in a mechanically noisy environment you will undoubtedly miss an edge or two. The key to properly designing an encoder into a mechanical design is the encoder resolution. Trying to get 4x the resolution from an encoder is indeed one way to fail if the encoder is of a higher resolution than is required. I have been designing encoders into mechanical fixtures for almost 40 years. I would rather have the processor executing code rather than constantly servicing interrupts in a mechanically noisy environment. It's just my way of thinking. Good luck...

[HenrikOlsson]

If you need a certain resolution and a certain speed then it's going to result in a certain number of "counts" per second (ie a certain number of interrupts per second) no matter if you're doing x1 or x4 decoding, won't it?

The difference is that with the former you need an encoder with 4 times the number of cycles compared to the latter. As far as the number of interrupts that micro needs to service there's no difference.

In this particular case we don't know what the speed is but we know that Chris needs (or wants) a resolution of the 0.25 degrees, which his 360CPR encoder will provide with x4 decoding. He could exchange his encoder for one with 1440CPR and do x1 decoding but given that the speed at which the enocder is being moved is the same there will be an equal number of "counts" per second. Doing the x4 decode in software is however a bit more complicated than x1, I'll give you that :-)

As far as noise goes I don't see the difference in running a 360CPR encoder doing x4 decoding and running a 1440CPR encoder doing x1 decoding.

And if using an external decoder circuit, like the one you linked to, there's no need for any interrupts at all, just have two counters count the up/down pulses and differentiate periodically.

/Henrik.