Trying to inch my way to the finish line w/ a 16F1829.........

[Demon]

Just wondering, why bother counting pulses?

Wouldn't you only need 360° rotation, 90° elevation and not sure for skew?

Since you haven't tackled the tracking yet, would it be simpler to just "move" as long as a button is pressed on the handheld?

Or, maybe enter a degree and go to that position (a rotary encoder on the devices can track where it's pointed).

Just tossing thoughts.

Robert

[thasatelliteguy]

Just wondering, why bother counting pulses?

Wouldn't you only need 360° rotation, 90° elevation and not sure for skew?

Since you haven't tackled the tracking yet, would it be simpler to just "move" as long as a button is pressed on the handheld?

Or, maybe enter a degree and go to that position (a rotary encoder on the devices can track where it's pointed).

Just tossing thoughts.

Robert

Well ya... that's the idea. But without an encoder, how would it have any idea where it is? The pulse counting is the only way to indicate how far the dish has travelled. When you look at the handheld, (or the phone or terminal) when I'm done, you will only see degrees or a satellite choice. You won't see the pulses anymore, but they have to be there. Maybe you misunderstood my project... This is a self-acquire satellite system, BUT I'm rebuilding the electronics from scratch. I S***canned all the stock electronics. The dish itself is VERY hearty, and well (over) built, but the electronics were way overbuilt as well, and as such, never worked reliably. Also, I am upgrading (completely changing) the satellite system that run on it as well. Totally different band even. So I have to establish a new way for it to identify and peak in on the new satellite as well.

I just re-read... OH! No, you would have to see the dish.. lol. Not small. 1 meter, on it's own trailer with an on-board box for generator, UPS, batteries, modem, router, etc. The dish only needs 360deg, (well a lil for overlap in case the user has the trailer oriented with the satellite right at the stop point) and elevation 90deg. BUT the motors are very small and geared down to hell and back. (I'm pretty sure the reason was so the motors could be de-energized and the dish stay put due to the extreme gearing) As a matter of fact, the elevation hardware is a C-band Superjack. The azimuth motor is nearly the same, but of course oriented differently. So an encoder that would only read a partial amount of a single revolution won't work. The motors turn many thousands of times to fully rotate the dish.

When I'm done, there will be a JOG mode that moves as long as the button's pressed. But I still want it tracking where it is, both for auto-stow purposes, and because the box that mounted on the trailer is in a possible path of the dish. It'll never be in the way to find the bird, but you can (and I did this morning, and ripped the mounting plate right off the trailer, something else I'll need to repair now) crash the dish into the box. Bad S*** happens. So even when jogging, I want to program in "no fly zones" that wont allow you to crash it.

As for giving it target coordinates, it'll be even easier than that. It only points to one satellite. With the addition of GPS and compass, you will be able to turn it on, and press Auto-Acquire and it'll do the rest. That's the end goal.


Make a lil more sense now?

[HenrikOlsson]

Hi,

Each encoder originally had two pulse wires with one pulse half a cycle behind so the MC could distinguish which way it was rotating. Ditching the second pulse wire from each encoder (since the MC already knows which way it was trying to move it) and combining the remaining three (since the MC also knows which encoder should be moving) was the only way I could think of to get it all on one wire.

So ordinary qudrature encoders then. Are they open collector output? I mean, if they are push-pull type output and you have several connected together there's quite a possibillity one will try to drive the line low while another tries to drive the line high.

Another option is to keep a global count for each encoder. Then you have each encoder signal connected to a timer/counter input on the PIC. When you're about to move an axis you clear the timer/counter register and run the motor. The timer/counter register will now track the relative movement which you can add or subtract from your global count for the axis moving. You'll still not have the direction information given by the quadrature nature of the encoder but it sounds as if the dish can't be backdriven anyway.

I figured it was something like this. I assumed it had to do with the ASM interrupts because through playing with the numbers, I found:
Faster Clock = Less errors (expected)
Faster Baud = Less errors (not expected)

When you increase the baudrate each "message" takes less time to send so it's less likely that an interrupt occurs while it's sending.

What can i use that's bigger than WORD?

That would be a LONG but they're only available on 18F parts. If you don't NEED the resolution then increase your count every X interrupt, that would be the easiest. Another option is to use two WORDS where the "top" one indicates degrees and the "bottom" one indicated minutes, seconds or 1/10 of degrees or whatever.

The high/low issue... So if I use high/low, it sets the TRIS bytes for me?

Yes it does. But it does every time you use HIGH/LOW.

If I use high/low, it significantly adds to the program size?

I guess it depends on how you define significantly but yes. Lets say you have WEST aliased to PortB.0, then doing HIGH WEST will basically be replaced with TRISB.0 = 0 : PortB.0 = 1. The "wasteful" part is that it does the TRISB.0 = 0 every time you do a HIGH/LOW west, even if the pin is and has been an output all the time.

And if I set the TRIS bytes, how do I do it? I guess, WEST = 1?? Very interesting... I don't recall this info being in the PBP manual?

Exactly, just clear the TRIS bit (like you're already doing). Then simple set the port register. PortB.0 = 1 or WEST = 1, if WEST is aliased to PortB.0.

/Henrik.

[thasatelliteguy]

Hi,
So ordinary qudrature encoders then. Are they open collector output? I mean, if they are push-pull type output and you have several connected together there's quite a possibillity one will try to drive the line low while another tries to drive the line high.

I thought of this when I first got rolling but one of the first things I worked on was to come up with some sort of scope. I made one from some CAT5, a stereo headphone jack from Radio Shack, and some alligator clips to use the mic jack on my laptop. Anyways, I can see the encoder signals, and from day one they have always been super clean. When I combined them I noticed no degradation or conflicts. Right now is probably the dirtiest I've seen because I have 50ft of CAT5 running in my living room window from the dish to my breadboard. (It's HOT in Texas!) But even when I say dirty, they are still really clean square waves, very little edging on the corners, if any, and no misses, dropoffs, or extra trash spikes. Just not PERFECT like you see people playing with PLL's on youtube on $1k scopes.

Another option is to keep a global count for each encoder. Then you have each encoder signal connected to a timer/counter input on the PIC. When you're about to move an axis you clear the timer/counter register and run the motor. The timer/counter register will now track the relative movement which you can add or subtract from your global count for the axis moving.

timer/counter input?? hmm, I'll have to look into this dark magic you speak of...

You'll still not have the direction information given by the quadrature nature of the encoder but it sounds as if the dish can't be backdriven anyway.

If by "backdriven", you mean you can't push it by hand and move it, then yes you are right. I think this is why the designers used regular DC motors with gearboxes and encoders instead of say, large steppers. The steppers could have been used with no gears and no encoding, but when powered down, the dish would be flapping in the wind.

When you increase the baudrate each "message" takes less time to send so it's less likely that an interrupt occurs while it's sending.

Ya but here's the rub... there was no interrupt happening. This has been happening since I put in the interrupt coding, but there was nothing hooked up. The encoder wire was just hanging off the CAT5 while I was jogging the dish manually while physically watching it (to avoid crashing) and tweaking the code for the menus and dish control. And remember, right now, there is no interrupt happening. That was the #2 subject of this post. (Which I still haven't figured out) And the way my code is written,

Eencoder0Pos = 0
HIGH UP
PAUSE 250
IF Eencoder0Pos = 0 Then goto moveerror

If I was having a float problem, it would only have to trigger ONE interrupt to avoid my error. My code doesn't require steady movement, or consistent movement, it only requires it not to still be on ZERO, which it is. So with confirmed zero triggered interrupts, it's still dropping characters from the ----- OMFG! Wow it's dark in here! Smells bad too... I just may pull my head out someday! The timer! Duh! I completely forgot the timer interrupt.... I'll get back to ya on this one..... UGH!

If you don't NEED the resolution then increase your count every X interrupt, that would be the easiest.

That's what I was figuring my factor of 5 on. If I have 250,000 pulses from limit to limit, and I count every 5th pulse, that's now 50,000 which gives me 15000 to spare.

[HenrikOlsson]

Hi,

I thought of this when I first got rolling but one of the first things I worked on was to come up with some sort of scope. I made one from some CAT5, a stereo headphone jack from Radio Shack, and some alligator clips to use the mic jack on my laptop. Anyways, I can see the encoder signals, and from day one they have always been super clean. When I combined them I noticed no degradation or conflicts. Right now is probably the dirtiest I've seen because I have 50ft of CAT5 running in my living room window from the dish to my breadboard. (It's HOT in Texas!) But even when I say dirty, they are still really clean square waves, very little edging on the corners, if any, and no misses, dropoffs, or extra trash spikes. Just not PERFECT like you see people playing with PLL's on youtube on $1k scopes

OK, soundcards generally have a capacitor in series with the input to remove any DC bias, I'm surprised that you get a clean crisp square wave but I guess it depends on at what frequency you measured. What if you remove the encoders and use a switch or whatever to simulate pulses and toggle a LED or something in ISR? That way you should be able to verify if interrupts aren't actually being generated.

timer/counter input?? hmm, I'll have to look into this dark magic you speak of...

Your PIC have two timers TMR0 and TMR1. They can be configured as timers or as counters. When configured as counters they will be "clocked" by a signal connected to T0CKI and T1CKI inputs respectively.

If by "backdriven", you mean you can't push it by hand and move it, then yes you are right. I think this is why the designers used regular DC motors with gearboxes and encoders instead of say, large steppers. The steppers could have been used with no gears and no encoding, but when powered down, the dish would be flapping in the wind.

That's exactly what I meant. If you don't get the direction information from the quadrature encoders then you must be SURE that each and every pulse from the encoder is caused by the dish moving in the desired direction. If there's any vibration etc it's going to cause "extra" pulses which eventually will cause the position to drift. Sounds like you've got it covered, just something to think about.

Ya but here's the rub... there was no interrupt happening. (snip) And remember, right now, there is no interrupt happening. That was the #2 subject of this post. (Which I still haven't figured out) And the way my code is written....(snip)....I just may pull my head out someday! The timer! Duh! I completely forgot the timer interrupt.... I'll get back to ya on this one..... UGH!... (snip)

Ya, exactly...THE TIMER.... :-)

Lets focus on one issue at the time, pick one and let us know how it goes. We'll go from there!

/Henrik.

[thasatelliteguy]

OK. I got multicalc working.
I got hserout working.
hserin - notsomuch.

My menu looks fine in the terminal. (although I can't test it with interrupts firing since I can't respond and mover the dish) But it just sits there and looks at me stupid when I give a command.

'****************************************************************
'*  Name    : UNTITLED.BAS                                      *
'*  Author  : [select VIEW...EDITOR OPTIONS]                    *
'*  Notice  : Copyright (c) 2014 [select VIEW...EDITOR OPTIONS] *
'*          : All Rights Reserved                               *
'*  Date    : 6/7/2014                                          *
'*  Version : 1.0                                               *
'*  Notes   :                                                   *
'*          :                                                   *
'****************************************************************
INCLUDE "DT_INTS-14.bas"
INCLUDE "ReEnterPBP.bas"


DEFINE HSER_RCSTA 90h ' Enable serial port & continuous receive
DEFINE HSER_TXSTA 24h ' Enable transmit, BRGH = 1
DEFINE HSER_SPBRG 129 ' 9600 Baud @ 20MHz, 0.16%
DEFINE HSER_CLROERR 1 ' Clear overflow automatically
APFCON0.2 = 1
APFCON0.7 = 1


#CONFIG
    __config _CONFIG1, _FOSC_HS & _WDTE_OFF & _PWRTE_OFF & _MCLRE_ON & _CP_OFF & _CPD_OFF & _BOREN_OFF &  _CLKOUTEN_OFF & _IESO_OFF
    __config _CONFIG2, _PLLEN_OFF & _LVP_OFF
#ENDCONFIG


DEFINE OSC 20
 
ANSELA = 0
ANSELB = 0


ASM
INT_LIST  macro    ; IntSource,        Label,  Type, ResetFlag?
        INT_Handler    INT_INT,  _doEncoder,    PBP,  yes
    endm
    INT_CREATE            ; Creates the interrupt processor
ENDASM
@   INT_ENABLE   INT_INT


LED var PORTC.7
TRISC.7 = 0
LED = 0
DOWN var PORTB.4
TRISB.4 = 0
DOWN = 0
EAST var PORTB.5
TRISB.5 = 0
EAST = 0
WEST var PORTB.6
TRISB.6 = 0
WEST = 0
TRISC.5 = 1
UP var PORTB.7
TRISB.7 = 0
UP = 0






a0 var byte
a1 var byte
e0 var byte
e1 var byte
i var byte
VerboseMode var byte
cereal var byte
Aencoder0Pos var word
Eencoder0Pos var word






VerboseMode = 1


goto MainMenu




doEncoder:
    if UP = 1 then 
        'if e0 = 5 then 
            Eencoder0Pos = Eencoder0Pos + 1
        '    e0 = 0
            if VerboseMode = 1 then Hserout ["Eencoder0Pos = ", #Eencoder0Pos, 13, 10]
        'endif
        'e0 = e0 + 1
    endif
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      if DOWN = 1 then 
        'if e1 = 5 then 
            Eencoder0Pos = Eencoder0Pos - 1
        '    e1 = 0
            if VerboseMode = 1 then Hserout ["Eencoder0Pos = ", #Eencoder0Pos, 13, 10]
        'endif
        'e1 = e1 + 1
    endif
    if EAST = 1 then 
        if a0 = 5 then 
            Aencoder0Pos = Aencoder0Pos + 1
            A0 = 0
            if VerboseMode = 1 then Hserout ["Aencoder0Pos = ", #Aencoder0Pos, 13, 10]
        endif
        a0 = a0 + 1
    endif
    if WEST = 1 then 
        if a1 = 5 then 
            Aencoder0Pos = Aencoder0Pos - 1
            a1 = 0
            if VerboseMode = 1 then Hserout ["Aencoder0Pos = ", #Aencoder0Pos, 13, 10]
        endif
        a1 = a1 + 1
    endif
@ INT_RETURN




MainMenu:
    gosub CLR
    HSEROUT ["******** MAIN MENU ********", 13, 10, 10]
    HSEROUT [" 1. Start Homing Sequence", 13, 10]
    HSEROUT [" 2. Manual JOG Mode", 13, 10]
    HSEROUT [" 3. Auto-Acquire Satellite", 13, 10]
    HSEROUT [" 4. Stow Dish for Travel", 13, 10, 10]
    HSEROUT ["Enter Your Selection:"]
    hSERIN [cereal]
    if VerboseMode = 1 then HSEROUT [#cereal,13,10]
'    If cereal = "1" then goto HomeDish 
    If cereal = "2" then goto JogMenu
'    If cereal = "3" then goto TEST1
'    If cereal = "4" then goto Startup
goto MainMenu


JogMenu:
    gosub CLR
    pause 250
    HSEROUT ["***** JOG MENU *****", 13, 10, 10]
    HSEROUT ["U - UP", 13, 10]
    HSEROUT ["D - DOWN", 13, 10]
    HSEROUT ["E - EAST", 13, 10]
    HSEROUT ["W - WEST", 13, 10]
    HSEROUT ["S - ALL STOP", 13, 10]
    HSEROUT ["X - MAIN MENU", 13, 10, 10]
    hSERIN [cereal]
    if cereal = "U" Then
        gosub allSTOP
        HIGH UP
    endif
    if cereal = "D" then
        gosub allSTOP
        HIGH DOWN
    endif
    if cereal = "E" then
        gosub allSTOP
        high EAST
    endif
    if cereal = "W" then
        gosub allSTOP
        HIGH WEST
    endif
    if cereal = "S" then gosub allSTOP
    if cereal = "X" then 
        gosub allSTOP
        goto MainMenu
    endif
goto JOGMenu


allSTOP:
    EAST = 0
    UP = 0
    DOWN = 0
    WEST = 0
    if VerboseMode = 1 then GOSUB POS
return


CLR:
    if VerboseMode = 0 then
        For i = 0 to 30
            HSEROUT [10]
        next i
    endif
return


abort:
    gosub allSTOP
    gosub clr
    HSEROUT ["USER STOP! -- MOVE ABORTED!", 13, 10]
    PAUSE(5000)
goto MainMenu


moveerror:
    gosub allSTOP
    gosub clr
    HSEROUT ["SYSTEM ERROR! -- MOVE ABORTED!", 13, 10]
    PAUSE(5000)
goto MainMenu


POS:
    pause 100
    HSEROUT ["  EL -- ", #Eencoder0Pos, "  AZ -- ", #Aencoder0Pos, 13, 10]
    pause 2000
return

[EarlyBird2]

Are you saying these lines do not execute?

hSERIN [cereal]
if VerboseMode = 1 then HSEROUT [#cereal,13,10]

[EarlyBird2]

Speaking of which, I am having a problem there too. The elevation isn't an issue. From "stowed" (down) to full travel UP, is like 3665 pulses. But the azimuth is WAY more. From "stowed" around to physical limits one way is approx 220 deg, and 109300 pulses. And that's only partial rotation. Full rotation is about 400 - 450 deg, so I have a counter that needs headroom of about 250,000. What can i use that's bigger than WORD?

This jogged my memory regarding a problem I had regarding time of day comparisons. I had the idea of converting time of day to seconds into day which obviously could go up to 86400 and will not fit into a byte or word variable. I resolved the issue by comparing hours, minutes and seconds into the day which was just a few more lines of code.

In your case is it possible to change pulses into second, minute and degree variables. Then again obviously your variables will have 60, 60 and 450. This will then be a clock routine of which there are many examples I am sure.