Help! Frying Cortex's, don't know why

Programming Support VEXcode Pro V5 Text Tech Support
1

First time creating topic, sorry for format. This thread involves a problem my team has faced practically all season. It involves frying ports on multiple cortex’s.

First V5 brain mess up :

The problem began a couple months go when I finally completed all the code for the robot. I completed all the functions for the subsystems (Driving, expansion, intake, tray, etc) and organized into separate cpp files as well as header files. After I uploaded the code it worked flawlessly for the first couple matches, until it didn’t. At first one motor running the front left wheel stopped working completely for the first half of the match, then for the final half of that match it began to run at full speed on it’s own (even when the user wasn’t controlling it to do so). Even after the match ended it kept running until we turned off the cortex completely. After this match whenever we tried to run it again this would occur all over again. At first we thought it was a hardware issue, so we changed out the motor that was messing up. This helped for a couple matches until this would occur all over again. I then assumed there was something wrong with the code, so I began making small adjustments that I thought may effect it. We kept testing with no new results, until more motors actually began to stop working. We then decided to check the ports, which showed that many of the ports stopped working. We would decide to change V5 brain’s and use a new one.

Second V5 brain mess up:
With the first brain being fried, I had a suspicion it was the code that somehow caused this. So I made drastic changes to the code without any real direction towards the problem. With a new cortex and new code (essentially) it started to work again. But the same problem happened again, with the wheel going out and then going non-stop. This time we starting testing each port with new wires and motors. We would switch ports for the motors to be wired to, which would then make it run for a little bit until it went out, and did not work again. A couple days ago, coming back from winter break, we tried running the robot a couple times. This led to a little less than half of the ports to stop working permanently.

With all of this being said it seems as though the code is some how causing the issues, since the likelihood of getting 2, even 1 faulty brain, is very slim. We are sending one of the brain’s into vex, any suggestions are helpful!

The code :

#include "vex.h"
using namespace vex;
vex::brain Brain;
vex::controller Controller1;
vex::competition Competition;
int threshold = 17;
int distance = 0;
vex::motor LeftMotor = vex::motor(PORT10, gearSetting::ratio18_1, true);
vex::motor RightMotor = vex::motor(PORT20, gearSetting::ratio18_1, true);
vex::motor LeftMotor2 = vex::motor(PORT2, gearSetting::ratio18_1, true);
vex::motor RightMotor2 = vex::motor(PORT12, gearSetting::ratio18_1, true);
vex::motor leftIntake = vex::motor(PORT11,gearSetting::ratio18_1);
vex::motor rightIntake = vex::motor(PORT3,gearSetting::ratio18_1);
vex::motor tray = vex::motor(PORT14, gearSetting::ratio18_1);
vex::motor arms = vex::motor(PORT17);


void Tray(){
vex::task::sleep(20);
if(Controller1.ButtonR1.pressing()){
tray.spin(vex::directionType::fwd,
 150, vex::velocityUnits::pct);
}
else if(Controller1.ButtonR2.pressing()){
  tray.spin(vex::directionType::rev,
 150, vex::velocityUnits::pct);
}
else{
   tray.spin(vex::directionType::rev,
 0, vex::velocityUnits::pct);
}
 }

void armMove(){
  vex::task::sleep(20);
  if(Controller1.ButtonUp.pressing()){
arms.spin(vex::directionType::rev,
 150, vex::velocityUnits::pct);
}
else if(Controller1.ButtonDown.pressing()){
  arms.spin(vex::directionType::fwd,
 150, vex::velocityUnits::pct);
}
else{
  arms.spin(vex::directionType::fwd,
 0, vex::velocityUnits::pct);
  arms.setBrake(vex::brakeType::hold) ;
}
 
}





void intake(){
  vex::task::sleep(20);
if(Controller1.ButtonL2.pressing()){
   leftIntake.spin(vex::directionType::rev,
   200, vex::velocityUnits::pct);
   rightIntake.spin(vex::directionType::fwd,
   200, vex::velocityUnits::pct);
}
else if(Controller1.ButtonL1.pressing()){
  leftIntake.spin(vex::directionType::fwd,
   200, vex::velocityUnits::pct);
   rightIntake.spin(vex::directionType::rev,
 200, vex::velocityUnits::pct);
}
else{
   leftIntake.spin(vex::directionType::rev,
   0, vex::velocityUnits::pct);
   rightIntake.spin(vex::directionType::rev,
   0, vex::velocityUnits::pct);
}
 
}


void driveExtend(){
  vex::task::sleep(20);
if(!Controller1.ButtonA.pressing() && !Controller1.ButtonB.pressing()){
 
int right = ( abs(Controller1.Axis4.value()) > threshold)?Controller1.Axis4.value():0;
int forward = ( abs(Controller1.Axis3.value()) > threshold)?-Controller1.Axis3.value():0;
int turn = ( abs(Controller1.Axis1.value()) > threshold)?Controller1.Axis1.value():0;
LeftMotor.spin(vex::directionType::fwd,
forward - turn - right, vex::velocityUnits::pct);
LeftMotor2.spin(vex::directionType::fwd,
forward - turn + right, vex::velocityUnits::pct);
RightMotor.spin(vex::directionType::rev,
forward + turn + right, vex::velocityUnits::pct);
RightMotor2.spin(vex::directionType::rev,
forward + turn - right, vex::velocityUnits::pct);
}
 
else if (Controller1.ButtonB.pressing()) {
 
LeftMotor.spin(vex::directionType::fwd,
200, vex::velocityUnits::pct);
LeftMotor2.spin(vex::directionType::rev,
200, vex::velocityUnits::pct);
RightMotor.spin(vex::directionType::rev,
200, vex::velocityUnits::pct);
RightMotor2.spin(vex::directionType::fwd,
200, vex::velocityUnits::pct);
}
else if(Controller1.ButtonA.pressing()){
 
LeftMotor.spin(vex::directionType::rev,
200, vex::velocityUnits::pct);
LeftMotor2.spin(vex::directionType::fwd,
200, vex::velocityUnits::pct);
RightMotor.spin(vex::directionType::fwd,
200, vex::velocityUnits::pct);
RightMotor2.spin(vex::directionType::rev,
200, vex::velocityUnits::pct);
}
 
else{
LeftMotor.spin(vex::directionType::rev,
0, vex::velocityUnits::pct);
LeftMotor2.spin(vex::directionType::rev,
0, vex::velocityUnits::pct);
RightMotor.spin(vex::directionType::rev,
0, vex::velocityUnits::pct);
RightMotor2.spin(vex::directionType::rev,
0, vex::velocityUnits::pct);
}
 
}
//-----------------------------------------------------------------------------
void rotateDistance(int &distance, int newDistance){
 distance = newDistance;
 distance = distance/12;
}

void setVeloBaby(int veloBaby){
 LeftMotor.setVelocity(veloBaby, percentUnits::pct);
 LeftMotor2.setVelocity(veloBaby, percentUnits::pct);
 RightMotor.setVelocity(veloBaby, percentUnits::pct);
 RightMotor2.setVelocity(veloBaby, percentUnits::pct);
}


void move(directionType lm, directionType lm2, directionType rm, directionType rm2){
         while(LeftMotor.rotation(vex::rotationUnits::deg) < 1800){
         LeftMotor.spin(lm);
         LeftMotor2.spin(lm2);
         RightMotor.spin(rm);
         RightMotor2.spin(rm2);
         
}


 


}

 
 //--------------------------------------
void pre_auton(void){}
void autorun(){
//rotateDistance(distance,12);
//setVeloBaby(100);
//move(fwd, directionType::rev, fwd, directionType::rev);

}
//-------------------------------------------
int main() {
Competition.autonomous( autorun );
 
pre_auton();
autorun();

   
    while(1) {
        driveExtend();
         intake();
         Tray();
         armMove();


    }
}
2

Could static be the cause of the problems? I seem to remember that was a problem last year.

3

It’s not possible for code to directly cause hardware failures* and nothing I see in you code is out of the ordinary. V5 ports can become damaged, and motors are know to fail in certain ways, but neither of these issue is directly related to anything the code may be doing. Is the brain and everything fully updated to vexos 1.0.9 ?

*obviously if you really try and perhaps have motors etc. connected physically that they can cause damage to themselves or the brain. You could argue that code can cause damage in this situation. What I mean is that there’s no chance of sending invalid voltages etc. to the hardware.

12 Likes
4

It could be a few things, static but im not sure about that one. I remember someone mentioned spreading out the loads on cortex ports so i would search that up. i would also reccomend against the 2 2 wire motor ports as those break the most.

1 Like
5

you are probably blowing ports on your brain. static is the likely (not definite, but its the best theory we have) cause of ports blowing. this is unrelated to your code.
does you field have a lot of static issues? if you shuffle around on it and touch the perimeter do you get shocked? if so, you probably have an esd issue. try using antistatic spray and/or using a humidifier in the room with your field. also make sure all parts of your robot are grounded together, that is, electricity could flow from your base to anywhere on your bot. that way, if you build up static, it will just flow into your base harmlessly through metal, rather than through your cables and ports (I think, I’m no electricity expert)

5 Likes
6

I would like to give a helpful reminder to say that the V5 microcontroller is called a ‘Robot Brain’, while the Cortex microcontroller is called a ‘Cortex’. Until we saw your code it was hard to tell which system you were reffering to, because you said ‘Cortex’ yet posted this in a V5 channel. Trying to prevent any misunderstandings like have occured occurred here before.

9 Likes
7

If I had to guess based on the prior statistic, I would say that most likely cause is the static electricity damaging V5 electronic components, like @ToshBoss and @Xenon27 had suggested. If you search the forum for ports esd or ports static, there will be plenty of hits.

If your robot has specific configuration with electrically isolated subsystem(s) that could easily accumulate electric charge and the fields in your area are not regularly treated with an anti-static spray, that could explain two damaged V5 brains in a row.

Except for the ESD vulnerability causing blown ports and WSODs and an unfortunate placement of the thermal sensor inside V5 motors, I don’t think we ever heard of any other systemic problems with V5 hardware before. It seems pretty robust if you protect it from the static during the winter months.

I agree with @jpearman that it is next to impossible to damage hardware with the ordinary code on V5. Built-in default PID values for the motors had been chosen conservatively and had not been exposed to the public. Also, eFuse chips protect each port and battery from over-current.

Your code doesn’t look like you are overriding built-in PID values for the motors or intentionally trying to run them in the worst possible thermal regime.

And for those curious about the topic of software damaging hardware beyond vex, lots of interesting reading can be found here: malware physical damage - Google Search

9 Likes
8

My team had a very bad problem with static, and it caused some of ports to blow out. But then I read somewhere here that I should ground my brain by screwing in screws into the brass threads on the bottom of the brain and make those screws touch some metal on the robot. I have no clue if this worked, but ever since doing that, I never blew out any more ports.

2 Likes
9

Thank You for all of the responses, we will try using anti-static spray as well as grounding the brain, and get back with the results.

10

It is good that you no longer experience port burnouts, but brass mounting holes on the bottom of V5 brain are not electrically connected to the brain’s pcb ground.

You can do other things to minimize ESD exposure as long as they are legal per VRC rules: V5 port burnout - #35 by technik3k

5 Likes
11

Other potential issues are the pins in the ports can get bent and not make proper contact. This can appear like a “blown” port. It takes a magnifying glass, a tiny tool and great nerves to observe and correct the problem. Also, if you are making custom length cables, get a cable tester to make sure that you have crimped the cable properly and the cable works as it should. As improperly made cables would be a problem. Otherwise, the static issues that others have mentioned are things to watch for.

3 Likes
12

I personaly think it has something to do with your code

from what I have read everyone thinks it has something to do with the static problem. I think it has something to do with your code/controler.
I read your original post and you didnt mention ever changeing the controler.

another thing that makes me thing it isnt related to the static is the whole fact that you had to remove power to the robot to stop the motor. if the robot is moveing after the match is concluded then the static shouldnt be a problem.

a few questons though.
first, did you change the controler?
did you get shocked by the robot at any time?
did you smell anything comeing off of the brain?
did you look at the motors electronics?
have you run the V5 battery cheaker code?

if anything new happens please tell us on the forums.

14

No we did not change the controller
Yes, quite often when we first picked it up to work on it
No we haven’t smelled anything off the brain
Yes, we checked the motors and they seemed perfectly fine from what we could tell
No, admittedly have not heard of v5 battery checker code

Update will come later tonight on how it worked based off the anti-static spray (we have matches tonight).

1 Like
15

Possible over voltage with the brain? Not sure if program that’s the cause. But overuse or ramping motors constantly can cause issues with the voltage. You can check the power draw of the motor on the cortex. Might be a cause, had that issue a lot at my school.

16

The problem is static build up. Short answer: Make sure to get rid of it and not let it build up or it can easy blow ports. Very much this year since most bots make cubes ride up a line made of metal and you could even put plates that build it up a lot.

1 Like
17

My team had three blown ports during the same practice session. I am pretty sure the issue is ESD (electro-static discharge). We were able to develop a solution that seems to have solved the problem.

All three of our blown ports were connected to a motor on the end of a lift. If you look closely at the standard VEX bearings, you will notice that a properly done joint has plastic between the two pieces of metal. This means that every joint provides electrical isolation.

There may be 4 joints in a row between the brain on your drive base and the motor at the top of your DR4B lift. This means that if you shock the top of your lift, the static electricity can jump through the motor cable to the brain more easily than through the structure.

The solution to this is to electrically bond the structure together.

Unfortunately, I am not aware of any VEX-legal electrical jumpers. You can, however take advantage of
<R7>:

Certain non-VEX EDR components are allowed. Robots are allowed the following additional
“non-VEX” components:
f. Commercially available items used solely for bundling or wrapping of 2-wire, 3-wire, 4-wire, or
V5 Smart Cables, and pneumatic tubing are allowed. These items must solely be used for the
purposes of cable protection, organization, or management. This includes but is not limited to
electrical tape, cable carrier, cable track, etc. It is up to inspectors to determine whether a component is serving a function beyond protecting and managing cables.

What you are looking for is an electrically conductive cable management material. There are a number of options:

You can make sure it is zip-tied firmly to the metal at the motor end and provide a continuous run down the cable to the base. Zip tie it firmly to the metal near the brain. You may want to also use electrical tape to cover up any sharp wire ends before you finish.

The key, from a rule standpoint is that the braid / sleeve is covering and managing your cables, as well as protecting them from static discharge. This is within the spirit and the text of <R7> f.

In our case, this seems to have completely resolved the issue.

I wish VEX would come out with jumper wires with ring terminals on each end. These could be simply screwed to the structure on both sides of a joint and would do the job even better than the wire wrap solution.

Best of luck!
Wayne

3 Likes
18

Hmm, not sure I agree:

If a product is being used to both wrap/manage cables, and connect cables electrically to robot structure, then I don’t see how that product is being used “solely…for the purposes or cable protection, organization, or management”. Absent any further guidance (such as a Q&A thread), I would probably rule something like this illegal at inspection.

1 Like
19

The product is NOT being used to connect the cables electrically to the robot structure. The product is being used to provide an alternate electrical pathway to PROTECT the cables from static discharge.

Remember, the rule is for the purpose of cable PROTECTION, organization or management.

The only reason the electrically conductive covering is relevant is because the V5 hardware is vulnerable to ESD damage carried over the smart cables. It is not providing any operational advantage of any sort.

3 Likes
20

Your interpretation of this may be overly broad - ask Q&A if you wish official answer.

The examples in the past have been about mechanical protection of cables. Also, in the past electrical modification has been prohibited. Your assertion is interesting and worthy of Q&A to clarify what protections are afforded teams in this context.

4 Likes
21

Why would GDC want to insist that using conductive wire sleeve that connects robot subsystems is an illegal electrical modification which needs to be prohibited?

Does VEX enjoy writing off monetary losses from replacing all the ESD damaged V5 Brains that are still covered under warranty?

That would make absolutely no sense.

3 Likes