[Kevin Sevcik]

To Alan's comments, the 3-6 ISR code looks functionally identical to my eyes. The falling edge side of the ISRs are doing multi-count prevention logic to keep counts from rising on a wiggly edge transition. Posting the actual user_fast and/or ifi_frc ISR definition would certainly be helpful, but I think it's likely to be KW standard and, thus, correct and identical for each encoder. I've attached the copy from ifi_frc_sensor.zip for the curious.

Personally, I endorse charris's suggestion of physically swapping the encoder hardware connections and also slowing things down and seeing if your problem goes away. I predict that despite swapping the definitions, the problems will remain with the software 5+6 encoders, and that slowing things down will make the problems "magically" disappear.

My bold prediction is that you're running all of your encoders at too high an aggregate frequency for the PIC to keep up, and it's either missing state transitions, or much, much more likely it's checking the B-Phase pin state too late, after it's already made a quarter cycle. This means the encoder will count backwards if it's spinning too fast. Longwinded explanation to follow.

Ideally, the encoder code should add to the count on a rising edge, if Phase_B == 1 at the instant of the rising edge. What the posted code actually does is add to the count on a rising edge, if Phase_B == 1 when the PIC gets around to checking the B_Phase pin. There's a distinct difference here. The rising edge occurs slightly before execution hits the main ISR in ifi_frc.c. The code doesn't get around to checking the state of Phase_B until it falls through several if-elses and finally calls up Int_5_ISR(). Only then does it check the state of Phase_B. But this could be a significant amount of time later if you're using lots of other interrupts, and especially encoders 3+4 are spinning fast enough to need processing at the same time as encoders 5+6. So if the processing delay between seeing a rising edge and checking Phase_B is long enough, the encoder could easily turn far enough that Phase_B == 0 by the time you check it. Which means your software would count down instead of up. This is especially likely if encoders 3+4 are spinning fast enough that the ISR is processing them at the same time it's processing encoders 5+6. The solutions are to either slow down your encoders, or save all the Phase_B states at the beginning of the main ISR. The latter option will help some, but if you're spinning things this fast, you're already riding the edge of overloading your processor anyways....