Our team also lost a brain port (port 10 with a 16" cable). All we have is a simple 4WD and a shooter. The wheels are driven 1:1 by chain. The motors are standard shipped 200 rpm. We lost a port that connected one of the wheel motors. While the shooter uses a “rotate to” command which always ends in a HOLD (still struggling to change that), we let the wheels COAST, never used HOLD on those (wanted to for the platform park, but if that breaks ports, will not). We never stalled these motors (chain snaps first anyway if a wheel can’t spin, we need to address that) and we did not notice any overheating or any other issue with the motor itself. The cables were not secured in any way, just plugged normally and dangling around. We did notice a significant wiggle and the red led on all the motors does flicker as we jiggle the wire. The cable on the broken port was made by us, with the VEX kit (official cable, crimper and 4P4C jacks). We used an RJ11 tester (yes I know these are not RJ11, the Vex cable fits in the “telephone” port of the tester) and cables showed continuity on all 4 wires with no shorts. We only drove the bot a few times, for 5-10 minutes max. until we noticed the motor did not spin. Wiggled the cable and motor started to spin again. Another time the motor’s connection led did not glow red at all. After a few disconnects/reconnects the light turned red and the motor worked for a while. Other times, the red led on the motor turned solid red then started flashing rapidly after a few seconds. Since then we have noticed the rapid flashing quite often, not sure what that means, can’t find any docs on that. Hit the forums and noticed people complaining about how lose the connector is. Bought new connectors from Amazon and re-built the cables. Same symptoms. A few times none of our motors responded. Of course our first reaction was something bad in the program or connection with the controller, but then unplugging and re-plugging motors would fix the issue. Same symptoms on fully charged and one-green-led-left battery. In the end we moved the motor to a different port and everything went back to normal. For now. We hope. We only have one brain (just realized how that sounds) so now we are scared to drive this thing, hope it can make it to competition. Sorry we could not find a pattern or a cause or a helpful fix, just wanted to report another “broken” port story.
Our team had problems as well. I believe that we are one of the the teams that the KMonkeys talked about above. At that competition we had 2 ports dead and another just died on us. I’m afraid that we will run out of good ports before the season is over with. I’ll need to get a replacement, but cannot afford the turnaround time. The only thing thing that I can think of is that they all may have died on ports that may have required high torque at one point or another. Maybe its a high current situation? We have also noticed that the ports do not seat well in the brain. I do not know if there is any correlation but when we wiggle the wires in the brain (using both vex premade and our in house cables made with vex equipment), the connection drops and reconnects. Maybe there is something with that?
Programming wise, we were not using any “hold” function. In fact our first port died before even programming the brain, so I do not believe it has anything to do with programming.
We have had a port fail that was connected to a lift and 2 ports fail connected as drive motors. We have 4 drive motors 2 on each side. I cannot pin point any exact thing that caused the problem.
Those are all very interesting data points. There could be one or many different mechanisms of V5 ports’ damage. I will outline a couple of them below, but there could be potentially more…
It is notoriously difficult to figure out conditions for ESDs or other similar damaging events and even more difficult to reproduce such conditions in the lab. They may depend on the specific robot design, parts’ off-spec parameters, field condition, humidity of the air, and other environmental variations such as dust levels, air circulation, etc…
It may require many people to conduct experiments in various conditions. The added difficulty is that I don’t think anyone would want to voluntarily conduct such experiments because of the risk of damaging expensive and hard to replace equipment.
So what could we do?
The best thing is to learn about potential mechanisms that could lead to the port’s damage, be aware of the risk factors and, if anything happens, know what system information could be relevant to record and report back here so that it could be aggregated, analysed and, hopefully, lead to either procedural workaround, or a physical add-on to the V5 system that could protect the ports.
Here is a Digi-Key article that discusses (on the example of USB) how modern electronic ICs get smaller every year and, as a result, it takes progressively less energy to damage them by an ESD (Electrostatic discharge) event:
The next two papers talk about specifics of RS-485 interface protection with high end TVS (Transient Voltage Suppression) devices:
The source of ESD could be movement with friction between any two surfaces, such as robot’s wheels and floor, two different parts on the robot, or even between a robot and dust particles suspended in the air. In order for large static charge to accumulate, the surfaces have to be either dielectric (i.e. plastic wire sleeve) or a metal parts isolated from the rest of the robot.
For example, I bet some of the robots have manipulator assemblies that are electrically isolated from the rest of the robot’s body thanks to the plastic bearings (try to measure continuity on your robot using a multimeter). In a dry environment they would be able to accumulate considerable static charge difference just by being exposed to the airflow and even without moving themselves.
When searching for sources of ESD there could be plenty of suspects, even such as friction between inner plastic components of the wire. Cables for important applications are made with metal grounded sleeves and may be sprayed with anti-static compounds.
To minimize the risk of static charge accumulation, ideally, you need to connect all metal components of your robot to the common ground (with fixed conductors or flexible wires) and/or use some sort of conductive sleeve to protect the wires. I am sure we could figure out a way to put some foil on the robot under <R7j> wire protection clause.
ESD poses a high voltage risk, resulting in high current spikes with a very short duration that still have enough energy to fry inadequately protected electronics.
In addition to ESDs, lower voltage spikes could do just as much damage if they have an energy source that could feed them longer. For example, inductive component of the motor’s coils. If you cut a circuit feeding a relatively large current to a motor running under load, it will try to maintain that current creating a voltage spike. It will take some time before electromagnetic energy stored in the coils partially converts into mechanical energy, partially charges connected filter capacitors, and dissipates into heat. Depending on the capacity of the filter caps even small motor could easily generate a 100v+ spike.
For example, if the ground wire between v5 brain and the motor becomes disconnected while motor was under load, motors’ ground terminal voltage could be pushed 100v+ in respect to the 14v power supply in either direction. If motor’s MCU was transmitting at the same time (using energy stored in its regulated Vcc capacitors) the output on the data lines in respect to V5 Brain ground could be quite damaging…
V5 system has some built in protections in its design but they are either not enough or manufacturing deviated from the intended design. This is a very real-life example of how lab-tested design could face challenges in the disparate end user environments.
As frustrating and disappointing as it is to deal with this problem that could leave you without functioning system, I think senior students should use this as the learning opportunity. Don’t just expect VEX engineers to fix this for you, take more active role to help analyse and understand the problem.
If just 5% of the students that have to deal with these port failures will go on to become electrical engineers and will remember very well to overdesign their products with 500% protection in mind, I think, this entire debacle would still be a fare price to pay.
Wow. I recorded the heat of the brain and motors after the port died. The brain was 85-89 degrees Fahrenheit . And the motors were about 79-83 degrees Fahrenheit.
80 F, that’s about the temperature in my office !
How did you measure that ?
With a inferred heat gun ,but room temperature was 75.
My point was, that doesn’t seem very warm, we start to limit motor power when internal temperature is 55C (about 130F).
That’s what the temperature was after a match that we lost 2 ports (they died) maybe 3 minutes after.
Could you share me to the pm? Kmonkeys is actually our sister team.
We are having the same problem, we have 6 ports disabled, 1 from a lift and 5 from a claw (both on hold). We believe disabled ports must be caused by long custom wires that are being bent on our dr4b just like @jpearman suggested. We gave the wires more flexibility and found that our zip ties were creating pinch points on our wires, so we also replaced those with loose zip ties.
This so far seems to be fixing the issue but we still have 6 ports disabled. How do we make these ports enabled? We have tried several motors, different code, and wires (custom and stock) and nothing seems to be enabling them. Any Ideas?
There is no way to re-enable the ports, you will need to contact vex support and arrange for an exchange.
Happening to us now, too. Also on motors farther away from the brain.
Could you give more information? Was the connection to the brain and motor secured? Did use any adhesive foam to secure the connectors and or anything to secure the wire ?
Wires were secured along the whole path with zip ties. Slack given at joints in the rd4b to try to prevent stretching. Happened at two different ports for two different motors (one of the lift motors and also our manipulator motor at the top of the lift).
Lights started flashing at motor and port no longer functioned. Motor works fine on other port, and other motor does not work at faulty port. Tried power cycling. Will check at our next practice to see if it still is a problem.
Teams who reported port issues all appear to be experienced and don’t seem to be making a rookie mistake all at once. They report using V5 components within its design parameters as would be expected by any reasonable user (and presumably tested during the beta phase).
So how come all over sudden we have multiple reported port failures and, probably, even more unreported ones? There could be several possibilities:
Beta kits and production systems may have some hardware differences. If there were any design changes - it would be great if we knew what was changed. If it may be different part sourcing or manufacturing process changes - it will be tougher to spot.
Some important functionality (like hold mode) may have never been tested during beta and/or under loads normally experienced by competition robots at actual match pace. It would be helpful if we were filled in with more details regarding beta test coverage.
Environments tested during the beta test phase may not have included something like a large air heated school gym in the winter that is typical for competitions in many areas. With each reported port failure case we need to collect environmental information about room size, if heating or cooling was active at a time, perceived air humidity, temperature, dust levels, field condition, anecdotal evidence of people hit by ESD, etc… If students report building robot at home or classroom for weeks and then multiple ports suddenly die during the competition - we need to document both environments.
The danger here is that if failures are indeed environment related and more competitions are coming up in a few weeks from now - then we could see very large number of damaged units. Remember, those teams didn’t do anything obviously wrong. It cold save a lot of headaches and money to be more open and proactive now in diagnosing possible causes, than risk waiting few more weeks when the season kicks in.
- VEX engineers must be looking at the serial numbers to see if failed v5 brains or motors came from common manufacturing batches as multiple failures seem to cluster together. But what about specific robot designs? Even though the teams who was unlucky to lose ports didn’t do any rookie mistakes, the robot designs that may have been perfectly good for Cortex hardware may share some feature that puts V5 system at greater risk in the specific competition environments.
VEX may want to collect not only failed v5 brains and motors, but also wires or even batteries in order to have a better chance to reproduce the problem. You also need to make sure to include detailed pictures of the robots that experienced the issues and description of the environment where it happen. Furthermore, you would want to include description of the build environment where port failure did not happen and pictures and serial numbers of the similarly built robots at the same competitions that did not experience the issues.
The problem may endup to be something simple to diagnose (like loose connections due to oversized ports on the brain because of the bad manufacturing batch) or it could take months and thousands of failed ports before anything becomes clear. It is better to be proactive now than sorry and disappointed later. For example, after all these years there was still no consistent explanation for IME failures on the Cortex. They worked great for some teams and kept resetting for others. I don’t remember anyone being able to definitively show the problem appear or disappear in an experiment. If IME would frequently reset the best answer was “it is static… just use quad encoders…”
In fact, if it proves elusive to reproduce port failures in the VEX lab, it may make sense to partner with some teams, that already experienced multiple failures, to conduct some tests on their existing robots. They apparently have something on the robot, in the code, or within their environment that causes multiple ports to fail.
Or it could be some subtle differences in the build techniques that makes the difference, like securing wires to the motor and brain ends but leaving them loose otherwise. The more information (including pictures) teams could collect and post the better chance there is to figure out what might be causing this issue.
The possible fixes may range from replacing a few dozen v5 brains from the bad batch, or 3d-printing retaining clips for the wires, or wrapping wires with few inches of electrically grounded copper foil, or … all the way to the off-chance that input/output protection system is inadequate and an add-on port adapter with TVS array needs to be made, or the V5 design needs another revision with more protection and all existing V5 brains will need to be eventually replaced as they suffer port failures during upcoming winter. Once again, sharing more details may get some insightful tips from other students or mentors who do this type of debugging for living.
Let me finish with an anecdote. Back when I was in college, one of the professors in the EE department made a batch of some experimental industrial control equipment and was testing it before sending to the field. I think they were zapping every input and output pin with 4kv discharge as a way to test the protection. One of the units failed the test. Apparently a pair of the zener diodes connected at the input was either defective or not soldered correctly and test fried not only a pair of inverter gates serving as a buffer, but also an expensive processor sitting behind them.
There was a tight deadline to ship the units, but they decided to add more protection. So they asked for volunteers among students who knew how to solder (i was one of them). We would open each unit, visually inspect PCBs, retouch solder on the zenner diodes, then add another pair of zeners at the connection point between the buffer gates and the processor. It was through hole PCBs (not surface mounts) so we could still patch them manually like that.
Normal unit functionality tests would not tell you if protection system is functioning correctly (i.e. all solder joints and parts are good). Consumer grade electronics may or may not have even one of the thousand units (from a batch) tested with ESD. Only low volume high-end or specialty equipment may get ESD testing of each unit either manually or with custom built test stand.
We don’t know what V5 brains were designed to withstand, what was beta phase test coverage, how they are QA tested post-production, … and only slight hints at what is causing port damage in the field… Information sharing is essential to solve this puzzle quickly.
Has anyone who has had a brain with the dead ports issues get a replacement yet? If so, did the replacement brain have any ports die?
VEX is offering to replace our brain (of course they would, but not sure on time frame). The current one has 3 dead ports. We are only using 10 or maybe 11 ports. If they don’t know what the problem is and fixed it, do I really want the replacement now?
1 died on the wrist (see nov 5th post).
1 died on the puncher, it had been working for a few weeks or so.
1 died on a drive motor, right before/after inspection at a tournament. It had been working the longest about 4 weeks.
@jpearman @VEX Support It’s been several weeks since this problem has been discovered. Are there any solutions yet? We are also having broken ports ( I’m assuming it is the port after reading through this entire thread) and I posted information about our problem at https://vexforum.com/t/v5-motors-randomly-disconnecting-from-v5-brain/50569/1 If the problem continues to happen, we may end up needing to get a new V5 Brain simply because we won’t even have enough ports to run all 8 motors and a radio. We would really appreciate some urgent assistance.
We suffered from this today on one of our 3 robots. The claw motor on a VEX 1.5m cable developed the light flicker and stopped working. We did get it working via other port. Later some drive motors went. In all 3 motors stopped on the robot. Didn’t realise at the time this is probably a brain issue and will continue. We did have a motor stop with no light and not connect on any port yesterday in preparation.
We also had a weird issue at our event with a few different teams robots of V5 motors continuing to run after the end of a match and only stopping when the robot was switched off.
Was there a lot of static in the field when the brain’s port died?
Were you all up to date on vexos firmware ? (latest is 1.0.3, we are releasing about once per month at the moment)