DC Motor position using Rotary Encoder and PWM

[Ttelmah]

Tell us more about your rotary encoder...
The code works 100% reliably with optical encoders that have reliable edges (some hysteresis built into the circuit). Where you _will_ get problems, is with mechanical encoders that exhibit contact bounce, or some analog optical encoders that give poorly defined edges. The old 'GIGO' syndrome.....
Other possible problems when dealing with encoders and motors, are (of course) noise, on either the signal lines, or the supply.

Best Wishes

[maryp]

Appreciate your response...
The encoder is a rotary optical 256-line incremental encoder with standard gray-code output. only 4 lines coming out of the encoder: A, B, +5 & GND. Seemingly, its not differential output, which might have been ideal to deal with a noise issue. And no shielded cable on the encoder wire. But these two things I can't change, have to work around these.
The encoder is not really in a close proximity to the motor. The motor drives a linear piston and the encoder is for the piston positioning. I am using some of those ferrite core snap-on things like on some USB cables and in my circuit the encoder lines get to the PIC after passing through a schmitt trigger. This does introduce some lag, but if I remember right, its in the nano-range.

[Ttelmah]

The code here, is for a _quadrature_ encoder, not a Gray code encoder. However I doubt if you have a Gray code encoder with only two data lines, and especially with them called 'A', and 'B', which is the standard for quadrature encoders. The Gray code encoders with two wires, usually use a SSI interface, and the lines are not then called A and B.
Many optical encoders, _require_ pull up resistors on the data lines (they have OC outputs). Do you have a part number for the encoder?.
You do realise that if this is a quadrature encoder, you will need some form of 'zero' detection as well?.

Best Wishes

[maryp]

thank you.
seems like i need to read-up some more on encoders....
but besides that, link to the encoder datasheet:
http://www.beiied.com/PDFs2/L15_Incremental_Encoder.pdf
though this one has only 4 lines coming out of the encoder... no gate pulse. also, i do have port B pull-ups enabled.

[Ttelmah]

Port_B_pullups, would _not_ be adequate for an encoder output.
The frequencies from an optical encoder are much too high to rely on the few uA these produce. They are ideal for things like keys, but an optical enocder will want something of only a very few Kohm.
Do you have the line driver output version, or the NPN (open collector) version. If you have the later, then put something like 1K2R pull up resistors, and you may well find the code starts working....

Best Wishes

[maryp]

I apologize if in my posts i sounded like i was blaming the code for my problems. I'm sure this code works very well like many other people have said and it sure helped me a lot. My code is just very slightly different, but it seemingly worked for me initially on the bench-test too.
But the fact remains that i am having a counting error which seems to be happening only while counting down. Counting up from dead-stop/zero-counter, its right-on every time. counting down, its off by so-many-counts each time which just cumulates. If its off by 14 first time, then 28 2nd time... about 140-150 10th time... reduced clk freq in half, and error was reduced in half. Though I'm not sure if those would co-relate, just an observation.
Right now I'm cheating my s/w so that counter=counter-7 end of each cycle, which hold up pretty decent till instead of 7, its off by 6 or 8, then it again starts to pile up.
I assume by "bchanged = 0" you are clearing the interrupt flag? In my code I had to move that statement to the top, right after i have read PortB. Encoder is not open-collector.

[Ttelmah]

OK.
First try something really simple.
Reverse the A, and B lines.
The counter will run the opposite way. See if the fault also 'reverses'.
If it remains in the same direction (when the unit moves in the direction you currently call 'down'), then the fault is coming from something outside. Noise etc., happening when the motor is powered in this direction. Then try buffering the signals from the encoder, through a Schmitt trigger buffer. Unfortunately, the inputs supporting the interrupt on change function, are TTL inputs and as such can seen quite small noise levels as a 'count'.
Then, post a trimmed down version of the code showing the problem. Maybe something obvious going on, like the interrupt getting disabled for some event (things like writing to the EEPROM for example....). The act of trimming down to a minimum showing the problem, may well in itself 'point out' where the problem is.

Best Wishes

[maryp]

Thank you for your time and help, really appreciate it. Seems like the problem has been solved.
I assumed that being TTL, signals were already wee-bit noise-immune but even then, like I'd mentioned earlier, I do already have my encoder o/p coming into the pic through a schmitt trigger.
I guess the reason for the problem was mechanical system's inertia. I gave my software additional 2sec delay and it seems to be working very well for the time being.

[zamzam23]

Thiago Alves, could you combine these two merged code for your 16f877? If yes, can I get it? Thanks.