The Cortex has 10 motor ports.
The motor ports contain 4Amp resettable fuses (circuit breakers) to ensure that the motors do not pull too much current from the Cortex. There are two of these fuses, with one covering ports 1-5 and another covering 6-10. Robot builders may have the inclination to plug, say, 6 motors into ports 1-6; it's tidy and seems efficient. However, because of these build-in fuses, it is recommended that motors be distributed so that half are in the 1-5 section and the other half are plugged into ports 6-10. This way, when the robot is under heavy usage, it's less likely to overload the system and trip the fuse (circuit breaker). Robot motors that are likely to run simultaneously, such as the 4 motors a chassis, can be strategically distributed with 2 motors plugged into each section (port 1-5 and 6-10).
On ports 2-9, the VEX Motor Controllers are driven by the master processor (one of the 2 CPUs inside the Cortex) using a standard hobby servo control scheme as follows:
These pulses typically appear on a 20 ms (50 Hz) duty cycle, and therefore it is recommended that the main loop of a user control program be run at 20ms intervals. Including a 20ms “wait” in one's loop, however, does not necessarily guarantee that the motors will be updated at precisely 20ms intervals; the SPI communication between the master processor (where the motors are set electrically) and the user processor (where the user's software sets the motor power) happens at 15ms intervals. The best-case interval for the motors to receive instructions is roughly 2ms, and the worst-case interval would be around 35ms (20ms + 15ms).1)
Ports 1 and 10 are driven by the user processor (as opposed to the master processor, as in Ports 2-9). This difference allows the motor instructions to be updated at faster intervals (up to 2ms) because the intervening step of the master processor-to-user processor communication is eliminated.
The VEX Forum user @jpearman ran numerous motor tests that compare the functioning of the two types of Cortex ports;2) his oscilloscope traces are shown below. In the following graphs:
In his first example below, his program switches a motor from full-forward to full-reverse every 40ms. The graph shows that the port 10 (blue) motor tracks the signal precisely, whereas port 3 (pink) has a significant delay and results in somewhat random amounts of time at each speed, shown by the uneven lengths of the horizontal bars and their poor tracking with the yellow line.
Next @jpearman did the same test, except told the program to reverse direction from full-forward to full-reverse every 4 milliseconds. The differences between the ports is even more dramatic: @jpearman says:
It can be seen that the motor on port 10 is able to keep up with this increase in changing requested speed; however, the motor on port 3 is not able to and changes randomly depending on the relationship between the motor speed request and the SPI message being transmitted to the master CPU [the timing of the communication between user & master CPUs].
Based on the graphs above, it is strongly recommended that motors that must work in concert (such as 2 sides of a lifting arm, or the 4 motors of a chassis) not be mixed-and-matched between Ports 1 & 10, and Ports 2-9. Builders should plan out their motors in advance so that coordinated functions are either controlled completely by external motor controllers (Ports 2-9) or controlled completely by Ports 1 & 10.
Additionally, for robot designs making use of a PID algorithm to match the speeds of 2 motors, plugging those motors into port 1 and port 10 will allow them to be much more responsive to the algorithm's requests for small adjustments.
@jpearman also performed speed tests on motors plugged into each type of port.3) The resulting graph below is a comparison of the real-world output of a motor (RPMs) when the same motor power instructions (e.g., +64, half-power forward) get relayed to the motor via internal motor controllers (Ports 1 & 10, blue line) and external motor controllers (Ports 2-9, red line). Observations:
This non-linearity has prompted some teams to remap the motor output in software to produce a linear output, as described in the Re-Mapping Motor Values article.