Gear tooth sensor / GTS on DIO 3,4,5,6?

[demerski]

Hi,

We're having some issues getting gear tooth sensors working on the inputs other than 1 or 2 (we may use more than 2 sensors for speed control). Last year, we modified the encoder code so that we could run up to 6 encoders on inputs 1 through 6, and it worked fine. Now, modifying what we were using last year, the GTS's work fine on inputs 1 and 2 (counting in both directions...though we are not sensing what direction). However, they will only count in one direction on any of the other 4 channels (counts one direction only, nothing the other way).

Has anyone else run into this issue? I know the interrupts on 3 through 6 are ganged together, and I *think* they are set up ok (like I said, encoders work on all 6 channels)...

Any clues? Thanks in advance...

- Jason D.

Team 1027: The Mechatronic Maniacs
www.team1027.com

[Goldeye]

I'm assuming your issue is accessing which of the interrupts 3-6 went off. If not, sorry -_-

Take a look at Kevin Watson's interrupt tutorial. It gives well annotated code for initializing and using all the interrupts. There is a way to use all 6 pins seperately, all though you need to use the method he does.

However, you need to convert it to use the files for the new RC.
Replace the #include <ifi_picdefs.h> with #include <p18cxxx>, replace the linker file with the 18c8722.lkr from this year's default code, and change MPLAB's project options to build using the P18C8722 as the processor.

[Alan Anderson]

The only difference in the GTS signal for the two directions is the length of the high-going pulse. It should trigger identically for both CW and CCW sensing. Unless you've forgotten to take out the "phase B" code, I can't think of any reason it would count in one direction but not the other.

Or maybe you're not properly accounting for the fact that you get both high-going and low-going interrupts on pins 3-6, though that doesn't seem to be likely to cause the results you're getting.

[demerski]

Thanks for your feedback...yeah, the second pin code has been removed.

The only thing going on in the code is the counter incrementing on any interrupt, whether the pulse is going high or low. I haven't looked at the hardware specs yet...and I'm not really a digital guy, but I'm wondering if the pulse in that direction is so short that the low-going interrupt triggers before the handler is done with the high-going interrupt. Would something like that cause the handler to bail before the first calculation is done? It would explain why it's not incrementing at all, but I'm just guessing. I'll keep looking...

We appreciate your input!


- Jason D.

Team 1027: The Mechatronic Maniacs
www.team1027.com

[Alan Anderson]

The "short" pulse from the GTS is about 30 microseconds. If it takes longer than that for the interrupt service routine to get around to clearing the proper interrupt flag, you'll already have missed the falling edge and won't get another interrupt from it. That means that you'd only count one transition per pulse, as opposed to two for the other sensor, but I don't see why you'd get no counts.

Just as a random suggestion, try moving the code for pins 3-6 to as early in the ISR as possible, before any serial interrupt, pins 1-2, or timer interrupt checks. If it is the pulse length that's tripping you up, that might help.

One more thing occurs to me, and please forgive my nagging about it, but can you double-check to make sure you're not still testing the state of the input pin and deciding whether to increment or decrement the counter? If that code is still there, then you're actually getting counts for the short pulse (because you're always reading it as low by the time you test it), but you're counting one way and then immediately the other way for the long pulses so it doesn't look like you're counting at all.

[demerski]

One more thing occurs to me, and please forgive my nagging about it, but can you double-check to make sure you're not still testing the state of the input pin and deciding whether to increment or decrement the counter? If that code is still there, then you're actually getting counts for the short pulse (because you're always reading it as low by the time you test it), but you're counting one way and then immediately the other way for the long pulses so it doesn't look like you're counting at all.
No problem...it is easy to overlook the obvious! I think we're ok, though. For the GTS, the interrupt handler looks like this:


void Int_3_Handler(unsigned char RB4_State)
{
// this function will be called when an interrupt 3 occurs
LF_Count = LF_Count + 1;
}

So it should just increment on any interrupt, no? For the encoders, it was set up like this:

void Int_4_Handler(unsigned char RB5_State)
{
// this function will be called when an interrupt 4 occurs
if ((rc_dig_in04 == 0) && (LR_Last_State == 1))
{
if (LR_PHASE_B_PIN == 0)
{
LR_Count = LR_Count - 1;
}
else
{
LR_Count = LR_Count + 1;
}
}
// remember the input state for next time
LR_Last_State = rc_dig_in04;
}