Software or hardware problem?
-
- Flowcode v5 User
- Posts: 28
- Joined: Wed Oct 02, 2013 12:16 pm
- Has thanked: 7 times
- Been thanked: 7 times
Software or hardware problem?
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
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
-
- Flowcode v5 User
- Posts: 28
- Joined: Wed Oct 02, 2013 12:16 pm
- Has thanked: 7 times
- Been thanked: 7 times
Re: Software or hardware problem?
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
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
-
- Flowcode v5 User
- Posts: 28
- Joined: Wed Oct 02, 2013 12:16 pm
- Has thanked: 7 times
- Been thanked: 7 times
Re: Software or hardware problem?
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.
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.

-
- Flowcode v5 User
- Posts: 28
- Joined: Wed Oct 02, 2013 12:16 pm
- Has thanked: 7 times
- Been thanked: 7 times
Re: Software or hardware problem?
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

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
-
- Matrix Staff
- Posts: 9521
- Joined: Sat May 05, 2007 2:27 pm
- Location: Northamptonshire, UK
- Has thanked: 2585 times
- Been thanked: 3815 times
Re: Software or hardware problem?
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
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
Martin
-
- Flowcode v5 User
- Posts: 28
- Joined: Wed Oct 02, 2013 12:16 pm
- Has thanked: 7 times
- Been thanked: 7 times
Re: Software or hardware problem?
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
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
-
- Flowcode v5 User
- Posts: 28
- Joined: Wed Oct 02, 2013 12:16 pm
- Has thanked: 7 times
- Been thanked: 7 times
Re: Software or hardware problem?
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
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
- Benj
- Matrix Staff
- Posts: 15312
- Joined: Mon Oct 16, 2006 10:48 am
- Location: Matrix TS Ltd
- Has thanked: 4803 times
- Been thanked: 4314 times
- Contact:
Re: Software or hardware problem?
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.
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.
Regards Ben Rowland - MatrixTSL
Flowcode Product Page - Flowcode Help Wiki - Flowcode Examples - Flowcode Blog - Flowcode Course - My YouTube Channel
Flowcode Product Page - Flowcode Help Wiki - Flowcode Examples - Flowcode Blog - Flowcode Course - My YouTube Channel
-
- Flowcode v5 User
- Posts: 28
- Joined: Wed Oct 02, 2013 12:16 pm
- Has thanked: 7 times
- Been thanked: 7 times
Re: Software or hardware problem?
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?
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?
-
- Flowcode v5 User
- Posts: 28
- Joined: Wed Oct 02, 2013 12:16 pm
- Has thanked: 7 times
- Been thanked: 7 times
Re: Software or hardware problem?
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
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
-
- Flowcode v5 User
- Posts: 28
- Joined: Wed Oct 02, 2013 12:16 pm
- Has thanked: 7 times
- Been thanked: 7 times
Re: Software or hardware problem?




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.
-
- Flowcode v5 User
- Posts: 28
- Joined: Wed Oct 02, 2013 12:16 pm
- Has thanked: 7 times
- Been thanked: 7 times
Re: Software or hardware problem?
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.



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.
- Attachments
-
- Interrupt Fault.jpg (125.15 KiB) Viewed 17617 times
-
- Matrix Staff
- Posts: 9521
- Joined: Sat May 05, 2007 2:27 pm
- Location: Northamptonshire, UK
- Has thanked: 2585 times
- Been thanked: 3815 times
Re: Software or hardware problem?
Hi Andrew,
Well done for getting your flwochart to work.
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
Well done for getting your flwochart to work.
Take a look at this help pageAndrewC wrote:I'm' not sure why the unused pins gave me so much trouble.
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
Martin
-
- Flowcode v5 User
- Posts: 28
- Joined: Wed Oct 02, 2013 12:16 pm
- Has thanked: 7 times
- Been thanked: 7 times
Re: Software or hardware problem?
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
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
-
- Flowcode v5 User
- Posts: 28
- Joined: Wed Oct 02, 2013 12:16 pm
- Has thanked: 7 times
- Been thanked: 7 times
Re: Software or hardware problem?
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
Where did it go?
Thanks Andrew
- LeighM
- Matrix Staff
- Posts: 2178
- Joined: Tue Jan 17, 2012 10:07 am
- Has thanked: 481 times
- Been thanked: 699 times
Re: Software or hardware problem?
probably here ...
http://www.matrixtsl.com/wiki/index.php ... 2979cfc92e
for any components, best starting here ...
http://www.matrixtsl.com/wiki/index.php ... Components
http://www.matrixtsl.com/wiki/index.php ... 2979cfc92e
for any components, best starting here ...
http://www.matrixtsl.com/wiki/index.php ... Components