Quick thoughts: DT Ints with encoders

[kevlar129bp]

Here's what I've got so far... for the "slave" pics anyhow.

Critiques are definitely welcome!

16F688 w/20Mhz

INCLUDE "DT_INTS-14-MOD.bas"
INCLUDE "ReEnterPBP.bas"

'Clock setup
    Define OSC 20
'Pin setups
    ANSEL = %00000000       'No analog input
    TRISA = %00000111       'PortA: TRISA = %00XXXXXX
    TRISC = %00000000       'PortC: TRISC = %00XXXXXX
'Usart setups
    DEFINE HSER_RCSTA 90h ' Enable serial port & continuous receive
    DEFINE HSER_TXSTA 24h ' Enable transmit, BRGH = 1
    DEFINE HSER_CLROERR 1 ' Clear overflow automatically
    DEFINE HSER_SPBRG 86  ' 57600 Baud @ SPBRGH = 0
    BAUDCTL.3 = 1         ' Enable 16 bit baudrate generator
'----------------------------------------------------------------------------

MaxCount con 21600
BtnZeroCount var PORTA.0
APin var PORTA.1
BPin var PORTA.2
AOld var byte
BOld var byte
CurCount var word

ASM
INT_LIST  macro    ; IntSource,  Label,  Type, ResetFlag?
        INT_Handler   RAC_INT,  _ABInt,   PBP,  yes
    endm
    INT_CREATE           ; Creates the interrupt processor

    INT_ENABLE  RAC_INT  ; Enable RA change interrupt
ENDASM

curcount = 0

Start:

if btnzerocount = 0 then    'btnzerocount (A.0) has pullup res
    curcount = 0
endif

aold = apin
bold = bpin

hserout ["$", dec5 curcount]

goto start

ABInt:

'\\\ A caused the interrupt ///
IF apin != aold THEN                       'APin IS NOT equal to AOld
    IF apin != bpin THEN                   'If A and B are different,
        GOTO CW                                 'it was clockwise rotation
    ELSE                                   'Otherwise,
        GOTO CCW                                'it was counter-clockwise rotation
    ENDIF
ENDIF

'\\\ B caused the interrupt ///
IF Bpin != Bold THEN                       'BPin IS NOT equal to BOld
    IF apin == bpin THEN                   'If A and B are the same,
        GOTO CW                                 'it was clockwise rotation
    ELSE                                   'Otherwise,
        GOTO CCW                                'it was counter-clockwise rotation
    ENDIF
ENDIF

CW:                 ' -1
if curcount > 0 then
    curcount = curcount -1
else
    curcount = MaxCount
endif
@ INT_RETURN

CCW:                ' +1
if curcount < maxcount then
    curcount = curcount +1
else
    curcount = 0
endif
@ INT_RETURN

Thanks again guys,
Chris

[HenrikOlsson]

Hi,
I'd move the aold=apin, bold=bpin to the ISR. If kept in the main routine it's possible that a new interrupt occurs, for example, right between those two lines which will mess with your count - I think.

[kevlar129bp]

Thanks Henrik,

Thanks for the heads up. I see your point there. Otherwise, do you think I've got viable code?

Thanks again,
Chris

[HenrikOlsson]

Hi,
Yes, it look OK to me, the quadrature decoding seems to be correct but I'm sure someone around here knows of a faster/slicker way of doing it. (I'm not saying your way is slow).

Are you sending directly to a VB program for testing or are you sending to a terminal program or something like that? If a terminal program I'd put Pause 100 or whatever in the mainloop and add a CR to the end of the "message". If you're sending to a VB program, you could send the high and low byte of the counter and put them together in the PC.

If the encoders have Index-channel you could use that to zero the counter, at startup you move each joint of the arm thru "center" and it automatically zeros.

/Henrik.

[kevlar129bp]

Hi Henrik,

The thought behind not using the index channel is:
After firmly attaching the base...
You will probe anywhere in 3d space, then click the "zero" button on the stylus.
At that point, all encoder rotations will be based from that point.
Logging 3d points will be performed by clicking the "log point" button on the stylus.
I'm hoping to have a routine to log points as fast as serially possible while holding the "log point" button down continuously.
The way I see it, this will be all variant on:
1) "slave" pic interrupt speed to acquire an accurate count
2) "slave" pic to "master" pic serial speed
3) "master" pic to pc serial speed

All of the above will hinge on the user's stylus "drag speed" across the intended surface.

Check out this link...maybe it will explain it a bit better than I can



Let me know whatcha think.

Thanks,
Chris

[HenrikOlsson]

Yes, but don't you need to know the absolute angle between segments in order to calculate the stylus position?

You can still use your zero button for relative measurements but shouldn't it be more like an offset from the absolute zero position?

If you wire a third signal between the master PIC and all slaves you can use that signal capture the count at all six joints simultanously", then the master "pings" each slave for the value. Perhaps that was what you meant, just thought I'd mention it if it wasn't.

This is a cool project!

[kevlar129bp]

Hey Henrik,

You are thinking correctly on the absolute angle needed.
That's where the pulse counting comes in...
On the arm I've got designed in SolidWorks now has the following:

500 line encoders
2000 counts in quadrature
10.8:1 gearing
21600 quad counts per 360 degrees

Upon "zero button" press, we'll get degrees "moved" like this:

\\\\ Snip of VB Code ////
Const DPP As Double = 1.66666666666667E-02 <<< 360 / 21600
Dim DegreesNow As Double
Dim CountsNow As Integer
DegreesNow = CountsNow * DPP

If I'm thinking correctly, that will give us the degrees "traveled" by each joint.
If I am reading your question correctly, are you referring to the angles from "zero planes"? (dead vertical and dead horizontal)

Let me know if my thinking is correct?

Hard for me to keep it all straight!

I'm will also be doing the CNC machining for the arm components as well...

Too much for 1 guy to think about!

Let me know what you think.

Thanks again,
Chris