Quote Originally Posted by HenrikOlsson View Post
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.

Quote Originally Posted by HenrikOlsson View Post
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...


Quote Originally Posted by HenrikOlsson View Post
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.


Quote Originally Posted by HenrikOlsson View Post
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!



Quote Originally Posted by HenrikOlsson View Post
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.