URGENT - Cortex Disconnection Problems

Repost from https://vexforum.com/showthread.p...144#post318144

Sorry for the spam, but any help is greatly appreciated. The two different sections require me to double post :mad:

We’re currently stuck as we cannot use our Cortex…

I have been having consistent problems where VEXnet would disconnect and the joystick would lose control of the robot. Usually this is not a big problem and we can figure it ourselves via different vexnet keys or whatnot. The issue we are having now is that our arm motors would continue to run in the direction that it was previously moving in BEFORE the disconnect. We’ve ended up with only a couple of broken axles thankfully, as we have to dive to turn the robot off…

I am using the newest revision of robotC and any help is appreciated. Is it a problem with robotC or could it be my code? I’ve already removed my arm state codes and the includes file is a fresh copy.


I have flashed the three different firmwares required using ROBOTC (3.51)'s latest firmwares. I will try to replicate the problem tomorrow in class, but without our arm on so we don’t break any gears If it is indeed not my code and nothing wrong with ROBOTC, does that imply the cortex is … malfunctioning … ahh

Many thanks,
Timothy Leung

#pragma config(Sensor, dgtl12, ArmButton,      sensorTouch)
#pragma config(Motor,  port1,           BackDriveLTwo, tmotorVex393, openLoop)
#pragma config(Motor,  port2,           FrontDriveL,   tmotorVex393, openLoop)
#pragma config(Motor,  port3,           ArmL2,         tmotorVex393, openLoop, reversed)
#pragma config(Motor,  port4,           ArmR1,         tmotorVex393, openLoop, reversed)
#pragma config(Motor,  port5,           BackDriveROne, tmotorVex393, openLoop)
#pragma config(Motor,  port6,           BackDriveLOne, tmotorVex393, openLoop, reversed)
#pragma config(Motor,  port7,           ArmL1,         tmotorVex393, openLoop)
#pragma config(Motor,  port8,           FrontDriveR,   tmotorVex393, openLoop, reversed)
#pragma config(Motor,  port9,           ArmR2,         tmotorVex393, openLoop)
#pragma config(Motor,  port10,          BackDriveRTwo, tmotorVex393, openLoop, reversed)
//*!!Code automatically generated by 'ROBOTC' configuration wizard               !!*//

#pragma platform(VEX)
#pragma competitionControl(Competition)
#pragma autonomousDuration(20)
#pragma userControlDuration(120)

#include "Vex_Competition_Includes.c"

// Variables

int joy_1_x = 0;
int joy_1_y = 0;
int joy_2_x = 0;
int FrontRight = 0;
int FrontLeft = 0;
int BackRight = 0;
int BackLeft = 0;
int armpower = 0;

void pre_auton()

	bStopTasksBetweenModes = true;


task autonomous()


task usercontrol()

	while (true)

		// Getting Values
		joy_1_x = vexRT[Ch4];
		joy_1_y = vexRT[Ch3];
		joy_2_x = vexRT[Ch1];

		// Setting Deadzones
		if(joy_1_x <= 50 && joy_1_x >= -50){joy_1_x = 0;}
		if(joy_1_y <= 30 && joy_1_y >= -30){joy_1_y = 0;}
		if(joy_2_x <= 30 && joy_2_x >= -30){joy_2_x = 0;}

		// Holonomic math
		FrontLeft = (1*joy_1_y) + (joy_1_x) +	 (joy_2_x);
		FrontRight = (1*joy_1_y) + (-1*joy_1_x) + (-1*joy_2_x);
		BackRight = (1*joy_1_y) + (joy_1_x) + (-1*joy_2_x);
		BackLeft = (1*joy_1_y) + (-1*joy_1_x) + (joy_2_x);

		// Checking

		if (FrontLeft >= 127)
			FrontLeft = 127;
		else if (FrontLeft <= -127)
			FrontLeft = -127;

		if (BackRight >= 127)
			BackRight = 127;
		else if(BackRight <= -127)
			BackRight = -127;

		if (	FrontRight >= 127)
			FrontRight = 127;
		else if(	FrontRight <= -127)
			FrontRight = -127;

		if (BackLeft >= 127)
			BackLeft = 127;
		else if(BackLeft <= -127)
			BackLeft = -127;

		//// Motor

		motor[BackDriveLOne] = motor[BackDriveLTwo] = BackLeft;
		motor[FrontDriveL] = FrontLeft;
		motor[BackDriveROne] = motor[BackDriveRTwo] = BackRight;
		motor[FrontDriveR] = FrontRight;

		if(vexRT[Btn5U] == 1)
			SensorValue[PistonLeft] =0;
			SensorValue[PistonRight] =0;

		else if (vexRT[Btn5U] ==0)
			SensorValue[PistonLeft] =1;
			SensorValue[PistonRight] =1;

		if(vexRT[Btn6U] == 1)
			armpower = 127;
		else if (vexRT[Btn6D] ==1)
			armpower = -127;
			armpower = 0;

		motor[ArmL1] = motor[ArmL2] = motor[ArmR1] = motor[ArmR2] = armpower;


You are not alone, im having the same problems with 3.51 - although i thought it was because of the IME’s like the previous problems, however you dont seem to be using them looking at the program… hmmm, i think im going to downgrade and see if it fixes my problems tomorow - did you only notice it after upgrading to 3.51 as well?

YES. I have two IME’s attached but they are not in the code as I stripped it down to the bare minimum. I assume they could continue to affect the cortex. Perhaps it is robotC and not the cortex then if you have the same problem :smiley: … I have started a q&a with robotC and they tested the code with no problems. I will let them know about the IME’s.

I’ve never had this problem until after the upgrade. Would downloading the worlds firmware that they handed out and downloading it manually be the way to go? Time to find out tomorrow

Im just gonna go back to 3.08 which was working fine just the other day, you can find the download here http://www.robotc.net/download/cortex/

No guarantee it will fix the problems, but its worth a shot (ive got a scrimmage tomorrow, so il tell you how it goes when i get back)

Are your IME’s plugged in or just attached?

Sounds exciting! we don’t have any scrimmages in our area :< .

They’re plugged in to cortex as we wired everything up but haven’t started to program. I’ve let them know about trying to recreate the problem simply by plugging in some IME’s.

I’ll let you know how 3.08 goes for me tomorrow.

Awesome, i just downloaded 3.08, so i will test right now and see if i can make it go into the infinite loop again

This all makes sense now… Because we attempted to use the same code with the same revision on an external cortex while powering only one arm
motor to recreate the problem… Had no luck because there was nothing in the i2c port

I’m going to head to bed in a bit, I’ll check up on the thread in the morning


I just had a quick 5 minute drive and couldnt get it to cut out, that doesnt mean its fixed though because it was so short, il just have to see tomorrow and let you know :stuck_out_tongue:

im off to bed now too, night :stuck_out_tongue:

I’m glad I’m not the only one experiencing this!

Our robot has been running like a champ, up until recently. As you guys mentioned, the cortex would lose sync and the robot would continue moving.
We also have some integrated encoders on our robot, but they haven’t been implemented yet.

What’s odd is that I downloaded the firmware onto 2 different cortex platforms, and they both experienced the same problem.

I’m beginning to suspect that it is actually the computer to blame! I’m using an ASUS R.O.G. laptop to download code. At Nationals last year, after downloading firmware from the same computer, the robot would simply decide to de-sync. However, when we downloaded the firmware from a different laptop, it ran perfectly!

So if worst comes to worst, try downloading firmware off of a different machine. We will be attempting it today, so I’ll tell you if it works. :slight_smile:

This should be pretty obvious, but as there are various versions of Cortex out there could everyone who posted with a problem reply with the version of the cortex they saw the problem on?

Also if you can the software inspection page from Robot C

And if you saw the problem when IME’s where installed in the I2C port or not (even if they were not identified in the code you tested)

Cheers Kb

We recently upgraded to 3.51 and haven’t had any noticeable issues as of right now, but we haven’t run the robot extensively.

Yes, look on the base of the cortex and let us know if it is NC1, NC2, A3 etc. This was key information the last time there were similar problems. I’ve been running 3.51 on a 4 motor/4 IME chassis with no issues, but the IMEs are enabled. I also tend to add the IMEs to the motors & sensors setup even if the code does not use them.

questions for timL

Do you loose control of all motors or just specific ports?

Can you reproduce this by manually causing a disconnect? For example, will turning off the joystick cause this issue?

Can you try to run the robot with the IME cable disconnected from the cortex.

An interesting thing about this issue back when it was caused by the IME’s is that even on field control when the robot that “locked up” was disabled, it would continue to move (ie. it did not respond to field control). If this is actually an issue with 3.51 and a particular cortex version, I’m sure a bunch of people will have the issue at the scrimmage today, so we’ll keep you updated if the issue is the same.

I lost control with the robot completely. I believe the the lights on the joystick controller were green joystick and one of the other lights were blinking green… The other two lights did not light up. I can’t seem to remember which now though.

I’m not sure what version our cortex is … but it is one of the newer ones with the raised vexnet housing.

I unplugged our IME’s today and the robot did not experience a single problem, including vexnet disconnects. This could lead me to believe that the problem is not related to VEXnet but a problem with the code/firmware itself? This is purely speculation though.

However, I did not downgrade the robot. For the sake of not destroying any more axles, I did not plug them back in to see if I could reproduce the problem.

Probably an A3

Any chance the I2C (the IME cable) was plugged into a UART port by mistake?

I tried to reproduce this on a couple of systems today but could not, the closest I thing I found was that ports 1 and 10 momentarily pulsing motors at the point of disconnect or reconnection.

Back home!

Today after downgrading to 3.08, i only got stuck in a loop once compared to every second or so practice match yesterday (yay!)

The only thing i can put it down to is the IME’s, im running the exact same program ive been running all season - all that has changed it the definitions at the top (oh, and adding a gyro as well), before the IME’s i didnt get stuck once :confused:

Im also using a humpback cortex, i havent got my robot with me right now so i cant check what sort though

It was not plugged into the UART port as I have my LCD plugged into the port but not programmed once again. :smiley:

I doubt it will be something as silly as that as jacko is having the same problem

I should be noted there are 2 uart ports and 1 I2C all in the same 3 slot 4 pin input spot. The 2 uarts are next to each other while the i2C is on the bottom. it’s not unreasonable to find the I2C plugged into one of the Uarts by mistake. Just looking for obvious configuration issues.

Cheers Kb

Sorry, I understand your point. Do you think that would cause such symptoms? I can’t be one hundred percent sure at the moment.

I unfortunately don’t know enough about the internals to know if this is a potential cause. I do like to take careful stock of the situation when we have problems because we have often had weird behavior and later it clears up for no apparent reason. Last year we had several instances of a robot continuing to move after losing link, and we had no IME’s on our bot. In our case we isolated a bad (or suspect) Vex Net Key and after we did not lose lock we stopped worrying about it. Unfortunately it’s very difficult sometimes to get the students to record the observable facts and with out a history each problem can take a long time to isolate and resolve. So any information you can provide to clarify the configuration during the issue would be welcome from my perspective to understanding in these unusual cases what might be contributing.

Cheers Kb