Yes, this is correct.
There are two asynchronous events happening.
The SPI communication from the user processor to the master processor which runs every 15mS.
The RC servo control pulse that happens every 18mS.
Worst case would be 15 + 18 + software delay of 1-2mS so perhaps 35mS
Best case if the planets align is perhaps 2mS.
Here are some more examples and tests.
Case 1 used the following code
#pragma config(UART_Usage, UART1, VEX_2x16_LCD, baudRate19200, IOPins, None, None)
#pragma config(Sensor, dgtl1, outputA, sensorDigitalOut)
#pragma config(Motor, port3, motorB, tmotorVex269, openLoop)
#pragma config(Motor, port10, motorA, tmotorVex269, openLoop)
//*!!Code automatically generated by 'ROBOTC' configuration wizard !!*//
task main()
{
while(1) {
// run motors forward
SensorValue outputA ] = 0;
motor motorA ] = 127;
motor motorB ] = 127;
wait1Msec(40);
// run motors backwards
SensorValue outputA ] = 1;
motor motorA ] = -127;
motor motorB ] = -127;
wait1Msec(40);
}
}
Two motors, one on port 10 the other on port 3 are switched between full forward and full reverse speeds. A digital output is set to indicate which speed has been sent to the motors. The scope trace below shows the resultant motor drive signal on one side of the motor, the blue trace (ch2) is for the motor on port 10, the purple trace (ch3) is for the motor on port3 but is measured after the motor controller 29. The Yellow trace is the digital output and is used to trigger the scope.
It can be seen that the port 10 motor responds to the speed control almost instantaneously but the port 3 motor has a variable delay between the requested speed to the resultant change in speed. At the trigger point the delay was measured as 31.6mS, however, this is just one example and varies as predicted in my other post.
This trace shows the delay from speed request to the motor 10 output with an expanded timebase.
The delay is typically around 1mS and is probably due to the ROBOTC task management.
The next trace was captured using the following modified code.
#pragma config(UART_Usage, UART1, VEX_2x16_LCD, baudRate19200, IOPins, None, None)
#pragma config(Sensor, dgtl1, outputA, sensorDigitalOut)
#pragma config(Motor, port3, motorB, tmotorVex269, openLoop)
#pragma config(Motor, port10, motorA, tmotorVex269, openLoop)
//*!!Code automatically generated by 'ROBOTC' configuration wizard !!*//
task main()
{
while(1) {
// run motors forward
SensorValue outputA ] = 0;
motor motorA ] = 127;
motor motorB ] = 127;
wait1Msec(4);
// run motors backwards
SensorValue outputA ] = 1;
motor motorA ] = -127;
motor motorB ] = -127;
wait1Msec(4);
}
}
The difference is that the delay between requesting motor speed changes has been reduced from 40mS to 4mS.
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.
Finally this trace shows the PWM signal going to both motors when a constant speed of 64 is requested. The pwm frequency is about 1200Hz for both. The signal to the motor on port 3 looks noisy due to lack of grounding to the scope.
These tests were done using ROBOTC but I would expect the same result using EasyC, this is not dependent on the user code but rather the way user processor and master processor communicate. It’s interesting that the duty cycle for the port 3 motor is not the expected 50%, if I have time I may measure the no load speeds of the two motors to see if they differ, but that will have to wait until tomorrow.
I post this just as information, in practice this has no impact on any competition code that anyone is likely to be running.
