There appears to be between .3 to .4 second delay reading the 3-wire ports values at driver mode initialization. We discovered this because we use a limit switch to reset rotation of some motors on startup. We had to add a .4 second delay before reading the value and determining if the mechanism had truly reached the limit or the motor would drive into the limit switch compressing it and modifying its responsiveness.
I just checked this and I see no delay on reading a limit switch on entry to driver control when using VCS. This was the simple test code I used.
using namespace vex;
brain Brain;
competition Comp;
limit l1( Brain.ThreeWirePort.A );
void autonomous( void ) {
while(true) {
task::sleep(20);
}
}
void usercontrol( void ) {
int count = 0;
static int calls = 0;
calls++;
Brain.Screen.printAt( 170, 120, "Limit on entry %d", l1.pressing() );
while (true)
{
Brain.Screen.printAt( 170, 80, "En %3d", count++ );
Brain.Screen.printAt( 170, 100, "Driver %d", calls );
Brain.Screen.printAt( 170, 140, "Limit now %d", l1.pressing() );
task::sleep(20);
}
}
int main() {
int count = 0;
Comp.autonomous( autonomous );
Comp.drivercontrol( usercontrol );
while(1) {
Brain.Screen.printAt( 10, 50, "Hello %d", count++ );
// Allow other tasks to run
this_thread::sleep_for(10);
}
}
Can you post something that demonstrates the problem ?
There will always be a small delay when reading the 3wire ports, but it should be less than 20mS when using VCS.
The following code will run the motor (even if the limit is pressed) for a little more than .3 seconds unless a delay is placed in front.
while(!Limit1.pressing()){
motor1.spin(directionType::rev,50,velocityUnits::pct);
}
motor1.stop();
motor1.resetRotation();
ok, I just tried this, the motor didn’t move if the limit switch is pressed.
However, are you using a competition switch ? If you are using the driver skills run feature from the controller there is a chance it can, the reason is that driver control will be called as soon as you program starts and before any of the three wire ports have been configured, So there’s not exactly a delay in reading the switch, they just need time to be configured properly.
Always use a competition switch to test code if possible.
void usercontrol( void ) {
int count = 0;
static int calls = 0;
calls++;
//Brain.Screen.printAt( 170, 120, "Limit on entry %d", Limit1.pressing() );
while(!Limit1.pressing()){
motor1.spin(directionType::rev,50,velocityUnits::pct);
}
motor1.stop();
motor1.resetRotation();
while (true)
{
Brain.Screen.printAt( 170, 80, "En %3d", count++ );
Brain.Screen.printAt( 170, 100, "Driver %d", calls );
Brain.Screen.printAt( 170, 140, "Limit now %d", Limit1.pressing() );
task::sleep(20);
}
}
I believe in most cases we are seeing it when we run the program directly. This is being run from a task in our code. Let me strip everything out and test again.
Does the 3 wire ports initiate when the program is running and field control is disabled? (Aka do they start sensing immediately when the program is running and field control is disabled?)
yes, actually the same situation.
When a program is run we don’t initially know what each 3wire port could be. The program configures them right at the beginning of the code, if they are read and the configuration has not yet finished (it can take some time) we probably just return 0 if you try and read them. If no competition switch is connected the usercontrol task will be started at more or less the same time as main (slightly after it), so yes you will see the situation you describe as configuration of the 3wire ports will not yet have completed.
Three wire ports are configured just before main is called for those you have declared as global instances, but the configuration has to be sent to the internal micro controller that supervises them, so it will take some time, I forget exactly, perhaps 50mS.
Confirmed here also. If I place the controller into disable mode first, the motor does not move. If I go directly into driver mode then the issue occurs (driver practice verses competition environment). As I stated before, the delay was causing issues setting a sustainable “zero” location and affecting the reliability of the limit switch. Just wanted others to know incase they see the same thing.
one more comment
this code demonstrates I think the issue you have.
using namespace vex;
brain Brain;
limit Limit1( Brain.ThreeWirePort.A );
int main() {
int line = 10;
Brain.Screen.setFont( fontType::mono15 );
for(int i=0;i<50;i++, line+=12 ) {
Brain.Screen.printAt( 10, line, "time %4d L1 %d", i*20, Limit1.pressing() );
this_thread::sleep_for(20);
}
while(1) {
// Allow other tasks to run
this_thread::sleep_for(10);
}
}
It shows that limit switch pressed state is not set until 260mS have elapsed, I’m surprised it’s that long so we will have a look and see why.
Much appreciated as always.