Most forum members cannot answer questions posted in the RobotC technical Support forum. As you have a competition to tomorrow I wanted to comment so am answering here.
You did not post the #pragma statements from your code, however, it seems unusual that you are using the same indices to the SensorValue arrays as the motor arrays, for example, the use of driveRightFront for both. Unless the motor ports are exactly aligned with the digital input ports I suspect this is your issue. Post the #pragma statement and I can give more input.
Other things to check.
You do mean quad encoders and not IMEs, right ?
Encoder white wire is toward the center of the cortex (towards the VEXnet key).
Is the battery good? (I know, but I have to ask).
Avoid the use of port 10 if port 4 is being used (long story). I suggest digital ports 1 through 8 for the 4 encoders.
If you configure to just use one does that work? Can you move it to different ports? You really only need one on each side for turning, what type of drive do you have?
This caught my eye a while back, Since we have a Cortex which seems to have a bad digital input port 4. This is probably unrelated, but I am curious what prompted the comment above.
The micro-controller in the cortex has a theoretical maximum number of general purpose IO lines, the datasheet lists this as 80. These are separated into 5 groups of 16 labeled PORTA through PORTE. Many of these IOs are shared with other more dedicated functionality such as serial ports, this reduces the available IO to a much smaller subset.
The external interrupt controller on the cortex can use up to 16 external interrupt sources, any of the GPIO lines can be configured to be an interrupt source, however, the same bit from two different ports cannot be used at the same time. For example, you cannot use PORTA bit 0 and PORTB bit 0 at the same time as an interrupt source.
The digital IO on the cortex is mapped as follows.
Digital 1 PortE-bit 9
Digital 2 PortE-bit 11
Digital 3 PortC-bit 6
Digital 4 PortC-bit 7
Digital 5 PortE-bit 13
Digital 6 PortE-bit 14
Digital 7 PortE-bit 8
Digital 8 PortE-bit 10
Digital 9 PortE-bit 12
Digital 10 PortE-bit 7
Digital 11 PortD-bit 0
Digital 12 PortD-bit 1
Notice how Digital 4 and Digital 10 are both using bit 7, this is the root cause of the problem, digital 4 and digital 10 cannot both be used as a source of interrupt at the same time. As the quad encoders rely on interrupts you cannot have an encoder using digital 4 and digital 10.
There is more bad news, I’ve recently noticed that with ROBOTC (V3.51) if digital 10 is configured to be an output then an encoder on digital 3&4 may not work, something in the configuration of digital 10 as an output disables some configuration register for digital 4. This is a bug and I need to look at it some more, I don’t know if it’s a problems with other versions of ROBOTC.
If you assign both ports 4 and 10 a sensor that uses interrupts, ROBOTC will start assigning ports at port 1 and work it’s way up from there. It will assign port 4 as the interrupt (for bit 7) but then when it reaches port 10, it will assign port 10 as the interrupt for bit 7 instead; it will override the previous assignment for port 4. The only way around this is to make sure that ports 4 and 10 are not both using sensors that require interrupts.
I understand this John, however, the situation I recently discovered had a quad encoder on ports 3&4 and an LED on port 10. The port 10 LED is overriding the port 4 interrupt, this should not happen. If port 4 was previously assigned to be a digital output (even on a previous program download) then this does not happen. I was planning to document this and check in older and newer versions before sending it in as a bug.
Well, Thank you for describing this behavior. as I said we had one cortex with a bad digi port 4 at least at the time I thought so, but it was being used as a demo platform for the Mecanum wheels and we had 4 quadrature encoders. so we easily could’ve run into this constraint. I will try to test this Further Saturday for that Cortex.