/Henrik,

Thanks for the reply. Yes the encoders were all separate at one time. There are two right now, but there are actually 3. Elevation, Azimuth, and Skew. I'm not using the skew right now as it's not super critical to change it within reasonable driving distance ie about 12 hrs. The remaining two, as well as eventually the third, all join together to come in to the MC on one wire. I did this when my plan was to have a wired handheld device only and was trying to keep the number of wires down to 8 so I could use CAT5 between the two. I have since gone BT with the multi-MC idea, but I saw no reason to change it. If you look at my interrupt coding, I simply made it so that the program decides which encoder to add the pulse to by deciding which axis it was trying to move. Since only one axis ever needs to move at one time, it works fine. I just re-read your post... UP, DOWN, EAST, WEST are the output pin aliases. Eencoder0Pos is the variable for the elevation encoder position. Aencoder0Pos is the variable for the Azimuth. If a pulse comes in and the MC was moving the dish up, UP will be = 1 to it'll add 1 to the Eencoder0Pos. If it was moving the dish down, then DOWN will = 1 and it'll subtract 1 from Eencoder0Pos and so forth. 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.

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? The 65k overflow point isnt really workin for me. When I started this project in Arduino, it wasn't an issue. If I can't get bigger than WORD, then the only other thing I can think of is to add code to the interrupt so on azimuth, it'll only -1/+1 to my var on say, every fifth pulse. I have resolution coming out my ears, but still, I'd rather not if there's another way.

The high/low issue... So if I use high/low, it sets the TRIS bytes for me? If I use high/low, it significantly adds to the program size? 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?

Yes, I'll kill the disable. I think it's an accidental leftover from when I started. I started using a PBP int for that and the DT-INT for a timer. Then after I understood the DT-INT a little better, it switched over to it for both. I was using velocity monitoring and a sudden slowing to calc when I hit the physical limit on azimuth. Then I found the switch yesterday, and eliminated that catastrophe of coding. I need to eliminate the timer as well since I have no use of any time-keeping anymore.