Matrix user forums

Hi

I'm try to read an rotary encoder (US Digital Differential 4000CPR, 16000PPR with index) together with a 26C32 differential line receiver.
The trouble is it's losing counts, even at a slow speed (The signal is good from the 26C32).

My question is, can I improve the programming with this chip or should I should start again and use another chip (18F25K22), increase the clock speed and using a PORT IOC as in this example? http://www.matrixtsl.com/mmforums/viewt ... 85&#p35128
Thanks
Andrew

Made some progress. It's not missing count's. There seems to be some extra erroneous signals being counted on the end of the return stroke. There for the count is less than before movement.

This was taken on the output side of the line receiver. Input to Pic.

The movement is off hard stop then back to hard stop. Vibration in the 'tone wheel' is one thought (not convinced though) - it is driven by a 2.5mm shaft 80mm long. I'll have a look on the input, both channels, side of the line receiver next for the blue channel.

Thought I'd post up in case anybody has come across this.


Thanks
Andrew

But why would the counter decrease?

Wouldn't that be calculated as vibration as the red channel is not switching?

Note: Complete amateur at this, which I'm sure is obvious.

I think I may have the answer.

The data transfer to interrupting the polling on the pins. Is that a possibility?

Is there any way round this?

Blue channel - Encoder
Red - TX on display


Cheers
Andrew

Hi Andrew,
In my opinion port interrupts is a better option to polling.
Since there is a timer interrupt as well, a change could be missed when polling.

The other thing to take into account is switch contact bounce.
That alone can give false readings with mechanical type of encoders.
I have posted a V6 flowchart here and in a post below that.
Maybe it will help?

Martin

Hi Medelec.

Thanks for that. I'll use a chip with more interrupts and work with your example.

Regarding the switch bounce. This is 16000 counts per revolution optical encoder (E5-4000-079-IE-D-D-D-3) so thinking switch bounce shouldn't be a problem?

The timer interrupt was only used so it wasn't continually updating the screen. I think I'm going to struggle on the screen update. When using an pin interrupt before I had a lot of "stack corruption" warnings.

I'll give it crack and see what happens.

Cheers
Andrew

Hi

Still having problems with this. I have changed the chip to an 18F25K22 and clocked at 64MHz. I have also added caps to the outputs from the line receiver to chip. It is still missing counts.
An interrupt can occur every 25µ seconds.

I'm trying to measure and display an angle and want to repeat the position accurately. Each switch equates to 0.0225°

Anybody got any ideas what I am missing?

Cheers
Andrew

Hello Andrew,

Program looks fine to me.

In your config settings you have the "Extended Instruction Set" option enabled, I would disable this and see if that helps at all. This is known to cause issues with strings and arrays.

Hi Benj

Thanks for the idea. I gave it a try but still no change.

If I do a steady sweep from the index to a fixed stop, about 3300 counts, it gives a very close (but not perfect) repetitive result.
If I randomly move it even just a little the count can be off but not always. Rapid movement will make it worse. A rapid sweep brings an error of about 10 degrees.

I have checked the encoder and that appears good. I have looked very closely at the signals to the chip and can not see any anomalies. No noise.

Could the timer interrupt or the TX cause a missed count?

Hi again.
I’m still not given up on this. I have written a short program to look at the chip’s reaction. Now I am even more confused as this ‘seems’ to imitate the results I have been getting.
Basically I have the chip using a IOC on port B. All the chip has to do once the interrupt has occurred is to check the state of the pins then change the state of two pins on port C to a corresponding state.

The results:
At the start Port C output mirrors the input almost perfectly. Blue is the input into the chip. Red is the output. Only looking at one channel.
After a change in direction a delay has occurred between the input and the mirrored output.
At the end, it just gives up and is now badly missing counts.
These results are the same time and time again. And seem to fit my poor counting results.

Any ideas? I can’t figure this logic out.
Thanks in advance for any input.

Andrew

And here's the program I used for the above test.
Thanks

Well. .... I knew I shouldn't of posted so swiftly. The above program is wrong. It's looking at the wrong pins.

But corrected it and now the behavior is as expected (one missed switch). So now I'm just adding one piece at a time and see what happens.

Oh the sweet, sweet taste of success!!!

A beginners error that caused a huge headache. Not that I understand it, but I can, at will, make this run as sweet as a nut or run like insane mad man. The polling did not work (for me in this case) as it appeared to stop polling/counting while comms was happening, around 30 ms long, which was why the count was incorrect in that case. Even tried changing the Baud rate to 115200 but still lost around 17 ms.

So IOC was the way. The error I had, again a miscount which added to the confusion, was caused by having all four pins on PortB IOC configured to IOC. As soon as I assigned only the pins I was using to the encoder, perfect.
I'm' not sure why the unused pins gave me so much trouble. They were only attached to the fly lead for when I used the Pic programmer - PGC, PGD. But it caused havoc with the interrupts, sometimes missing non, sometimes just missing one (as mentioned above), other times missing many as the image shows. I'm not even convinced it was counting correctly when it didn't seem to miss an interrupt. It was such a simple error that drove me nuts.

Any way, very happy now. The project is to display the angle of a cutting arm, used to facet gemstones on diamond impregnated copper discs. It's now accurate to about 0.07*. Most of the error there is in the linkage to the encoder as a tap and it will settle to with in it's 0.0225* resolution. I'll post an image once I have it finished. I've attached the program with the toggling pins that react to the interrupt. Again only one channel.

Cheers.

Hi Andrew,
Well done for getting your flwochart to work.

AndrewC wrote:I'm' not sure why the unused pins gave me so much trouble.

Take a look at this help page
It shows how to connect switches to microcontroller inputs.
Pins left floating will be changing state due to electrical noise.
to prevent this all unconnected pins must not be assigned to any ports.
They can be set up as outputs but that's unnecessary.
Any pins connected as an input i.e in the case of IOC must have a load e.g pull-up or pull-down resistors which prevents floating pins from randomly changing state.
Microcontrollers have built-in Weak Pull-Up resistors that can be used to reduce hardware count.
The Microcontroller datasheet shows what pins WPU's are used on.



Martin

Thanks for the explanation medelec. Quite obvious really in hindsight.

I had the thought 'well the program isn't using the input from those pins, how can it be a problem' but ignoring the fact the processor was probably going mad servicing the interrupt from interference.


Thanks again
Andrew

Ok. This project is going to fight me to my dying day or drive me to insanity. I have just gone to look at this page a bit deeper http://www.matrixtsl.com/wiki/index.php ... :_General) that medelec35 directed me to.

Where did it go?

Thanks Andrew

probably here ...
http://www.matrixtsl.com/wiki/index.php ... 2979cfc92e

for any components, best starting here ...
http://www.matrixtsl.com/wiki/index.php ... Components