Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)
-   -   Third Encoder Channel (http://www.chiefdelphi.com/forums/showthread.php?t=34454)

crazykid234 11-02-2005 21:26

Third Encoder Channel
 
Yo. I'm new to encoders. From what I can understand, the default code at Kevin Watson's website only allows for two channels: the first channel uses analog inputs 1 & 6, and the second uses analog inputs 2 & 8. Does anyone know how to create a third encoder channel? Any help will be highly appreciated. Thank you.

Mike Betts 11-02-2005 21:32

Re: Third Encoder Channel
 
Quote:

Originally Posted by crazykid234
Yo. I'm new to encoders. From what I can understand, the default code at Kevin Watson's website only allows for two channels: the first channel uses analog inputs 1 & 6, and the second uses analog inputs 2 & 8. Does anyone know how to create a third encoder channel? Any help will be highly appreciated. Thank you.

First of all, they are digital I/O channels, not analog. You can use DIO3-6 for the next interrupt input (phase A) and almost any unused digital channel for phase B.

Alan Anderson 11-02-2005 23:37

Re: Third Encoder Channel
 
Quote:

Originally Posted by crazykid234
Yo. I'm new to encoders. From what I can understand, the default code at Kevin Watson's website only allows for two channels: the first channel uses analog inputs 1 & 6, and the second uses analog inputs 2 & 8. Does anyone know how to create a third encoder channel? Any help will be highly appreciated. Thank you.

It's not hard, but you do have to know what you're doing to get it right.

We're using three encoders. Two of them are on pins 1&7 and 2&8, using essentially Kevin's code. The third is on pins 3&9, with a few lines of interrupt initialization and service routine copied from Kevin's interrupts.c to dispatch the third encoder's handler when INT4 occurs. There is also an extra check to call the handler only when INT4 was triggered by a falling edge of the signal on pin 3. (That part of the code seems a little inconsistent, as if the input pin were going low and then high again before we had a chance to look at it. I'm considering wiring in a hardware pulse-stretch circuit to deal with it.)

To avoid extra interrupts that we would just have to ignore, we have nothing connected to pins 4-6.

Kevin Watson 12-02-2005 00:51

Re: Third Encoder Channel
 
Quote:

Originally Posted by Alan Anderson
I'm considering wiring in a hardware pulse-stretch circuit to deal with it.)

Alan,

The simplest way to do this is with a D-type flip-flop (e.g., 74ACT74, 74HCT74, 74LS74, etc.). The encoder's phase-A signal goes to the the clock input and the RC interrupt input. The phase-B signal goes to the flip-flop's D input and the Q output goes to the RC digital input formally used by the phase-B signal. I prototyped this circuit and saw a pretty dramatic increase in the maximum count rate that the RC could handle.

-Kevin

Mr. Lim 12-02-2005 08:53

Re: Third Encoder Channel
 
Quote:

Originally Posted by Kevin Watson
Alan,

The simplest way to do this is with a D-type flip-flop (e.g., 74ACT74, 74HCT74, 74LS74, etc.). The encoder's phase-A signal goes to the the clock input and the RC interrupt input. The phase-B signal goes to the flip-flop's D input and the Q output goes to the RC digital input formally used by the phase-B signal. I prototyped this circuit and saw a pretty dramatic increase in the maximum count rate that the RC could handle.

-Kevin

Three quick questions:

1) Must interrupts 3-6 be enabled/disabled as a package? i.e. you cannot ONLY enable 3, but not 4-6? I am using two encoders and the Hall Effect sensor, and need only 3 interrupts, and would rather not have to enable 6 of them.

2) If Q1 is true, and we enable 3-6, should we move the phase-B signal on I/O 6 to 7 in order to avoid unnecessary interrupts?

3) Does phase stretching circuit described in the threads above allow a faster count rate because it prevents the phase-B state from changing (to the wrong state) before the interrupt is serviced?

I know some of these should be pretty obvious, but Team 188 is running the Grayhill 63R256 encoders, and our count rates are pretty high. I'm hoping to stave off any interrupt issues that might arise =).

-SlimBoJones...

Kevin Watson 12-02-2005 12:56

Re: Third Encoder Channel
 
Quote:

Originally Posted by SlimBoJones
1) Must interrupts 3-6 be enabled/disabled as a package? i.e. you cannot ONLY enable 3, but not 4-6? I am using two encoders and the Hall Effect sensor, and need only 3 interrupts, and would rather not have to enable 6 of them.

Yes, but it's not a big deal. If you're not using the other three interrupts, just treat the interrupt the same way you would the first two. The only added step is to determine which edge caused the interrupt to fire off.



Quote:

Originally Posted by SlimBoJones
2) If Q1 is true, and we enable 3-6, should we move the phase-B signal on I/O 6 to 7 in order to avoid unnecessary interrupts?

Yes, definitly. Just edit encoder.h to specify which digital input you've moved it to.



Quote:

Originally Posted by SlimBoJones
3) Does phase stretching circuit described in the threads above allow a faster count rate because it prevents the phase-B state from changing (to the wrong state) before the interrupt is serviced?

Yes, and it works really well.



Quote:

Originally Posted by SlimBoJones
I know some of these should be pretty obvious, but Team 188 is running the Grayhill 63R256 encoders, and our count rates are pretty high.

The above circuit will increase your maximum count rate by a factor of four.

-Kevin

Kevin Watson 12-02-2005 15:24

Re: Third Encoder Channel
 
Quote:

Originally Posted by Kevin Watson
The simplest way to do this is with a D-type flip-flop (e.g., 74ACT74, 74HCT74, 74LS74, etc.). The encoder's phase-A signal goes to the the clock input and the RC interrupt input. The phase-B signal goes to the flip-flop's D input and the Q output goes to the RC digital input formally used by the phase-B signal. I prototyped this circuit and saw a pretty dramatic increase in the maximum count rate that the RC could handle.

Here's a schematic of the circuit described above.

-Kevin

stephenthe1 13-02-2005 17:10

Re: Third Encoder Channel
 
Quote:

Originally Posted by Alan Anderson
It's not hard, but you do have to know what you're doing to get it right.

We're using three encoders. Two of them are on pins 1&7 and 2&8, using essentially Kevin's code. The third is on pins 3&9, with a few lines of interrupt initialization and service routine copied from Kevin's interrupts.c to dispatch the third encoder's handler when INT4 occurs. There is also an extra check to call the handler only when INT4 was triggered by a falling edge of the signal on pin 3. (That part of the code seems a little inconsistent, as if the input pin were going low and then high again before we had a chance to look at it. I'm considering wiring in a hardware pulse-stretch circuit to deal with it.)

To avoid extra interrupts that we would just have to ignore, we have nothing connected to pins 4-6.

hi, I tried doing the same thing, but I ran into problems because interrupts 3-6 are "ganged together". how do I reference one at a time? I couldn't figure out how to clear the interrupt flag either. basically, are there any magic lines of code to access one instead of all 4. we're going to need a third interrupt also (the arm), and since our team is pushing the building to the last minute, I can't afford have code messing up too much. thanks.

Alan Anderson 13-02-2005 20:50

Re: Third Encoder Channel
 
Quote:

Originally Posted by stephenthe1
hi, I tried doing the same thing, but I ran into problems because interrupts 3-6 are "ganged together". how do I reference one at a time? I couldn't figure out how to clear the interrupt flag either. basically, are there any magic lines of code to access one instead of all 4.

The magic lines of code are what I cribbed from Kevin's interrupts.c example.

Initialization is easy (easier than the other two interrupts, because there's no rising/falling edge selection). Testing to see which pin caused the interrupt involves remembering the state of PortB between interrupts and comparing the current state to see where they differ. My software also specifically checks to make sure the pin is in the proper state, so that I'm only calling the service routine on the desired edge of the signal.

Mr. Lim 13-02-2005 23:32

Re: Third Encoder Channel
 
Quote:

Originally Posted by Kevin Watson
Here's a schematic of the circuit described above.

-Kevin

Built it =)

It runs great!!! Thanks!

-SlimBoJones...

kutty18 16-02-2005 10:16

Re: Third Encoder Channel
 
Hmmmm...is it possible to have a fourth encoder channel. How do I check for which Interrupt's (3-6) logic state has changed if I used a fourth encoder? Thanks.

Jon236 16-02-2005 10:50

Re: Third Encoder Channel
 
1 Attachment(s)
Quote:

Originally Posted by kutty18
Hmmmm...is it possible to have a fourth encoder channel. How do I check for which Interrupt's (3-6) logic state has changed if I used a fourth encoder? Thanks.


Here are our encoder files which will help you.

Jon
Mentor
Team236

kutty18 16-02-2005 14:49

Re: Third Encoder Channel
 
Quote:

Originally Posted by Jon236
Here are our encoder files which will help you.

Thank you very much. I will test it tonight...

about_abot 18-02-2005 09:29

Re: Third Encoder Channel
 
Quote:

Originally Posted by Jon236
Here are our encoder files which will help you.

Jon
Mentor
Team236

Jon,

Thanks for the help. I see you have a robot.h included in your user_routines_fast.c. Is there something in it that we would need to get it all to work?

-Gary
Team 1008

Jon236 18-02-2005 10:47

Re: Third Encoder Channel
 
Quote:

Originally Posted by about_abot
Jon,

Thanks for the help. I see you have a robot.h included in your user_routines_fast.c. Is there something in it that we would need to get it all to work?

-Gary
Team 1008


We were unable to get the scripts to work as advertised. What finally worked was changing the list of commands into a switch...case series of statements that stepped through the commands in much the same way as the code in robot.c does. We used variables for the parameters which are then used by the called function. We did use the functions in robot.c and wrote additional ones for our arm.

Jon
Team236
"It's in the blood!"


All times are GMT -5. The time now is 01:12.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi